1. Arquitectura de Software
Entendiendo las Necesidades
Maria A. Perez de Ovalles
www.lisi.usb.ve
mariapovalles@gmail.com

2. Topicos
! La complejidad de desarrollar sistemas
! Las mejores practicas
! Analizando el Problema
! Entendiendo las Necesidades
2 2011

3. La Complejidad de Desarrollar Sistemas
! Hacer sistemas de software es una tarea compleja….
3 2011

4. ¿Cuál es la complejidad?
Factores de éxito 1) Involucrar al usuario
2) Soporte de la gerencia ejecutiva
3) Descripción clara de los objetivos
del negocio
Sin embargo:
! Sólo 28% de los proyectos completados a tiempo y en presupuesto (toda la
muestra)
! 24% en empresas grandes
! 32% en empresas pequeñas
! 46% de los proyectos sobrepasaron sus estimados originales ($22 billones por
encima)
! 28% de los proyectos cancelados antes de completarse ($75 billones antes de
cancelarse) Standish Group 2004
¿por qué estos resultados son tan malos?
4 2011

5. ¿Cuál es la complejidad?
Razones de Fracaso
Falta de Información de los usuarios 12,8
Especificaciones Incompletas 12,3
Especificaciones Cambiantes 11,8
Falta de compromiso alta gerencia 7,5
Incompetencia tecnológica 7
Falta de recursos 6,4
Expectativas irreales 5,9
Objetivos poco claros 5,3
Tiempos optimistas 4,3
Nueva tecnología 3,7
Otros 23
5 2011

6. ¿Cuál es la complejidad?
Razones de Exito
Participación de usuarios 15,9
Apoyo alta gerencia 13,9
Requerimientos claros 13
Buena planificación 9,6
Expectativas reales 8,2
Alcances pequeños 7,7
Staff competente 7,2
Objetivos claros 2,8
Staff trabajador 2,4
Otros 19,2
6 2011

7. ¿Cuál es la complejidad?
! Laingeniería de software nos llevó
a ver el proceso de desarrollo del
software como un proceso de
Necesidades
ingeniería.
! Este proceso es complejo y
!
variable.
! Un modelo que detalle el proceso
de desarrollo del software sigue Codificación
bajo investigación, en la actualidad
existe un amplio espectro de Compilación
proposiciones.
7 2011

8. ¿Cuál es la complejidad?
! Los proyectos, a menudo, se tardan más de lo previsto y
consumen el doble del presupuesto planificado.
! Algunos proyectos de desarrollo de software
producen excelentes resultados; sin embargo, obtener los
mismos resultados depende directamente de contar con
los mismos individuos disponibles.
8 2011

9. ¿Cuál es la complejidad?
! El proceso utilizado para desarrollar el sistema
generalmente se improvisa.
! Las especificaciones del proceso no son seguidas
rigurosamente, acatadas a cabalidad o compartidas.
! Los cronogramas y los presupuestos son rutinariamente
irrespetados.
9 2011

10. ¿Cuál es la complejidad?
! El software se desarrolla; no se fabrica en el sentido clásico.
! El software no se deteriora.
! La mayoría del software se construye a la medida.
! Se crean expectativas poco factibles.
! Problemas de comunicación.
! Ausencia de documentación.
10 2011

11. ¿Cuál es la complejidad?
! Procesos de negocio complejos y enfocados al cliente
! Distribuidos espacialmente y en el tiempo
! Exigencia de altos niveles de calidad en el servicios, tales
como buenos tiempos de respuesta, seguridad, confiabilidad,
entornos regulatorios.
! Tiempos cortos de desarrollo
! Equipo de proyecto interdisciplinario y numeroso
! Múltiples canales de comunicación
! Requerimientos novedosos
! Habilitadores Tecnológicos que deben ejecutarse sobre
múltiples plataformas y sobre múltiples bases de datos
Además,
11 2011

12. ¿Cuál es la complejidad?
Pasamos de: A:
• plicaciones ejecutándose
A • jecutándose en dos o mas
E
en un solo procesador procesadores
• alidas Alfanuméricas
S • nterfaces de usuarios
I
gráficas
• ntradas en forma lineal
E
• rquitecturas Cliente-Servidor
A
• roceso de desarrollo en
P
cascada • obre diferentes sistemas
S
operativos
• rquitecturas basadas en
A
procesos o transacciones • n máquinas distribuidas
E
geográficamente….
12 2011

13. ! Time to market.
! Cambios económicos del hardware.
! Presión por la disponibilidad de computadoras de escritorio
cada vez más poderosas.
! Surgimiento de redes locales y urbanas muy amplias
(www).
! Surgimiento de nuevos paradigmas: Orientación a objeto,
Componentes, Ingeniería Web, a Servicios, Aspectos……
13 2011

14. En resumen..
! Los proyectos de desarrollo de software no tienen indicadores de
éxito halagadores
! Tres son los factores críticos de éxito:
! Involucrar a los usuarios
! Soporte de la gerencia ejecutiva
! Descripción clara de los objetivos el negocio
! Este proceso es complejo y variable
! El proceso utilizado para desarrollar el sistema generalmente se
improvisa
! Problemas de comunicación.
! Ausencia de documentación
14 2011

15. Mejores Prácticas
Como un aprendizaje de
cuatro décadas de desarrollo
de sistemas, se obtienen las
mejores prácticas…
15 2011

16. Mejores Prácticas
! Desarrollo Iterativo del Software
! Gestión de Requerimientos
! Arquitecturas Probadas
! Modelar el Software Visualmente
! Verificación de la Calidad del Software
! Gestión del Cambio
! Desarrollo Colaborativo
! Más allá de un Desarrollo
! Gestión de Riesgos
16 2011

17. Desarrollo Iterativo del Software
! No es realista usar un modelo lineal de desarrollo
como el de cascada
! Un proceso iterativo permite una comprensión
creciente de los requerimientos a la vez que se va
haciendo crecer el sistema
! Con esto se logra reducir los riesgos del proyecto
y tener un subsistema ejecutable tempranamente
! El descubrimiento de defectos en fases
posteriores de diseño dan como resultado un
aumento en los costos y/ó la cancelación del
proyecto
17 2011

18. Gestión de Requerimientos
Definir
Prioridades
Detectar
inconsistencias a
través de registro de
Evaluar Repositorio de cambios
Funcionalidad Requerimientos
Definir
Requerimientos
18 2011

19. Gestión de Requerimientos
! Elicitar, organizar, y documentar la funcionalidad y restricciones requeridas.
! Llevar un registro y documentación de cambios y decisiones.
! Los requerimientos de negocio son fácilmente capturados y comunicados a través de
casos de uso.
! Los casos de uso son instrumentos importantes de planeación. Han probado ser una
buena forma de captar requerimientos y guiar el diseño, la implementación y las
pruebas.
realización influenciado por verifica
Los casos de uso
dirigen el trabajo
desde el análisis Modelo de Diseño
hasta las pruebas Modelo de Implementación Modelo de Prueba
19 2011

20. Arquitecturas Probadas
! Se enfoca en el pronto desarrollo de una arquitectura
ejecutable robusta.
! Resistente al cambio mediante el uso de interfaces bien
definidas
! Intuitivamente comprensible
! Promueve una reutilización más efectiva del software
! Es derivada a partir de los Casos de Uso más importantes
20 2011

21. Modelado Visual del Software
! Disminuye la ambigüedad
! Se identifican arquitecturas no modulares e inflexibles
! Se acerca más a la interpretación correcta de los
requerimientos
! Muestra como encajan de forma conjunta los elementos del
sistema
21 2011

22. Modelado Visual del Software
! Captura la estructura y comportamiento de arquitecturas y
componentes.
! Mantiene la consistencia entre los componentes, el diseño y
su implementación.
! Promueve una comunicación no ambigua en el equipo de
desarrollo
22 2011

23. Verificación de la Calidad del Software
! La calidad se toma en cuenta a lo largo de todo el proyecto
! Las pruebas se concentran en los aspectos de mayor riesgo y para
cada iteración
! Se reduce los costos de depuración
! Crea pruebas para cada escenario (Casos de Uso) para asegurar
que todos los requerimientos están propiamente implementados
23 2011

24. Verificación de la Calidad del Software
! Verifica la calidad del software con respecto a los
requerimientos basados en la confiabilidad,
funcionalidad, desempeño de la aplicación y del sistema
! No sólo la funcionalidad es esencial, también el
rendimiento y la confiabilidad
! El aseguramiento de la calidad es parte del proceso de
desarrollo y no la responsabilidad de un grupo
independiente
24 2011

25. Gestión del Cambio
! Los cambios son inevitables, pero es preciso
evaluar si éstos son necesarios y rastrear su
impacto
! Las solicitudes de cambios se logran con buena
comunicación
! La propagación del cambio es controlado
25 2011

26. Gestión del Cambio
! Controlar, llevar un registro y monitorear cambios para
permitir un desarrollo iterativo.
! Establecer espacios de trabajo seguros para cada
desarrollador
! Proveer aislamiento de cambios hechos en otros espacios
de trabajo
! Controlar todos los artefactos de software – modelos,
código, documentos, etc…
26 2011

27. Desarrollo Colaborativo
! Los sistemas son construidos por equipos de
personas
! Si estos equipos trabajan conjuntamente se
neutralizan los riesgos
! La metodologías ágiles han hecho un aporte
significativo para la comprensión de este
concepto
! Modelar con los otros, promociona la
efectividad
27 2011

28. Mas allá de un Desarrollo
! No sólo basta con construir un sistema sino
además que sea operado y soportado.
! Este sistema debe “calzar” dentro de la
organización
! Hay que asegurarse de que el sistema satisface
las expectativas del negocio
28 2011

29. Analizar el Problema
! Si analizamos el problemas ya comenzamos a construir la
solución correcta…..
29 2011

30. La regla del 1 - 10 - 100 1
Etapa
10
.1-.2 Requerimientos 100
0.5 Diseño
“Los resultados muestran una proporción
1 Codificación de costo de 200:1 entre detectar los
errores en los requerimientos o en la
2 Prueba Unitario etapa de mantenimiento organizado del
5 ciclo de vida del software.”
Prueba Aceptac.
20
Mantenimiento
Costo Relativo de Reparación Relación de Costos Promedio
Boehm ‘76, 88 14:1 Grady 1989
30 2 0 11

31. ¿Cómo pueden ser exitosos los
proyectos?
! Análisis del problema
! Entender el problema
! Obtener acuerdo con los involucrados.
! Obtener requerimientos
! Determinar quién usará el sistema (actores)
! Determinar cómo será usado el sistema (casos de uso)
! Gestión de Requerimientos
! Especificar requerimientos completamente
! Manejar las expectativas, cambios y errores
! Controlar cambios frecuentes de alcance
! Reclutar todos los miembros de su equipo
31 2 0 11

32. Análisis del Problema
! ¿Cuál es el problema?
! Entender la perspectiva del cliente
! Escribirla
! Obtener acuerdo en ello
! ¿Cuál es realmente el problema?
! Buscar las causas de raíz
! Enfocarse a la causa de raíz
32 2 0 11

33. ¿Por qué es importante analizar el
problema?
! Evitar el Sí ... pero ...
! Evitar trabajo extra
! Entender los requerimientos
! ¿Cuál es realmente el problema?
33 2 0 11

34. Definición de un problema
Un problema puede definirse como la
diferencia entre...
(Problema)
cosas como las cosas como se
y
son desean”
Gause & Weinberg, 1989 Turn Your Lights On !
34 2 0 11

35. Los actores ayudan a definir los
límites del sistema
¿Límites del
sistema?
PC
PC
Servidor
Servidor
PC PC
PC
¿Es el software del cliente parte del sistema?
¿o un actor?
Usuario
Final
35 2 0 11

36. Identifique las restricciones al
sistema
Políticos
Económicos
Ambientales
Técnicos
Factibilidad
Sistema
36 2 0 11

37. Establezca un vocabulario común
! Para definir términos usados en el proyecto
! Para ayudar a prevenir malos entendidos
• Comience pronto
• Actualícelo durante todo el proyecto
Glosario
37 2 0 11

38. Visión del Sistema
! Veamos su estructura
! Entrega el 5 de Octubre de 2012

39. Formulando la declaración del
problema
El problema de (describa el problema)
Afecta a (los involucrados afectados por el
problema)
Lo cual impacta a (cuál es el impacto del problema)
Una solución exitosa (liste algunos beneficios de una
solución exitosa)
39 2 0 11

40. Formulando la declaración del
problema
Ejemplo de Sistema de Soporte a Clientes
El problema de La inadecuada y extemporánea solución
de problemas de servicio del cliente
Afecta a Nuestros clientes, representantes de
soporte al cliente y técnicos de servicio
Lo cual impacta a Insatisfacción de los clientes, percepción de baja
calidad
Empleados insatisfechos y bajos ingresos
Una solución exitosa Proveería acceso en tiempo real a una B/D de
problemas por representante, facilitaría el
despacho oportuno de técnicos a los lugares
apropiados
40 2 0 11

41. Ejercicio N° 1
1. Elaboren el planteamiento del problema
2. En grupo y para la proxima clase,
documenten los puntos: 1, 2.1,
2.2.1,2.2.2,2.2.3 y 2.2.4 del documento
Vision del Sistema