Segunda parte - Requisitos

jalcaldea commented 10 years ago

Como bien dije en https://github.com/KekoAlk/Practica_DAS/issues/13 abro este Issue, para poder comentar sobre los requisitos y las funcionalidades de nuestro framework.

Posteriormente se podría habilitar una página en la wiki para que quedase constante, ¿Que os parece si ponemos de fecha hasta el lunes para tener los requisitos ?

baos99 commented 10 years ago

A mi lo del lunes me parece bien!

Es decir, en la wiki vamos a ir poniendo los requisitos que nos parecen importantes, y entre todos vamos hablando y editandolos hasta que los completemos, ¿verdad?

jalcaldea commented 10 years ago

Obviamente a mi me parece bien tenerlo para el lunes =D

Yo propongo que el framework sea una librería para C++ y a parte de las funcionalidades básicas de in , out y rd buscar alguna que nos guste, creo que sería interesante pensar en aplicaciones que usasen esa librería para poder ver que funcionalidades requerirían de ésta para de ahí poder obtener la funcionalidad. Un ejemplo podría ser el propio GitHub, una aplicación estilo dropbox pero con ejercicios grupales, ...

Y sí, la idea sería esa, poder ir escribiendo los requisitos en la wiki y por aquí comentándolos.

cavasanchez commented 10 years ago

A mi me parece bien lo que dice @kekoAlk y aprovechar para hablar de algo parecido al Git que nos viene a huevo... lo del código no recuerdo si dijo que era opcional, pero si no vamos muy mal de tiempo yo metería aunque fuera un poco. Y yo lo haría en Java o C++, alguno OO.

jalcaldea commented 10 years ago

Visto lo visto, con la poca participación, para el lunes, mañana, no tenemos ni de coña hecho una lista de requisitos. Aun así, que por mi parte no quede.

Cómo bien dije antes, creo que una buena manera de pensar en la funcionalidad que tenga nuestra librería es a través de posibles aplicaciones y a mi se me han ocurrido:

Una aplicación estilo github.
Una de resolución de ejercicios grupales: En la que interactúen tanto el profesor como los alumnos, el profesor podrá subir ejercicios y hacer correciones graves, mientras que los alumnos solo podrían resolver los ejercicios.

De esta última obtendríamos un par de cosillas:

La pizarra debe basarse en una BD, para poder gestionar los distintos usuarios, ejercicios, cursos, etc.
Debe haber distintos tipos de personas que interactúen, distintos tipos de agentes, agentes de distintos niveles.
Quizás la posibilidad de subir la solución por parte del profesor y que la pizarra busque automáticamente los errores.

Obviamente hay que sumarle los requisitos obvios:

La pizarra y los agentes siguen un modelo cliente-servidor.
Los agentes pueden leer, escribir y modificar la pizarra.

PD: Espero haberos dado alguna idea. =) PD2: Esta noche voy a abrir una página en la wiki donde escribir los requisitos que vayamos sacando

AdrianGJ commented 10 years ago

La cuestión es que estamos dando un poco palos de ciego. Al ser tantos y no tener definido la estructura de la práctica con detalle se hacen cosas y se espera que estén bien. Después otro lo cambia. Al final estamos desperdiciando mucho trabajo. Sin contar con las cosas que hemos hecho 2 personas al mismo tiempo. Debemos organizarnos un poco, dividirnos el trabajo y establecer desde el principio la estructura de forma detallada que vamos a seguir en la práctica.

Sobre los requisitos la segunda opción, la de los ejercicios grupales, me parece más acertada, el problema es cómo organizar los requisitos. ¿Un listado sin más? Pueden ser muchísimos si queremos darle profundidad y sería difícil de ver bien. Podemos dividirlos por apartados. Es decir, relacionados con la estructura interna de la pizarra, relacionados con la interacción pizarra-agente, ... También podemos desempolvar los apuntes de AIR y dividir funcionales/no funcionales.

cavasanchez commented 10 years ago

Yo también creo que si nos repartimos bien la tarea, y cada uno tiene muy clarito lo que tiene que hacer, seremos infinitamente más eficiente. Yo haría un listado de las cosas que faltan y nos lo repartimos según lo que a cada uno se le de mejor o le guste más. El problema en mi opinión es que no tenemos claro al 100% como será la aplicación al final...Lo de la resolución de ejercicios grupales yo lo veo mejor. Para los requisitos estoy un poco gamba, pero los veo más intuitivos dividirlos como dice @AdrianGJ ,y dividirlos en estructura interna y pizarra-agente Pero sobretodo que hoy (o muy tarde mañana) quede todo esto ya decidido para que podamos repartirnos el trabajo

AdrianGJ commented 10 years ago

He creado la página de la wiki para meter los requisitos que se os ocurran y he metido unos cuantos (https://github.com/KekoAlk/Practica_DAS/wiki/Lista-de-requisitos). Son provisionales, así que meter lo que querais por descabellado que sea, jeje. Cuando tengamos clara la organización que vamos a hacer de estos los ordenamos.

jalcaldea commented 10 years ago

Pero es que yo sí tengo claro lo que hay que hacer, una captura de requisitos como la de AIR (en funcionales y no funcionales, y cada uno en sus respectivos) y después un diseño de esos requisitos, la parte especial está en que en el desiseño no se hace al tuntún(cómo hacíamos el año pasado), se hace siguiendo una arquitectura y definiendo una propia.

En cuanto a lo de la estructura, cuando cree el brach que tengo pensado crear, dejo toda la estructura de la memoria para haber si así os liáis menos va?

AdrianGJ commented 10 years ago

El problema no es que nos liemos, el problema radica en el concepto que tiene cada uno de la práctica terminada que, como se puede comprobar, choca bastante de los unos a los otros. A mi parecer deberíamos asignar lo que queda a cada persona en vez de seguir con el efecto "el que lo coja que lo haga". Es solo mi opinión, pero creo que con esa organización rendiríamos a un nivel mucho mayor.

jalcaldea commented 10 years ago

Pero asi no va a ningún lado @AdrianGJ porque:

Lo que queda por hacer es un proceso lineal, uno no puede empezar hasta que el otro haya acabado.
Como bien dices, no todos hemos entendido la páctica igual y si lo que para mi es rojo para ti es rosa al juntarlo vamos a haber puesto cosas sin sentido.
Si hacemos por aqui los requisitos, cada uno luego puede hacer sus diseños y una vez nos pogamos de acuerdo, sólo va a hacer falta traspasarlos a la memoria, lo que no tiene sentido es ponerse a escribir sin plantearse cómo se ha de organizar, o sin tener claro que es lo que se pide porque acaban apareciendo cosas cómo en clase, que no tienen nada o muy poco que ver con el tema.

AdrianGJ commented 10 years ago

Con el 3er punto has dado en el clavo con lo que estoy diciendo. Lo hagamos como lo hagamos hay que organizarse antes. La división a la que me refería era una posible forma, también podemos organizarlo de forma que lo que pongamos lo hayamos puesto en común todos. La cuestión es que si no lo ordenamos acabamos con cosas del estilo de -La parte X esta libre y alguien la hace. -Otro rehace la parte X porque no le parece bien como está. -Otro no sabe con qué ponerse ya que hasta ese momento estaba planteándose cómo hacer la parte X.

No se si me explico

jalcaldea commented 10 years ago

Pero @AdrianGJ esto que me dices, es justo lo que os intenté explicar en #13 y me dijissteis que así estaba bien, cierto es que el problema fue mio, pues pensé que tenías/iais pensado una manera de organizarlo, y por lo que veo en vuestros mensajes NO teníais ni idea de dónde meter qué.

Mírate bien #13 , especialmente el primer mensaje y dime si lo que puse no se trata de una manera de organizar las cosas?

PD: de todas formas, de aquí a un rato voy ha coger directamente la parte 2 y la voy a reestructurar en un nuevo branch, para que tan solo tengáis que "rellenar los apartados" en vista de que sino no sabéis qué hacer y aparece lo que yo ya he denominado "la figura del supervisor"

AdrianGJ commented 10 years ago

No me has entendido. La estructuración que tú tenias pensada para la práctica es lo que se refleja en #13, pero yo no hablo de la estructura de la práctica, sino de la organización entre nosotros, el ¿quién hace qué?. Los post-its que cada uno tiene que hacer.

PD: La organización de #13 me parece correcta, no me he metido con ella. PD2: No seas tan borde, lo de la parte X es solo una exageración. No te estoy atacando ni nada, no te lo tomes mal, es simple y llanamente una opinión.

jalcaldea commented 10 years ago

Para nada me lo he tomado a mal, pero es que sigues diciendo lo mismo una y otra vez... ¿Entiendes que es lo que hay que hacer en la práctica? Porque a lo mejor ese es el problema.

La asignatura de DAS es la continuación de AIR, la primera se centra en la captura y análisis de requisitos, la segunda se centra en la fase de diseño. Hay que hacer un "ejercicio" en el que ya se nos están dando la mayoría de requisitos (en el enunciado) y se nos da libertad de añadir más o modificar alguno siempre y cuando se justifique; y la parte de la practica en sí es el diseño. Todo ello es un proceso lineal, hasta que no se acaben y tengamos claros los requisitos no podemos hacer el diseño. No hay post-it, no hay tareas, hay que llegar a un acuerdo de qué requisitos tiene nuestra libreria.

Más adelante, ya con los requisitos, hay que hacer el diseño de la misma manera, hay que llegar a un acuerdo en algunas cosas, sólo que en ese caso cómo hay variedad de diagramas cada uno podrá hacer uno y luego compararlos hasta que lleguemos a un acuerdo, una vez hecho esto ya esta acabada.

En ese punto si quieres nos repartimos quien escribe qué en la memoria, pero de momento no hay nada que escribir que es lo que intento decir todo el rato, no hay nada que repartir, entre TODOS tenemos que concretar tanto requisitos como diseño.

AdrianGJ commented 10 years ago

Bueno, mejor vamos a dejarlo, porque es cierto que nos estamos repitiendo xD. Si entiendo la práctica, la idea solo era buscar una organizacion mejor, pero vamos, podemos seguir como siempre, aun hay tiempo para acabarla y que quede bien hecha.

jalcaldea commented 10 years ago

Y otra vez... Ahora no hay que escribir nada, hace falta que TODOS se metan por aquí y les de por decir aunque sea un "OK, me parecen bien esos requisitos" "Genial no cambiaría nada" y así poder avanzar.

Creo que el hacerlo mediante Git os esta liando, si esta práctica la hubiéramos hecho quedando, ahora mismo sería necesario quedar para hacer una lista de requisitos y pensar los UMLs y al acabar la "reunión" diríamos "Yo me encargo de pasar este UML", "Yo paso la lista de requisitos" ,etc

Pero parece que lo único que hay que hacer es escribir en la memoria, y no es así, acabo de ver el último commit de @cavasanchez (https://github.com/KekoAlk/Practica_DAS/commit/03018115fb6ef98711fe30fafb1a9108b8a5241c) y me ha sentado como una patada el los ...... porque esta explícitamente puesto ahora mismo en el prefacio que hay que poner algo pareció a lo que ha puesto, pero en el prefacio. En su día me moleste de organizarlo un poco, nadie puso pegas, pero es que ahora dudo de si lo leísteis, ademas puesto en ROJO para destacar que falta por hacerse.

Si lo que te refieres con "el que lo coja que lo haga" te refieres a "hay que hacer esto y yo lo estoy haciendo, nadie lo puede segur haciendo" estas muy equivocado, precisamente la gracia de esto radica en que dos personas a la vez pueden hacer lo mismo y luego se escoge la mejor, o un híbrido.

AdrianGJ commented 10 years ago

Pero si ahora no he dicho nada... Ya he dicho que vale, que seguimos tu método. Relajemonos que si no nada tiene sentido. Lo de @cavasanchez no hay problema, lo movemos al prefacio y ya está, no es nada grave. Yo también lo leí y no me acordaba ya. Preocupemonos por lo importante, por cosas como esta no tiene sentido enfadarse.

jalcaldea commented 10 years ago

Bueno, tienes razón, no hay ningún problema... pero no estoy enfadado, estoy lo de después y "el supervisor" sigue entre nosotros, su último ataque no ha sido hace mucho.

Con los requisitos que hay ya, los podríamos organizar en funcionales y no funcionales. Y lo que hay que hacer es extrapolarlos, ahora están puesto como para una aplicación y hay que ponerlos como se fuera una librería, que básicamente lo que hay que hacer es cambiar profesor y alumnos por agentes, y algún requisito más específico formularlo para que se trate de la librería.

cavasanchez commented 10 years ago

@KekoAlk no lo he metido dentro del propio prefacio porque ahí pone las cosas que faltan por meterle, y no voy a quitar esas frases en rojo hasta que TODO o que pone en ellas esté acabado, porque si no nos dejaremos algo en el tintero. Una vez todo hecho, se mete en el prefacio Me explico, cuando todo lo que pone en el prefacio esté hecho, se pondrá ahí. Hasta entonces lo meto aparte para que todo el mundo vea las frases en rojo. Por cierto estoy haciendo lo de "Explicar los objetivos y motivaciones de la practica" y "Recalcar que hay dos partes y en que se centra cada una". Esta tarde lo subiré (y no al prefacio, que aun quedarán dos cosas por hacer)

baos99 commented 10 years ago

Como dice @KekoAlk con los requisitos que hay ya valdría, pero hay que cambiar lo que has dicho ya que estan hechos para la aplicación de ejercicios y no para la librería. Por otra parte, son todos requisitos funcionales, ya que los no funcionales se refieren al lenguaje de programación (c++), fiabilidad, tiempos de respuesta, estándares, o requisitos éticos, lesgislativo, etc. Así que, tenemos que añadir requisitos no funcionales, pero a parte de hacerlo en c++ no se me ocurren RNF para una librería..

jalcaldea commented 10 years ago

@cavasanchez he creado un brach "memoria2" sincronizalo y compila la práctica... luego me comentas si lo podías haber hecho así o no.

Al parecer @AdrianGJ y yo hemos editado la wiki a la vez, chicos no lo intentéis en casa, menos mal que me ha salido un mensaje bien grade diciendo que alguien más la estaba editando.

@AdrianGJ Me acaba de aparecer tu mensaje, eso es justo lo que estaba haciendo yo =D Ahora hay que separar en funcionales y no funconales esos, y como bien dices, al ya tener una base, ya podemos añadir más!

AdrianGJ commented 10 years ago

A mi no me ha aparecido ningún mensaje, así que he seguido a la locura, jaja. Ahora sería poner las reformuladas en los apartados de funcionales/no funcionales. ¿Lo hago yo?, pregunto para que no pase lo mismo otra vez xD.

baos99 commented 10 years ago

Yo vuelvo a repetir lo mismo, todos los que has puesto son requisitos funcionales.. Y parecia que lo estaba haciendo @KekoAlk así que no se si ponerme a ello o no, ya que yo tmbn estaba editando y a nadie le ha salido que lo estaba haciendo y me he enterado por aquí que lo estabais haciendo los 2 así que he cerrado por si acaso jaja

jalcaldea commented 10 years ago

Sí, hazlo tú =D

PD: El mensaje era chulo, en ROJO y bien grande. Me ha servido para copiar antes de descartar cambios xD

jalcaldea commented 10 years ago

Lista de requisitosVale, no eramos 2 editando, eramos 3 jajajaja

Pues ahora se encarga @AdrianGJ de organizar esos y ya vemos si vamos metiendo más, no?

AdrianGJ commented 10 years ago

@baos99 , no son todos funcionales. Los de contraseñas y tal son opciones de seguridad, por lo tanto son no funcionales, los de bloquear contenido igual.

baos99 commented 10 years ago

@AdrianGJ yo creo que si son funcionales, ya que añaden funcionalidad... De seguridad serían encriptar los datos y cosas asi (yo creo), pero bueno como digais.

jalcaldea commented 10 years ago

Lista de requisitos @baos99 Precisamente hay un tipo de RNF que es seguridad xD

PD: Voy a poner todo el rato Lista de requisitos para que tengamos más a mano la wiki.

AdrianGJ commented 10 years ago

Segun los apuntes de AIR y cito textualmente:

Identificar características no funcionales del sistema Restricciones de la plataforma Seguridad Rendimiento Tiempos de acceso…

Seguridad y restricciones los pone como no funcionales.

baos99 commented 10 years ago

Ya ya @KekoAlk, pero creo tal como esta redactado es un requisito funcional: "La pizarra debe almacenar una contraseña y un identificador único para cada usuario y no permitir que otros accedan." Para mi, no funcional sería, por ejemplo: "Los datos manejados por el sistema (o la pizarra) están protegidos de acceso no autorizado y divulgación"

Bueno da igual, me he liado, porque yo lo hacia así en AIR, pero supongo que es lo mismo

jalcaldea commented 10 years ago

Lista de requisitos @baos99 No te fijes en los requisitos de arriba, fíjate en los de abajo que son los que nos valen.

Es lo mismo dicho, solo que con otras palabras, "datos protegidos de acceso" y "contraseña e identificador único" viene a ser la misma idea, un user y un pass

AdrianGJ commented 10 years ago

Por cierto, para hacerlo más genérico yo cambiaría en los requisitos la palabra "problema" por ... no se, ¿elemento? o algo del estilo.

EDIT: Y ya borramos los requisitos antiguos, no los necesitamos.

jalcaldea commented 10 years ago

Lista de requisitos @AdrianGJ he puesto problema por que habría que poner el nombre del elemento básico de la arquitectura de pizarra, sinceramente no se cuál es, pero me sonaba "problema".

jalcaldea commented 10 years ago

Lista de requisitos @AdrianGJ Ya que veo que has estado mirando los apuntes de AIR, podrías copiar la clasificación de lo RF y de los RNF ??

Para refrescarlo un poco =D

AdrianGJ commented 10 years ago

Lista de requisitos

-Requisitos Funcionales: Son declaraciones de los servicios que debe proporcionar el sistema. Especifica la manera en que éste debe reaccionar a determinadas entradas. Especifica cómo debe comportarse el sistema en situaciones particulares. Pueden declarar explícitamente lo que el sistema no debe hacer.

-Requisitos No Funcionales: No se refieren a funciones específicas que proporciona el sistema. Son restricciones de los servicios o funciones ofrecidas por el sistema (fiabilidad, tiempo de respuestas, capacidad de almacenamiento, etc.). Generalmente se aplican al sistema en su totalidad. Surgen de las necesidades del usuario debido a restricciones de presupuesto, políticas de la organización, necesidad de interoperatividad, etc.

A veces, no hay una distinción clara entre requisitos funcionales y no funcionales -Expresar un requisito como funcional o no funcional depende del nivel de detalle requerido en el documento de requisitos.

AdrianGJ commented 10 years ago

Principalmente es eso lo que viene, después son ejemplos

baos99 commented 10 years ago

Yo me acuerdo.

Funcionales: (servicios que proporciona el sistema)
No funcionales: (restricciones de los servicios del sistema)
- -Del producto: (ejemplo: fiabilidad, rapidez de ejecucion).
```
1 -Fiabilidad
2 -Rendimiento
3 -Espacio
4 -Portabilidad
5 -Seguridad
```
- -Organizacionales: (Lenguajes de programacion, estandares y metodos de diseño)
- -Requisitos externos: (requisitos legislativos y éticos)
De dominio: (Eran los que provienen de la aplicacion del sistema, de estos me imagino que no hay, al ser una libreria)

jalcaldea commented 10 years ago

Lista de requisitos @AdrianGJ me referia a la clasificación... Los distintos tipos de funcionales, y los distintos tipos de no funcionales.

AdrianGJ commented 10 years ago

Ah, va un segundo

EDIT: Ya lo ha puesto @baos99 , pero de todas formas lo voy a buscar

baos99 commented 10 years ago

Lo acabo de poner yo.. Porque no me haceis caso? xD

AdrianGJ commented 10 years ago

Los no funcionales se dividen en:

Requisitos Del Producto:

Especifican el comportamiento del producto.
Ejemplos: rapidez de la ejecución, capacidad de memoria, fiabilidad, etc. Requisitos Organizacionales:
Derivan de políticas y procedimientos existentes en la organización del cliente y del desarrollador.
Ejemplos: Estándares de procesos, métodos de diseño, lenguajes de programación, métodos de entrega, etc.

Requisitos Externos:

Se derivan de factores externos al sistema y a su proceso de desarrollo.
Ejemplos: Requisitos de interoperatividad, legislativos, éticos, etc.

De los funcionales no parece haber una definición clara, al fin y al cabo son los casos de uso.

Después están los de Dominio:

Provienen del dominio de aplicación del sistema. Reflejan características y restricciones del dominio de la aplicación. * Pueden ser funcionales o no funcionales.

PD: Jajaja, si te hemos hecho caso, pero voy a buscarlo para que quede más completo

baos99 commented 10 years ago

Mi comentario mola más. Voy a pensar alguno más no funcional, porque funcionales no se me ocurren

jalcaldea commented 10 years ago

Lista de requisitos Pero antes, porqué no clasificamos los que tenemos ya ( lo no funcionales ) para intentar que nos salangan mínimo un par de cada y que quede más completo ?

baos99 commented 10 years ago

Son todos de producto, creo.

Hay que hacer el de que esta programado en c++, que sería organizacional. Y que pusiste tu "El framework debe seguir una arquitectura de pizarra" ? que también seria organizacional, ya que es un método de diseño.

jalcaldea commented 10 years ago

Lista de requisitos Pues yo diría que son de dominio, especifican hasta donde abarca la librería, le ponen límites.

EDITO: Intentad no editar los comentarios, porque es liosos, es mejor poner otro, y si lo haceis intentad que se note que lo habeis editado =D

AdrianGJ commented 10 years ago

En realidad los de dominio pueden ser no funcionales, que (supongo) a su vez podrán ser de producto Organizacionales es fácil sacar alguno, pero externos... No violamos la legalidad ni ética de ningún país no?

baos99 commented 10 years ago

@KekoAlk, entonces todos los no funcionales nos van a salir de dominio, ya que todos van a poner limites. Yo creo que podemos organizarlo en funcionales y no funcionales, sin poner los de dominio.

jalcaldea commented 10 years ago

Lista de requisitos @AdrianGJ Paises hay muchos... vete tú a saber si no violamos alguna de Corea del Norte... Tan sólo Carlos Cuesta lo sabrá!

@baos99 Por mi vale, es menos lio.. pero a la hora de escribirlo en la memoria va a quedar más cutre, y luego nos va a costar más para el diseño.

@baos99 y @AdrianGJ Ya que @jiep y @cavasanchez no han dado AIR y no tienen mucha idea... vamos a ver si los podemos acabar hoy, para que no estén ociosos xD (deberiamos subir el WIP)

Ahora podríamos pensar en más y luego si eso que sólo uno de nosotros se encargue de organizarlos y si surgen dudas se habla más tarde, os hace?

jalcaldea commented 10 years ago

@AdrianGJ te encargas de ir metiéndolos tu en la wiki ?? Lista de requisitos

Yo propongo añadir los que ya hemos dicho antes (C++ y arquitectura de pizarra), movería el de cliente-servidor a no funcional y añadiría:

La pizarra es capaz de comparar dos archivos del tipo del problema para buscar diferencias.
Se podrá configurar el estado de la pizarra (público o privado)
La pizarra permite la creación de nuevos problemas.
La pizarra permite subir manualmente una solución. (para poder ser comparada)

baos99 commented 10 years ago

@KekoAlk , Estoy de acuerdo, a ver si conseguimos sacar ya todos los requisitos y luego ya los organizamos. Creo que con sacar 2 o 3 funcionales más y un par de ellos para los que quedan de los no funcionales vale. Y si quieres meter tu alguno de dominio vale, yo es que no los entendia en su momento, y sigo sin hacerlo.

Apunte AIR: hablando de WIP, acabo de mirar los apuntes de AIR y viene lo que es una historia de usuario! jaja

@KekoAlk , los que has dicho son muy dificiles de cambiar para que sea libreria no? ya que son muy especifico para esa aplicación. Pero vamos, es que me estoy liando un poco así que, si estan bien. Ya solo faltan los externos, voy a pensar alguno que sea de no violar ética y eso pero generalizado para que este todo de acuerdo jaja

jalcaldea / Practica_DAS

Segunda parte - Requisitos #14