Systems Development Life Cycle

El ciclo de vida de desarrollo de un sistema, CVDS (en inglés, SDLC), es un proceso lógico utilizado en el mundo del desarrollo de software de sistemas para desarrollar un sistema de información, incluidos los requisitos, la validación, formación, como los usuarios (interesados) en la propiedad. Cualquier CVDS debe resultar en un sistema de alta calidad que cumple o excede las expectativas del cliente, llega a término en el tiempo y estimaciones de costos, sea barato de mantener y rentable.

Los sistemas informáticos son complejos y muchas veces (especialmente con el aumento reciente de Service-Oriented Architecture) están vinculados entre fabricantes de software diferentes. Para gestionar este nivel de complejidad, una serie de sistemas de ciclo de vida de desarrollo (CVDS ) se han creado: «Cascada», «Fuente», «Espiral», «Construir y arreglar», «Prototipado rápido», «Incremental», «sincronizar y estabilizar», etc.

También existen las metodologías ágiles, como XP y Scrum, que se centran en los procesos de peso ligero, permitiendo la rápida evolución a lo largo del ciclo de desarrollo.

Metodologías iterativas, como Rational Unified Process (RUP), se centran en los ámbitos del proyecto limitado y la mejora o expansión de los productos de múltiples iteraciones.

Secuencial o de gran diseño inicial (BDUF) modelos, como la cascada, se centran en la planificación completa y correcta para guiar a los grandes proyectos al éxito, disminuyendo los riesgos. Algunos defensores de la metodología ágil e iterativa confunden la palabra CVDS con procesos secuenciales o «más tradicionales», sin embargo, CVDS es un término para todas las metodologías y cubre todas las etapas como el diseño, implementación y puesta en libertad de software.

En la gestión de proyectos se definen el ciclo de vida del proyecto (PLC) y el CVDS, durante el cual suceden actividades ligeramente diferente ocurrir. Según Taylor (2004) «el ciclo de vida del proyecto abarca todas las actividades del proyecto, mientras que el ciclo de vida de desarrollo de sistemas se centra en el cumplimiento de los requisitos de los productos».

El ciclo de vida de desarrollo de sistemas (CVDS) es un tipo de metodología utilizada para describir el proceso para la construcción de sistemas de información, destinado a desarrollar sistemas de información de un modo muy deliberado, estructurado y metódico, reiterando cada etapa del ciclo de vida. El ciclo de vida de desarrollo de sistemas, de acuerdo con Elliott & Strachan y Radford (2004), "se originó en la década de 1960 para desarrollar sistemas de gran escala funcional de negocio en una época de conglomerados empresariales a gran escala. Sistemas de información giró en torno a las actividades de procesamiento de datos pesados y crujido de número rutinas". Varios sistemas de marcos de desarrollo se han basado en parte en CVDS, tales como el análisis de sistemas estructurados y Método de Diseño (SSADM) elaborado para el gobierno del Reino Unido Office of Government Commerce, en la década de 1980. Desde entonces, según Elliot (2004), "los enfoques tradicionales de ciclo de vida para el desarrollo de sistemas han sido sustituidos cada vez con enfoques alternativos y los marcos, que intentó superar algunas de las deficiencias inherentes al CVDS tradicional".

Desarrollo de Sistemas de Ciclo de Vida (CVDS) se adhiere a las fases importantes que son esenciales para los desarrolladores, tales como la planificación, análisis, diseño y ejecución. Existen varios sistemas para el Desarrollo del Ciclo de Vida. El modelo más antiguo, que fue considerado como "el Sistema para el Desarrollo del Ciclo de Vida" es el modelo en cascada: una secuencia de etapas en las que la salida de cada etapa se convierte en la entrada para el siguiente. Estas etapas suelen seguir los mismos pasos básicos, pero muchas metodologías diferentes en cascada suelen tener los mismos pasos con diferentes nombres y el número de pasos parecen variar entre 4 y 7. No hay un modelo definitivo para el desarrollo de ciclo de vida de un sistema, pero todas las opciones tienen el mismo propósito.

El CVDS se puede dividir en diez fases durante las cuales se definen los productos de TI de trabajo creados o modificados. La décima etapa se produce cuando el sistema se elimina y la tarea realizada se eliminan o se transfieren a otros sistemas. Las tareas y los productos de trabajo para cada fase se describen en los capítulos siguientes. No en todos los proyectos será necesario que las fases se ejecuten secuencialmente. Sin embargo, las fases son interdependientes. Dependiendo del tamaño y la complejidad del proyecto, las fases se pueden combinar o puede alternar.

Para generar una visión de alto nivel del proyecto y pretender determinar los objetivos del proyecto. El estudio de viabilidad se utiliza a veces para presentar el proyecto a la alta dirección en un intento de obtener financiación. Los proyectos son evaluados en tres áreas de viabilidad: económica, operativa y organizativa y técnica. Además, también se utiliza como referencia para mantener el proyecto en marcha y evaluar los avances del equipo de MIS. El MIS es también un complemento de esas fases. Esta fase se denomina también como fase de análisis.

Operaciones y mantenimiento

Vida de temas de desarrollo de sistemas de ciclo
Gestión y control

Los sistemas de ciclo de vida del desarrollo (secuencias de comandos) fases servir de guía programática para la actividad del proyecto y proporcionar una manera flexible pero coherente para llevar a cabo proyectos a una profundidad de juego el alcance del proyecto. Cada uno de los objetivos de la fase secuencias de comandos se describen en esta sección con los resultados clave, una descripción de las tareas recomendadas, y un resumen de los objetivos de control relacionados para la gestión eficaz. Es fundamental para el gestor de proyecto para establecer y supervisar los objetivos de control en cada fase de secuencias de comandos, mientras que la ejecución de proyectos. Los objetivos de control de ayudar a proporcionar una declaración clara de los resultados deseados o el propósito y debe ser utilizado durante todo el proceso de secuencias de comandos entero. Objetivos de control pueden agruparse en categorías principales (dominios), y se refieren a las fases de secuencias de comandos como se muestra en la figure.9 Para la gestión y el control de cualquier iniciativa secuencias de comandos, cada proyecto será necesario establecer algún grado de una estructura de desglose de trabajo (WBS) para la captura y el calendario de los trabajos necesarios para completar el proyecto. La WBS y todo el material programático debe mantenerse en la sección "Descripción del proyecto" de la portátil del proyecto. El formato de PEP es sobre todo a la izquierda al jefe de proyecto para establecer en la forma que mejor describe el trabajo del proyecto. Hay algunas áreas clave que deben definirse en el PEP como parte de la política de secuencias de comandos. El diagrama siguiente se describen tres áreas clave que se abordarán en la WBS en una forma establecida por el proyecto mánager.

La sección superior de la estructura de desglose de trabajo (WBS) debe identificar las principales fases y los hitos del proyecto en forma de resumen. Además, la sección superior debería proporcionar una visión general de todo el alcance y el calendario del proyecto y será parte del esfuerzo inicial descripción del proyecto que conduce a la aprobación de proyectos. La sección central de la EDT se basa en los siete sistemas de Desarrollo del Ciclo de Vida (secuencias de comandos) fases como una guía para el desarrollo de tareas EDT. Los elementos PEP debe consistir de los hitos y las "tareas" en oposición a las "actividades" y tienen un período definitivo (generalmente dos semanas o más). Cada tarea debe tener una salida medibles (por ejemplo, el documento, decisión, o análisis). Una tarea PEP puede basarse en una o más actividades (por ejemplo, ingeniería de software, ingeniería de sistemas) y puede requerir una estrecha coordinación con otras tareas, ya sean internos o externos al proyecto. Cualquier parte del proyecto que necesitan el apoyo de los contratistas deben tener una declaración de trabajo (SOW) por escrito para incluir las tareas adecuadas de las fases secuencias de comandos. El desarrollo de una Declaración de trabajo no se producen durante una fase específica de secuencias de comandos, pero se ha desarrollado para incluir los trabajos del proceso de secuencias de comandos que podrá ser realizada por recursos externos, como contractors.

Las líneas de base son una parte importante de los Sistemas de Ciclo de Vida de Desarrollo (secuencias de comandos). Estas líneas de base se estableció después de que cuatro de las cinco fases del secuencias de comandos y son esenciales para la naturaleza iterativa del modelo 10. Cada línea de base se considera como un hito en el secuencias de comandos. • Funcional de referencia: establecido después de la fase de diseño conceptual. • Asignado de referencia: establecido después de la fase de diseño preliminar. • Producto de referencia: establecido después de que el diseño de detalle y la fase de desarrollo. • Actualización de productos de referencia: establecido después de la fase de construcción de la producción.

Métodos complementarios de desarrollo de software para desarrollo de sistemas de Ciclo de Vida (secuencias de comandos) son: • Software de prototipos • Aplicaciones de diseño mixto (JAD) • Desarrollo rápido de aplicaciones (RAD) • Extreme Programming (XP), extensión de los trabajos anteriores en los prototipos y RAD. • Open Source Development • Terminar con el desarrollo de usuario • Programación Orientada a Objetos Comparación de Metodologías (Post, y Anderson 2006) 11

secuencias de comandos RAD Open Source Objetos JAD prototipos para el usuario final Control formal MIS débil Normas conjunto de usuarios del usuario Plazos Largo Corto Medio a corto Corto Mediano Muchos usuarios Varía Pocas Pocas Pocas Una o Dos Uno Cientos de personal MIS Pocas Muchas Split Pocos Ninguno de uno o dos Transacción / DSS transacciones Ambos Ambos Ambos DSS DSS DSS Interfaz Minimal Minimal débil Windows crucial crucial Documentación y formación Vital internos limitados en objeto limitado débil Ninguno La integridad y la seguridad Vital objeto limitado Desconocido En débil débil Reutilización limitada, algunos Quizá Vital Limitada débil Ninguno

Fortalezas y debilidades

Pocas personas en el mundo de la computación moderna utilizan un modelo en cascada estrictas para su desarrollo de sistemas del ciclo de vida (secuencias de comandos), como muchas metodologías modernas han sustituido este pensamiento. Algunos dirán que el secuencias de comandos ya no se aplica a los modelos como el Agile development, pero todavía es un término ampliamente utilizado en los círculos tecnológicos. La práctica de secuencias de comandos tiene ventajas en los modelos tradicionales de desarrollo de software, que se presta más a un ambiente estructurado. Las desventajas de usar la metodología secuencias de comandos es cuando hay necesidad de un desarrollo iterativo o (es decir, el desarrollo web o e-commerce) donde los interesados tienen la necesidad de revisar periódicamente el programa que se está diseñando. En lugar de ver secuencias de comandos desde una perspectiva de fuerza o debilidad, es mucho más importante tener las mejores prácticas del modelo de secuencias de comandos y aplicarlo a todo lo que puede ser más apropiado para el software se está diseñando. Una comparación de las fortalezas y debilidades de secuencias de comandos: Fortalezas y debilidades de secuencias de comandos 11

Fortalezas Debilidades Control. El aumento de tiempo de desarrollo. Los proyectos de monitor de gran tamaño. El aumento de los costes de desarrollo. Pasos detallados. Los sistemas deben ser definidos desde el principio. Evaluar los costos y objetivos de conclusión. La rigidez. Documentación. Difícil estimar los costos, los sobrecostos del proyecto. Bien definido de entrada del usuario. La entrada del usuario es a veces limitado. Facilidad de mantenimiento. Desarrollo y diseño de las normas. Tolera los cambios en la dotación de personal de MIS. Una alternativa a la secuencias de comandos se desarrolló rápido de aplicaciones, que combina la creación de prototipos, Joint Application Development y la aplicación de herramientas CASE. Las ventajas de RAD son la velocidad, la reducción de los costes de desarrollo, y la participación activa del usuario en el proceso de desarrollo. No debe suponerse que solo porque el modelo en cascada es la más antigua secuencias de comandos modelo original que es el sistema más eficiente. En un momento en que el modelo fue beneficiosa sobre todo para el mundo de la automatización de actividades que fueron asignados a los empleados y contables. Sin embargo, el mundo de la evolución tecnológica exige que los sistemas tienen una mayor funcionalidad que ayude a ayudar a los técnicos al servicio de asistencia a los administradores o especialistas en tecnologías de la información / analistas.

COMPLEMENTO DE LEER.

Introducción Un proyecto de ingeniería de software involucra a las personas guiadas por objetivos comunes y estrategias de trabajo con una colección de herramientas para producir documentos y código. Las herramientas incluyen compiladores, depuradores, entornos de gestión de cambios, control de código fuente, gestión de proyectos, procesadores de documentos, y herramientas de modelado de dominio. Los documentos producidos incluyen los requisitos que definen el problema, los manuales de los clientes, planes de prueba, los escenarios, un diseño que define la arquitectura, y los planes de ejecución. El código puede hacer frente a objetos, estructuras de datos, algoritmos, métodos, módulos, protocolos, y las definiciones de interfaz. Las estrategias se materializan a través de la recopilación de la arquitectura, los métodos, los paradigmas, análisis de riesgos, convenios y una declaración de misión. Estas medidas en conjunto a definir la cuna a la tumba del ciclo de vida del proyecto de software. Hay cuatro fases fundamentales en la mayoría, si no todas, las metodologías de ingeniería de software. Estas fases son: análisis, diseño, implementación y pruebas. Estas fases frente a lo que se va a construir, cómo se va a construir, la construcción, y por lo que es de alta calidad. La fase de análisis La fase de análisis se definen los requisitos del sistema, independiente de cómo estos requisitos se llevará a cabo. Esta fase se define el problema de que el cliente está tratando de resolver. El resultado a entregar al final de esta fase es un documento de obligación. Idealmente, este documento indica de manera clara y precisa lo que se va a construir. Este análisis lo que representa el ``fase. El documento de obligación trata de captar las necesidades desde la perspectiva del cliente mediante la definición de objetivos y de las interacciones a nivel retirado de los detalles de implementación. El documento de obligación puede ser expresada en un lenguaje formal basado en la lógica matemática. Tradicionalmente, el documento de obligación está escrito en inglés o en otro idioma escrito. El documento requisito no se especificarán los detalles de arquitectura o de aplicación, pero especifica la información en el nivel superior de la descripción. El enunciado del problema, las expectativas del cliente, y los criterios de éxito son ejemplos de descripciones de alto nivel. Hay una línea difusa entre descripciones de alto nivel y los detalles de bajo nivel. A veces, si un detalle exacto de ingeniería debe ser determinado, este detalle también aparecerá en el documento de obligación. Esta es la excepción y no debería ser la norma. Estas excepciones se producen por muchas razones, incluido el mantenimiento de la coherencia con otros sistemas establecidos, la disponibilidad de opciones particulares, las demandas del cliente, y establecer, en el nivel de exigencia, una visión de la arquitectura en particular. Un ejemplo de un detalle de bajo nivel que podrían aparecer en el documento de requisitos es el uso de la línea de productos de un fabricante concreto, o el uso de algunos norma aceptada de la industria informática, o una limitación en el tamaño de la imagen de la aplicación. Hay un conflicto fundamental entre los niveles altos y bajos niveles de detalle. El documento de obligación de los Estados lo que el sistema debe cumplir, independiente de muchos de los detalles. El proceso de descubrimiento utilizado en el establecimiento de los requisitos durante la fase de análisis se describe mejor como un proceso de refinamiento que como los niveles de proceso detalle Tradicionalmente, el documento describe el requisito de las cosas en el sistema y las acciones que se pueden hacer en estas cosas. Las cosas pueden ser expresadas como objetos en un objeto de la tecnología basada en datos y algoritmos, se esconden detrás jerárquico métodos polimórficos. Alternativamente, las cosas podrían ser expresado como los servicios de acceso a bases de datos en un enfoque funcional, donde los datos es un concepto radicalmente diferente de las funciones. En general, la descripción de las cosas en el sistema puede ser mucho más general y no limitarse a una tecnología en particular. En un sentido más general, este documento describe la ontología que los sintagmas nominales y las frases verbales que se convertirán en las directrices para definir la aplicación de protocolo específico. Las descripciones de los requisitos de las cosas en el sistema y sus acciones no implica un diseño de arquitectura más bien una descripción de los artefactos del sistema y cómo se comportan, desde la perspectiva del cliente. Más tarde, en la fase de diseño, estas descripciones requisito se asignan en ciencias de la computación basada en las primitivas, tales como listas, pilas, árboles, gráficos, algoritmos y estructuras de datos. La descripción de la abstracción de los sintagmas nominales y las frases verbales no están obligados a la utilización de un lenguaje humano, por escrito. La mayoría de las lenguas escritas humanos son demasiado vagas para capturar la precisión necesaria para construir un sistema. Mecanismos alternativos descriptivo basado en la lógica matemática son a veces más adecuado, pero mucho más difícil de lograr. La lógica matemática proporciona una base científica para expresar con precisión la información. Sin embargo, con frecuencia en el mundo real, una descripción precisa es alcanzable. Una vez más el documento de requisitos debe indicar de manera clara y precisa lo que se va a construir. El mecanismo definitivo al autor de dicho documento, ya sea formal o informalmente, aún no se ha desarrollado, aunque bastante éxito se ha logrado con los métodos existentes, incluyendo las herramientas CASE y herramientas basadas en la lógica matemática Más tarde, en la fase de diseño, la descomposición muy importante del problema conduce al desarrollo de estructuras de datos y algoritmos. La descomposición funcional para un entorno distribuido conduce a una división natural de las estructuras de datos y algoritmos. Algunos ejemplos son distribuidos los sistemas cliente-servidor, donde una base de datos contiene los datos en un servidor, mientras que los algoritmos de manipulación de los datos que residen en el cliente. Un objeto basado en la descomposición natural lleva a una unión de estructuras de datos y algoritmos de formación de objetos con métodos. Los documentos requisito debe ser independiente de la técnica de descomposición. El equipo de análisis se desarrolla el documento de obligación, que habla de las cosas y las acciones sobre las cosas. Este documento debería incluir también los estados, eventos, escenarios típicos de uso, y escenarios típicos de uso de La fase de diseño En la fase de diseño de la arquitectura se ha establecido. Esta fase se inicia con el documento emitido por el requisito de la fase de requisito y mapas de los requisitos en la arquitectura. La arquitectura define los componentes, sus interfaces y comportamientos. El documento de diseño de realización es la arquitectura. El documento de diseño describe un plan para aplicar los requisitos. Esta fase representa la `` cómofase. Los detalles sobre los lenguajes de programación y entornos, máquinas, paquetes, arquitectura de aplicaciones distribuidas capas de la arquitectura, tamaño de la memoria, la plataforma, algoritmos, estructuras de datos, se establecen las definiciones de tipo global, interfaces, y muchos otros detalles de ingeniería. El diseño puede incluir el uso de componentes existentes. El equipo de arquitectura ahora puede ampliar la información establecida en el documento de obligación. Uso de la típica y una hipótesis típica prevista en el documento de requisitos, el desempeño del comercio-offs puede llevarse a cabo, así como la complejidad de la aplicación del comercio-offs. Obviamente, si una acción se hace muchas veces, es necesario que se haga correctamente y de manera eficiente. Una acción rara vez se utiliza debe aplicarse correctamente, pero no es evidente cuál es el nivel de cumplimiento es obligatorio. El documento requisito que debe guiar este proceso de decisión. Un ejemplo de una acción rara vez se utiliza la que se debe hacer con el alto rendimiento es el cierre de emergencia de un reactor nuclear. Analizar las ventajas y desventajas de la necesaria complejidad permite muchas cosas para seguir siendo sencillo, que, a su vez, conducirá finalmente a un producto de mayor calidad. El equipo de arquitectura también convierte los escenarios típicos en un plan de prueba. En nuestro enfoque, el equipo, teniendo en cuenta un documento de obligación de completar, también debe indicar las prioridades fundamentales para el equipo de aplicación. Una prioridad fundamental de aplicación conduce a una tarea que tiene que ser bien hecho. Si falla, el producto falla. Si tiene éxito, el producto podría tener éxito. Por lo menos, el nivel de confianza del equipo de producción de un producto de éxito se incrementará. Esto mantendrá el equipo de implementación focalizada. Exactamente cómo se transmite la información es una técnica basada en la experiencia más que una ciencia basada en fundamentos fundamentales. La fase de ejecución En la fase de ejecución, el equipo desarrolla los componentes ya sea desde cero o por la composición. Teniendo en cuenta el documento de la arquitectura de la fase de diseño y el documento de requerimiento de la fase de análisis, el equipo debe construir exactamente lo que se ha solicitado, aunque aún hay margen para la innovación y la flexibilidad. Por ejemplo, un componente puede ser estrictamente diseñada para este sistema en particular, o el componente puede ser más general, para satisfacer una directriz reutilización. El documento de la arquitectura debe proporcionar orientación. A veces, esta guía se encuentra en el documento de obligación. Las ofertas de la fase de ejecución de las cuestiones de calidad, rendimiento, parámetros de referencia, las bibliotecas, y la depuración. El final realización es el producto mismo. La fase de prueba En pocas palabras, la calidad es muy importante. Muchas empresas no han aprendido que la calidad es importante y ofrecer más funcionalidad reclamada, pero a un nivel de calidad inferior. Es mucho más fácil explicar a un cliente por qué hay una característica que falta que explicar a un cliente por el producto carece de calidad. Un cliente satisfecho con la calidad de un producto que seguirá siendo fiel y esperar a que la nueva funcionalidad en la próxima versión. La calidad es un atributo distintivo de un sistema que indica el grado de excelencia de En muchas metodologías de ingeniería de software, la fase de pruebas es una fase separada que se lleva a cabo por un equipo diferente después de completar la aplicación. No hay mérito en este enfoque, es difícil ver los propios errores, y una mirada fresca puede descubrir errores evidentes mucho más rápido que la persona que ha leído y releído el material muchas veces. Desafortunadamente, la delegación de la prueba a otro equipo lleva a una actitud de holgura respecto a la calidad por el equipo de aplicación. Alternativamente, otro enfoque es delegar las pruebas para toda la organización. Si los equipos están a ser conocido como los artesanos, a continuación, los equipos deben ser responsables de establecer una elevada calidad en todas las fases. A veces, un cambio de actitud debe tener lugar para garantizar la calidad. La técnica de ensayo es desde la perspectiva del proveedor del sistema. Debido a que es casi imposible duplicar el medio ambiente a todos los clientes posibles, y porque los sistemas están en libertad con todavía-a-ser-descubierto errores, el cliente tiene un papel importante, aunque a regañadientes, en función de las pruebas. COMPLEMENTO DE LEER

Proceso de desarrollo de software De Wikipedia, la enciclopedia libre Saltar a navegación, búsqueda Proceso de desarrollo de software Actividades y las medidas • Requisitos de Especificación • Diseño de Arquitectura • Aplicación de Pruebas • Mantenimiento de implementación

Modelos Agile • • DSDM para salas blancas Iterativo • RAD RUP • • Espiral Cascada XP • • • Lean Scrum V-Modelo • • FDD TDD

Apoyo a las disciplinas Gestión de la configuración Documentación Garantía de calidad (SQA) Gestión de proyectos Diseño de experiencia de usuario

Herramientas Compilador • • Depurador Profiler Diseñador GUI Entorno de desarrollo integrado

v • d • e

Un proceso de desarrollo de software es una estructura impuesta sobre el desarrollo de un producto de software. Los sinónimos son de ciclo de vida del software y el proceso de software. Existen varios modelos para estos procesos, cada uno de los enfoques para describir una variedad de tareas o actividades que tienen lugar durante el proceso. Contenidos ocultar • 1 Información general • 2 actividades de desarrollo de software 2,1 o Planificación o 2.2 La ejecución, pruebas y documentación de 2,3 o de implementación y mantenimiento • 3 modelos de desarrollo de software 3,1 o Cascada Modelo 3,2 o un modelo de espiral 3,3 o iterativo e incremental de desarrollo 3.4 Ágil o Desarrollo • 4 Proceso de Mejora de Modelos • 5 métodos formales • 6 Véase también • 7 Referencias • 8 Enlaces externos

Descripción general

El cuerpo en gran medida cada vez mayor de organizaciones de desarrollo de software de aplicación de las metodologías del proceso. Muchos de ellos están en la industria de defensa, que en los EE.UU. requiere de una clasificación basada en "modelos de procesos" para obtener contratos. El estándar internacional para describir el método de selección, aplicación y seguimiento del ciclo de vida para el software es la norma ISO 12207. A décadas de meta ha sido encontrar repetible, predecible procesos que mejoran la productividad y la calidad. Algunos tratan de sistematizar y formalizar la tarea aparentemente ingobernables de la escritura de software. Otros se aplican técnicas de gestión de proyectos para el software de escritura. Sin gestión de proyectos, proyectos de software fácilmente pueden ser entregados con retraso o por encima del presupuesto. Con un gran número de proyectos de software que no cumpla sus expectativas en términos de funcionalidad, costo, o el calendario de entrega, gestión de proyectos efectiva parece ser insuficiente. Las organizaciones pueden crear un grupo de procesos de Ingeniería de Software (SEPG), que es el punto focal para la mejora de procesos. Compuesto por profesionales de primera línea que han variado las habilidades, el grupo está en el centro de la colaboración de todos en la organización que esté involucrada en la mejora de procesos de ingeniería de software.

Las actividades de desarrollo de software

Las actividades del proceso de desarrollo de software representados en el modelo de cascada. Hay varios otros modelos para representar a este proceso.

Planificación

La tarea importante en la creación de un producto de software es la extracción de las exigencias o requisitos de análisis. Los clientes suelen tener una idea abstracta de lo que quieren como resultado final, pero no lo que el software debe hacer. Incompleta, ambigua o, incluso, exigencias contradictorias son reconocidos por los ingenieros de software especializados y experimentados en este punto. Con frecuencia viven demostrando código puede ayudar a reducir el riesgo de que los requisitos son incorrectos. Una vez que los requisitos generales que se deducen de la cliente, un análisis del alcance del desarrollo debe ser determinada y claramente. Esto es a menudo llamado un documento de alcance. Algunas funciones pueden estar fuera del alcance del proyecto en función del costo o como resultado de los requisitos de claro en el inicio del desarrollo. Si el desarrollo se realiza en el exterior, este documento puede ser considerado un documento legal de manera que si cada vez hay controversias, ninguna ambigüedad de lo que se comprometió a que el cliente pueda ser aclarado.

Implementación, pruebas y documentación de

La implementación es la parte del proceso en el que los ingenieros de software en realidad el programa de código para el proyecto. Pruebas de software es una parte integral e importante del proceso de desarrollo de software. Esta parte del proceso asegura que los defectos son reconocidos tan pronto como sea posible. Documentar el diseño interno de software con el propósito de mantenimiento futuro y la mejora se realiza durante todo el desarrollo. Esto también puede incluir la autoría de una API, ya sea externa o interna.

Implementación y el mantenimiento

Despliegue comienza después de que el código es prueba de forma adecuada, es aprobado para su liberación y vendidos o distribuidos en un entorno de producción. Software de capacitación y apoyo es muy importante y una gran cantidad de desarrolladores no se dan cuenta de que. No sería por mucho tiempo y la planificación de un equipo de desarrollo lleva a la creación de software si nadie en una organización que acaba de usarlo. La gente a menudo se resisten al cambio y evitar adentrarse en una zona desconocida, así como una parte de la fase de despliegue, es muy importante contar con clases de formación para nuevos clientes de su software. Mantener y mejorar el software para hacer frente a los problemas recién descubiertos o nuevos requisitos puede tomar mucho más tiempo que el desarrollo inicial del software. Puede ser necesario agregar código que no se ajusta al diseño original para corregir un problema imprevisto o puede ser que un cliente solicita una mayor funcionalidad y el código se puede añadir a sus peticiones. Si el costo laboral de la fase de mantenimiento supera el 25% del coste de las fases anteriores "mano de obra, entonces es probable que la calidad general, de al menos una fase previa, es pobre. En ese caso, la administración debería considerar la opción de la reconstrucción del sistema (o partes) antes de costes de mantenimiento está fuera de control. Sistema de seguimiento de fallos de herramientas que frecuentemente se utilizan en esta fase del proceso para permitir que los equipos de desarrollo de interfaz con los clientes, equipos de campo de pruebas del software para identificar cualquier problema real o percibida. Estas herramientas de software, tanto de código abierto y con licencia comercial, ofrecer un proceso personalizable para adquirir, revisar, reconocer y responder a los problemas reportados.

Modelos de Desarrollo de Software

Existen varios modelos para agilizar el proceso de desarrollo. Cada uno tiene sus pros y sus contras, y es hasta el equipo de desarrollo a adoptar la más adecuada para el proyecto. A veces una combinación de los modelos pueden ser más adecuados.

Cascada Modelo

El modelo muestra un proceso de cascada, donde los desarrolladores deben seguir estas fases a fin de: 1. Especificación de Requisitos (Análisis de requerimientos) 2. Diseñar 3. Aplicación (o codificación) 4. Integración 5. Pruebas (o de validación) 6. Implementación (o instalación) 7. Mantenimiento En un modelo de cascada estricta, después de finalizar cada fase, se procede a la siguiente. Las revisiones pueden ocurrir antes de pasar a la siguiente fase que permite la posibilidad de cambios (que puede implicar un proceso formal de control de cambios). Sin embargo, se desaconseja volver a examinar y revisar cualquier fase anterior una vez que esté completo. Esta "rigidez" en un modelo en cascada pura ha sido una fuente de críticas por otras más "flexible" modelos.

Un modelo de espiral

La principal característica de un modelo en espiral es la gestión del riesgo en las etapas regulares en el ciclo de desarrollo. En 1988, Barry Boehm publicó un sistema formal para el desarrollo de software "modelo en espiral", corresponde modelos y los modelos de prototipos rápidos combinar el énfasis ha sido descuidado por otros modelos de análisis de riesgos, especialmente adaptadas a gran escala de sistemas complejos. Un modelo de espiral de caracol a un número de iteración, los cuatro representante diagrama de cuadrante de las siguientes actividades: (1) formular planes a identificar blancos de software seleccionado para implementar el programa, aclarar las restricciones proyecto de desarrollo, (2) Análisis de riesgos: un análisis y evaluación de los programas seleccionados, para estudiar la manera de identificar y eliminar el riesgo, (3) la ejecución del proyecto: la aplicación de desarrollo de software y de verificación; (4) Evaluación de los clientes: la evaluación de la labor de desarrollo, la propuesta de enmiendas, los planes de formular el siguiente paso. Riesgo modelo basado en espiral, haciendo hincapié en las condiciones de las opciones y limitaciones a fin de apoyar la reutilización de software, la calidad del software puede ayudar como un objetivo especial de la integración en el desarrollo de productos. Sin embargo, el modelo en espiral que tiene algunas condiciones restrictivas, como sigue: (1) el modelo en espiral hincapié en el análisis de riesgos, sino que requieren los clientes a aceptar y creer que gran parte de este análisis, y dar la respuesta pertinente no es fácil, por lo tanto, este modelo es a menudo adaptado a interno en gran escala de desarrollo de software. (2) Si la aplicación de análisis de riesgo afectará en gran medida los beneficios del proyecto, a continuación, el análisis de riesgo no tiene sentido, por lo tanto, el modelo en espiral es solo apto para grandes proyectos de software a gran escala. (3) Buenas a los desarrolladores de software debe buscar los posibles riesgos, un análisis preciso de los riesgos, de lo contrario, dará lugar a un mayor riesgo de Primera etapa es determinar la etapa de la meta de lograr estos objetivos, las opciones y limitaciones y, a continuación, desde la perspectiva del programa de análisis de riesgos, la estrategia de desarrollo, y esforzarse por eliminar todos los riesgos potenciales y, a veces necesaria para lograr a través de la construcción de la prototipo. Si algún riesgo no puede descartarse, el programa para poner fin de inmediato, o bien iniciar el desarrollo de los próximos pasos. Por último, los resultados de la evaluación de la etapa, y el diseño de la próxima fase.

Desarrollo iterativo y creciente

Iterativo Desarrollo1 prescribe la construcción de porciones inicialmente pequeño pero cada vez mayor de un proyecto de software para ayudar a todos los participantes a descubrir aspectos importantes principios antes que los problemas o suposiciones erróneas pueden llevar al desastre. Los procesos iterativos son preferidas por los desarrolladores comerciales, ya que permite un potencial de alcanzar los objetivos de diseño de un cliente que no sabe cómo definir lo que quieren.

Agile Development

Ágiles de desarrollo de software de desarrollo iterativo utiliza como base, pero los defensores de un pueblo más ligero y más centrada en el punto de vista que los enfoques tradicionales. Los procesos ágiles de votos utilizar, en lugar de planificación, como su principal mecanismo de control. La respuesta es impulsado por las pruebas regulares y las liberaciones de los programas en constante evolución. Hay muchas variaciones de los procesos ágiles. XP (Extreme Programming) En XP, las fases se lleven a cabo en muy pequeña (o "continuo") las medidas frente a la antigua, "lote" los procesos. La (intencionalmente incompleta) de primer paso a través de los pasos que podría tomar un día o una semana, en vez de los meses o años de cada paso completo en el modelo de cascada. En primer lugar, se escribe pruebas automatizadas, para proporcionar metas concretas para el desarrollo. Lo siguiente es la codificación (por un par de programadores), que se completa cuando todas las pruebas pasan, y los programadores no pueden pensar en más pruebas que se necesitan. Diseño y arquitectura emergen de refactorización, y viene en pos de codificación. El diseño es realizado por las mismas personas que hacen la codificación. (El último rasgo - la fusión de diseño y código - es común a todos los demás procesos ágiles.) La incompleta pero funcional sistema se instala, ni ha demostrado para subconjunto (algunos de) los usuarios (al menos uno de los cuales está en el equipo de desarrollo). En este punto, los profesionales de empezar de nuevo a escribir ensayos para la parte más importante del sistema. Rational Unified Process Scrum

Proceso de Mejora de Modelos de

Capability Maturity Model Integration Modelo de Madurez de la Capacidad de Integración (CMMI) es uno de los principales modelos y basado en las mejores prácticas. Evaluaciones independientes de las organizaciones de grado de lo bien que siguen sus procesos definidos, no en la calidad de los procesos o el software producido. CMMI ha sustituido a la CMM. ISO 9000 ISO 9000 describe las normas para un proceso formalmente organizados para la fabricación de un producto y los métodos de gestión y seguimiento de los progresos realizados. Aunque la norma fue creada originalmente para el sector manufacturero, las normas ISO 9000 se han aplicado al desarrollo de software. Como CMMI, la certificación ISO 9000 no garantiza la calidad del resultado final, solo que los procesos de negocio formalizado se han seguido. ISO 15504 ISO 15504, también conocida como Proceso de Determinación de Software Mejora de las Capacidades (SPICE), es un "marco para la evaluación de los procesos de software". Esta norma está destinada a establecer un modelo claro para la comparación de procesos. SPICE se utiliza mucho como CMMI. Que los modelos de los procesos para administrar, controlar, orientar y supervisar el desarrollo de software. Este modelo se utiliza para medir lo que una organización de desarrollo o el equipo de proyecto en realidad lo hace durante el desarrollo de software. Esta información es analizada para identificar las debilidades y la mejora de la unidad. También identifica los puntos fuertes que puede mantenerse o integrarse en una práctica común para esa organización o equipo.

Los métodos formales

Los métodos formales son métodos matemáticos para la solución de software (y hardware) los problemas en los requisitos, especificaciones y los niveles de diseño. Ejemplos de los métodos formales son el B-Método, redes de Petri, lo que prueba automática de teoremas, plantear y VDM. Varios anotaciones especificación formal están disponibles, tales como la notación Z. Más en general, la teoría de autómatas se puede utilizar para construir y validar el comportamiento de la aplicación mediante el diseño de un sistema de máquinas de estados finitos. Máquina de estados finitos (FSM), metodologías basadas en la especificación de software permiten ejecutable y por paso de la codificación convencional (véase el virtual máquina de estados finitos o un evento impulsado por máquina de estados finitos). Los métodos formales son más susceptibles de ser aplicadas en el software de aviónica, en particular cuando el software es indispensable para la seguridad. Normas de garantía de software de seguridad, tales como los métodos de la demanda DO178B formal al más alto nivel de categorización (Nivel A). Formalización de desarrollo de software se infiltra en él, en otros lugares, con la aplicación de Object Constraint Language especializaciones (y como Java Modeling Language) y, especialmente, con el modelo impulsado por la arquitectura permite la ejecución de diseños, si no las especificaciones. Otra de las tendencias emergentes en el desarrollo de software es escribir una especificación en algún tipo de lógica (por lo general una variación de FOL), y luego de ejecutar directamente la lógica, como si se tratara de un programa. El lenguaje OWL, basados en la descripción lógica, es un ejemplo. También se está trabajando sobre la cartografía de alguna versión de inglés (u otro lenguaje natural) y de forma automática a partir de la lógica, y la ejecución de la lógica directamente. Ejemplos de ello son Attempto Inglés controlada, y la lógica de negocios de Internet, que no tratan de controlar el vocabulario o la sintaxis. Una característica de los sistemas que apoyan bidireccional Inglés-mapping lógica y la ejecución directa de la lógica es que pueden hacerse para explicar sus resultados, en inglés, en el negocio o nivel científico. La Oficina de Responsabilidad Gubernamental, en un informe de 2003 sobre una de tráfico de la Administración Federal de Aviación de los programas de modernización del control aéreo, 2 recomienda seguir las orientaciones de la agencia para la gestión de sistemas de adquisición de los principales • establecer, mantener y controlar una forma precisa, válida y actual base de referencia de medición del desempeño, que incluiría la negociación de todos los autorizados, el trabajo sin precio a menos de 3 meses; • la realización de un examen integrado de base de cualquier modificación importante contrato dentro de 6 meses, y • preparación de una vida rigurosa estimación del coste del ciclo, incluyendo una evaluación del riesgo, de conformidad con la orientación del conjunto de herramientas de Sistema de Adquisición y de identificar el nivel de incertidumbre inherente a la estimación.