Ciclo De Vida Grupos.docx

CICLO DE VIDA DEL DESARROLLO DE UN SOFTWARE

Generalidades La gran cantidad de organizaciones de desarrollo de software implementan metodologías para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un contrato. El estándar internacional que regula el método de selección, implementación y monitoreo del ciclo de vida del software es ISO 12207. Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software. Otros aplican técnicas de gestión de proyectos para la creación del software. Sin una gestión del proyecto, los proyectos de software corren el riesgo de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen sus metas en términos de funcionalidad, costes o tiempo de entrega, una gestión de proyectos efectiva es algo imprescindible. Algunas organizaciones crean un grupo propio (Software Engineering Process Group, abreviado SEPG) encargado de mejorar los procesos para el desarrollo de software en la organización.

Modelos de Desarrollo de Software Los modelos de desarrollo de software son una representación abstracta de una manera en particular. Realmente no representa cómo se debe desarrollar el software, sino de un enfoque común. Puede ser modificado y adaptado de acuerdo a las necesidades del software en proceso de desarrollo. Hay varios modelos para perfilar el proceso de desarrollo, cada uno de las cuales cuenta con pros y contras. El proyecto debería escoger el más apropiado para sus necesidades. En ocasiones puede que una combinación de varios modelos sea apropiado. Existen tres paradigmas de los modelos de desarrollo de software: 1. Paradigma Tradicional: Es uno de los paradigmas más antiguo, se inventó durante la creación del método estructurado. Si se elige un proyecto, el método varia en etapas.Como todo modelo, existen sus pros y contras al usar este paradigma:

Si se aplica este paradigma, unos de los principales problemas, es que las etapas realizadas no son autónomas de las siguientes, creando una dependencia estructural y en el caso de un error atrasaría todo el proyecto. Se tiene que tener pautas bien definidas, y que no se incurra a modificación porque implicaría en que el software no cumpla con su ciclo de vida. Tener en cuenta que el cliente no se vea afectado por la impaciencia. Paradigma de Desarrollo Ágil: Es un paradigma de las Metodologías De Desarrollo basado en procesos ágiles. Estos intentan evitar los tediosos caminos de las metodologías tradicionales enfocándose en las personas y los resultados. Usa un enfoque basado en el Valor para construir software, colaborando con el cliente e incorporando los cambios continuamente.

CICLO DE VIDA DEL DESARROLLO DE UN SOFTWARE

Modelo de cascada El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva: 1. 2. 3. 4. 5. 6. 7.

Especificación de requisitos Diseño del software Construcción o Implementación del software Integración Pruebas (o validación) Despliegue (o instalación) Mantenimiento

Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles. El desarrollo en cascada, también llamado modelo en cascada (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), 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. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.... De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy El "modelo cascada" sin modificar. El progreso fluye de arriba hacía abajo, como una cascada.

Ventajas     

Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se requiere de menos capital y herramientas para hacerlo funcionar de manera óptima. Es un modelo fácil de implementar y entender. Está orientado a documentos. Es un modelo conocido y utilizado con frecuencia. Promueve una metodología de trabajo efectiva: Definir antes que diseñar, diseñar antes que codificar

Desventajas    

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien. Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa anterior.

CICLO DE VIDA DEL DESARROLLO DE UN SOFTWARE

Modelo de espiral La principal característica del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala. La espiral se visualiza como un proceso que pasa a través de algunas interacciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades: 1. crear planes con el propósito de identificar los objetivos del software, seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software; 2. Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo; 3. la implementación del proyecto: implementación del desarrollo del software y su pertinente verificación; Modelo de espiral con énfasis en los riesgos, haciendo hincapié en las condiciones de las opciones y limitaciones para facilitar la reutilización de software, la calidad del software puede ayudar como una meta propia en la integración en el desarrollo del producto. Sin embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan: 1. El énfasis se sitúa en el análisis de riesgo, y por lo tanto requiere de clientes que acepten este análisis y actúen en consecuencia. Para ello es necesaria confianza en los desarrolladores así como la predisposición a gastar más para solventar los temas, por lo cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala. 2. Si la implementación del riesgo de análisis afectará de forma esencial los beneficios del proyecto, no debería utilizarse este modelo. 3. Los desarrolladores de software han de buscar de forma explícita riesgos y analizarlos de forma exhaustiva para que este modelo funcione. La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último, se evalúan los resultados y se inicia el diseño de la siguiente fase.

Desarrollo iterativo e incremental El desarrollo iterativo recomienda la construcción de secciones reducidas de software que irán ganando en tamaño para facilitar así la detección de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes que no saben cómo definir lo que quieren.5

Desarrollo ágil El desarrollo ágil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista más ligero y más centrado en las personas que en el caso de las soluciones tradicionales. Los procesos ágiles utilizan retroalimentación en lugar de planificación, como principal mecanismo de control. La retroalimentación se canaliza por medio de pruebas periódicas y frecuentes versiones del software.

Orientado a la Reutilización La reutilización de software es un proceso donde se recurre al uso de activos de software en las especificaciones de análisis, diseños, implementación y pruebas de una aplicación o sistemas de software La reutilización tiene ciertos Indicadores por ejemplo: 1. Entre el 40% y 60% de una aplicación es re-utilizable en otra. 2. Aproximadamente el 0% de una aplicación administrativa es re-utilizable. 3. Aproximadamente el 75% de las funciones son comunes a más de un programa. 4. Solo el 15% del código encontrado en muchos sistemas es único y novedoso a una aplicación especifica.

CICLO DE VIDA DEL DESARROLLO DE UN SOFTWARE

Modelos de mejora de procesos Capability Maturity Model Integration El Capability Maturity Model Integration (CMMI), en español «Integración de Modelos de Madurez de Capacidades» es uno de los modelos líderes basados en mejores prácticas. Son evaluaciones independientes las que confirman el grado con el que una organización siguen sus propios procesos, que no evalúa la calidad de los procesos o del software que se produce. CMMI ha reemplazado a CMM y tiene un ámbito global, no sólo en procesos destinados al desarrollo del software. ISO 9000 ISO 9000 describe estándares para un proceso organizado formalmente para resultar en un producto y los métodos de gestión y monitoreo del progreso. Aunque este estándar se creó inicialmente para el sector de producción, los estándares de ISO 9000 también se han aplicado al desarrollo del software. Al igual que CMMI, que una organización está certificada con el ISO 9000 no garantiza la calidad del resultado final, sólo confirma que se ha seguido los procesos establecidos. ISO 15504 ISO 15504, también conocido como Software Process Improvement Capability Determination (SPICE), en español «Determinación de la Capacidad de Mejora del Proceso de Software» es un marco para la evaluación de procesos de software. Este estándar tiene como objetivo un modelo claro para poder comparar procesos. SPICE se utiliza como en el caso de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el desarrollo del software. Este modelo se utiliza entonces para medir lo que una organización o proyecto hace durante el desarrollo del software. Esta información se analiza para identificar puntos débiles y definir acciones para subsanarlos. También identifica puntos fuertes que pueden adoptarse en el resto de la organización.

Las Normas ISO: Importancia y beneficios La implantación de las Normas ISO ayudan a que las empresas apliquen eficazmente las nuevas tecnología y gestionen adecuadamente los recursos que disponen. Resumen de los beneficios que nos ofrecen las Normas ISO: Podemos distinguir una serie de beneficios básicos y generales que nos aporta la utilización de las normas ISO por las PYMES y que ahora vamos a comentar: 









Las normas ISO no distinguen por tamaño o por dedicación a las empresas, por lo que les sirve de ayuda tanto a grandes organizaciones como a pequeñas empresas. No es necesario distinguir en dimensiones si se desea crecer y mejorar, ya que no sería lógico y efectivo. Gracia a que se consigue una igualación de las características básicas y se aplican unos procedimiento y registros que no diferencían entre países o leyes, se puede hablar un idioma común que mejora y abre los mercados de exportación para sus productos y servicios. Los procedimientos de aplicación y los registros que aportan las normas ISO permiten aplicar las técnicas empresariales más actuales y permite mejorar continuamente en la gestión de su negocio, impulsando la eficiencia en las operaciones de su organización. El adecuado control y gestión de sus relaciones comerciales con sus clientes, aumenta su credibilidad, consigue la fidelización de estos, aumentando las oportunidades de ventas y le da una ventaja competitiva frente a otros negocios del mercado. La aplicación de las normas ISO hacen que su empresa y su marca gane un reconocimiento internacional y proporciona el impulso que su organización necesita para emprender un crecimiento continuo y con grandes beneficios.

CICLO DE VIDA DEL DESARROLLO DE UN SOFTWARE

Métodos formales Los métodos formales son soluciones matemáticas para resolver problemas de software y hardware a nivel de requisitos, especificación y diseño. Ejemplos de métodos formales incluyen el Método B, la red de Petri, la demostración automática de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales, tales como el lenguaje Z. Más generalmente, se puede utilizar la teoría de autómatas para aumentar y validar el comportamiento de la aplicación diseñando un sistema de autómata finito. Las metodologías basadas en los autómatas finitos permiten especificación de software ejecutable y evitar la creación convencional de código. La formalización del desarrollo de software está ganando en fuerza poco a poco, en otros ámbitos, con la aplicación del lenguaje de especificación OCL2.0 (y especializaciones tales como Java Modeling Language) y particularmente con Model-driven Architecture, que permite la ejecución de diseños, incluso especificaciones. Otra tendencia que está surgiendo en el desarrollo de software es la redacción de especificaciones en algún tipo de lógica (normalmente una variación de FOL), para acto seguido ejecutar esa lógica como si se tratase de un programa. El lenguaje OWL, basado en lógica descriptiva, es un buen ejemplo. También se está trabajando en enlazar un idioma natural de forma automática con lógica, lógica que puede ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lógica de negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una características de los sistemas que apoyan el vínculo bidireccional inglés-lógica y ejecución directa de la lógica es que pueden explicar sus resultados en inglés en un nivel de negocios o científico.

Un método formal es un camino a la construcción y análisis de modelos matemáticos que permitan una automatización del desarrollo de sistemas informáticos. Los métodos formales se caracterizan por emplear técnicas y herramientas matemáticas para lograr una facilitación a la hora de encarar la construcción o el análisis de un modelo matemático de un sistema.

Ventajas Se comprende mejor el sistema.     

La comunicación con el cliente mejora ya que se dispone de una descripción clara y no ambigua de los requisitos del usuario. El sistema se describe de manera más precisa. El sistema se asegura matemáticamente que es correcto según las especificaciones. Mayor calidad en el software respecto al cumplimiento de las especificaciones. Mayor productividad.

Desventajas    

El desarrollo de herramientas que apoyen la aplicación de métodos formales es complicado y los programas resultantes son incómodos para los usuarios. Los investigadores por lo general no conocen la realidad industrial. Es escasa la colaboración entre la industria y el mundo académico, que en ocasiones se muestra demasiado dogmático. Se considera que la aplicación de métodos formales encarece los productos y ralentiza su desarrollo.

Principales Roles en el proceso de Desarrollo de Software Un Rol se define como una “Función que alguien o algo cumple” (Abstracta Academy, 2016). Cada uno de los roles aportará al grupo parte del total necesario para tener éxito en el desarrollo. Los roles son necesarios para cubrir todas las especificaciones necesarias para cumplir un proceso ya que no todos tenemos las mismas cualidades y experiencias. Además al asignar roles, se definen objetivos y actividades para cada uno; lo anterior evitando que alguna actividad no sea asignada o que dos personas realicen el mismo trabajo.

Descripción de roles en el Proceso de Desarrollo de Software El software se construye en equipo y hay muchas metodologías diferentes. Los roles se asignan de acuerdo a las capacidades de cada persona, así como también su especialización, experiencia e interés. Los roles más comunes son: Gerente de proyecto Tiene por función presentar informes sobre las litigaciones de riesgos, hacer cumplir los plazos y lleva el control de los costos. También organiza el equipo, realiza planificación y estima el tiempo de las actividades. En conclusión, resuelve problemas. Analista de requerimientos Se encarga del revelamiento de los requerimientos esenciales para el desarrollo del Software, la documentación de los requerimientos para así el resto del equipo lo pueda consulta en cualquier momento. Debe ser una persona con capacidad de abstracción y análisis. 



Desarrollador de software o programador Un programador de software (que “pica código” en base a unos requisitos) podríamos compararlo con un albañil de la construcción (que usa “el pico y la pala” siguiendo unos planos). Esto lo digo sin ánimo de ofender ni a programadores ni a albañiles jaja. Un desarrollador de software es (más o menos) lo mismo que un analista/programador (esto sería un programador —aquí parece que discrepo con algunas de las respuestas— que además es capaz de realizar análisis funcionales y definir los requisitos a partir de las necesidades del cliente, entre otras funciones) y podríamos compararlo con un Arquitecto Técnico (que en la construcción sería un profesional capaz de llevar a cabo la ejecución de una obra: instalaciones, estructuras, sistemas constructivos, topografía, organización de obra, economía, legislación, dirección de obra, calidad, seguridad, organización, materiales, dibujo, etc.). Testeador Diseña y ejecuta las pruebas, para ello requiere conocer el producto a probar claro esta, estudiar funcionalidad del producto y desarrollar las pruebas que revelen incidentes críticos. Reporta los incidentes y provee información sobre la calidad del sistema. Arquitecto de software Determina las estructuras de la aplicación y las tecnologías con las que se construirá la aplicación. Está encargado del aseguramiento de la calidad, mejorar continuamente la arquitectura. Gestiona los requerimientos no funcionales, asume la dirección técnica para asegurar que todos los aspectos de la arquitectura se estén desarrollando de manera correcta. Debe ser una persona con un innato sentido de liderazgo, dispuesto a formar a los integrantes del equipo, dispuesto a recibir y aplicar abiertamente recomendaciones.

Estudio De Viabilidad En Sistemas Informaticos. El objetivo principal de esta tema es ver si existe una solución factible al problema planteado y si merece la pena resolverlo o no. El estudio de viabilidad consta de: - viabilidad Técnica - viabilidad Económica y - viabilidad operacional el estudio de viabilidad tiene como salidas la presentación al usuario y la dirección de lo siguiente:Revisión del informe de alcance y objetivos, propuestas de soluciones viables, análisis costes-beneficios. ESTUDIOS DE VIABILIDAD TECNICA. Un nuevo SI es viable técnicamente si sus componentes existen o pueden crear con las herramientas disponibles. ESTUDIO DE VIABILIDAD ECONOMICA: Como cualquier proyecto, el diseño de un nuevo SI debe estar económicamente justificado. Es decir, durante la vida útil del sistema, los beneficios deben sobrepasar los costos; para este fin, los analistas preparan un análisis de Costo/ Beneficio, en una hoja de calculo que incluya todos los costos en que incurre el sistema y todo los beneficios que se espera de su operación. El método mas exacto de análisis económico es el de ganancias sobre inversión, un calculo de la diferencia entre el flujo de beneficios y el flujo de gastos sobre la vida del sistema, descontados por la tasa de interés aplicable para encontrar la ganancia sobre inversión, el valor neto presente del sistema se calcula combinando el valor neto presente de los costos del sistema con el valor neto presente de los beneficios del sistema, haciendo cálculos basados en costos y beneficios anuales y con la tasa de interés apropiada. Si la ganancia sobre inversión es positiva, el sistema resulta económicamente viable, o de costo justificado; recuerde que durante el tiempo de creación del sistema que puede ser de varios años, no hay beneficios, solo costos de creación; los costos operacionales durante la vida del sistema incluyen personal de mantenimiento, telecomunicaciones, proveedores de equipo de computo (para reemplazo de hardware en caso de problemas y actualización de software y para compra de papel y tinta ) y energía. ESTUDIO DE VIABILIDAD OPERACIONAL El propósito del estudio de viabilidad operacional es determinar si el nuevo sistema se usara como está planeado. De manera más especifica, este análisis responde a las siguientes preguntas: • ¿Se adecuara el sistema a la cultura de esta organización? • ¿Usaran todos los usuarios potenciales el sistema a su máxima capacidad? • ¿Afectara el sistema las políticas de la compañía o los estatutos?

Ventajas. - Atravez de un estudio de la viabilidad obtendremos un conjunto de requerimientos preliminares. - obtendremos una descripción resumida del sistema y de cómo este pretende contribuir con el negocio. - Tendremos un informe en el cual sabremos si valdra o no la pena seguir con la ingeniería de requerimientos y con el proceso del desarrollo del software.

CONDICIONES PREVIAS AL DISEÑO DE UN SISTEMA 

El primer paso para las condiciones de diseño del sistema, es la comunicación entre el Analista y el Usuario (un representante institucional, departamental o cliente particular), los cuales deben identificar las metas globales, analizando las perspectivas del cliente. necesidades y requerimientos que puedan ayudar a la identificación y desarrollo del proyecto.



Como segundo paso es la organización, la cual determina el cumplimiento del Sistema de Gestión de Calidad, por que en ella se integran los documentos de las auditorias, los procedimientos, instrucciones, programas, etc. Que deben tener un orden y un control de documentos por medio de las listas maestras.



Tercer paso es el diseño del software para que garantice que la organización que se estableció se mantenga y no genere hallazgos o inconformidades por no cumplir con las actividades.

 

Desarrollo de un Software para el control del Sistema de Gestión de Calidad: Características: i) Proveer una interfase única y de fácil navegación. ii) Registro e identificación de usuarios, ya sean éstos administradores o usuarios normales. iii) Creación y presentación de un diseño único de los servicios e información. iv) Permitir un acceso adecuado para las consultas, pero también para requerimientos más complicados como la generación de diversos reportes. v) Permitir un acceso adecuado a los usuarios e impedir el acceso a las personas no autorizadas. Requerimientos Técnicos: i)Asegurar una gran versatilidad, además de ser amplio y una gran flexibilidad. ii)Proveer un ambiente manejable y seguro. iii)Soportar un nivel de accesos amplio y flexible hacia las nuevas tecnologías Web y sin importar el sistema operativo con que se cuente. Modelado de la arquitectura del Sistema; Todos los Sistemas basados en computadoras pueden modelarse empleando una arquitectura del tipo entrada y salida de la información. La arquitectura de las Aplicaciones Web describe una infraestructura que permite a un sistema o aplicación basada en la misma, lograr sus objetivos de negocios. Las aplicaciones deben construirse con el uso de capas en las que se toma en cuenta las diferentes necesidades; en particular los datos de la aplicación se deben separar de los contenidos de la página (nodos de navegación), los cuales deben estar claramente separados de la apariencia y la percepción de la interfaz. Especificación del Sistema; Son un Documento que sirve como fundamento para la Ingeniería, Hardware, Software, Base de datos, e Ingeniería Humana. Describe la función y rendimiento de un Sistema basado en computadoras y las dificultades que estarán presentes durante su desarrollo. Las Especificaciones de los requisitos del software se producen en la terminación de la tarea del análisis. En Conclusión un proyecto de desarrollo de un Sistema de Información comprende varios componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno más de los componentes: software, hardware, personas, base de datos, documentación y procedimientos.