Sesion de capacitacion sobre Personal Software Process (TM) / Español / 2014.02. NOTA: Todas la marcas son propiedad de sus respectivos dueños.

1. SESIÓN 05: DESIGN
1

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