1. DESARROLLO DE
SOFTWARE
PROCESO BIEN ESTRUCTURADO
DE ACUERDO A LA PARTICIPACION
DEL EQUIPO DE DESARROLLO

2. ¿Quiénes participan en el
proceso?
La participación del personal casi
siempre esta sujeta a roles ya definidos
de acuerdo a sus responsabilidades.

3. Roles (1): Adm. del Proyecto
Es el principal responsable proyecto (Decision-maker). Entre sus
responsabilidades está:
1. Delimitar el Alcance del Sistema (con los
analistas).
2. Planificar/replanificar y Administrar el Proyecto.
Incluyendo el plan de pruebas e implantación
junto con el implementador.
3. Coordinar el trabajo de los distintos miembros
del equipo.
4. Interactuar con el Cliente.
5. Velar por el cumplimiento de los objetivos,
plazos y costos comprometidos.
Administrador Este es uno de los roles más críticos dentro
de
del Proyecto cualquier proyecto de desarrollo de software.

4. Roles (2): Analista
Es el encargado de relevar y especificar los requisitos del
sistema a desarrollar. Entre sus tareas está:
1. Identificar y entrevistar a clientes y usuarios.
2. Delimitar el alcance del sistema (con el AdP).
3. Desambigüar los requisitos.
4. Generar el documento de requisitos que
incluye los requisitos de software y de
usuario, dentro de los plazos comprometidos.
5. Apoyar al Téster en la especificación de las
Analista pruebas de sistema y de usuario.
6. Velar porque el diseño cumpla con los
requisitos (junto con el téster).
7. Velar porque el producto final cumpla con los
requisitos (junto con el téster).

5. Roles (3): Diseñador
Es el encargado de generar el diseño del front-end
y back-end del sistema. Entre sus funciones está:
1. Generar el diseño arquitectónico y
diseño detallado del sistema (DD-
Documento de Diseño), basándose en
los requisitos. El diseño debe ser
implementable.
2. Generar prototipos rápidos del sistema
(con analistas e implementadores) para
chequear los requisitos entregados por
el cliente.
Diseñador 3. Validar los prototipos con clientes y
usuarios pertinentes.
4. Velar porque el producto final se ajuste
al diseño realizado (funciones de téster).

6. Roles (4): Implementador
Es el encargado de implementar el sistema.
Entre sus funciones está:
1. Implementar los prototipos rápidos para
chequear los requisitos.
2. Implementar los diseños del sistema,
especificados por los diseñadores (en el
DD).
3. Realizar la primera batería de pruebas y
ajustar el sistema en base a los
resultados.
Implementador 4. Diseñar (junto al AdP) y llevar a cabo el
plan de implantación.

7. Roles (5): Téster
Es el encargado de asegurar la calidad de cada uno de los
productos (documentos, prototipos, etc). Entre sus tareas
está:
1. Coordinar las revisiones de los productos del
proyecto.
2. Generar los informes post-revisión.
3. Realizar un seguimiento de las falencias
identificadas.
4. Informar al AdP acepta de riesgos identificados.
5. Velar por la adhesión al estándar adoptado.
6. Velar por la completitud, y exactitud (no
ambigüedades) de los documentos.
7. Velar por la calidad del producto final
Téster (cumplimiento de los requisitos).
8. Especificar las pruebas a realizar (con analistas).

8. … El Desafío (1)
Trabajar en equipo para resolver el problema
asignado

9. … El Desafío (2)
… y que el cliente quede felíz.

10. El Proceso de Software
“Conjunto estructurado de actividades
requeridas para desarrollar un sistema de
software.
Especificación.
Diseño.
Validación.
Evolución”.
“Las actividades varían dependiendo de la
organización y del tipo de sistema a
desarrollarse”.
“Debe estar explícitamente modelado si va a
ser bien administrado”.

11. El Proceso de Software
Las instrucciones para desarrollar una
aplicación.
Cómo descubrir qué tiene que hacer la aplicación.
Cómo decidir cómo va a estar estructurada la
aplicación.
Cómo asegurarse de que la aplicación funciona y hace
lo que tenía que hacer.
Cómo ocuparse de que la aplicación se pueda ampliar /
migrar / adaptar.
Hay que adaptarlas para cada caso.
Conviene que las instrucciones figuren por
escrito
(¿Cuándo?)

12. Qué debe incluir un Proceso
Especificación - establecer los requisitos y
restricciones del sistema
Diseño - producir un modelo en papel del
sistema
Manufactura - construir el sistema
Prueba - verificar que el sistema cumpla con
las especificaciones requeridas
Instalación - entregar el sistema al usuario y
asegurarse de que satisface sus necesidades
Mantenimiento - reparar fallos en el sistema
cuando sea descubiertos

13. Ejemplos
Dos modelos de proceso concretos:
 Proceso Unificado de Rational (pesado)
 Extreme Programming (ágil)

14. Proceso Unificado de Rational
Organization along time
Phases
Process Components Inception Elaboration Construction Transition
Requirements Capture
Analysis & Design
Implementation
Organization Test
along content
Supporting Components
Management
Environment
Deployment
preliminary iter. iter. iter. iter. iter. iter. iter.
iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations

15. Extreme Programming (XP)
Diferencias fundamentales (hay más que ya se
verán)
No hay requisitos explícitos sino que el cliente
participa en el desarrollo
Se empieza por automatizar las pruebas
Se desarrolla siempre la versión más simple
posible que resuelva el problema
Se ejecutan todas las pruebas todos los días
Se cambia el diseño (aunque sea radicalmente)
siempre que haga falta

16. ¿Qué atributos tiene un buen
Software?
El software debería entregar la funcionalidad y
desempeño requeridos por el usuario y debería ser
mantenible, confiable, eficiente y usable
Manteneabilidad
 Software debe evolucionar para cubrir necesidades
cambiantes
Confiabilidad
 Software debe producir los resultados esperados
Eficiencia
 Software no debe malgastar los recursos del sistema
Usabilidad
 Software debe ser de fácil uso para los usuarios finales

17. Bibliografía
“Software Engineering - A Practitioner’s Approach” - Roger
S. Pressman. 6º Ed. (2002). McGraw Hill.
“ESA Software Engineering Standards”. PSS-05-0 Issue 2.
ESA Board for Software Standardization and Control
(BSSC) - European Space Agency. (1991). URL:
www.ess.co.at/ECOSIM/ESA.txt.
“Software Engineering” - Ian Somerville. 7º Ed. (2004).
Addison Wesley.
“A Discipline for Software Engineering” – Watts Humphrey.
(1995). Addison Wesley.
Software Engineering Institute (SEI), Carnegie Melon
University (www.sei.cmu.edu).
Material Docente en U-Cursos.