Catalogo by Jorge

Autor: Jorge Zárate Martínez

Ciclos de vida - Autor: Jorge Zárate Martínez 1

2015

Ciclos de vida - Autor: Jorge Zárate Martínez 2

Ciclos de vida Catálogo Ingeniería de Software

Contenido Ciclos de Vida del Software: Tipo Estructurado.............................................................................................. 3 Modelo Lineal o Estructurado ............................................................................................................................ 4 Modelo Cascada ........................................................................................................................................................ 6 Modelo en V ................................................................................................................................................................ 8 Ciclos de vida del Software: Tipo Evolutivo.................................................................................................... 10 Modelo Iterativo .................................................................................................................................................... 10 Modelo Incremental ............................................................................................................................................. 13 Modelo Espiral ....................................................................................................................................................... 15 Modelo Prototipado ............................................................................................................................................. 19 Modelo Rational Unified Process.................................................................................................................... 24 Modelo Desarrollo Rápido de Aplicaciones .............................................................................................. 29 Modelo Evolutivo .................................................................................................................................................. 32 Ciclos de Vida del Software: Tipo Última Generación................................................................................. 34 Modelo Orientado a Objetos ............................................................................................................................. 35 Modelo TPS .............................................................................................................................................................. 38 Modelo Programación Extrema ...................................................................................................................... 43 Modelo SCRUM ....................................................................................................................................................... 49

Ciclos de vida - Autor: Jorge Zárate Martínez 3

Ciclos de Vida del Software: Tipo Estructurado

Ciclos de vida - Autor: Jorge Zárate Martínez 4

Modelo Lineal o Estructurado Descripción Definición y uso: En este modelo consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal Modelo orientado a identificar usuarios, deficiencias, metas, objetivos, insumos y factores. Se necesita: Analistas, diseñadores, programadores. Ventajas: La sencillez de su gestión y administración tanto económica como temporal, ya que se acomoda perfectamente a proyectos interno de una empresa para programa muy pequeños Desventajas: No es apto para desarrollos que superen mínimamente requerimientos de retroalimentación entre etapas, es decir, es muy costoso retomar una etapa anterior al detectar alguna falla

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 5

Digrama

1.1 Ciclo de vida Lineal

Ciclos de vida - Autor: Jorge Zárate Martínez 6

Modelo Cascada Descripción Definición y uso: Es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Modelo orientado en las actividades y documentos. Se necesita: Analistas, diseñadores, programadores. Ventajas: Ha sido muy usado y, por tanto, está ampliamente contrastado Desventajas: Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones El producto final obtenido puede que no refleje todos los requisitos del usuario.

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 7

Diagrama

1.2 Modelo Cascada

Ciclos de vida - Autor: Jorge Zárate Martínez 8

Modelo en V Descripción Definición y uso: En este modelo se describen los resultados y las actividades que deben realizarse durante el desarrollo del proyecto. Este modelo está orientado a la gestión de proyectos y creación de sistemas. Se necesita: Analistas, diseñadores, programadores. Ventajas: La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos Involucra al usuario en las pruebas Desventajas: Es difícil que el cliente exponga explícitamente todos los requisitos El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 9

Diagrama

1.3 Modelo en V 9

Ciclos de vida - Autor: Jorge Zárate Martínez 10

Ciclos de vida del Software: Tipo Evolutivo

Modelo Iterativo Descripción

Ciclos de vida - Autor: Jorge Zárate Martínez 11

Definición y uso: Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos. Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos. Modelo orientado a en proyectos en los que los requisitos no están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente. Se necesita: Analistas, diseñadores, programadores. Ventajas: Menor tasa de fallo del proyecto, mejor productividad del equipo, y menor cantidad de defectos, según demuestran estudios realizados sobre proyectos que han aplicado esta técnica. Permite manejar la complejidad del proyecto, apuntando a la resolución de los problemas por partes, y no caer en la inanición del “súper análisis” del producto.

Desventajas: 11

Ciclos de vida - Autor: Jorge Zárate Martínez 12

El uso de un desarrollo iterativo e incremental no garantiza por sí solo el éxito de su uso. Hay costos ocultos en su implementación, ya que se incorporan varias actividades a realizar por el equipo, y hay que saber medir ese impacto para no fracasar en el intento Diagrama

2.1 Modelo Iterativo

Ciclos de vida - Autor: Jorge Zárate Martínez 13

Modelo Incremental Descripción Definición y uso: Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Está orientado en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación Se necesita: Analistas, diseñadores, programadores. Ventajas: Resolución de problemas de alto riesgo en tiempos tempranos del proyecto. Visión de avance en el desarrollo desde las etapas iniciales del desarrollo. Obtención del feedback del usuario lo antes posible, para orientar el desarrollo al cumplimiento de sus necesidades y realizar todas las adaptaciones identificadas para cumplir con los objetivos planteados. Desventajas:

Ciclos de vida - Autor: Jorge Zárate Martínez 14

2.2 Modelo Incremental

Ciclos de vida - Autor: Jorge Zárate Martínez 15

Modelo Espiral Descripción Definición y uso: El modelo de ciclo de vida en Espiral consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no necesariamente ha de ser así. El modelo en espiral está orientado para proyectos largos, caros y complicados. Este modelo no fue el primero en tratar el desarrollo iterativo, pero fue el primer modelo en explicar las iteraciones. Para cada ciclo habrá cuatro actividades: 1. Determinar o fijar objetivos: a. Fijar también los productos definidos a obtener: requerimientos, Especificación, manual de usuario. b. Fijar las restricciones c. Identificación de riesgos del proyecto y estrategias alternativas para evitarlos d. Hay una cosa que solo se hace una vez: planificación inicial o previa 2. Análisis del riesgo: 15

Ciclos de vida - Autor: Jorge Zárate Martínez 16

a. Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos 3. Desarrollar, verificar y validar (probar): a. Tareas de la actividad propia y de prueba b. Análisis de alternativas e identificación de resolución de riesgos c. Dependiendo del resultado de la evaluación de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. 4. Planificar: a. Revisamos todo lo que hemos hecho, evaluándolo y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. El proceso empieza en la posición central. Desde allí se mueve en el sentido de las agujas del reloj. Hay cuatro tareas que también se deben cumplir: - La tarea de planificación: para definir recursos, responsabilidades, hitos y planificaciones - La tarea de determinación de objetivos: para definir los requisitos y las restricciones para el producto y definir las posibles alternativas

Ciclos de vida - Autor: Jorge Zárate Martínez 17

- La tarea de análisis de riesgos: para evaluar riesgos tanto técnicos como de gestión - La tarea de ingeniería: para diseñar e implementar uno o más prototipos o ejemplos de la aplicación Se necesita: Analistas, diseñadores, programadores. Ventajas: La ventaja más notoria de este modelo de desarrollo de software es que puede comenzarse el proyecto con un alto grado de incertidumbre, se entiende también como ventaja el bajo riesgo de retraso en caso de detección de errores, ya que se puede solucionar en la próxima rama del espiral. Desventajas: Algunas de las desventajas son: el costo temporal que suma cada vuelta del espiral, la dificultad para evaluar los riesgos y la necesidad de la presencia o la comunicación continúa con el cliente o usuario. Se observa que es un modelo adecuado para grandes proyectos internos de una empresa, en donde no es posible contar con todos los requerimientos desde el comienzo y el usuario está en nuestro mismo ambiente laboral

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 18

Diagrama

2.3 Modelo Espiral

Ciclos de vida - Autor: Jorge Zárate Martínez 19

Modelo Prototipado Descripción Definición y uso: Metodología para desarrollar aplicaciones que permite la participación directa del usuario en el diseño e implementación de un sistema de información. Está orientado al cliente, por ejemplo, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre máquina. Para este modelo de ciclo de vida se definen 6 etapas especiales: 1.- Plan rápido: Evaluar la petición del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es esencial que:1) El cliente participe en la evaluación y refinamiento del prototipo 2) El cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en la eficacia del prototipo. 19

Ciclos de vida - Autor: Jorge Zárate Martínez 20

2.- Modelo y Diseñado Rápido: Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos. Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar los dominios funcionales y de información del programa y desarrollar un método razonable de partición. La aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos. 3.- Construcción del prototipo: Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño procedimental detallado. 4.- Desarrollo, entrega, y Retroalimentación: El software del prototipo se crea, prueba y refina idealmente, los bloques de construcción de software preexisten se utilizan para crear el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementación de un prototipo que funcione es impracticable, es escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre-máquina usando una serie de hojas de historia.

Ciclos de vida - Autor: Jorge Zárate Martínez 21

5.-Comunicación: Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicación y sugiere modificaciones. Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales. 6.-Entrega del desarrollo final: Los pasos 4 y 5 se repiten interactivamente hasta que todos los requerimientos estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de producción. El paradigma de construcción del prototipo puede ser conducido con uno o dos objetivos en mente: 1) El propósito del PROTOTIPADO es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la producción de programas mediante el uso de métodos y técnicas de ingeniería de programación 2) El propósito de la construcción del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen sus méritos y ambos crean problemas Se necesita: Analistas, diseñadores, programadores. Ventajas: Permite la construcción del sistema con requisitos poco claros o cambiantes

Ciclos de vida - Autor: Jorge Zárate Martínez 22

El cliente recibe una versión del sistema en muy poco tiempo, por lo que lo puede evaluar, probar e, incluso, empezar a utilizarlo Se pueden introducir cambios en las funcionalidades del sistema en cualquier momento Involucra al usuario en la evaluación de la interfaz de usuario Se reduce el riesgo y la incertidumbre sobre el desarrollo Genera signos visibles de progreso, que se utilizan cuando existe una demanda en la velocidad del desarrollo Permite entender bien el problema antes de la implementación final Desventajas: El cliente puede quedar convencido con las primeras versiones y, quizás, no vea la necesidad de completar el sistema o rediseñarlo con la calidad necesaria. Requiere trabajo del cliente para evaluar los distintos prototipos y traducirlo en nuevos requisitos Requiere un tiempo adicional para definir adecuadamente el sistema. No se sabe exactamente cuánto será el tiempo de desarrollo ni cuantos prototipos se tienen que desarrollar Si un prototipo fracasa, el coste del proyecto puede resultar muy caro.

Ciclos de vida - Autor: Jorge Zárate Martínez 23

Diagrama

2.4 Modelo PROTOTIPADO

Ciclos de vida - Autor: Jorge Zárate Martínez 24

Modelo Rational Unified Process Descripción Definición y uso: El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias Semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura. Este proyecto está orientado a las siguientes situaciones: –Profesionales en el desarrollo de software. –Interesados en productos de software. –Profesionales en la ingeniería y administración de procesos de software.

Ciclos de vida - Autor: Jorge Zárate Martínez 25

–En proyectos de nuevos productos de software –En ciclos de desarrollo subsecuentes Este modelo tiene 4 etapas especiales las cuales se describen a continuación: Inicio (Incepción) El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto. Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto. Elaboración El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase. La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo. Construcción El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.

Ciclos de vida - Autor: Jorge Zárate Martínez 26

Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de la operaciones para optimizar costos, tiempo y calidad. Transición Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios. Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario. En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización. Se necesita: –Cliente. - Analista. –Programador. –Diseñador. Ventajas: La ventaja principal de RUP es que se basa todo en las mejores prácticas que se han intentado y se han probado en el campo. Mitigación temprana de posibles riesgos altos, progreso visible en las primeras etapas, temprana retroalimentación que se

Ciclos de vida - Autor: Jorge Zárate Martínez 27

ajuste a las necesidades reales. Gestión de la complejidad. Conocimiento adquirido en una iteración puede aplicarse de iteración a iteración. Desventajas: Por el grado de complejidad puede no resultar muy adecuado. El RUP es generalmente mal aplicado en el estilo cascada. Requiere conocimientos del proceso y de UML

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 28

Diagrama

2.5 Modelo RUP

Ciclos de vida - Autor: Jorge Zárate Martínez 29

Modelo Desarrollo Rápido de Aplicaciones Descripción Definición y uso: RAD por sus siglas en ingles Rapid Application development. Se trata de una adaptación del modelo tradicional en cascada en el que se logra el desarrollo rápido utilizando una construcción basada en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite crear un sistema completamente funcional dentro de periodos cortos de tiempo (entre 60 y 90 días). Es un modelo de diseño que se utiliza para el desarrollo de software y de sistemas de información en el menor tiempo posible. Se necesita: Analistas, diseñadores, programadores. Ventajas: Enfatiza ciclos de desarrollo extremadamente cortos. Tiene las ventajas del modelo clásico. Se asegura de que el producto entregado cumple las necesidades del cliente.

Ciclos de vida - Autor: Jorge Zárate Martínez 30

Desventajas: Solo se puede aplicar si el sistema se puede modularizar de forma que permita completarse cada una de las funciones principales en menos de tres meses Para proyectos grandes puede requerir muchos equipos de trabajo distintos Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias No resulta adecuado cuando los riesgos técnicos son elevados Se pueden tener problemas con la aceptación del prototipo

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 31

Diagrama

2.6 Modelo RAD

Ciclos de vida - Autor: Jorge Zárate Martínez 32

Modelo Evolutivo Descripción Definición y uso: Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. Este modelo se utiliza en proyectos de ventas Proyectos de Facturación y proyectos de Mercadeo. Se necesita: Analistas, diseñadores, programadores. Ventajas: Este modelo acepta que los requerimientos del usuario se pueden cambiar en cualquier momento. Es un modelo es muy útil cuando desconocemos la mayoría de los requerimientos iniciales o cuando los requerimientos no están completos. Busca reemplazar el viejo sistema con uno nuevo que tendría la propiedad de satisfacer los nuevos requerimientos lo más rápido posible. El desarrollo evolutivo es 100% compatible con el modelo cascada. Desventajas: 32

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 33

Modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulaciĂłn de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Diagrama

2.7 Modelo Evolutivo

Ciclos de vida - Autor: Jorge Zárate Martínez 34

Ciclos de Vida del Software: Tipo Última Generación

Ciclos de vida - Autor: Jorge Zárate Martínez 35

Modelo Orientado a Objetos Descripción Definición y uso: Al igual que la filosofía del paradigma de la programación orientada a objetos, en esta metodología cada funcionalidad o requerimiento solicitado por el usuario es considerado un objeto. Los objetos están representados por un conjunto de propiedades a los cuales denominamos atributos, por otra parte, al comportamiento que tendrán estos objetos los denominamos métodos. Vemos que tanto la filosofía de esta metodología, los términos utilizados en ella y sus fines, coinciden con la idea de obtener un concepto de objeto sobre casos de la vida real. Se necesita: -En este modelo se utilizan las llamadas fichas CRC (claseresponsabilidades-colaboración) como herramienta para obtener las abstracciones y mecanismo clave de un sistema analizando los requerimientos del usuario. -Programadores, analistas y diseñadores. Ventajas: La característica principal de este modelo es la abstracción de los requerimientos de usuario, por lo que este modelo es mucho más flexible que los restantes, que son rígidos en requerimientos y definición, soportando mejor la incertidumbre que los anteriores, aunque sin garantizar la ausencia de riesgos. 35

Ciclos de vida - Autor: Jorge Zárate Martínez 36

Favorece la reducción de la complejidad del problema que seamos abordar y permite el perfeccionamiento del producto. Desventajas: Su principal desventaja es que permite un desarrollo solapado e iterativo. La historia de los ciclos de vidas Orientados a Objetos va ligada a la evoluciones de los lenguajes de programación orientados a Objetos tales como: a finales de los 60's SIMULA, finales de los 70's Smalltalk-80, la primera versión de C+, Java de Sun(ahora Oracle) y C# de Microsoft a finales de los 80', comenzaron a consolidarse algunos métodos orientados a objetos.

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 37

Diagrama

3.1 Modelo Orientado a Objetos

Ciclos de vida - Autor: Jorge Zárate Martínez 38

Modelo Sistema de Procesamiento de Transacciones Descripción Definición y uso: Un sistema de procesamiento de transacciones (TPS por sus siglas en inglés) es un tipo de sistema de información que recolecta, procesa, almacena, exhibe modifica, cancela y recupera toda la información generada por las transacciones producidas en una organización. Son sistemas computarizados que efectúan y registran las transacciones diarias necesarias para dirigir el negocio, es decir, dan servicio a nivel operativo de la organización y se utilizan para producir un conjunto de informes programados con regularidad. Los gerentes necesitan los TPS para supervisar el estado de las operaciones internas y las relaciones de la empresa con el entorno externo. Los sistemas de información basan su trabajo principalmente en cuatro actividades: recolección o entrada, almacenamiento, procesamiento y salida de datos, estas características pueden describirse de manera más detallada: Entrada: Se denomina así a la captura o recolecta de datos en bruto, tanto del interior de la organización como de su entorno externo. La entrada puede ser manual o automática acorde al modelo de negocio, pero de la validez que contengan dichos datos dependerá en gran medida la veracidad y exactitud de la información de salida de donde fueron tomados estos datos. Almacenamiento: 38

Ciclos de vida - Autor: Jorge Zárate Martínez 39

Como su nombre lo indica es archivar esta información en algún medio para su posterior tratamiento, puede ir desde simples archivos a extensas y complejas bases de datos. Todo esto acorde a los propósitos de la organización y también en gran parte para el tratamiento que se les hará en el procesamiento de los mismos dentro de la empresa. Procesamiento: Supone la conversión de los datos en salidas útiles para los interesados (se cuenta la misma empresa en dependencias y áreas, como entre externos que también hagan uso de esta información acorde al modelo de negocio y la salida propuesta para los datos), este proceso se lleva a cabo mediante cálculos, análisis y operaciones que pueden variar su complejidad. Como en la entrada, el procesamiento también puede llevarse a cabo de manera manual o automática. Salida: Se entiende como salida en este caso la transferencia o distribución de la información procesada previamente, al personal que la utilizará o a las actividades para las que se utilizará. Casi siempre la salida de un sistema de información viene en forma de documentos y/o reportes. Éste “ciclo” se completa con un quinto paso descrito como Retroalimentación o Feedback Que es la salida que se devuelve al personal o dentro de algún tipo de proceso interno adecuado de la organización para ayudarle a evaluar o corregir la etapa de entrada en donde se 39

Ciclos de vida - Autor: Jorge Zárate Martínez 40

captaron estos datos, en caso de errores existe la necesidad de corregir estos, incluso no sólo los datos de entrada, sino también algún proceso que no satisfaga total o parcialmente la información de salida deseada o esperada. Se necesita: Programador, base de datos, analista y diseñador. Ventajas: Respuesta rápida: En este tipo de sistemas resulta crítico que los tiempos de respuesta sean cortos. Una empresa no puede permitirse tener clientes esperando por una respuesta; el tiempo total transcurrido desde que se inicia la transacción hasta que la misma se finaliza debe ser de unos pocos segundos o menos. Fiabilidad: Muchas organizaciones se basan fiabilidad en los SPT; un fallo en un SPT afectará negativamente a las operaciones o incluso parará totalmente el negocio. Para que un SPT sea efectivo, su tasa de fallos debe ser muy baja y en caso de fallo de un SPT, debe existir algún mecanismo que permita una recuperación rápida y precisa del sistema. Esto convierte en esencial la existencia de procedimientos de copia de seguridad y de recuperación de datos. Inflexibilidad: Un SPT requiere que todas las transacciones sean procesadas exactamente de la misma forma, independientemente del

Ciclos de vida - Autor: Jorge Zárate Martínez 41

usuario o la hora del día. Si los SPT fuesen flexibles, habría entonces demasiadas posibilidades de ejecutar operaciones no estandarizadas. Por ejemplo, una aerolínea comercial necesita aceptar de forma consistente reservas de vuelos realizadas por un gran número de agencias de viaje distintas; aceptar distintos datos de transacción de cada agencia de viajes supondría un problema. Operaciones Controladas: El SPT debe estar implementado siguiendo rigurosamente las normas de seguridad y control en el manejo de sus operaciones, en el fin de impedir el sabotaje del sistema de información. Algunos de los controles que debe tener son los siguientes: -Registro de los datos de cada transacción. -Respaldo de la información. -Capacidad de acceso restringido identificando los usuarios válidos y las operaciones disponibles para estos. Desventajas: -Su principal desventaja es su limitación ya que su capacidad de generar informes es limitada. Ofrecen registros básicos lo cual es un problema para los administradores quienes necesitan informes más sofisticados para poder comprender y analizar los datos. -Son intensivos en entradas y salidas de información, sus cálculos y procesos son poco sofisticados. 41

Ciclos de vida - Autor: Jorge ZĂĄrate MartĂnez 42

Diagrama

3.2 Sistema de Procesamiento de Transacciones

Ciclos de vida - Autor: Jorge Zárate Martínez 43

Modelo Programación Extrema Descripción Definición y uso: Usa un enfoque de Programación Orientada a Objetos cómo paradigma preferido de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en el contexto de 4 actividades estructurales: planeación, diseño, codificación y pruebas. Planeación: o también llamada juego de planeación inicia escuchando una actividad para recabar los requerimientos que permite que los miembros técnicos del equipo xp entiendan el contexto del negocio para el software y adquieran la sensibilidad de la salida y características principales y funcionalidades que se requieren.

Diseño: el diseño XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseño siempre se prefiere sobre una presentación más compleja. Además el diseño guía la implementación de una historia conforme se escribe, si el diseño de una historia se encuentra un problema de diseño difícil, XP

Ciclos de vida - Autor: Jorge Zárate Martínez 44

recomienda la creación inmediata de un prototipo de esa porción del diseño. Entonces, se implementa y se evalúa el prototipo de diseño, llamado solución en punta. El objetivo es disminuir el riesgo Cuando comience la implementación verdadera y evaluar las estimaciones originales para la historia que contiene el problema del diseño. En el rediseño el principal objetivo es controlar dichas modificaciones, sugiriendo pequeños cambios en el diseño que "son capaces de mejorarlo en forma radical". Sin embargo, debe notarse que el esfuerzo que requiere el rediseño aumenta en forma notable con el tamaño de la aplicación. Codificación: después de que las historias han sido desarrolladas y de que se ha hecho el trabajo de diseño preliminar, el equipo no inicia la codificación, sino que desarrolla una serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en curso. Una vez que creamos la prueba unitaria, el desarrollador está mejor capacitado para centrarse en lo que debe implementar para pasar la prueba, No se agrega nada extraño. Una vez que el código está terminado, se aplica de inmediato una prueba

Ciclos de vida - Autor: Jorge Zárate Martínez 45

unitaria, con lo que se obtiene de retroalimentación instantánea para los desarrolladores. En la codificación un concepto muy importantes es la programación en parejas así XP recomienda que dos personas trabajen juntas en una estación de trabajo con el objetivo de crear código para una historia. Esto da un mecanismo para la solución de problemas en tiempo real. A medida que la pareja de programadores terminan su trabajo, el código que desarrollan se integra con el trabajo de los demás. Así está estrategia de integración continua ayuda a evitar los problemas de compatibilidad e interfaces y brinda un ambiente de «prueba de humo» que ayuda a descubrir a tiempo los errores. Pruebas: Cómo ya se dijo de las pruebas unitarias antes de que comience la codificación es un elemento clave del enfoque de XP. Las pruebas unitarias que se crean deben implementarse con el usó de una estructura que permita automatizarlas (de modo que puedan ejecutarse en repetidas veces y con facilidad). Las pruebas de aceptación también llamadas pruebas del cliente, son especificadas por el cliente y se centran en las características y funcionalidades generales del sistema que son visibles y revisables por parte del cliente. Las pruebas de aceptación se derivan de las historias de los usuarios que se han implementado cómo parte de la liberación del software.

Ciclos de vida - Autor: Jorge Zárate Martínez 46

Se necesita: -En este modelo se utilizan las llamadas fichas CRC (claseresponsabilidades-colaboración) como herramienta para obtener las abstracciones y mecanismo clave de un sistema analizando los requerimientos del usuario.

-Programadores, analistas y diseñadores. 46

Ciclos de vida - Autor: Jorge Zárate Martínez 47

Ventajas: Al tener un desarrollo n-iteraciones, permite tener la capa lógica de la capa del negocio y la capa de presentación, según el número de capas con la que se desarrolla, esto facilita la mantenibilidad y escalabilidad de las aplicaciones. La recodificación es el fuerte más grande de la metodología, permitiendo optimizar aún más el código. Desventajas: Se debe fijar una serie de reglas generales en la comunicación con el cliente ya que por el grado de informalidad que la metodología presenta, puede surgir diferencias que pongan en peligro la culminación exitosa del proyecto. Debe hacerse una capacitación al cliente sobre XP antes de iniciar el proyecto debido que este hace parte del equipo de desarrollo. El código debe ser lo más sencillo, con el fin de que esta pueda someterse a cambios, en el caso de ser necesario y estos no sean tan complejos realizarlos.

Ciclos de vida - Autor: Jorge Zárate Martínez 48

Diagrama

3.3 Programación Extrema (XP)

Ciclos de vida - Autor: Jorge Zárate Martínez 49

Modelo SCRUM Descripción Definición y uso: SCRUM es un proceso ágil que se puede usar para gestionar y controlar desarrollos complejos de software y productos usando prácticas iterativas e incrementales. SCRUM es un proceso incremental iterativo para desarrollar cualquier producto o gestionar cualquier trabajo. Aunque SCRUM estaba previsto que fuera para la gestión de proyectos de desarrollo de software, se puede usar también para la ejecución de equipos de mantenimiento de software o como un enfoque de gestión de programas. Estas unidades iterativas se llaman SPRINTS. Se sugiere que un sprint tenga una duración mínima de una semana y una máxima de cuatro SCRUM aparece como una práctica destinada a los productos tecnológicos y será en 1993 cuando realmente Jeff Sutherland aplique un modelo de desarrollo de Software en Ease/Corporation. Una parte muy importante de SCRUM son las reuniones que se realizan durante cada una de las iteraciones. Hay distintos tipos: - SCRUM diario: cada día durante la iteración, tiene lugar una reunión de estado del Proyecto. A esta reunión se le domina SCRUM - Reunión de planificación de iteración (sprint): se lleva a cabo al principio del ciclo de la iteración. 49

Ciclos de vida - Autor: Jorge Zárate Martínez 50

- Reunión de revisión de iteración: al final del ciclo de la iteración. - Iteración retrospectiva: al final del ciclo de la iteración Se necesita: Analistas, diseñadores, programadores. Ventajas: -Una de las mayores ventajas de SCRUM es que es muy fácil de entender y requiere poco esfuerzo para comenzar a usarse. Desventajas: -En general, dificultad de aplicación en grandes proyectos. -Se requiere de un “agile champion”, experto en la metodología que monitorice su cumplimiento. Diagrama

3.4 Modelo ágil SCRUM 50

Ciclos de vida - Autor: Jorge Zárate Martínez 51

Descripción de las etapas de los ciclos de vida: Análisis de requisitos En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD. Diseño del Sistema Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software). Diseño del Programa Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. Codificación Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido. Pruebas Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que

Ciclos de vida - Autor: Jorge Zárate Martínez 52

cumple con los requisitos, antes de ser entregado al usuario final. Verificación Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo Mantenimiento Una de las etapas más críticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas. Especificación: Es la etapa en la que se recopila, examina y formulan los requisitos del cliente y examina cualquier descripción que se pueda aplicar. Diseño del Sistema (funcional): Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Implementación Consiste en la puesta en producción del software construido durante las etapas previas del ciclo de vida.