![Proceso de diseño [30min]
• La idea de un diseño es transformar una definición debil (ill) de requerimientos en una
especificación implementable “blueprint” del producto: llegar a una vista de la solución, sin tener
que tocar los detalles de bajo nivel (low-level)
• Basados en datos de 8100 programas, los programadores que usaron diseño: (1) gastaron más
tiempo que aquellos que no lo hicieron (53% más) (2) produjeron programas 46% mas pequeños,
reduciendo el esfuerzo de encontrar mayor candidad de defectos en fases posteriores.
• Algunos issues que pueden salir en la fase de diseño, se pueden deber a (1) no estar familiarizados
con la tecnologia a implementar (2) temas de escalabildiad y no funcionales: que es mejor atacar de
forma templrana para no impactar el performance del producto al final (3) algo de prototyping o
algunas POC pueden ayudar a aliviar la incertidumbre (algunas veces el prototipo se descarta)
• El principio de incertidumbre en los requerimientos: dice que los requerimientos no están lo
suficientemente completos sino hasta que se tiene el producto completo, pero el diseño es una base
para el crecimiento consistente del producto
• Psp no plantea una metodología de diseño. Sin embargo explora algunos elementos que el diseño
debe cubrir y plantea unas plantillas para hacerlo. El objetivo es que la representación sea
aprovechada por quienes lo van a implementar por lo cual debería ser un documento claro, no
ambiguo (comuncar la idea) y además que baja a un nivel de detallle.
• La idea de las plantillas es definir que el diseño sea completo y preciso, por lo cual hay 4 plantillas
donde se plasma el trabajo:
• EXTERNO-DINAMICO: Servicios y Mensajes, se captura con la plantilla operational
Specification Template
• EXTERNO-ESTATICO: estructura de clases
• INTERNO-ESTATICO: logica de los programas, pseudocodigo
• INTERNO-DINAMICO: diagrama de estados
7](https://image.slidesharecdn.com/pspslides05-140222062244-phpapp01/85/Personal-Software-Process-Sesion-05-7-320.jpg)
![Relación con UML [30min]
Antes de decidirse por una alternativa, estar convencido de que provee:
• Precisión
• Completitud (completness)
• Efectividad en revisión de diseño
UML es una alternativa de diseño que permite a través de una representación gráfica, describir la
estructura de un sistema.
Deben usarse consistentemente nombres de clases y operacioens
Como son varios los diagramas, normalmente se trabaja con un subset de ellos.
OCL es una alternativa para describir el comportamiento de UML.
12](https://image.slidesharecdn.com/pspslides05-140222062244-phpapp01/85/Personal-Software-Process-Sesion-05-12-320.jpg)
Personal Software Process / Sesion 05
- 2. 2
- 3. 3
- 4. 4
- 5. 5
- 6. 6
- 7. Proceso de diseño [30min] • La idea de un diseño es transformar una definición debil (ill) de requerimientos en una especificación implementable “blueprint” del producto: llegar a una vista de la solución, sin tener que tocar los detalles de bajo nivel (low-level) • Basados en datos de 8100 programas, los programadores que usaron diseño: (1) gastaron más tiempo que aquellos que no lo hicieron (53% más) (2) produjeron programas 46% mas pequeños, reduciendo el esfuerzo de encontrar mayor candidad de defectos en fases posteriores. • Algunos issues que pueden salir en la fase de diseño, se pueden deber a (1) no estar familiarizados con la tecnologia a implementar (2) temas de escalabildiad y no funcionales: que es mejor atacar de forma templrana para no impactar el performance del producto al final (3) algo de prototyping o algunas POC pueden ayudar a aliviar la incertidumbre (algunas veces el prototipo se descarta) • El principio de incertidumbre en los requerimientos: dice que los requerimientos no están lo suficientemente completos sino hasta que se tiene el producto completo, pero el diseño es una base para el crecimiento consistente del producto • Psp no plantea una metodología de diseño. Sin embargo explora algunos elementos que el diseño debe cubrir y plantea unas plantillas para hacerlo. El objetivo es que la representación sea aprovechada por quienes lo van a implementar por lo cual debería ser un documento claro, no ambiguo (comuncar la idea) y además que baja a un nivel de detallle. • La idea de las plantillas es definir que el diseño sea completo y preciso, por lo cual hay 4 plantillas donde se plasma el trabajo: • EXTERNO-DINAMICO: Servicios y Mensajes, se captura con la plantilla operational Specification Template • EXTERNO-ESTATICO: estructura de clases • INTERNO-ESTATICO: logica de los programas, pseudocodigo • INTERNO-DINAMICO: diagrama de estados 7
- 8. OST contiene: escenarios, flujos de esos escenarios bajo el enfoque estímulo/respuesta 8
- 9. FST contiene: la funcionalidad que se expone como interfaz, la firma de los metodos, las relaciones con otras clases. Normalmente se realiza en varios pasos (se construye el cascarón general y se va refinando cada vez que se conocen mas detalles del funcionamiento o se entienen mejor el problema) 9
- 10. SST contiene: estados, transiciones, condicion que causa la transición y acciones tomadas durante cada transicion 10
- 11. LST contiene: pseudocodigo compatible con el lenguaje usado para implementar, referencias externas Al implementar el programa, se puede incluir algo del pseudicodigo en los comentarios. 11
- 12. Relación con UML [30min] Antes de decidirse por una alternativa, estar convencido de que provee: • Precisión • Completitud (completness) • Efectividad en revisión de diseño UML es una alternativa de diseño que permite a través de una representación gráfica, describir la estructura de un sistema. Deben usarse consistentemente nombres de clases y operacioens Como son varios los diagramas, normalmente se trabaja con un subset de ellos. OCL es una alternativa para describir el comportamiento de UML. 12
- 13. 13
- 14. 14
- 15. TSP PARTE 1 Pero el trabajo no es solo realizado por una persona, por lo cual se debe tener en cuenta al planear que: Se deben tener metas cumplibles (Planes realistas), Con buena calidad, para que el schedule no se alargue, y luego dicho tiempo se gaste en testing. Combinar los esfuerzos de cada integrante de equipo Que la planeación sea realizada por los integrantes del equipo pero que ellos estén comprometidos (commited) a realizar las tareas, Además que no quede sobrecargado un miembro del equipo (balancear las tareas cuando hay retrasos de uno de los miembros). 15
- 16. Ver puntos de slides. 16
- 17. Equipos autoorganizados Algunos roles delegados dentro del equipo para que el equipo se desempeñe eficientemente Design Manager: • foco en el diseño a lo largo del proyecto • Control de arquitectura • Foco para resolver los nofuncionales del desempeño del producto y sizing • Control de Asumptions & issuees para que queden documentadas y resueltas • Validar que la arquitectura considera una futura evolución del producto • Estandares para producir el diseño • Interfaces u otras dependencias con componentes externos Planning Manager Asegurar que el equipo sigue el plan Asiste a los ingenieros en estimar Ayuda a balancear cargas Quality Manager Conduce al qeuipo para hacer un Quality Plan Dirige los nvolucrados en las inspecciones Process Manager Se asegura que se sigue el proceso, que los datos son reportados y analizados Gestiona los PIP’s 17