You are on page 1of 10

Systems Development Life Cycle

Scrum, que se centran en los procesos de peso ligero,
permitiendo la rápida evolución a lo largo del ciclo de
desarrollo.

Analysis

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

Design

Evaluation

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 metoModelo de ciclo de Vida del Desarrollo de software con la bur- dología ágil e iterativo confunden la palabra SDLC con
buja de Mantenimiento resaltada.
procesos secuenciales o «más tradicionales», sin embargo, SDLC es un término para todas las metodologías y
El ciclo de vida de desarrollo de sistemas (SDLC), o cubre todas las etapas como el diseño, implementación y
ciclo de vida de desarrollo de software en la ingeniería de puesta en libertad de software.
sistemas e ingeniería de software, es el proceso de crea- En la gestión de proyectos se definen el ciclo de vida
ción o modificación de los sistemas, modelos y metodo- del proyecto (PLC) y el SDLC, durante el cual suceden
logías que la gente usa para desarrollar estos sistemas de actividades ligeramente diferente ocurrir. Según Taylor
software. El concepto general se refiere a la computadora (2004) «el ciclo de vida del proyecto abarca todas las aco sistemas de información. En ingeniería de software el tividades del proyecto, mientras que el ciclo de vida de
concepto de SDLC sostiene muchos tipos de metodolo- desarrollo de sistemas se centra en el cumplimiento de
gías de desarrollo de software. Estas metodologías cons- los requisitos de los productos».
tituyen el marco para la planificación y el control de la
creación de una información en el proceso de desarrollo
de software.[1]
Testing

Implementation

2 Historia
1

Descripción general

El ciclo de vida de desarrollo de sistemas (SDLC) 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
".6 Varios sistemas de marcos de desarrollo se han basado en parte en SDLC, 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 SDLC

El ciclo de vida de desarrollo de un sistema (SDLC) es
un proceso lógico utilizado en el mundo del Desarrollo
de Software sistemas para desarrollar un sistema de información, incluidos los requisitos, la validación, formación,
como los usuarios (interesados) en la propiedad. Cualquier SDLC 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 ServiceOriented 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 (SDLC) 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
1

Existen varios sistemas para el Desarrollo del Ciclo de Vida modelos en existencia. La recogida de caja Negro • Las pruebas de caja blanca • Las pruebas de regresión • Automatización de Pruebas • Pruebas de aceptación del usuario • Las pruebas de rendimiento Operaciones y mantenimiento El despliegue del sistema incluye cambios y mejoras antes de la clausura o el ocaso del sistema. así como partes proveedor de servicios para obtener los requisitos detallados y precisos. rompiendo lo que es necesario crear y tratar de comprometer a los usuarios para que los requisitos definidos puede ser definido. Iteración de no forman parte del modelo de cascase denomina también como fase de análisis. La etapa de diseño toma como su aportación inicial de las necesidades identificadas en el documento aprobado los requisitos. El SDLC se puede dividir en diez fases durante las cuales se definen los productos de TI de trabajo creados o modificados. y se explican en la sección de abajo. Como . 4. diseño y ejecución. Sin embargo. Tipos de pruebas: 4. pero por lo general se producen algunos en esta etapa. Unidad de sistema y pruebas de aceptación también se utiliza como referencia para mantener el pro. analizar los objetivos del proyecto.del usuario se realiza a menudo. incluyendo diseños de pantalla. Los elementos de diseño describen las características de software que desee en detalle.4 Pruebas a la alta dirección en un intento de obtener financiación. los diagramas de proceso de negocio. los diagramas de proceso y otra documentación.7 vará a cabo durante esta etapa. será necesario que las fases se ejecutan 4. No todos los proyectos. Dependiendo del tamaño y la complejidad del Modular y código de programación del subsistema se lleproyecto. Unidad de prueba y comprobación de los módulos se realiza en esta etapa por los desarrolladores.2 Diseñar En las funciones de diseño de sistemas y operaciones se describen en detalle. El estudio de viabilidad se utiliza a veces para presentar el proyecto 4. tales como la planificación. las fases se pueden combinar o puede overlap. Estas etapas suelen seguir los mismos pasos básicos. 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.6 3 requisitos a veces requiere que los individuos o equipos de cliente. pseudocódigo.8 El mo muchos existen diferentes opiniones en cuanto a lo de MIS es también un complemento de esas fases. de software. un conjunto de uno o más elementos de diseño se produce como resultado de las entrevistas. • Prueba de unidad • Las requisitos pruebas del sistema • Prueba de integración • Pruebas de El objetivo de los sistemas de análisis es determinar dónde está el problema en un intento de arreglar el sistema. y generalmente incluyen diagramas de jerarquía funcional. Esta fase las etapas de prueba y cuánto. los cuadros de reglas de negocio. Fases de desarrollo de software Desarrollo de Sistemas de Ciclo de Vida (SDLC) se adhiere a las fases importantes que son esenciales para los desarrolladores. Este paso implica dividir el sistema en diferentes piezas y elaborar diagramas para analizar la situación. si se produce cualquier iteración. las fases son interdependientes. La décima etapa se produce cuando el sistema se elimina y la tarea realizada se eliminan o se transfieren a otros sistemas. coyecto en marcha y evaluar los avances del MIS team. da. Para generar una visión de alto nivel del proyecto y pretende determinar los objetivos del proyecto.3 Construcción secuencialmente. Mantenimiento del sistema es un aspecto importante de la SDLC. Además. pero los pasos que se caracteriza y se divide en varios pasos. La salida de esta etapa se describe el nuevo sistema como un conjunto de módulos o subsistemas. diagramas de disposición de la pantalla. análisis. No hay definitivamente correcto desarrollo de sistemas modelo de ciclo de vida. pero muchas metodologías diferentes cascada dar los pasos diferentes nombres y el número de pasos parecen variar entre 4 y 7. talleres. Las tareas y los productos de trabajo para cada fase se describen en los capítulos siguientes. las reglas de negocio. El modelo más antiguo.2 4 INICIACIÓN / PLANIFICACIÓN tradicional”. Los proyectos son evaluados en tres áreas de viabilidad: El código es probado en los distintos niveles en la prueba económica. operativa y organizativa y técnica. Estos elementos de diseño se pretende describir el software con el suficiente detalle que los programadores cualificados puede desarrollar el software con el aporte adicional mínimo. y una entidad completa el diagrama de la relación con un diccionario de datos completo. Esta es un área gris. y / o los esfuerzos de prototipo.1 Reunión de relevamiento y análisis de • Conjunto de datos de prueba. Esta etapa se entremezcla con los si4 Iniciación / planificación guientes módulos individuales en que sería necesario probar antes de la integración con el proyecto principal. Para cada necesidad.

cada que el diseño de detalle y la fase de desarrollo. Los objetivos de control de ayudar a propor.Cada tarea debe tener una salida medibles (por ejemplo. • Open Source Development • Terminar con el desarrollo de usuario • Programación Orientada a Objetos Comparación de Metodologías 6 Estructura de desglose de trabajo (Post. extensión de los trabajos anteuna forma establecida por el proyecto manager. El desarrollo de una gestión Controles. y se refieren a las referencia: establecido después de la fase de diseño prefases de SDLC como se muestra en la figure. ya sean internos o externos al proyecto. ingeniería de software. una descripción de las tareas recomendadas. riores en los prototipos y RAD. Una tarea PEP puede Vida de temas de desarrollo de sistemas de ciclo Gestión basarse en una o más actividades (por ejemplo. El diagrama siguiente se • Software de prototipos • Aplicaciones de diseño mixto describen tres áreas clave que se abordarán en la WBS en (JAD) • Desarrollo rápido de aplicaciones (RAD) • Extreme Programming (XP). 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.mas de Ciclo de Vida de Desarrollo (SDLC). yecto y proporcionar una manera flexible pero coherente para llevar a cabo proyectos a una profundidad de juego el alcance del proyecto. los un período definitivo (generalmente dos semanas o más). y un resumen de los objetivos de control relacionados para la gestión eficaz. Además. y Anderson 2006) 11 la organización 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. Es fundamental para el gestor de pro.3 personal clave cambiar de posición en la organización. La sección central de la EDT se basa en los siete sistemas de Desarrollo del Ciclo de Vida (SDLC) fases como una guía para el desarrollo de tareas EDT.lización de productos de referencia: establecido después tructura de desglose de trabajo (WBS) para la captura y de la fase de construcción de la producción. el documento.7 Líneas de base en el SDLC dos clave. • Asignado de en categorías principales (dominios). • Producto de referencia: establecido después de gestión y el control de cualquier iniciativa SDLC. Estas líneas trol en cada fase de SDLC. el calendario de los trabajos necesarios para completar el proyecto. Cada línea de base se considera como el propósito y debe ser utilizado durante todo el proceso un hito en el SDLC. cambios se aplicarán nuevas.fases del SDLC y son esenciales para la naturaleza iteracionar una declaración clara de los resultados deseados o tiva del modelo 10. Cualquier parte del proyecto que necesitan el apoyo de los contratistas deben tener una 5 SDLC fases relacionadas con la declaración de trabajo (SOW) por escrito para incluir las tareas adecuadas de las fases SDLC. Objetivos de control pueden agruparse do después de la fase de diseño conceptual. pero se ha desarrollado para incluir Los sistemas de ciclo de vida del desarrollo (SDLC) falos trabajos del proceso de SDLC que podrá ser realizada ses servir de guía programática para la actividad del propor recursos externos. Hay Métodos complementarios de desarrollo de software paalgunas áreas clave que deben definirse en el PEP como ra desarrollo de sistemas de Ciclo de Vida (SDLC) son: parte de la política de SDLC. decisión. Cada uno de los objetivos de la fase SDLC se describen en esta sección con los resulta.9 Para la liminar. mientras que la ejecución de de base se estableció después de que cuatro de las cinco proyectos. • Actuaproyecto será necesario establecer algún grado de una es. o análisis). nes del sistema. La WBS y todo el material programático debe mantenerse en la sección “Descripción del proyecto” de 8 Como complemento a SDLC la portátil del proyecto. que requieren actualizacio.Las líneas de base son una parte importante de los Sisteyecto para establecer y supervisar los objetivos de con. • Funcional de referencia: establecide SDLC entero. Los elementos PEP debe consistir de los hitos y las “tareas” en oposición a las “actividades” y tienen SDLC 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. 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. como contractors. ingeniería de sistemas) y puede requerir y control una estrecha coordinación con otras tareas. algunos Quizá Vital Limitada débil Ninguno . Declaración de trabajo no se producen durante una fase específica de SDLC.

procesadores de documentos. este documento indica de manera clara y precisa lo que se va a construir. que combina la creación de prototipos. Estas fases frente a lo que se va a construir. El documento de obligación puede ser expresada en un lenguaje formal basado en la lógica matemática. Estas fases son: análisis. el desarrollo web o e-commerce) donde los interesados necesidad de revisar periódicamente el programa se está diseñando. El resultado a entregar al final de esta fase es un documento de obligación. análisis de riesgos. Las estrategias se materializan a través de la recopilación de la arquitectura. Los sistemas deben ser definidos desde el principio. algoritmos.4 Fortalezas y debilidades Pocas personas en el mundo de la computación moderna se utiliza un modelo en cascada estrictas para su desarrollo de sistemas del ciclo de vida (SDLC). Tolera los cambios en la dotación de personal de MIS. el documento describe el requisito de las cosas en el sistema y las acciones que se pueden hacer en estas cosas. y los criterios de éxito son ejemplos de descripciones de alto nivel. La práctica de SDLC tiene ventajas en los modelos tradicionales de desarrollo de software. El código puede hacer frente a objetos. Hay cuatro fases fundamentales en la mayoría. Estas excepciones se producen por muchas razones. diseño. incluido el mantenimiento de la coherencia con otros sistemas establecidos. implementación y pruebas. Evaluar los costos y objetivos de conclusión. depuradores. Documentación. los métodos. las metodologías de ingeniería de software. es mucho más importante tener las mejores prácticas del modelo de SDLC y aplicarlo a todo lo que puede ser más apropiado para el software se está diseñando. los sobrecostos del proyecto. gestión de proyectos. En lugar de ver SDLC desde una perspectiva de fuerza o debilidad. El aumento de tiempo de desarrollo. La entrada del usuario es a veces limitado. independiente de muchos de los detalles. La fase de análisis La fase de análisis se definen los requisitos del sistema. y la participación activa del usuario en el proceso de desarrollo. Los documentos producidos incluyen los requisitos que definen el problema. o el uso de algunos norma aceptada de la industria informática. protocolos. que se presta más a un ambiente estructurado. en el nivel de exigencia. control de código fuente. y por lo que es de alta calidad. Hay una línea difusa entre descripciones de alto nivel y los detalles de bajo nivel. Las desventajas de usar la metodología SDLC es cuando hay necesidad de un desarrollo iterativo o (es decir. entornos de gestión de cambios. Las ventajas de RAD son la velocidad. pero todavía es un término ampliamente utilizado en los círculos tecnológicos. 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. No debe suponerse que sólo porque el modelo en cascada es la más antigua SDLC modelo original que es el sistema más eficiente. como muchos metodologías modernas han sustituido este pensamiento. y los planes de ejecución. los paradigmas. y herramientas de modelado de dominio. Algunos dirán que el SDLC ya no se aplica a los modelos como el Agile informática. planes de prueba. los escenarios. Una alternativa a la SDLC se desarrolló rápido de aplicaciones. Tradicionalmente. Estas medidas en conjunto a definir la cuna a la tumba del ciclo de vida del proyecto de software. Bien definido de entrada del usuario. Facilidad de mantenimiento. Difícil estimar los costos. Idealmente. si un detalle exacto de ingeniería debe ser determinado. Pasos detallados. Esta fase se define el problema de que el cliente está tratando de resolver. Joint Application Development y la aplicación de herramientas CASE. las demandas del cliente. Hay un conflicto fundamental entre los niveles altos y bajos niveles de detalle. 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. pero especifica la información en el nivel superior de la descripción. la reducción de los costes de desarrollo. los manuales de los 8 COMO COMPLEMENTO A SDLC clientes. Las cosas pueden ser expresadas como objetos en un objeto de la tecnología . Sin embargo. métodos. la disponibilidad de opciones particulares. módulos. El documento requisito no se especificarán los detalles de arquitectura o de aplicación. Una comparación de las fortalezas y debilidades de SDLC: Fortalezas y debilidades de SDLC 11 Fortalezas Debilidades Control. Este análisis lo que representa el ``fase. convenios y una declaración de misión. 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. un diseño que define la arquitectura. una visión de la arquitectura en particular. 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. la construcción. Los proyectos de monitor de gran tamaño. Las herramientas incluyen compiladores. y las definiciones de interfaz. El enunciado del problema. las expectativas del cliente. este detalle también aparecerá en el documento de obligación. Esta es la excepción y no debería ser la norma. El aumento de los costes de desarrollo. estructuras de datos. El documento de obligación de los Estados lo que el sistema debe cumplir. si no todas. Desarrollo y diseño de las normas. La rigidez. 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. 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. COMPLEMENTO DE LEER. A veces. independiente de cómo estos requisitos se llevará a cabo. el documento de obligación está escrito en Inglés o en otro idioma escrito. y establecer. cómo se va a construir. o una limitación en el tamaño de la imagen de la aplicación.

si una acción se hace muchas veces. aunque bastante éxito se ha logrado con los métodos existentes. aún no se ha desarrollado. la plataforma. el equipo. Mecanismos alternativos descriptivo basado en la lógica matemática son a veces más adecuado. rendimiento. Una prioridad fundamental de aplicación conduce a una tarea que tiene que ser bien hecho. Obviamente. Si falla. 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. así como la complejidad de la aplicación del comercio-offs. 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 la fase de diseño. 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. pilas. arquitectura de aplicaciones distribuidas capas de la arquitectura. el equipo desarrolla los componentes ya sea desde cero o por la composición. las bibliotecas. El documento requisito que debe guiar este proceso de decisión. conducirá finalmente a un producto de mayor calidad. máquinas. Muchas empresas no han aprendido que la calidad es importante y ofrecer más funcionalidad reclamada. interfaces. Más tarde. El documento de diseño de realización es la arquitectura. escenarios típicos de uso. En general. teniendo en cuenta un documento de obligación de completar. La lógica matemática proporciona una base científica para expresar con precisión la informació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. que. 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. un componente puede ser estrictamente diseñada para este sistema en particular. Las ofertas de la fase de ejecución de las cuestiones de calidad. estas descripciones requisito se asignan en ciencias de la computación basada en las primitivas. aunque aún hay margen para la innovación y la flexibilidad. parámetros de referencia. la descomposición muy importante del problema conduce al desarrollo de estructuras de datos y algoritmos. Es mucho más fácil explicar a un cliente por qué . y la depuración. y muchos otros detalles de ingeniería. por escrito. Los detalles sobre los lenguajes de programación y entornos. La mayoría de las lenguas escritas humanos son demasiado vagas para capturar la precisión necesaria para construir un sistema. que habla de las cosas y las acciones sobre las cosas. eventos. El diseño puede incluir el uso de componentes existentes. El final realización es el producto mismo. con frecuencia en el mundo real. y escenarios típicos de uso de La fase de diseño En la fase de diseño de la arquitectura se ha establecido. el producto falla. esta guía se encuentra en el documento de obligación. Uso de la típica y una hipótesis típica prevista en el documento de requisitos. la calidad es muy importante. las cosas podrían ser expresado como los servicios de acceso a bases de datos en un enfoque funcional. El documento de diseño describe un plan para aplicar los requisitos. paquetes. ya sea formal o informalmente. se esconden detrás jerárquico métodos polimórficos. sus interfaces y comportamientos. El equipo de arquitectura ahora puede ampliar la información establecida en el documento de obligación. una descripción precisa es alcanzable. Una acción rara vez se utiliza debe aplicarse correctamente. gráficos. el nivel de confianza del equipo de producción de un producto de éxito se incrementará. es necesario que se haga correctamente y de manera eficiente. La arquitectura define los componentes. En un sentido más general. Si tiene éxito. 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. algoritmos. El mecanismo definitivo al autor de dicho documento.5 basada en datos y algoritmos. Los documentos requisito debe ser independiente de la técnica de descomposición. Por lo menos. pero mucho más difícil de lograr. también debe indicar las prioridades fundamentales para el equipo de aplicación. En nuestro enfoque. La fase de ejecución En la fase de ejecución. Alternativamente. Esta fase se inicia con el documento emitido por el requisito de la fase de requisito y mapas de los requisitos en la arquitectura. el equipo debe construir exactamente lo que se ha solicitado. pero a un nivel de calidad inferior. Esto mantendrá el equipo de implementación focalizada. o el componente puede ser más general. El documento de la arquitectura debe proporcionar orientación. en la fase de diseño. donde los datos es un concepto radicalmente diferente de las funciones. El equipo de arquitectura también convierte los escenarios típicos en un plan de prueba. estructuras de datos. tales como listas. árboles. Sin embargo. Analizar las ventajas y desventajas de la necesaria complejidad permite muchas cosas para seguir siendo sencillo. Por ejemplo. el producto podría tener éxito. a su vez. tamaño de la memoria. desde la perspectiva del cliente. incluyendo las herramientas CASE y herramientas basadas en la lógica matemática Más tarde. Algunos ejemplos son distribuidos los sistemas cliente-servidor. el desempeño del comercio-offs puede llevarse a cabo. se establecen las definiciones de tipo global. Una vez más el documento de requisitos debe indicar de manera clara y precisa lo que se va a construir. para satisfacer una directriz reutilización. Este documento debería incluir también los estados. El equipo de análisis se desarrolla el documento de obligación. donde una base de datos contiene los datos en un servidor. Esta fase representa la `` cómofase. 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. A veces. 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. mientras que los algoritmos de manipulación de los datos que residen en el cliente. algoritmos y estructuras de datos. pero no es evidente cuál es el nivel de cumplimiento es obligatorio. La descomposición funcional para un entorno distribuido conduce a una división natural de las estructuras de datos y algoritmos. La fase de prueba En pocas palabras.

y porque los sistemas están en libertad con todavía-a-ser-descubierto errores.UU.6 8 COMO COMPLEMENTO A SDLC hay una característica que falta que explicar a un cliente por el producto carece de calidad. 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.que quieren como resultado final.fuera del alcance del proyecto en función del costo o coriedad de tareas o actividades que tienen lugar durante el mo resultado de los requisitos de claro en el inicio del proceso.güedad de lo que se comprometió a que el cliente pueda rrollo de software 3. Los sinónimos son de ciclo de vida del software y el determinada y claramente. COMPLEMENTO DE LEER Descripción general Proceso de desarrollo de software De Wikipedia. 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. Modelos Agile • • DSDM para salas blancas Iterativo • Planificación RAD RUP • • Espiral Cascada XP • • • Lean Scrum V. Las organizaciones pueden crear un grupo de procesos de Ingeniería de Software (SEPG). Otros se aplican técnicas de gestión de proyectos para el software de escritura. la fase de pruebas es una fase separada que se lleva a cabo por un equipo diferente después de completar la aplicación. a continuación. pero no lo que el software debe hacer. este actividades de desarrollo de software 2. Compuesto por profesionales de primera línea que han variado las habilidades. exigenyectos Diseño de experiencia de usuario cias contradictorias son reconocidos por los ingenieros de Herramientas Compilador • • Depurador Profiler Disesoftware especializados y experimentados en este punto.La tarea importante en la creación de un producto de softModelo • • FDD TDD ware es la extracción de las exigencias o requisitos de Apoyo a las disciplinas Gestión de la configuración Do. en función de las pruebas. otro enfoque es delegar las pruebas para toda la organización. ninguna ambiimplementación y mantenimiento • 3 modelos de desa.análisis. requiere de una clasificación basada en “modelos de procesos” para obtener contratos. costo. Algunas funciones pueden estar procesos. 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. 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. Existen varios modelos para estos documento de alcance. Esto es a menudo llamado un proceso de software.3 o de manera que si cada vez hay controversias.1 o Planificación documento puede ser considerado un documento legal de o 2. un cambio de actitud debe tener lugar para garantizar la calidad. El estándar internacional para describir el método de selección. No hay mérito en este enfoque. que es el punto focal para la mejora de procesos. que en los EE. Sin gestión de proyectos. pruebas y documentación de 2. Alternativamente. Hay varios otros modelos para representar a este proceso. Incompleta. Si los equipos están a ser conocido como los artesanos. Un proceso de desarrollo de software es una estructura Una vez que los requisitos generales que se deducen de impuesta sobre el desarrollo de un producto de softwa. proyectos de software fácilmente pueden ser entregados con retraso o por encima del presupuesto. un análisis del alcance del desarrollo debe ser re. Con un gran número de proyectos de software que no cumpla sus expectativas en términos de funcionalidad.2 La ejecución. ñador GUI Entorno de desarrollo integrado Con frecuencia viven demostrando código puede ayudar v•d•e a reducir el riesgo de que los requisitos son incorrectos. es difícil ver los propios errores.3 o iterativo e incremental de desarrollo 3.4 Implementación. los equipos deben ser responsables de establecer una elevada calidad en todas las fases. 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 Las actividades de desarrollo de software El cuerpo en gran medida cada vez mayor de organizaciones de desarrollo de software de aplicación de las metodologías del proceso. aplicación y seguimiento del ciclo de vida para el software es la norma ISO 12207. la enciclopedia libre Saltar a navegación. Debido a que es casi imposible duplicar el medio ambiente a todos los clientes posibles. Algunos tratan de sistematizar y formalizar la tarea aparentemente ingobernables de la escritura de software. Contenidos ocultar • 1 Información general • 2 desarrollo. pruebas y documentación de Ágil o Desarrollo • 4 Proceso de Mejora de Modelos • 5 La implementación es la parte del proceso en el que los métodos formales • 6 Véase también • 7 Referencias • 8 ingenieros de software en realidad el programa de código Enlaces externos .1 o Cascada Modelo 3. Muchos de ellos están en la industria de defensa. La técnica de ensayo es desde la perspectiva del proveedor del sistema. ambigua o. 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. cada uno de los enfoques para describir una va. Las actividades del proceso de desarrollo de software representados en el modelo de cascada. aunque a regañadientes. gestión de proyectos efectiva parece ser insuficiente. A veces. A décadas de meta ha sido encontrar repetible. de espiral 3. el cliente tiene un papel importante. predecible procesos que mejoran la productividad y la calidad.2 o un modelo ser aclarado. Desafortunadamente. incluso.la cliente. Los clientes suelen tener una idea abstracta de lo cumentación Garantía de calidad (SQA) Gestión de pro. Si el desarrollo se realiza en el exterior. o el calendario de entrega.

Si el costo laboral de la fase de mantenimiento supera el 25% del coste de las fases anteriores “mano de obra. (4) Evaluación de los clientes: la evaluación de la labor de desarrollo. es muy importante contar con clases de formación para nuevos clientes de su software. Estas herramientas de software. y es hasta el equipo de desarrollo a adoptar la más adecuada para el proyecto. a continuación.7 para el proyecto. las opciones y limitaciones y. Si algún riesgo no puede descartarse. Riesgo modelo basado en espiral. Especificación de Requisitos (Análisis de requerimientos) 2. 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. (2) Análisis de riesgos: un análisis y evaluación de los programas seleccionados. revisar. desde la perspectiva del programa de análisis de riesgos. Mantenimiento En un modelo de cascada es. Cascada Modelo El modelo muestra un proceso de cascada. ofrecer un proceso personalizable para adquirir. es pobre. este modelo es a menudo adaptado a interno en gran escala de desarrollo de software. se procede a la siguiente. Modelos de Desarrollo de Software Existen varios modelos para agilizar el proceso de desarrollo. el modelo en espiral es sólo apto para grandes proyectos de software a gran escala. el análisis de riesgo no tiene sentido. Por último. a continuación. sino que requieren los clientes a aceptar y creer que gran parte de este análisis. (2) Si la aplicación de análisis de riesgo afectará en gran medida los beneficios del proyecto. Barry Boehm publicó un sistema formal para el desarrollo de software “modelo en espiral”. Integración 5. (3) Buenas a los desarrolladores de software debe buscar los posibles riesgos. la propuesta de enmiendas. dará lugar a un mayor riesgo de Primera etapa es determinar la etapa de la meta de lograr estos objetivos. se desaconseja volver a examinar y revisar cualquier fase anterior una vez que esté completo. En ese caso. tanto de código abierto y con licencia comercial. después de finalizar cada fase. especialmente adaptadas a gran escala de sistemas complejos. Cada uno tiene sus pros y sus contras. corresponde modelos y los modelos de prototipos rápidos combinar el énfasis ha sido descuidado por otros modelos de análisis de riesgos.Desarrollo iterativo y creciente . a veces necesaria para lograr a través de la construcción de la prototipo. 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. Esto también puede incluir la autoría de una API. Un modelo de espiral de caracol a un número de iteración. haciendo hincapié en las condiciones de las opciones y limitaciones a fin de apoyar la reutilización de software. de lo contrario. como sigue: (1) el modelo en espiral hincapié en el análisis de riesgos. y dar la respuesta pertinente no es fácil. los planes de formular el siguiente paso. y el diseño de la próxima fase. 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. y esforzarse por eliminar todos los riesgos potenciales y. tricta. por lo tanto. para estudiar la manera de identificar y eliminar el riesgo. 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. el modelo en espiral que tiene algunas condiciones restrictivas. En 1988. Implementación y el mantenimiento Un modelo de espiral Despliegue comienza después de que el código es prueba de forma adecuada. Diseñar 3. donde los desarrolladores deben seguir estas fases a fin de: 1. la estrategia de desarrollo. reconocer y responder a los problemas reportados. equipos de campo de pruebas del software para identificar cualquier problema real o percibida. la calidad del software puede ayudar como un objetivo especial de la integración en el desarrollo de productos. Software de capacitación y apoyo es muy importante y una gran cantidad de desarrolladores no se dan cuenta de que. o bien iniciar el desarrollo de los próximos pasos. entonces es probable que la calidad general. Sin embargo. el programa para poner fin de inmediato. Pruebas (o de validación) 6. Implementación (o instalación) 7. 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. es aprobado para su liberación y vendidos o distribuidos en un entorno de producción. de al menos una fase previa. Esta parte del proceso asegura que los defectos son reconocidos tan pronto como sea posible. por lo tanto. 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). ya sea externa o interna. Sin embargo. La principal característica de un modelo en espiral es la gestión del riesgo en las etapas regulares en el ciclo de desarrollo. los cuatro representante diagrama de cuadrante de las siguientes actividades: (1) formular planes a identificar blancos de software seleccionado para implementar el programa. un análisis preciso de los riesgos. los resultados de la evaluación de la etapa. La gente a menudo se resisten al cambio y evitar adentrarse en una zona desconocida. aclarar las restricciones proyecto de desarrollo. Aplicación (o codificación) 4. Documentar el diseño interno de software con el propósito de mantenimiento futuro y la mejora se realiza durante todo el desarrollo. (3) la ejecución del proyecto: la aplicación de desarrollo de software y de verificación. Esta “rigidez” en un modelo en cascada pura ha sido una fuente de críticas por otras más “flexible” modelos. así como una parte de la fase de despliegue. Pruebas de software es una parte integral e importante del proceso de desarrollo de software. A veces una combinación de los modelos pueden ser más adecuados.

Normas de garantía de software de seguridad. La 9000 no garantiza la calidad del resultado final. las fases se lleven a Petri. es un ejemplo. Rational Unified Process Scrum tura permite la ejecución de diseños. en el negocio o nivel científico. En este punto. pero los defensores de un pueblo más en una práctica común para esa organización o equipo. para proporcio. Más en general. en ne en pos de codificación.solución de software (y hardware) los problemas en los gulares y las liberaciones de los programas en constante requisitos. Los métodos formales son más susDiseño y arquitectura emergen de refactorización. La (intencionalmente in. 8 COMO COMPLEMENTO A SDLC Determinación de Software Mejora de las Capacidades (SPICE). Varios anotaciones especificación formal están la antigua. Ejemevolución. como si se tratara de un los principales modelos y basado en las mejores prácti. Máquina lugar. orientar y supervisar el desarrollo de software. Esta información es analizada para identificar Agile Development las debilidades y la mejora de la unidad. También se está trabajando sobre de grado de lo bien que siguen sus procesos definidos.lógica (por lo general una variación de FOL).la fusión de diseño y código . controlar. También identiÁgiles de desarrollo de software de desarrollo iterativo fica los puntos fuertes que puede mantenerse o integrarse utiliza como base.de Internet. se escribe pruebas automatizadas. especificaciones y los niveles de diseño. ISO 9000 ISO 9000 la ejecución de la lógica directamente. En primer ño de un sistema de máquinas de estados finitos. La respuesta es impulsado por las pruebas re. 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. Evaluaciones independientes de las organizaciones lógica. redes de XP (Extreme Programming) En XP. plos de los métodos formales son el B-Método. la sintaxis. que se com. la completa) de primer paso a través de los pasos que podría teoría de autómatas se puede utilizar para construir y valitomar un día o una semana. es un “marco para la evaluación de los procesos de software”. si no las especificaciones. en otros gunos de) los usuarios (al menos uno de los cuales está en lugares. tales como la notación Z.es común a todos tales como los métodos de la demanda DO178B formal los demás procesos ágiles. lo que prueba automática de teoremas. Esta norma está destinada a establecer un modelo claro para la comparación de procesos. Como CMMI. CMMI ha sustituido a la CMM. “lote” los procesos. Otra de las tendencias emergentes en el desarrollo Proceso de Mejora de Modelos de de software es escribir una especificación en algún tipo de Capability Maturity Model Integration Modelo de Ma. Formalizasistema se instala.ción de desarrollo de software se infiltra en el. Los procesos ágiles de votos utilizar.programa. con el modelo impulsado por la arquitecimportante del sistema. ni ha demostrado para subconjunto (al.son Attempto Inglés controlada.8 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. El diseño es realizado por las particular cuando el software es indispensable para la semismas personas que hacen la codificación. la cartografía de alguna versión de Inglés (u otro lenguano en la calidad de los procesos o el software produci.) La incompleta pero funcional al más alto nivel de categorización (Nivel A). de estados finitos). Una característica de los sistemas que apoyan Aunque la norma fue creada originalmente para el sector bidireccional Inglés-mapping lógica y la ejecución direcmanufacturero. ya que permite un potencial de alcanzar los objetivos de diseño de un cliente que no sabe cómo definir lo que quieren. Lo siguiente es la pecificación de software permiten ejecutable y por paso codificación (por un par de programadores). la certificación ISO resultados. sólo que Oficina de Responsabilidad Gubernamental. ligero y más centrada en el punto de vista que los enfoques tradicionales. basados en la descripción cas. Que los modelos de los procesos para administrar. que no tratan de controlar el vocabulario o dos de gestión y seguimiento de los progresos realizados. Los procesos iterativos son preferidas por los desarrolladores comerciales. rasgo . metodologías basadas en la esnar metas concretas para el desarrollo.je natural) y de forma automática a partir de la lógica. como su principal mecanismo Los métodos formales son métodos matemáticos para la de control. Ejemplos de ello describe las normas para un proceso formalmente orga. plantear cabo en muy pequeña (o “continuo”) las medidas frente a y VDM. y do. y los programado. (El último guridad. y la lógica de negocios nizados para la fabricación de un producto y los méto. y luego de durez de la Capacidad de Integración (CMMI) es uno de ejecutar directamente la lógica.disponibles. las normas ISO 9000 se han aplicado al ta de la lógica es que pueden hacerse para explicar sus desarrollo de software. Los métodos formales en lugar de planificación. también conocida como Proceso de deral de Aviación de los programas de modernización del . Hay muchas variaciones de los procesos ágiles. El lenguaje OWL. y vie. ISO me de 2003 sobre una de tráfico de la Administración Fe15504 ISO 15504.na de estados finitos o un evento impulsado por máquina res no pueden pensar en más pruebas que se necesitan. SPICE se utiliza mucho como CMMI. con la aplicación de Object Constraint Language el equipo de desarrollo). de empezar de nuevo a escribir ensayos para la parte más especialmente.ceptibles de ser aplicadas en el software de aviónica. en un inforlos procesos de negocio formalizado se han seguido.de estados finitos (FSM). en vez de los meses o años de dar el comportamiento de la aplicación mediante el disecada paso completo en el modelo de cascada. los profesionales especializaciones (y como Java Modeling Language) y.de la codificación convencional (véase el virtual máquipleta cuando todas las pruebas pasan. en Inglés.

y • preparación de una vida rigurosa estimación del coste del ciclo. Retrieved 27 October 2008. mantener y controlar una forma precisa. que incluiría la negociación de todos los autorizados. • la realización de un examen integrado de base de cualquier modificación importante contrato dentro de 6 meses.9 control aéreo. . 9 Referencias [1] SELECTING A DEVELOPMENT APPROACH. el trabajo sin precio a menos de 3 meses. válida y actual base de referencia de medición del desempeño. incluyendo una evaluación del riesgo. 2 recomienda seguir las orientaciones de la agencia para la gestión de sistemas de adquisición de los principales • establecer. 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.

svg Fuente: https://upload. COLABORADORES Y LICENCIAS 10 10.nz 10. LordT.svg Artista original: GNOME icon artists and User:ViperSnake151 • Archivo:Spanish_Language_Wiki.wikimedia. Pluke.10 10 ORIGEN DEL TEXTO Y LAS IMÁGENES.org/wiki/Systems_Development_Life_Cycle?oldid=88536026 Colaboradores: CEM-bot. Ralgisbot. Elvisor. colaboradores y licencias Texto • Systems Development Life Cycle Fuente: https://es.org/wikipedia/commons/2/2a/Spanish_Language_Wiki. EmausBot.1 Origen del texto y las imágenes. Hernaldo.svg Licencia: CC0 Colaboradores: Trabajo propio Artista original: Pluke • Archivo:Commons-emblem-issue.org/wikipedia/commons/b/bc/Commons-emblem-issue.wikimedia. Xqbot.0 .wikimedia.wikipedia. Jacorream.svg Fuente: https://upload. KLBot2.mcd. MahdiBot.2 Imágenes • Archivo:CPT-SystemLifeSycle.svg by user:Kimbar Artista original: James. Grillitus. JAnDbot. Ganímedes.svg Licencia: CC BY-SA 3. BOTarate. Agabi10 y Anónimos: 9 10.3 Licencia del contenido • Creative Commons Attribution-Share Alike 3. Dangelin5.org/wikipedia/commons/a/aa/CPT-SystemLifeSycle.0 Colaboradores: Derived from Wiki puzzle.svg Fuente: https://upload.svg Licencia: GPL Colaboradores: File:Gnome-emblem-important.