Personal Software Process / Sesion 05

Post on 06-Jul-2015

95 views 0 download

description

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

Transcript of Personal Software Process / Sesion 05

SESIÓN 05: DESIGN

1

2

3

4

5

6

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

OST contiene: escenarios, flujos de esos escenarios bajo el enfoque estímulo/respuesta

8

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

SST contiene: estados, transiciones, condicion que causa la transición y acciones tomadas durante cada transicion

10

LST contiene: pseudocodigo compatible con el lenguaje usado para implementar, referencias externasAl implementar el programa, se puede incluir algo del pseudicodigo en los comentarios.

11

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ñoUML 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

14

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

Ver puntos de slides.

16

Equipos autoorganizados

Algunos roles delegados dentro del equipo para que el equipo se desempeñe eficientementeDesign 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 externosPlanning ManagerAsegurar que el equipo sigue el planAsiste a los ingenieros en estimarAyuda a balancear cargasQuality ManagerConduce al qeuipo para hacer un Quality PlanDirige los nvolucrados en las inspeccionesProcess ManagerSe asegura que se sigue el proceso, que los datos son reportados y analizadosGestiona los PIP’s

17