23 Noviembre

Borrador!! Dar buen formato.

Clase de IS del 23-nov

El proceso unificado de desarrollo

*notas de gerval para navidades…:
*invito al avezado lector a que edite estas notas; tecleo demasiado rápido como para pensar entre medias XD*

problemas tras saber qué hacemos

1. cómo hacerlo
2. cómo organizarnos

*para navidades: depende de nosotros

Lo siguiente que toca: planificación (de todo, qué va a estar para navidades)

Partiendo de que sabemos qué tiene que funcionar desde fuera:

1. Diseñar atendiendo a requisitos que ya tenemos. Una vez tenemos diseño, investigar tecnologías. Como alguna no engancha con el diseño, hay que reajustar el diseño para que funcione con las tencologías.

2. Buscamos las tecnologías primero, hacemos los prototipos tecnológicos que procedan y cuando eso esté claro hacemos un diseño que conecte requisitos con las tecnologías ("wrappers"). Es lo que interesa hacer ahora.

*No vamos a dedicar temas concretos a cómo se hacen prototipos tecnológicos, pero hay que hacerlo y tenerlo presente. Convendría que la entrega de noviembre, además del diseño bonito, incluyera los prototipos tecnológicos para que el diseño real sea un puente entre prototipos tecnológicos y el diseño; así tenemos garantía de que encajarán requisitos y tecnologías*.

Lo ideal es hacer el diseño tal que el enganche valga para varias tecnologías diversas sin cambiar todo el diseño (por si hay que cambiar unas por otras).

Dicho todo esto…

El proceso unificado de desarrollo (ahora sí xD)

No hace falta que hagamos *todo* lo que se puede hacer.

Rayas de los moeses que quedan: Inception, Elaboration, Construction, Transition. (el gráfico que *no* pienso copiar xD)

1 er mes: requisitos. A partir de cierto punto hay análisis y diseño, algo de implementación tb (prototipos tecnológicos).
Luego: "aclaremos de verdad qué hay que hacer" -> varias iteraciones a la fuerza

La parte de diseño tb va con implementación para ir aclarando tanto requisitos como diseño.

*Todo* lo que se va implementando se prueba (pero las pruebas gordas son al final, cuando todo está implementado).

Más cositas: gestión (al principio de las iteracones, y al ppio más por la puesta en marcha del entorno).

Al final: despliegue (instalación en el cliente: instalador, checks (configure), etc etc). Convendría intentar hacerlo; *ahora* hay que pensar esas cosas (y no "cuando acabemos"), tipo "tiempo que va a requerir en nuestro proyecto; qué hay que hacer que cuente como despliegue".

Metodología de desarrollo

*Todas las preguntas del examen son sobre *nuestros proyectos* (gulp)*

Conjunto de actividades necesarias para transformar requisitos en un sistema software (esquema de cómo hacer un proyecto, vaya).

Basado en componentes.

Utiliza UML.

FRASES CLAVE:

* Dirigido por casos de uso

Fragmento de funcionalidad del sistema que proporciona al usuario resultado importante (requisitos funcionales).
Todos los casos de uso constituyen el modelo de casos de uso.
*Más o menos ya hecho*

* Centrado en la arquitectura

(relación entre tecnologías, requisitos y qué va en medio -diseño-, a gran escala. Las ideas generales de cómo conectarlos).
Vista del diseño completo con las características más importantes resaltadas (no es completo, sino un resumen de eso).

1. Crear esquema de la arquitectura
2. Trabajar con cto. de casos de uso, repartido en subsistemas, clases y componentes (cómo se convierte en ello).
3.

Al madurar los casos de uso se desarrolla más la arquitectura
4. Madurar más casos de uso
5. Repetir hasta que la arquitectura sea estable (cuando añades un caso de uso la arquitectura no necesita cambios). Importante: da una frontera básica en la planificación: a partir de ahí se puede tirar código de serio. Hasta entonces habrá que tirar código pero probablemente no sean las finales.

*caso de uso: cliente servidor: el usuario que está fuera solo ve el cliente: los casos de uso son esos. Importante: que te sirvan (no tanto que sean según la definición). Criterio es: ¿Esto se puede probar solo, o no?. => haremos casos de uso del backend.

* Iterativo e incremental (pregunta de examen…).

Dividir *ahora* el trabajo en pequeños proyectos de un mes. Hay 7 miniproyectos (glubs, 1 por mes). ¿¿Qué casos de uso van a funcionar en cada uno??
Cada uno es una iteración o flujo de trabajo (recorre requisitos, implementación, prueba, etc) que lleva a un incremento (cada iteración tiene que generar algo nuevo; añadir un caso de uso que no funcionaba, una tecnología, etc). Lo que se va añadiendo tiene que eliminar un riesgo (al menos).

Iteración: esfuerzo de trabajo en un proyecto que recorre varias etapas de desarrollo (no necesariamente todas), y al final del cual se ha incrementado el material disponible sobre el sistema. => Todos los meses hay que entregar código, y cada mes tiene que haber un poquito más.
Incremento: avance significativo en el grado de especificación, diseño, implementación o prueba del sistema que tenga lugar durante una iteración.

Vida de un sistema
Serie de ciclos: nacimiento + ciclos intermedios + muerte. Hoy es raro encontrar soft sin nº de versión: cuando acabas una versión, estás acabando un ciclo intermedio (digamos).
cuando pasas entre versiones hay que comprobar cosas como que los datos se migran bien, que se mantiene funcionalidad, etc: eso es el ciclo de muerte.

Cada ciclo tiene varias fases: inicio, elaboración, construcción y transición.
Inicio: requisitos hasta que se tiene idea (bastante) clara de lo que va a hacer el sistema.
Elaboración: Análisis y diseño hasta que la arquitectura sea estable. Para llegar: decidir un día que se está en condiciones de repartir el código directamente. No es trivial (no, en serio? XD). Entre medias hay que escribir bastante código no obstante. *está hablando de clases a nivel de análisis, "que nadie descubra que le hacen falta 2 clases más". Glubs*.
Construcción: acaba cuando hay una versión completa y que funciona. Ahí *no* acaba el desarrollo.
Transición: pruebas exhaustivas, depuraerroresfest, instalar al cliente.

Para sacar la 2.0: otra vez el *mismo* ciclo.

*siendo razonables: Si sacamos un ciclo nos matamos ya XD; si sobra tiempo podemos empezar otro*. Importante es haber acabado con los finales de fase. Lo ideal sería comprobar un ciclo entero, pero se suele entregar a mitad de la elaboración (diseño solo pensado, apenas probado, etc).

* Inicio:

se especifica la visión del proyecto
Idea inicial del desarrollo está lo bastante detallado y clarito para poder ponerse a diseñar. OJO con esto…

* Elaboración:

Se definen la visión del producto y su arquitectura: Construir lo de en medio hasta que solo quede tirar código.

* Construcción:

Iteraciones incrementales.
Se lleva el software desde una base arquitectónica *ejecutable* hasta su disponibilidad. Para declarar una arquitectura estable tienes que tener *bastante* implementado. Llegas hasta la beta.

* Transición:

Das la beta a los usuarios y te enfrentas a lo que tengan que decir. *aquí deberíamos dejar bastante tiempo para hacerlo usable…*

Cada ciclo produce una versión del sistema *preparada para la entrega*.

Para la entrega de junio harán falta las versiones intermedias de cada cosa!!!

* Contenido de una entrega:

o Código fuente
o Manuales
o Otros productos asociados
o Requisitos
o Casos de uso
o Specs no funcionales
o Casos de prueba <- lo tenemos ya, más o menos
o Modelo de la arquitectura
o Modelo visual (UML)

*Obviamente esto no lo tenemos en la 1ª entrega*.
Planificación

*Esto hay que hacerlo ya*

* Cuántas iteraciones (nos lo da resuelto: al menos una al mes). Plan de fase.
* Cómo de largas. Plan de fase.
* Cómo determinar contenidos y objetivos de una iteración. Plan de iteración.
* Cómo seguir el progreso de una iteración. Plan de iteración.

Gestión de un proyecto
Asignar tareas y responsabilidades a un equipo de gente a lo largo del tiempo.
Si se lo asignamos a alguien, luego habrá pegas en el examen para quien no lo haya tocado XD.
Dos tipos de planes, de aquí a navidades.

1. Grandes rasgos (fase)
2. Varios planes detallados (iteración).

A la vuelta de navidades habrá que retocar el plan de fase respecto a lo que hayamos conseguido hacer, y hacer el plan de iteración para enero.
En el proyecto ideal el plan de fase no cambia nunca más, pero si no se retoca cada iteración. Los documentos están vivos y tienen un seguimiento.

Al final habrá que hacer una memoria de cómo ha cambiado el plan de fase: la memoria de seguimiento de planificación de proyecto.

Plan de fase
Uno por proyecto. En una página!!

* Fechas de los hitos principales

1. Objetivo del ciclo (final de la fase de inicio) <- *gervás nos "sugiere" que demos tiempo a pensar requisitos de disco y demás*
2. Arquitectura
3. Capacidad operativa inicial
4. Entrega del producto (lo que interesaría es entregar en mayo algo "pero falta terminar y estimamos que nos falta tanto", que entregar algo "está completo" y falten cosas. Lo que Gervás valora no es el producto, sino a nosotros como desarrolladores. ).

* Perfil de personal: recursos que harán falta a lo largo del tiempo: "necesitamos a alguien que sepa de…".
* Hitos secundarios: final de cada iteración, y objetivo principal si se conoce.

Características:
Es pregunta de examen, así que tiene que dar tiempo en 15 mins.
Se actualiza tanto como sea necesario
Se refiere a la documentación de proyecto para definir alcance (no repetir nada que ya esté escrito!!).

Plan de iteración
Consumiendo iteraciones del plan de fase.
Uno solo por iteración.
Un proyecto suele tener dos planes activos a la vez.

1. Actual (seguimiento del trabajo de la iteración)
2. Siguiente (se genera hacia el final de la actual y está disponible al terminarla).

Características:
*hay herramientas de planificación pero no nos resultarán demasiado útiles por nuestras características; Microsoft Proyect (antes muerto… que sencillo XD).
Lo más razonable es decir "qué tiene que tener hecho quién, al final de la semana".

* Se genera con herramientas tradicionales de planificación (definir tareas y asignar a equipos e individuos).
* Contiene fechas importantes: construcciones ppales (cuándo tiene que haber algo hecho; probablemente será más a la vuelta. Habrá días de labo dedicados a probar las aplicaciones "estén como estén".). Pueden ser a mitad de la iteración (yikes!)
* Ventana que se desplaza por el plan de fase según dónde estemos.

- Construir un plan de fase
Cuánto esfuerzo supone (cuánto voy a hacer)
Cuándo tiene que estar (fecha final de entrega).

Porcentajes estimados (en nuestro caso varían porque todos hacemos todo, etc).
Tiempo Esfuerzo
Inicio 10% 5%
Elab 30% 20%
Constr 50% 65%
Trans 10% 10%

OJO: Pregunta de examen: "describe las decisiones de diseño más importantes de vuestro proyecto". => Documentación es importante.

Si hace falta mucho tiempo: alarga fase de inicio
Si no hay arquitectura, tecnología nueva, muchas restricciones rendimiento (y el labo maldito!), muchos retos: alarga elaboración.
Segunda generación de algo: acorta inicio y elaboración. (Pasa mucho en los juegos: primero lo pasan mal, pero luego van muucho más rápido. )
Llegar al mercado rápido (se llega tarde o se está creando mercado) y se planea terminar poco a poco: acorta la fase de construcción y alarga la de transición. (modelo MS XD).
Despliegue complicado: reemplazar sistema antiuo sin interrumpir el servicio, o conseguir certificación: alarga transición.

Iteración. debería durar de 2 a 6 semanas. Relativo!. Cuanta más gente, más tiempo para organizarse. 20 personas pueden necesitar un planificador… 40 personas tienen niveles intermedios de jerarquía, con más protocolos y documentación formal. 3 meses xD.

Cuántas: inicio: entre 0 iteraciones y 1.
- no hay real (no se produce soft)
- En algunos casos se puede tener una para:

  • construir un prototipo para convencer de que la idea es buena
  • Mitigar un riesgo importante (tecnología / algoritmos nuevos).
  • acostumbrar a usar las iteraciones.

Elaboración: al menos 1 (1 a 3).
Si no hay arquitectura entrada y hay que ajustar muchos factores nuevos (tech, plataforma, gente, lenguaje de programación) => 2 ó 3 al menos, porque no conviene tratar todos los riesgos a la vez, y hay que enseñar algo al cliente. IKIWISI: I know it when I see it.

Construcción: al menos 1 (1 a 3).
3 ó más si se puede con la sobrecarga. (no hace falta que las iteraciones sean todas iguales… Pueden ser de 2 semanas!).

Transición: al menos 1.
Los defectos encontrados suelen obligar a hacer otra.

=> Normalmente: 6 +- 3.

Inicio: para ver si ha funcionado, ver si estamos todos de acuerdo en alcance, coste y planificación temporal (hacer!!).

Elaboración: linea base (baseline): entrega validada del producto bajo control de configuración que sirva como punto de partida tan rápido como sea posible. INTENTAR PARA DICIEMBRE!
Al final queremos tener un modelo del 80% de los usecases aprox, y revisar todo. Manual de usuario (preliminar); la diferencia desde los casos de uso bien hechos es solo de orientación.
El ejecutable demuestra que los riesgos ppales (tecnológicos) se han resuelto.
Para que haya acabado se tiene que llegar al punto en que se puede repartir *directamente* el trabajo, sin que haya mucho turrón para integrar.

Construcción: objetivos: optimizar recursos, conseguir calidad rápidamente y tener versiones útiles (alpha, beta…).
Artefactos: producto, manuales y descripción de la presente versión.
Evaluación: Maduro y estable para que lo prueben los usuarios (todos actuaremos de usuarios para todos => breakfest).

Transición: betatesting, operación paralela con sistema anterior, y lo más importante: transferencia a marketing, ventas, etc.
Evaluación: usuario satisfecho.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License