Ciclo de vida de desarrollo de sistemas

Para otras aplicaciones, vea SDLC (desambiguación).

Modelo del ciclo de vida de desarrollo de sistemas, destacando la fase de mantenimiento.

El ciclo de vida de desarrollo de sistemas (SDLC), también conocida como la vida-ciclo de desarrollo de aplicaciones, es un término usado en Ingeniería de sistemas, sistemas de información y Ingeniería de software para describir un proceso de planificación, creación, pruebas y despliegue de un sistema de información. El concepto de ciclo de vida de desarrollo de sistemas se aplica a una variedad de configuraciones de hardware y software, como un sistema puede estar compuesto de hardware, software o una combinación de ambos.

Resumen

Sistemas de un ciclo de vida de desarrollo se compone de una serie de etapas de trabajo claramente definidas y diferenciadas que son utilizados por los ingenieros de sistemas y desarrolladores de sistemas para planear, diseñar, construir, probar y entregar sistemas de información. Como todo lo que se fabrica en una línea de montaje, un SDLC pretende producir sistemas de alta calidad que cumplan o superen las expectativas del cliente, basado en los requerimientos del cliente, mediante la entrega de los sistemas que circulan a través de cada fase claramente definida, dentro de plazos programados y costos estimados. Sistemas informáticos son complejos y a menudo (especialmente con la reciente subida de arquitectura orientada a servicios) vincular múltiples sistemas tradicionales potencialmente suministrados por proveedores de software diferentes. Para administrar este nivel de complejidad, un número de SDLC modelos o metodologías se han creado, como por ejemplo"cascada"; "espiral"; "Desarrollo de software ágil"; "prototipado rápido"; "incremental"; "sincronizar y estabilizar".

SDLC puede ser descrito a lo largo de un espectro de ágiles a iterativa a secuencial. Metodologías ágiles, tales como XP y Scrum, se centran en los procesos ligeros que permiten cambios rápidos (sin necesariamente siguiendo el modelo de enfoque SDLC) a lo largo del ciclo de desarrollo. Iterativo metodologías, tales como Rational Unified Process y método de desarrollo de sistemas dinámicos, centrarse en el alcance del proyecto limitado y ampliar o mejorar los productos por iteraciones múltiples. Secuenciales o grande-diseño-up-front modelos (BDUF), tales como cascada, centran en la completa y correcta planificación dirigir grandes proyectos y riesgos a resultados exitosos y predecibles. Otros modelos, tales como desarrollo anamórfico, tienden a centrarse en una forma de desarrollo que es guiado por el alcance del proyecto y adaptativas iteraciones de desarrollo de la función.

En gestión de proyectos un proyecto puede ser definido con una ciclo de vida del proyecto (PLC) y un SDLC, durante el cual se presentan ligeramente diferentes actividades. Según Taylor (2004) "el ciclo de vida del proyecto abarca todas las actividades de la proyecto, mientras que el ciclo de vida de desarrollo de sistemas se centra en la realización del producto requisitos".

SDLC es utilizado durante el desarrollo de un proyecto de IT, describe las diferentes etapas involucradas en el proyecto desde el tablero de dibujo, a través de la realización del proyecto.

Historia

El ciclo de vida del producto describe el proceso para la construcción de sistemas de información de una manera muy deliberada, estructurada y metódica, reiterando cada etapa de vida del producto. Los sistemas desarrollo ciclo vital, según Elliott & Strachan y Radford (2004), "se originó en la década de 1960, para desarrollar a gran escala funcional sistemas de negocio en una época de gran escala conglomerados de negocios. Actividades de sistemas de información giró en torno a pesados procesamiento de datos y números rutinas".

Varios marcos de desarrollo de sistemas han sido basados en parte en SDLC, tales como la Análisis de sistemas estructurado y método de diseño (SSADM) producido por el gobierno del Reino Unido Office of Government Commerce en la década de 1980. Desde entonces, según Elliott (2004), "los enfoques tradicional ciclo de vida de desarrollo de sistemas han sido cada vez más reemplazados con enfoques alternativos y Marcos, que intentaron superar algunas de las deficiencias inherentes de la SDLC tradicional".

Fases

El marco de ciclo de vida de desarrollo de sistema proporciona una secuencia de actividades para los diseñadores de sistemas y desarrolladores a seguir. Consiste en un conjunto de pasos o fases en las que cada fase de la SDLC utiliza los resultados de la anterior.

El SDLC se adhiere a las fases importantes que son esenciales para los desarrolladores, tales como planificación, Análisis, diseño, y implementacióny se explican en la sección siguiente. Incluye evaluación del actual sistema, recopilación de información, estudio de viabilidad y solicitud de aprobación. Se han creado varios modelos SDLC: cascada, fuente, espiral, construir y arreglar, prototipado rápido, incremental y sincronizar y estabilizar. El mayor de éstos y el más conocido, es el modelo de cascada: una secuencia de etapas en las que la salida de cada etapa se convierte en la entrada para el próximo. Estas etapas pueden ser caracterizadas y divididas en diferentes formas, incluyendo las siguientes:

• Análisis preliminar:: El objetivo de la fase 1 es realizar un análisis preliminar, proponer soluciones alternativas, describir los costos y beneficios y presentar un plan preliminar con recomendaciones.

Realizar el análisis preliminar: en este paso, usted necesita saber los objetivos de la organización y la naturaleza y el alcance del problema bajo estudio. Incluso si un problema se refiere solamente a un pequeño segmento de la propia organización entonces tienes que averiguar cuáles son los objetivos de la propia organización. Entonces tienes que ver cómo encaja el problema estudiando en ellos.

Proponer soluciones alternativas: en investigar problemas específicos y objetivos de la organización, puede haber ya cubierto algunas soluciones. Propuestas alternas pueden provenir de entrevistar a empleados, clientes, proveedores o consultores. También puedes estudiar qué hacen los competidores. Con estos datos, tendrá tres opciones: dejar el sistema como está, mejorar o desarrollar un nuevo sistema.

Describir los costos y beneficios.

• Sistemas de análisis, definición de requerimientos:: Define los objetivos del proyecto en las funciones definidas y el funcionamiento de la aplicación deseada. Analiza las necesidades de información para el usuario final.

• Diseño de sistemas:: Describe las características deseadas y operaciones en detalle, incluyendo diseños de pantalla, reglas de negocio, diagramas de procesos, pseudocódigo y otra documentación.

• Desarrollo:: Aquí está escrito el código real.

• Integración y pruebas:: Reúne todas las piezas en un entorno de prueba especial, y luego comprueba si hay errores, fallos y la interoperabilidad.

• Aceptación, instalación, implementación:: La etapa final de desarrollo inicial, donde el software se pone en producción y dirige el negocio real.

• Mantenimiento:: Durante la etapa de mantenimiento de la SDLC, se evalúa el sistema para asegurar que no llega a ser obsoleto. También es donde se realizan cambios al software inicial. Se trata de la evaluación continua del sistema en términos de su rendimiento.
• Evaluación:: No ve esto como una etapa oficial de la SDLC algunas empresas, pero es una importante parte del ciclo de vida. Evaluación paso es una extensión de la fase de mantenimiento y se puede referir que en algunos círculos como revisión post-implementación. Esto es donde se evalúa el sistema que fue desarrollado, así como todo el proceso. ¿Algunas de las preguntas que deben responderse incluyen: el sistema recién implementado cumple los requerimientos del negocio inicial y objetivos? ¿Es el sistema fiable y tolerante? Funciona el sistema según los requisitos funcionales aprobados. Además de evaluar el software que fue puesto en libertad, es importante evaluar la efectividad del proceso de desarrollo. Si hay algún aspecto de todo el proceso, o ciertas etapas, que la administración no está satisfecho con, este es el tiempo para mejorar. Evaluación y valoración es un asunto difícil. Sin embargo, la empresa debe reflexionar sobre las debilidades del proceso y la dirección.
• Eliminación: En esta fase, se desarrollan planes para descartar la información del sistema, hardware y software en hacer la transición a un nuevo sistema. El propósito aquí es mover correctamente, archivar, deseche o destruir información, hardware y software que está siendo reemplazado, en un asunto que impide toda posibilidad de divulgación no autorizada de datos sensibles. Aseguran de que las actividades de eliminación adecuada migración a un nuevo sistema. Especial énfasis es dado a la adecuada preservación y archivos de datos procesados por el sistema anterior. Todo esto debe hacerse conforme a los requisitos de seguridad de la organización.

En el ejemplo siguiente (véase el cuadro) estas etapas del ciclo de vida de desarrollo de sistemas se dividen en diez pasos de definición a la creación y modificación de lo productos de trabajo:

La décima fase ocurre cuando el sistema sea eliminado y la tarea desempeñada es eliminada o transferida a otros sistemas. En los capítulos siguientes se describen las tareas y productos de trabajo para cada fase.

No todos los proyecto requerirá que las fases ejecutarse secuencialmente. Sin embargo, las fases son interdependientes. Dependiendo del tamaño y complejidad del proyecto, fases pueden combinarse o pueden superponerse.

Investigación de sistema

El sistema servici es propuesta. Durante este paso, debemos considerar todas las prioridades actuales que serían afectadas y cómo deben ser manejadas. Antes de hacer cualquier sistema de planificación, un estudio de viabilidad deben realizarse para determinar si la creación de un sistema de nuevo o mejorado es una solución viable. Esto le ayudará a determinar los costos, beneficios, necesidades de recursos y necesidades de los usuarios específicos necesarias para la terminación. El proceso de desarrollo sólo puede continuar una vez aprueba gestión de las recomendaciones del estudio de factibilidad.

Los siguientes son los diferentes componentes del estudio de factibilidad:

• Factibilidad operacional
• Viabilidad económica
• Viabilidad técnica
• Viabilidad de factores humanos
• Viabilidad legal/política

Análisis del sistema

El objetivo de Análisis del sistema es determinar dónde está el problema en un intento de arreglar el sistema. Este paso consiste en derribando el sistema en diferentes piezas para analizar la situación, analizando los objetivos del proyecto, rompiendo lo que tiene que ser creado y tratando de involucrar a los usuarios así que pueden definirse requisitos definidos.

Diseño

En diseño de sistemas, las funciones de diseño y las operaciones se describen en detalle, incluyendo diseños de pantalla, reglas de negocio, diagramas de proceso y otra documentación. La salida de esta etapa describe el nuevo sistema como una colección de módulos o subsistemas.

La etapa de diseño toma como su entrada inicial los requisitos identificados en el documento de requisitos aprobados. Para cada requisito, un conjunto de uno o más elementos de diseño se producirá como resultado de entrevistas, talleres, o esfuerzos de prototipo.

Elementos de diseño describen las características del sistema deseado en detalle y generalmente incluyen diagramas de jerarquía funcional, pantalla diseño diagramas, tablas de reglas de negocio, diagramas de procesos de negocio, pseudo código y un diagrama entidad-relación completa con un diccionario de datos completo. Estos elementos están diseñados para describir el sistema con suficiente detalle, tal que los ingenieros y desarrolladores expertos pueden desarrollar y entregar el sistema con diseño minimalista de entrada adicional.

Entornos

Los ambientes son áreas controladas donde los desarrolladores de sistemas pueden construir, distribuir, instalar, configurar, probar y ejecutar sistemas que se mueven a través del SDLC. Cada ambiente está alineado con las diferentes áreas de la SDLC y pretende tener propósitos específicos. Ejemplos de estos entornos el:

• Entorno de desarrollo, donde los desarrolladores pueden trabajar independientemente uno del otro antes de tratar de combinar su trabajo con el trabajo de otros,
• Entorno común de construir, donde se fusionó el trabajo puede ser construido, juntos, como un sistema combinado,
• Entorno de prueba de integración de sistemas, donde puede probar prueba básica de los puntos de integración de un sistema a otros sistemas de río arriba o río abajo,
• Entorno de prueba de aceptación de usuario, donde pueden probar los actores empresariales contra sus requerimientos de negocio original
• Entorno de producción, donde sistemas finalmente conseguir desplegados, para el uso final de sus usuarios finales previstos.

La planificación para, provisioning y funcionamiento de dichos entornos se conocen como práctica de Gestión medio ambiente.

Pruebas

El código es probado en varios niveles en pruebas de software. A menudo se realizan pruebas de aceptación de unidad, sistema y usuario. Esta es un área gris como existen muchas opiniones diferentes en cuanto a cuáles son las etapas de la prueba y cuánto, si se produce cualquier iteración. Iteración generalmente no es parte del modelo de cascada, pero algunos ocurren generalmente en esta etapa. En la prueba todo el sistema es probado uno por uno

Los siguientes son los tipos de pruebas:

• Defecto de prueba los escenarios fallidos, incluyendo defecto de seguimiento
• Prueba de ruta
• Datos de establecer pruebas
• Pruebas unitarias
• Pruebas del sistema
• Pruebas de integración
• Pruebas de caja negra
• Pruebas de caja blanca
• Pruebas de regresión
• Automatización de pruebas
• Pruebas de aceptación de usuario
• Pruebas de rendimiento de software

Formación y transición

Una vez que un sistema se ha estabilizado a través de pruebas adecuadas, el SDLC asegura que formación adecuada en el sistema es realizado ni documentado antes de hacer la transición del sistema a su personal de apoyo y los usuarios finales.

Entrenamiento generalmente cubre entrenamiento operacional para aquellas personas que se encargará de apoyar el sistema, así como capacitación para aquellos usuarios finales que va a utilizar el sistema después de su entrega a una producción entorno operativo.

Después de entrenamiento ha sido completada con éxito, ingenieros de sistemas y desarrolladores de transición el sistema a su entorno de producción final, donde está destinado a ser utilizado por sus usuarios finales y apoyado por su personal de soporte y operaciones.

Operaciones y mantenimiento

El despliegue el sistema incluye cambios y mejoras antes de la clausura o la puesta del sol del sistema. Mantenimiento el sistema es un aspecto importante del SDLC. Como personal clave cambia posiciones en la organización, se implementarán nuevos cambios. Existen dos enfoques para el desarrollo del sistema; Hay el enfoque tradicional (estructurado) y orientado a objetos. Ingeniería de información incluye el enfoque de sistema tradicional, que también se llama la técnica de análisis y diseño estructurada. El orientado a objetos vistas del enfoque del sistema de información como una colección de objetos que se integran unos con otros para hacer un sistema de información plena y completa.

Evaluación

La fase final de la SDLC es medir la efectividad de la aplicación y evaluar posibles mejoras.

Sistemas de análisis y diseño

El sistemas de análisis y diseño (SAD) es el proceso de desarrollo de sistemas de información (IS) que efectivamente utilizan hardware, software, datos, procesos y personas para apoyar los objetivos de negocios de la empresa. Diseño y análisis del sistema pueden ser considerados el meta-desarrollo de la actividad, que sirve en el escenario y obligado el problema. SAD puede aprovecharse para establecer el equilibrio correcto entre requisitos de alto nivel de competencia en los dominios de análisis funcionales y no funcionales. Diseño y análisis del sistema interactúa fuertemente con arquitectura distribuida empresarial, empresa de arquitectura informática y arquitectura de negocios y se basa principalmente en conceptos como la partición, interfaces, personae y papeles y despliegue/modelado para llegar a una descripción de alto nivel del sistema operativo. Esta descripción de alto nivel es entonces más descompuesta en los componentes y módulos que pueden ser analizados, diseñados y construidos por separado e integrados para lograr el objetivo de negocio. SDLC y SAD son pilares fundamentales del ciclo de vida completo producto y planificación del sistema.

Análisis orientado a objetos

Análisis orientado a objetos (OOA) es el proceso de analizar una tarea (también conocido como un dominio del problema), para desarrollar un modelo conceptual que puede utilizarse para completar la tarea. Un modelo típico de OOA describiría informáticos que podrían usarse para satisfacer un conjunto de requisitos definidos por el cliente. Durante la fase de análisis de problemas, un programador puede considerar una declaración escrita de los requisitos, un documento de visión formal o entrevistas con las partes interesadas u otras partes interesadas. La tarea de abordar puede ser dividida en varias subtareas (o dominios), cada uno representando a una empresa diferente, tecnológica, u otras áreas de interés. Cada subtarea podría analizarse por separado. Limitaciones de aplicación, (por ejemplo, simultaneidad, distribución, persistenciao cómo se va a construir el sistema) no se consideran durante la fase de análisis; por el contrario, ellos son abordados durante el diseño orientado a objetos (OOD).

El modelo conceptual que resulta de OOA típicamente consistirá en un conjunto de casos de usouno o más UML diagramas de clasey un número de diagramas de interacción. También puede incluir algunas de interfaz de usuario maqueta.

La entrada para el diseño orientado a objetos es proporcionada por la salida de Análisis orientado a objetos. Se da cuenta que un artefacto de salida no necesitan estar completamente desarrollada para servir como entrada de diseño orientado a objetos; Análisis y diseño pueden ocurrir en paralelo, y en la práctica los resultados de una actividad pueden alimentar el otro en un ciclo corto de retroalimentación a través de un proceso iterativo. Diseño y análisis pueden realizarse gradualmente, y los artefactos pueden cultivarse continuamente en vez de completamente desarrollado en un tiro.

Algunos artefactos de entrada típicas de orientación a objetos:

• Modelo conceptual:: Modelo conceptual es el resultado del análisis orientado a objetos, capturas de conceptos en el dominio del problema. El modelo conceptual explícitamente es elegido para ser independiente de los detalles de implementación, como el almacenamiento de datos o concurrencia.

• Caso de uso:: Caso de uso es una descripción de las secuencias de eventos que, tomados en conjunto, conducen a un sistema de hacer algo útil. Cada caso de uso proporciona uno o más escenarios transmitir cómo el sistema debe interactuar con los usuarios llamados actores para lograr un objetivo de negocio específica o una función. Actores de caso de uso pueden ser usuarios finales u otros sistemas. En muchas circunstancias casos de uso son más elaborados en diagramas de casos de uso. Diagramas de casos de uso se utilizan para identificar el agente (usuarios u otros sistemas) y los procesos que realizan.

• Diagrama de secuencia del sistema:: Diagrama de secuencia sistema (SSD) es un cuadro que muestra, por una situación particular de un caso de uso, los eventos que generan los agentes externos, su orden y posibles eventos del sistema interamericano.

• Documentaciones de la interfaz de usuario (si corresponde): documento que muestra y describe los apariencia de interfaz de usuario del producto final. No es obligatorio tener esto, pero ayuda a visualizar el producto final y por lo tanto ayuda a la diseñadora.

• Modelo de datos relacional (si corresponde): un modelo de datos es un modelo abstracto que describe cómo los datos es representados y utilizados. Si un base de datos de objeto No es se utiliza, el modelo de datos relacional debe normalmente ser creado antes el diseño, desde la estrategia elegida para Mapeo objeto-relacional es una salida del proceso de diseño OO. Sin embargo, es posible desarrollar el modelo de datos relacionales y los artefactos de diseño orientado a objetos en paralelo, y el crecimiento de un artefacto puede estimular el perfeccionamiento de otros artefactos.

Ciclo de vida

Gestión y control

Fases SPIU relacionadas con controles de administración.

Las fases SDLC servir como una guía programática para actividad de proyecto y proporcionar una forma flexible pero consistente para llevar a cabo proyectos a una profundidad que empareja el alcance del proyecto. Cada uno de los objetivos de la fase SDLC se describen en esta sección con entregables claves, una descripción de las tareas recomendadas y un Resumen de los objetivos de control relacionados para la gestión efectiva. Es fundamental para el director del proyecto establecer y supervisar los objetivos de control durante cada fase SDLC durante la ejecución de proyectos. Los objetivos de control ayudan a proporcionar una declaración clara del resultado deseado o propósito y deben ser utilizados durante todo el proceso SDLC. Objetivos de control se pueden agrupar en categorías principales (dominios) y se refieren a las fases SDLC como se muestra en la figura.

Para gestionar y controlar cualquier iniciativa SDLC, estarán obligado a establecer cierto grado de cada proyecto un estructura de descomposición del trabajo (WBS) para capturar y programar el trabajo necesario para completar el proyecto. Deben mantenerse la WBS y programación todo el material en la sección "Descripción del proyecto" el cuaderno de proyecto. El formato WBS sobre todo quedo al Gerente de proyectos para establecer de una manera que mejor describe el trabajo del proyecto.

Hay algunas áreas claves que deben ser definidos en la WBS como parte de la política SDLC. El siguiente diagrama describe tres áreas principales que se abordarán en la WBS en una forma establecida por el director del proyecto.

Descomposición estructurada organización del trabajo

Estructura de descomposición del trabajo.

La sección superior de la estructura de descomposición del trabajo (WBS) debe identificar las principales fases y los hitos del proyecto de manera sumaria. Además, la sección superior debe proporcionar una visión general del alcance completo y cronograma del proyecto y será parte de los esfuerzos de Descripción del proyecto inicial hacia la aprobación del proyecto. La sección intermedia de la WBS se basa en el desarrollo de siete sistemas fases del ciclo de vida como una guía para el desarrollo de la tarea de WBS. Los elementos de WBS deben consisten en hitos y "tareas" en contraposición a "actividades" y tendrán un plazo definitivo (generalmente dos semanas o más). Cada tarea debe tener una salida medible (documento e.x., decisión o análisis). Una tarea de WBS puede depender de una o más actividades (ingeniería de sistemas, ingeniería de software) y puede requerir estrecha coordinación con otras tareas, ya sea internos o externos al proyecto. Cualquier parte del proyecto que necesitan la ayuda de contratistas debe tener una Declaración de trabajo (SOW) escrito para incluir las tareas apropiadas de las fases SDLC. El desarrollo de una cerda no se produce durante una fase específica del SDLC pero está desarrollado para incluir el trabajo a partir del proceso SDLC que puede llevarse a cabo por recursos externos tales como contratistas.

Líneas de base

Las instantáneas son una parte importante del ciclo de vida de desarrollo de sistemas. Estas líneas se establecen después de cuatro de las cinco fases del SDLC y son críticos a la naturaleza iterativa del modelo. Cada base se considera como un hito en el SDLC.

• base funcional: establecida después de la fase de diseño conceptual.
• asignado referencia: establecida después de la fase de diseño preliminar.
• Referencia del producto: establecida después de la fase de diseño y desarrollo de detalle.
• actualización instantánea de producto: establecida después de la fase de construcción de la producción.

Metodologías complementarias

Complementarios métodos de desarrollo de software al ciclo de vida de desarrollo de sistemas son:

• Prototipos de software
• Desarrollo de aplicaciones conjuntas (JAD)
• Desarrollo rápido de aplicaciones (RAD)
• Programación extrema (XP); extensión del trabajo anterior en prototipos y RAD.
• Open source desarrollo
• Desarrollo del usuario final
• Programación orientada a objetos

Comparación de los enfoques de metodología (Post & Anderson 2006)

	SDLC	RAD	Código abierto	Objetos	JAD	Creación de prototipos	Usuario final
Control	Formal	MIS	Débil	Estándares	Empalme	Usuario	Usuario
Marco de tiempo	Largo	Corto	Medio	Cualquier	Medio	Corto	Corto –
Usuarios	Muchos	Pocos	Pocos	Varía	Pocos	Uno o dos	Uno
Personal de MIS	Muchos	Pocos	Cientos	Split	Pocos	Uno o dos	Ninguno
Transacción /DSS	Transacción	Ambos	Ambos	Ambos	DSS	DSS	DSS
Interfaz	Mínima	Mínima	Débil	Windows	Crucial	Crucial	Crucial
Documentación y formación	Vital	Limitada	Interno	En objetos	Limitada	Débil	Ninguno
Integridad y seguridad	Vital	Vital	Desconocido	En objetos	Limitada	Débil	Débil
Reutilización	Limitada	Algunos	Tal vez	Vital	Limitada	Débil	Ninguno

Fortalezas y debilidades

Pocas personas en el mundo de la computación moderno utilizaría un estricto en cascada para su SDLC como muchas metodologías modernas han reemplazado este pensamiento. Algunos argumentarán que el SDLC ya no se aplica a los modelos como Agile de computación, pero aún es un término ampliamente en uso en los círculos de la tecnología. La práctica SDLC tiene ventajas en los modelos tradicionales de desarrollo de sistemas, que se presta más a un ambiente estructurado. Las desventajas que utilizando la metodología del SDLC es cuando hay necesidad desarrollo iterativo o (es decir, desarrollo web o e-commerce) donde los interesados hay que revisar regularmente el software está diseñado. En lugar de ver SDLC desde una perspectiva de fuerza o debilidad, es mucho más importante para tomar las mejores prácticas del modelo SDLC y aplicarlo para que sea más apropiado para el software se diseña.

Una comparación de las fortalezas y debilidades del SDLC:

Fuerzas y debilidades del SDLC

Fortalezas	Debilidades
Control.	Tiempo de mayor desarrollo.
Supervisar proyectos de grandes envergadura.	Costo de mayor desarrollo.
Pasos detallados.	Los sistemas deben ser definidos por adelantado.
Evaluar los costos y objetivos de realización.	Rigidez.
Documentación.	Difícil de estimar costes, proyecto desborda.
Entrada de usuario definidas.	Introducidos por el usuario a veces es limitado.
Facilidad de mantenimiento.
Diseño y desarrollo de estándares.
Tolera cambios en MIS personal.

Una alternativa para el SDLC es el desarrollo rápido de aplicaciones, que combina la creación de prototipos, la aplicación conjunta de desarrollo e implementación de herramientas CASE. Las ventajas de RAD son velocidad, costo de menor desarrollo y participación activa en el proceso de desarrollo.

Véase también

• Application lifecycle management de
• Modelo IPO
• Metodologías de desarrollo de software
• Ciclo de vida del sistema

Lectura adicional

• Blanchard, B. S., & Fabrycky, J. W. (2006) Ingeniería de sistemas y análisis (4ª ed.) Nueva Jersey: Prentice Hall.
• Cummings, Haag (2006). Sistemas de gestión de información para la era de la información. Toronto, McGraw-Hill Ryerson
• Beynon-Davies P. (2009). Sistemas de información empresarial. Palgrave, Basingstoke. ISBN 978-0-230-20368-6
• Mundo de la informática, 2002Consultado el 22 de junio de 2006 de la World Wide Web:
• Sistemas de información gerencial, 2005Consultado el 22 de junio de 2006 de la World Wide Web:
• Este artículo está basado en material extraído de la Diccionario en línea gratuito de la computación antes de 01 de noviembre de 2008 e incorporada bajo los términos "conjetura" de la GFDL, versión 1.3 o posterior.

Enlaces externos

• El ciclo de vida del desarrollo ágil sistema
• Pensión beneficio Guaranty Corporation – información tecnología soluciones metodología de ciclo de vida
• Marco del ciclo de vida FSA
• HHS Enterprise Performance marco de ciclo de vida
• El ciclo de vida de desarrollo de sistemas abiertos
• Modelado de sistemas desarrollo ciclo vital evolución
• Ciclo de vida de cero desviación
• La defensa integrada en & L vida ciclo gráfico de gestión, la forma de defensa de Estados Unidos de este concepto.

Otras Páginas

• Cemento de asbesto
• Sahand, Iran
• Cementerio de Graceland (Washington, D.C.)
• Arquitectura de software
• Abhyanga
• Ley de Medicare calidad Cancer Care demostracion
• Compaq Aero-
• FC Grand Olympique de Menabe
• Sanjay Rajoura