Sistemas de Informacion II

Modelos de Procesos

Repaso
Modelos de Procesos Modelo en Cascada Modelos Evolutivos
Prototipo Iterativo Incremental Espiral

IS basada en componentes Modelo Transformacional

Lic. Paola Piovano

Modelos de Procesos
Modelo en Cascada : considera las actividades del proceso y las representa como fases separadas Desarrollo Evolutivo: entrelaza las actividades de especificacin, desarrollo y validacin IS basada en componentes: se basa en la existencia de componentes reutilizables y su integracin
Estos modelos no se excluyen mutuamente y a menudo se utilizan juntos
Lic. Paola Piovano

Modelo de Cascada (MC)

Las actividades o etapas de desarrollo se organizan en cascada, una despus de la otra. El resultado de c/fase es uno o mas documentos aprobados La salida (output) de una etapa es la entrada (input) de la siguiente etapa. Las etapas se pueden dividir en actividades ejecutadas concurrentemente. Puede integrarse a ciclos de vida ms complejos

Lic Paola Piovano

Modelo en Cascada

Lic. Paola Piovano

MC - Ventajas
La ventaja es que la documentacin se produce en cada fase Es disciplinado En proyectos donde hay alta estabilidad es eficiente ya que se pueden encontrar errores de alto impacto en etapas tempranas y a bajo costo.

Lic. Paola Piovano

MC - Desventajas
Inflexibilidad al dividir en etapas. Es rgido y lineal. No provee anticipacin al cambio. Se deben hacer compromisos en etapas iniciales lo que hace dificil responder a los cambios en requerimientos de cliente El usuario interviene al principio y al final del proyecto. No permite implementaciones parciales. Se prueba al final y se retrasa asi la deteccin de errores crticos No apto para desarrollos agiles por la cantidad de dcocumentacin
Lic. Paola Piovano

El paradigma Evolutivo
Problema gap entre la definicin de requerimientos y la distribucin de la aplicacin. Estrategia Entregar algo y medir el valor agregado. Ajustar diseo y objetivos. Exponer implementacion inicial a comentarios del usuario y refinarla en nuevas versiones Iterar: desarrollo de versiones cada vez ms completas del software.

Lic Paola Piovano

Modelos Evolutivos
Las actividades de especificacion, desarrollo y validacion se entrelazan

Lic. Paola Piovano

Modelos Evolutivos: Conclusiones

Es efectivo porque satisface las necesidades inmediatas de los clientes. La especificacion se puede desarrollar en forma creciente. Sin embargo, el proceso no es visible -> dificil producir documentos que reflejen cada version. Estructuras deficientes -> los cambios continuos tienden a corromper la estructura del sw

Lic. Paola Piovano

Modelo de PROTOTIPO (MP)

Como primer desarrollo construir un prototipo para descartar. El prototipo es para validar requerimientos y resolver aspectos crticos del diseo. Objetivos Investigacin repetida de requerimientos y diseo. Reducir el riesgo que la aplicacin no se ajuste a las necesidades del cliente. Modelo orientado a proyectos donde no existe una buena definicin de requerimientos La revisin del prototipo puede resultar que se necesite revisar los requerimientos de las etapas anteriores.
Lic Paola Piovano
11

Modelo de Prototipos

Lic Paola Piovano

12

Modelo de Prototipos
Ventajas Extraccin de requerimientos incremental y buena interaccin con el cliente. Es til cuando los requerimientos son pobremente definidos o nadie conoce bien el dominio del problema. Desventajas El cliente ve el prototipo y lo confunde con el sistema real. Se toman decisiones rpidas para poder construir el prototipo, que son difciles de revertir Difcil saber en que momento el producto converger a la solucin El prototipo para descartar nunca se descarta. No hay especificacin del sistema.
Lic Paola Piovano
13

IS basada en componentes (CBSE)

CBSE se basa en la reutilizacin de componentes de sw y establece un marco de trabajo de integracin Las etapas del proceso intermedias (anlisi, diseo y desarrollo) difieren del resto de los modelos

Lic. Paola Piovano

CBSE
Anlisis de componentes -> dada la especificacin se buscan los componentes para satisfacer los requerimientos Modificacin de requerimientos -> se analizan los requerimientos en base a los componentes encontrados para determinar modificaciones necesarias Diseo del sistema con reutilizacin -> organizar un marco de trabajo segn los componentes Desarrollo e integracin -> la integracin forma parte del desarrollo

Lic. Paola Piovano

CBSE - Conclusiones
Ventaja - > reduce cantidad de sw a desarrollar, menos costos y menos riesgos Generalmente, permite una rapida entrega del sw Desventaja -> se deben hacer compromisos en los requerimientos y el sistema puede no cumplir la necesidad real del usuario

Lic. Paola Piovano

Modelo Iterativo Incremental

Consisten en de incrementos expandidos de un producto de sw operativo, conducidos por la evolucin determinada segn la experiencia operativa. Los incrementos se distribuyen a medida que se completan. Se conoce lo que se va a construir desde el comienzo pero planifica la entrega en etapas Es til cuando la definicin de requisitos es ambigua e imprecisa porque permite el refinamiento

Lic Paola Piovano

17

Modelo Iterativo Incremental

Lic Paola Piovano

18

Paradigma Iterativo Incremetal

Ventajas El usuario ve algo rpidamente. Se admite que se est construyendo el sistema y se piensa en su calidad desde el principio. Los ciclos van mejorando con las experiencias de los anteriores. YA que los servicios de mas prioridad se entregan primero, y los incrementos posteriores se integran a ellos, los servicios ms importantes resultan los ms probados .
Lic Paola Piovano
19

Paradigma Iterativo Incremetal

Desventajas
Es difcil mantener el foco. Los primeros incrementos entran en mantenimiento mientras se est desarrollando nuevos. Los incrementos deben ser relativamente pequeos y cada uno debe entregar funcionalidad del sistema Es difcil seguir procesos puramente iterativos incrementales.: recursos que se utilizan en diferentes partes del sistema

Lic. Paola Piovano

10

Modelo Espiral
Modelo Espiral - combina las actividades del desarrollo con la gestin del riesgo, para minimizar y controlar el riesgo.
Riesgo: circunstancias potencialmente adversas que pueden perjudicar el proceso de desarrollo y la calidad del producto. Administracin del riesgo: disciplina cuyos objetivos son manejar y eliminar los tems de riesgo (del software) antes que se transformen en amenaza.
Lic Paola Piovano
21

Modelo Espiral
Es cclico -> cada ciclo representa una fase del proceso del sw Es un meta-modelo. Estrategia: comenzar por los desarrollos de mayor riesgo.

Lic Paola Piovano

22

11

Lic Paola Piovano

23

Modelo Espiral
Primera etapa Se identifican los objetivos de la porcin del producto Plantear alternativas: comprar, disear, o reusar Segunda etapa Se evalan las alternativas y se identifican las reas de riesgo -> actividades asociadas a la evaluacion de riesgo Tercera etapa Consiste del desarrollo y verificacin del prximo nivel del producto. Cuarta etapa Se revisan los resultados para planificar la prxima vuelta de espiral.
Lic Paola Piovano
24

12

Modelo Espiral
Ventajas Constituye un enfoque realista del desarrollo de sistemas de software de gran escala. Desarrollador y cliente comprenden y manejan mejor los riesgos. Mantiene el enfoque sistemtico de los pasos sugeridos por el ciclo de vida de cascada, pero incorpora el marco de trabajo iterativo. Considera los riesgos tcnicos en todas las etapas, y aplicado adecuadamente, logra reducirlos.
Lic Paola Piovano
25

Modelo Espiral
Desventajas Requiere de habilidades para la evaluacin del riesgo, si un riesgo importante no se descubre pierde eficacia. No existe demasiada experiencia en su uso. Requiere un gran conocimiento de gestin por parte de quien dirige el proyecto Es un modelo complejo

Lic Paola Piovano

26

13

Modelo Transformacional
Modelo Transformacional est basado en especificaciones formales. Ve al desarrollo de sw como una secuencia de pasos que gradualmente transforma una especificacin en implementacin.
Requiere que se transformen los requerimientos informales en especificaciones formales: mtodos de especificacin formal. Pretende reducir errores automatizando pasos del desarrollo.
Lic Paola Piovano
27

Modelo Transformacional

Lic Paola Piovano

28

14

Modelo Transformacional
Ventajas Busca reusar y construir componentes reusables. Los cambios se hacen en la especificacin. Todo queda documentado. Garantiza resultados correctos. Desventajas El desarrollo de modelos formales es caro y lleva tiempo. Se requiere de estudios detallados y personal capacitado. Es difcil utilizar el modelo como medio de comunicacin con el cliente.
Lic Paola Piovano
29

PU Proceso Unificado (RUP)

Proceso de sw guiado por los Casos de Uso, de arquitectura centrica, iterativo e incremental

Lic. Paola Piovano

15

PU

Lic. Paola Piovano

PU
Metodo Unificado : reune y combina las mejores caracteristicas de los mtodos OO propuestos por los 3 autores y otros expertos El resultado fue el desarrollo del UML, Lenguaje Unificado de Modelado que contiene una notacin robusta para el modelado OO El UML proporciona la herramienta pero no el marco de trabajo del proceso El PU provee este marco La empresa Rational Corporation apoy y contrribuy para el desarrollo del proceso, de ah el nombre alternativo
Lic. Paola Piovano

16

UML

Lic. Paola Piovano

Fases del PU

Lic. Paola Piovano

17

Fases del PU
Inicio: CU preliminares, esquema tentativo de susbsistemas importantes Elaboracin: refina y expande CU preliminares, expande arquitectura, modelo de anlisis, modelo de diseo Construccin: implementacin en cdigo fuente, diseo y ejecucin de pruebas de unidad, integracin Transicin: pruebas de versiones beta, documentacin soporte, lanzamiento de incremento

Lic. Paola Piovano

Relacin de fases del PU con actividades genricas del marco de procesos

Lic. Paola Piovano

18

Productos de trabajo del PU

Lic. Paola Piovano

Lic. Paola Piovano

19

Desarrollo Agil
Un grupo de expertos, consultores y escritores reunidos en una organizacin la Alianza Agil Firman el Manifiesto Agil para desarrollo gil de sw
En esencia los mtodos giles son un intento por superar debilidades advertidas y reales en la IS convencional
Lic. Paola Piovano

Manifiesto Agil
Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar: A los individuos y su interaccin, por encima de los procesos y las herramientas. Al sw que funciona, por encima de la documentacin exhaustiva. La colaboracin con el cliente, por encima de la negociacin contractual. La respuesta al cambio, por encima del seguimiento de un plan. Aunque hay valor en los elementos de la derecha, valoramos ms los de la izquierda.
Lic. Paola Piovano

20

Valor del manifiesto

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades.
Lic. Paola Piovano

Valor del manifiesto

Desarrollar software que funciona ms que conseguir una buena documentacin.
La regla a seguir es .no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental..

Lic. Paola Piovano

21

Valor del manifiesto

La colaboracin con el cliente ms que la negociacin de un contrato Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito.

Lic. Paola Piovano

Valor del manifiesto

Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.

Lic. Paola Piovano

22

Agilidad
Propone una respuesta efectiva al cambio (insistencia en el cambio) Resalta la entrega rapida del sw operativo y le resta importancia a los productos de trabajo intermedio (no siempre es bueno) Adopta al cliente como una parte del equipo de desarrollo y trabaja para eliminar el nosotros y ustedes
Lic. Paola Piovano

Principios de procesos agiles

1) Resulta dificil predecir cuales requisitos del sw persistirn y cules cambiarn Idem con las prioridades del cliente 2) Para muchos tipos de sw el diseo y la construccin estn intercalados: ambas actividades se deben realizar de manera conjunta 3) El anlisis, el diseo y la construccin no son predecibles desde la planeacin
Proceso gil debe adaptarse en forma incremental
Lic. Paola Piovano

23

Lic. Paola Piovano

Modelos Agiles
PE: Programacion Extrema Scrum Crystal Methodologies Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Feature -Driven Development (FDD) Lean Development (LD)

Lic. Paola Piovano

24

PE
Utiliza un enfoque OO Es la ms destacada de los procesos giles de desarrollo de software Propone practicas para 4 actividades del marco de trabajo: planeacin, diseo, codificacin y pruebas

Lic. Paola Piovano

PE

Lic. Paola Piovano

25

Proceso PE
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementacin. 3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1

Lic. Paola Piovano

Practicas XP
El juego de la planificacin. Hay una comunicacin frecuente el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Entregas pequeas . Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio. Una entrega no debera tardar ms 3 meses.

Lic. Paola Piovano

26

Practicas XP
Metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema (conjunto de nombres que acten como vocabulario para hablar sobre el dominio del problema , ayudando a la nomenclatura de clases y mtodos del sistema). Diseo simple . Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto.

Lic. Paola Piovano

Practicas XP
Pruebas . La produccin de cdigo est dirigida por las pruebas unitarias. stas son establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios. Se mejora la estructura interna del cdigo sin alterar su comportamiento externo

Lic. Paola Piovano

27

Practicas XP
Programacin en parejas . Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor satisfaccin de los programadores, .) Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da
Lic. Paola Piovano

Practicas XP
40 horas por semana. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. ste es uno de los principales factores de xito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita.
Lic. Paola Piovano

28

Practicas XP
Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin para mantener el cdigo legible. El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se apoyan unas en otras El mrito de XP PE es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo
Lic. Paola Piovano

Otras metodologas giles

SCRUM: Est especialmente indicada para proyectos con un rpido cambio de requisitos. Sus principales caractersticas se pueden resumir en dos.: El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda caracterstica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin
Lic. Paola Piovano

29

Otras metodologas giles

Crystal Methodologies: Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reduccin al mximo del nmero de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del equipo, establecindose una clasificacin por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros)
Lic. Paola Piovano

Otras metodologas giles

Dynamic Systems Development Method (DSDM) : Define el marco para desarrollar un proceso de produccin de software. Sus principales caractersticas son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseo y construccin, y finalmente implementacin. Las tres ltimas son iterativas, adems de existir realimentacin a todas las fases.

Lic. Paola Piovano

30

Otras metodologas giles

Adaptive Software Development (ASD) : Sus principales caractersticas son: iterativo, orientado a los componentes software ms que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las caractersticas del software; en la segunda desarrollan las caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisin de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo
Lic. Paola Piovano

Otras metodologas giles

Feature -Driven Development (FDD) : Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseo e implementacin del sistema partiendo de una lista de caractersticas que debe reunir el software. Lean Development (LD): En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal caracterstica es introducir un mecanismo para implementar dichos cambios

Lic. Paola Piovano

31