Qué

Qué es la gestió
gestió n de un proyecto?
Estrategia de Gesti
Gestióón de
n Gestionar un proyecto consiste en
Proyectos Dirigida por la asegurar que se entregará
entregará un producto
Arquitectura que cumpla con las especificaciones
dentro del plazo y costo acordado, con el
nivel de calidad pactado
n Entorno de Naturaleza Cambiante
MC Ing. Mariel Feder n Incertidumbre (RRHH, tecnoló
tecnoló gicos, negocio)

Ciclo de vida del proyecto Inicializacion

n Análisis de consecuencias
Aná
n Definición de magnitudes
n Aná
An álisis de alternativas
n Aná
An álisis té
t écnicos (viabilidad, mat
mat,, rec
rec,, etc
etc))
n Aná
An álisis de inversió
inversión y rentabilidad
n Aná
An álisis de riesgo

Planificació
Planificación Producció
Producción o Implementació
Implementación

n Esquema de trabajo para alcanzar el n Administración

objetivo n Ejecución
n Estimaciones n Control
n Se itera durante el proyecto
Cierre

1
 Arquitectura de Software
Administraci ón

n Disciplina joven
Planificación
general
Planificación
espec ífica
Ejecuci ón Retroalimentación n Bass,, Clements y Kazman
Bass Kazman:: La arquitectura de
Inicio Planificación
un programa o sistema de computació
computació n es
Control
la estructura o estructuras del sistema,
que comprenden sus componentes de
Producción
software, las propiedades externas de los
componentes, y la relació
relació n entre ellos,
ellos, que
coincide con la propuesta por Soni
Soni,, Nord y
Etapas en la gestión de un proyecto Hofmeister

Ciclo de vida del Desarrollo del

Producto
Cascada (Royce
(Royce,, 1970)

n Orden de las actividades que ocurren n Secuencia de fases que no se repite:

durante el desarrollo n Planificar el proyecto antes de comenzar
n Definir el comportamiento externo esperado
del sistema antes de definir su
funcionamiento interno.
n Documentar los resultados de cada actividad

n Dise
Diseññar el sistema antes de codificarlo
n Testear el sistema una vez que est á
construido.

Cascada Desarrollo Incremental (Hirsch

Hirsch,, 1985 )
Requerimientos
Requerimientos

Arquitectura
Arquitectura

Diseño Diseño
Diseño

Codificación y Codificación y
Codificación y testing unitario testing unitario
testing unitario
Integración Integración
Integración
Operación Operación
Operación
Ciclo de vida en Cascada
Ciclo de vida de desarrollo incremental

2
 Evolutivo (Basili - Turner
Turner,, 1975)
Otros
Requerimientos Requerimientos

Diseño Diseño
n Espiral (Boehm
(Boehm 1988)
n Prototipación
Codificación y
testing unitario
Codificación y
testing unitario n Etc

Integraci ón Integraci ón

Operación Operación

Ciclo de Vida Evolutivo

Ciclo de vida para PDA

Proceso para Gestió
Gestió n de
n Autores como Paulish
Paulish,, importancia a
Proyectos dirigidos por la Arquitectura previa.
arquitectura n Necesaria para PDA
n Ciclo cascada/incremental

Planificació
Planificación del Proyecto Estimació
Estimación

n Proyectos bien gestionados comienzan n Pequeño grupo arq. de alto nivel

Pequeñ
como proyectos bien planificados. n Mecanismos de estimación toptop--down
n Cuá
Cu ándo: en paralelo con la definición del a (Cocomo
Cocomo,, Puntos Funcion
Funcion,, Slim
Slim,, Price
Price--S)
arquitectura. n Basarse en componentes para estimación
n Presió
Presión externa. Problema de Bottom Up (vista lógica de Krutchen
Krutchen). ).
estimaciones tempranas. Responsabilidad del arquitecto
n Cronograma viable, metas intermedias. n Integración de ambas estimaciones.

3
 Aná
Análisis de Riesgo
Top--Down vs Bottom Up
Top
Identificación

n Bottom up: mayor precision en cada Análisis

componente
n Top down
down:: incluye otras tareas Planificación

n Integración entre ambas

n Cota mí
m ínima: Bottom up Seguimiento

Evaluación

Ciclo de gestión de
Riesgo

Aná
Análisis de Riesgo
Riesgos y Arquitectura
Identificación

Análisis n Arquitectura como entrada importante

n Riesgos té
t écnicos
Planificación

Seguimiento

Evaluación

Ciclo de gestión de
Riesgo

Riesgos y Arquitectura – Check list Riesgos y Arquitectura – Check list

n Experiencia de los equipos de desarrollo en las n Nivel de complejidad, testeabilidad y

plataformas, lenguajes y herramientas acoplamiento de los componentes
seleccionadas n Identificació
Identificaci ó n de los componentes crícríticos ya sea
n Estabilidad de las herramientas y plataformas por su importancia para el funcionamiento del
n Disponibilidad de las herramientas y plataformas producto o por su complejidad.
n Integrabilidad de las plataformas seleccionadas n Atributos de calidad requeridos que resulten
crííticos para el producto (ej.
cr (ej.:: performance
performance,,
n Interoperabilidad entre los componentes
seguridad, amigabilidad, etc.) y que la
diseñ
dise ñados
arquitectura debe garantizar

4
 Criterios para orden y contenido de
Plan de Versiones las versiones
n Desarrollo simult áneo? n Dirigido por el riesgo
n Desarrollos en paralelo y en secuencia n Dirigido por las necesidades del
n Identificación de paquetes o componentes usuario/mercado
y precedencias n Secuencia lógica
n Puntos de control, plan de versiones n Dirigido por la capacitación
n Arquitectura como input para este proceso n Combinación

Arquitectura Recursos Humanos

n Identificación de componentes o paquetes n Reclutamiento: Perfiles necesarios

por funcionalidad n Organización de los equipos: Vertical,
n Complejidad y criticidad de los Horizontal
componentes (entrada tambié
también para la
estrategia de testing
testing).
).

Organizació
Organizaci ón de equipos horizontal
Org.. Equipos horizontal
Org
Equipo 3

Expertos en el componente
Capa/componente 3
n

n Uniformidad en el componente
Equipos simult áneos
Equipo 2

Capa/componente 2 n

n Visibilidad parcial
Equipo 1
Capa/componente 1

Organizació n de equipos horizontal

5
 Org.. Equipos Vertical
Org
Org.. Equipos vertical
Org
Equipo 1 Equipo 2 Equipo 3

Capa/componente 3
n Posibilidad de un solo equipo
(serialización)
n Evitar problemas de comunicación.
Capa/componente 2 n Visió
Visión completa de la funcionalidad
n Componentes menos cohesivos o
Capa/componente 1 redundancia

Proyectos de gran porte Organizació

Organización del cronograma

n Combinaciones: n WBS – Work BreakDown Structure

n Equipos horizontales y sub
sub--equipos verticales n Orientadas a la funció
funció n
o viceversa, en base a la arquitectura. n Orientadas a la fase
n Orientadas al producto

n Integrar participantes del diseñ

diseño n Híbridos

n Visió n má
Visió más global
n Compromiso con la estimació
estimació n

WBS Orientada a la Fase WBS Orientada al Producto

Proyecto

Proyec
to

Diseñ Modulo 1 Modulo 2

Requerimien Integraci
o
tos ón
Implementaci
Arquitect y
ón
Testing Implantaci ón
ura
Implantaci Análisis Análisis
Implantaci ón
ón

Modulo Modulo Modulo Modulo Testing e

Diseñ

1 2 1 2 Diseño Integraci ón
o

Testing

Modulo Modulo
Modulo 2 Modulo 1 Implementaci ón Implementaci ón
1 2

WBS Orientada a la fase WBS orientada al producto

6
 Cronograma enero
Cronograma
febrero marzo abril mayo junio julio agosto septiembre
Id Nombre de tarea F P M F P M F P M F P M F P M F P M F P M F P M F P M F
1 Ing. 'Requerimientos

2 Arquitectura

n Sugerencia: imitar el ciclo de vida. 3

4
Version pre-release 1

Componente 1

Hitos segú
seg ún plan de versiones
5 Componente 2

n 6 Integración

7 Fin 26/06

n Componentes de las iteraciones surgen del 8

9
Version release 2
Componente 4

arquitectura 10

11
Componente 5

Componente 6

12 Componente 7
13 Integración

14 Fin 30/08

15 Version pre-release 3

Factores a considerar
n Estimació n del esfuerzo de cada componente
Estimació
n Cantidad de recursos humanos, perfiles y Resumen del Proceso
requerimientos de cada componente
n Secuencia de desarrollo segú
según el plan de
versiones.
n Otras restricciones:
n Tiempo mámáximo de desarrollo
n Presupuesto
n Flujo de caja, etc.

Ing. de

Resumen Proceso
Requerimient
os

Estimación Integraci ón n A partir de los requerimientos funcionales y no

Top-Down de
estimacione
funcionales se diseñ
diseñ a la arquitectura del producto
s mientras en paralelo se realiza la estimació
estimació n top
top-- down
Estimación del proyecto.
Bottom-Up
Arquitectur n A partir de la arquitectura se realiza una estimació
estimació n
a
bottom-- up de cada uno de los componentes
bottom
Plan de identificados.
Versiones
n Se integran ambas estimaciones en la que se utilizar á
Confección para la planificació
planificació n del proyecto.
del
Análisis de
cronograma n Se realiza el an álisis de riesgo, incorporando a la
Riesgo arquitectura como fuente de posibles riesgos que
pueden afectar al proyecto. Algunos de los riesgos
Organizació identificados pueden ocasionar la toma de decisiones
n de los que afecten la arquitectura con lo que se repite el ciclo.
equipos

Proceso de planificación y organizaci ón del proyecto

7
 Resumen del Proceso
n A partir de la arquitectura, los requerimientos o
necesidades del usuario y del an álisis de riesgo, se
confecciona el plan de versiones.
n A partir de la arquitectura, se organizan los equipos que
participará
participar án en el proyecto.
n A partir del plan de versiones, del resultado del proceso
de estimació n, de las tareas de prevenció
prevenció n y de las
decisiones tomadas a partir del an álisis de riesgo, y de
los equipos previstos se confecciona el cronograma.
Algunas consideraciones en el momento de confeccionar
el cronograma para tener en cuenta todas las
restricciones del proyecto pueden afectar la organizació
organizació n
de los equipos, con lo que se vuelve a iterar el ciclo
hasta encontrar el punto de equilibro.
n Una vez definidos el plan de versiones y el cronograma,
puede comenzar el desarrollo del proyecto, el cual se
gestionar á para mantenerlo dentro de lo previsto en los
documentos obtenidos como resultado del proceso
descripto
Referencias Bibliográ
Bibliográficas
n Feder , Mariel. Gestió
Gestió n de proyectos dirigida por la Arquitectura.
Congreso Argentino de Ciencias de la Computaci ó n. 2003
n A guide to the Project Management Body of Knowledge (PMBOK) ,
Project Management Institute, www.pmi.org
www.pmi.org..
n Humphrey, W.S, Managing the software process
n Bass, Clements y Kazman 1998. Software Architecture in Practice.
Massachusetts, USA. Addison Wesley.
n Soni D, Nord R y Hofmeister C, Software Architecture in Industrial
Applications , en Proceedings of the 17th International Conference
on Software Engineering, New York: ACM Press, 1995.
n Davis Alan M., Software Life Cycle Models. Software Engineering
project management , editado por Richard H Thayer, 2ª 2ª edici ó n.
IEEE Computer Society Press, 1988
n Royce W.W., Managing the Development of Large Software
Systems: Concepts and Techniques , Proc. 1970 WESCON Technical
Papers, Vol. 14, 1970
n Hirsch E., Evolutionary Acquisition of Command and Control
Systems,, Program Manager, Nov. Dec. 1985.
Systems
n Giddings R.V, Accommodating Uncertainty in Software Design,
Design,
Comm ACM, Vol 27, N° N° 5, May 1984.

Referencias Bibliográ
Bibliográficas Referencias Bibliográ
Bibliográficas
n Gomaa H y Scott D, Prototyping as a Tool in the Specification of
n Grey S, Practical Risk Assessment for Project Management , John
User Requirements , Proc. 5th IEEE International Conference on Wiley & Sons
Software Engineering, IEEE CS Press, Los Alamitos , California, 1981.
n Karolak D.W, Software Engineering Risk Management , IEEE
n Boehm B.W. A Spiral Model of Software Development and
Enhancement , Computer, May 1988. Computer Society Press
n Paulish D.J, Architecture -Centric Software Project Management, A n Michaels J.V, Technical Risk Management , Prentice Hall
practical guide , Carnegie Mellon, Software Engineering Institute, n BASS L. et al
al.. Quality Attribute Design Primitives . Technical Note
2002. CMU/SEI--2000 -TN
CMU/SEI TN-- 017. Diciembre 2000
n Boehm B, Software Engineering Economics , E Englewood Cliffs, NJ, n BASS L., et al. Quality Attribute Design Primitives and the Attribute
Prentice Hall 1981. Drive Design Method.
Method. SEI, Carnegie Mellon University, Pittsburgh.
n Boehm B. et al, Software Cost Estimation with Cocomo I I, I, Upper n MOUSQUES Gast ó n. 2002. Transparencias Curso de Arquitectura.
Saddel River, NJ, Prentice Hall, 2000. Ingenieríía de Sistemas, Universidad ORT, Uruguay.
Ingenier
n Paulish D.J, Architecture -Centric Software Project Management, A n KAZMAN R. et al. Octubre 1999. Attribute Based Architectural Styles.
practical guide , Carnegie Mellon, Software Engineering Institute, Technical Report CMU/SEI - 99 99--TR022.
2002. n Thayer R, Software Engineering Project Management
n KRUTCHEN Philippe. Noviembre 1995. The 4+1 View Model of n Rees F, Equipos de trabajo,
trabajo, Prentice Hall 1997
Architecture.. IEEE Software, 12(6), pp 42-
Architecture 42- 50. n Simons, Lucarelli
Lucarelli,, Work Breakdown Structures
n Higuera R.P, Software Risk Management , CMU/SEI-
CMU/SEI -96
96--T R-
R-012 ESC - n Gido,, Clements, Network Planning and Scheduling
Gido
TR--96
TR 96-- 012, Software Engineering Institute (SEI), www.sei.cmu.edu n Pinto J, Project Management Handbook,
Handbook , PMI