Ciclo de vida del desarrollo de sistemas - Systems development life cycle

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

En ingeniería de sistemas , sistemas de información e ingeniería de software , el ciclo de vida de desarrollo de sistemas ( SDLC ), también conocido como ciclo de vida de desarrollo de aplicaciones , es un proceso para planificar, crear, probar e implementar 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, ya que un sistema puede estar compuesto solo por hardware, solo por software o una combinación de ambos. Por lo general, hay seis etapas en este ciclo: análisis de requisitos, diseño, desarrollo y prueba, implementación, documentación y evaluación.

Visión general

Un ciclo de vida de desarrollo de sistemas se compone de una serie de fases de trabajo claramente definidas y distintas que utilizan los ingenieros de sistemas y los desarrolladores de sistemas para planificar, diseñar, construir, probar y entregar sistemas de información . Como todo lo que se fabrica en una línea de ensamblaje, un SDLC tiene como objetivo producir sistemas de alta calidad que cumplan o superen las expectativas del cliente, en función de los requisitos del cliente, mediante la entrega de sistemas que se mueven a través de cada fase claramente definida, dentro de los plazos programados y las estimaciones de costos. Los sistemas informáticos son complejos y, a menudo (especialmente con el reciente aumento de la arquitectura orientada a servicios ) enlazan múltiples sistemas tradicionales potencialmente suministrados por diferentes proveedores de software. Para gestionar este nivel de complejidad, se han creado una serie de modelos o metodologías SDLC, como cascada , espiral , el desarrollo ágil de software , creación rápida de prototipos , incrementales y sincronizar y estabilizar.

SDLC se puede describir a lo largo de un espectro de metodologías ágiles, iterativas y secuenciales. Las metodologías ágiles, como XP y Scrum , se centran en procesos ligeros que permiten cambios rápidos (sin seguir necesariamente el patrón del enfoque SDLC) a lo largo del ciclo de desarrollo. Las metodologías iterativas , como Rational Unified Process y el método de desarrollo de sistemas dinámicos , se centran en el alcance limitado del proyecto y en la expansión o mejora de los productos mediante múltiples iteraciones. Los modelos secuenciales o de gran diseño inicial (BDUF), como la cascada, se centran en una planificación completa y correcta para guiar los grandes proyectos y riesgos hacia resultados exitosos y predecibles. Otros modelos, como el desarrollo anamórfico , tienden a centrarse en una forma de desarrollo guiada por el alcance del proyecto y las iteraciones adaptativas del desarrollo de características.

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

El SDLC no es una metodología per se, sino más bien una descripción de las fases en el ciclo de vida de una aplicación de software. En un sentido amplio, estas fases son: investigación, análisis, diseño, construcción, prueba, implementación y mantenimiento y soporte. Todas las metodologías de desarrollo de software siguen las fases de SDLC, pero el método de hacerlo varía enormemente entre las metodologías. En el marco de Scrum, por ejemplo, se podría decir que una sola historia de usuario pasa por todas las fases del SDLC en un solo sprint de dos semanas. Compare esto con la metodología en cascada, como otro ejemplo, donde todos los requisitos comerciales (registrados en la fase de análisis del SDLC en un documento llamado Especificación de requisitos comerciales) se traducen en descripciones de características / funciones (registradas en la fase de diseño en un documento llamado la Especificación Funcional) que luego se integran de una vez como una colección de características de la solución, generalmente durante un período de tres a nueve meses, o más. Estas metodologías son enfoques diferentes, sin embargo, ambos contienen las fases de SDLC en las que nace un requisito, luego viaja a través de las fases del ciclo de vida que terminan en la fase final de mantenimiento y soporte, después de lo cual todo el ciclo de vida normalmente comienza de nuevo para una etapa posterior. versión de la aplicación de software.

Historia y detalles

El ciclo de vida del producto describe el proceso para construir sistemas de información de una manera muy deliberada, estructurada y metódica, reiterando cada etapa de la vida del producto. El ciclo de vida del desarrollo de sistemas, según Elliott & Strachan & Radford (2004), "se originó en la década de 1960, para desarrollar sistemas comerciales funcionales a gran escala en una era de conglomerados comerciales a gran escala . Las actividades de los sistemas de información giraban en torno al procesamiento pesado de datos y al procesamiento de números. rutinas ".

Varios marcos de desarrollo de sistemas se han basado en parte en SDLC, como el método de diseño y análisis de sistemas estructurados (SSADM) producido para la Oficina de Comercio Gubernamental del gobierno del Reino Unido en la década de 1980. Desde entonces, según Elliott (2004), "los enfoques tradicionales del ciclo de vida para el desarrollo de sistemas han sido reemplazados cada vez más por enfoques y marcos alternativos, que intentaron superar algunas de las deficiencias inherentes del SDLC tradicional".

Etapas

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

El SDLC se adhiere a fases importantes que son esenciales para los desarrolladores, como la planificación , el análisis , el diseño y la implementación, y se explican en la sección siguiente. Esto incluye la evaluación del sistema utilizado actualmente, la recopilación de información, los estudios de viabilidad y la aprobación de la solicitud. Se han creado varios modelos SDLC, que incluyen cascada, fuente, espiral, construcción y reparación, creación rápida de prototipos, incremental, sincronización y estabilización. El más antiguo de ellos, 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 la siguiente. Estas etapas se pueden caracterizar y dividir de diferentes formas, entre las que se encuentran las siguientes:

Una versión de diez fases del ciclo de vida de desarrollo de sistemas
  • Análisis preliminar : comience con un análisis preliminar, proponga soluciones alternativas, describa costos y beneficios y presente un plan preliminar con recomendaciones.
  1. Realizar el análisis preliminar: Descubrir los objetivos de la organización y la naturaleza y alcance del problema en estudio. Incluso si un problema se refiere solo a un pequeño segmento de la propia organización, averigüe cuáles son los objetivos de la propia organización. Luego vea cómo encaja con ellos el problema que se está estudiando.
  2. Proponer soluciones alternativas: después de indagar en los objetivos y problemas específicos de la organización, es posible que se hayan descubierto varias soluciones. Sin embargo, las propuestas alternativas aún pueden provenir de entrevistas a empleados, clientes, proveedores y / o consultores. También se puede obtener información mediante la investigación de lo que están haciendo los competidores.
  3. Análisis de costo-beneficio: Analice y describa los costos y beneficios de implementar los cambios propuestos. Al final, la decisión final sobre si dejar el sistema como está, mejorarlo o desarrollar un nuevo sistema estará guiada por este y el resto de los datos de análisis preliminares.
  • Análisis de sistemas, definición de requisitos : Defina los objetivos del proyecto en funciones y operaciones definidas de la aplicación prevista. Esto implica el proceso de recopilar e interpretar hechos, diagnosticar problemas y recomendar mejoras al sistema. Los objetivos del proyecto se verán reforzados por el análisis de las necesidades de información del usuario final y la eliminación de cualquier inconsistencia e incompletitud en estos requisitos.
Una serie de pasos seguidos por el desarrollador incluyen:
  1. Recopilación de hechos: obtenga los requisitos del usuario final a través de documentación, entrevistas con el cliente, observación y cuestionarios.
  2. Escrutinio del sistema existente: Identifique los pros y los contras del sistema actual instalado, a fin de llevar adelante los pros y evitar los contras del nuevo sistema.
  3. Análisis del sistema propuesto: encuentre soluciones a las deficiencias descritas en el paso dos y prepare las especificaciones utilizando las propuestas específicas de los usuarios.
  • Diseño de sistemas : en este paso, las funciones y operaciones deseadas se describen en detalle, incluidos diseños de pantalla, reglas comerciales , diagramas de proceso , pseudocódigo y otra documentación.
  • Desarrollo : El código real está escrito aquí.
  • Integración y prueba : todos los módulos se reúnen en un entorno de prueba especial y luego se comprueban en busca de errores, errores e interoperabilidad.
  • Aceptación, instalación, implementación : esta es la etapa final del desarrollo inicial, donde el software se pone en producción y ejecuta el negocio real.
  • Mantenimiento : Durante la etapa de mantenimiento del SDLC, el sistema es evaluado / evaluado para asegurar que no quede obsoleto. Aquí también es donde se realizan los cambios en el software inicial.
  • Evaluación : algunas empresas no ven esto como una etapa oficial del SDLC, mientras que otras lo consideran una extensión de la etapa de mantenimiento y, en algunos círculos, puede denominarse revisión posterior a la implementación. Aquí es donde se evalúa el sistema que se desarrolló, así como todo el proceso. Algunas de las preguntas que deben responderse incluyen si el sistema recién implementado cumple con los requisitos y objetivos comerciales iniciales, si el sistema es confiable y tolerante a fallas, y si funciona de acuerdo con los requisitos funcionales aprobados. Además de evaluar el software que se lanzó, es importante evaluar la eficacia del proceso de desarrollo. Si hay algún aspecto de todo el proceso (o ciertas etapas) con el que la gerencia no está satisfecha, este es el momento de mejorar.
  • Eliminación: en esta fase, se desarrollan planes para interrumpir el uso de la información, el hardware y el software del sistema y realizar la transición a un nuevo sistema. El propósito aquí es mover, archivar, descartar o destruir adecuadamente la información, el hardware y el software que se está reemplazando, de manera que se evite cualquier posibilidad de divulgación no autorizada de datos confidenciales. Las actividades de eliminación garantizan una migración adecuada a un nuevo sistema. Se hace especial hincapié en la conservación y el archivo adecuados de los datos procesados ​​por el sistema anterior. Todo esto debe hacerse de acuerdo con los requisitos de seguridad de la organización.

En el siguiente diagrama, estas etapas del ciclo de vida del desarrollo de sistemas se dividen en diez pasos, desde la definición hasta la creación y modificación de los productos de trabajo de TI:

No todos los proyectos requerirán que las fases se ejecuten secuencialmente; sin embargo, las fases son interdependientes. Dependiendo del tamaño y la complejidad del proyecto, las fases pueden combinarse o superponerse.

Investigación del sistema

Primero se investiga la propuesta del sistema de TI. Durante este paso, considere todas las prioridades actuales que se verían afectadas y cómo deben manejarse. Antes de realizar cualquier planificación del sistema, se debe realizar un estudio de viabilidad para determinar si la creación de un sistema nuevo o mejorado es una solución viable. Esto ayudará a determinar los costos, beneficios, requisitos de recursos y necesidades específicas de los usuarios requeridos para completar. El proceso de desarrollo solo puede continuar una vez que la gerencia apruebe las recomendaciones del estudio de factibilidad.

Los siguientes representan diferentes componentes del estudio de viabilidad:

Análisis

El objetivo del análisis es determinar dónde está el problema, en un intento de arreglar el sistema. Este paso implica dividir el sistema en diferentes partes para analizar la situación, analizar los objetivos del proyecto, desglosar lo que se necesita crear e intentar involucrar a los usuarios para que se puedan definir los requisitos definidos.

Diseño

En el diseño de sistemas , las funciones y operaciones de diseño se describen en detalle, incluidos diseños de pantalla, reglas comerciales, diagramas de procesos y otra documentación. El resultado de esta etapa describirá el nuevo sistema como una colección de módulos o subsistemas.

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

Los elementos de diseño describen en detalle las características deseadas del sistema y, por lo general, incluyen diagramas de jerarquía funcional, diagramas de disposición de pantalla, tablas de reglas comerciales, diagramas de procesos comerciales, pseudocódigo y un diagrama completo de relación entre entidades con un diccionario de datos completo. Estos elementos de diseño están destinados a describir el sistema con suficiente detalle, de modo que los desarrolladores e ingenieros capacitados puedan desarrollar y entregar el sistema con un diseño de entrada adicional mínimo.

Ambientes

Los entornos 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 entorno está alineado con diferentes áreas del SDLC y está destinado a tener propósitos específicos. Ejemplos de tales entornos incluyen:

  • entorno de desarrollo , donde los desarrolladores pueden trabajar de forma independiente antes de intentar fusionar su trabajo con el trabajo de otros;
  • entorno de construcción común , donde el trabajo combinado se puede construir, juntos, como un sistema combinado;
  • entorno de prueba de integración de sistemas , donde se pueden probar las pruebas básicas de los puntos de integración de un sistema con otros sistemas ascendentes o descendentes;
  • entorno de prueba de aceptación del usuario , donde las partes interesadas de la empresa pueden realizar pruebas en función de sus requisitos comerciales originales; y
  • entorno de producción , donde los sistemas finalmente se implementan para su uso final por parte de los usuarios finales previstos.

Pruebas

El código se prueba en varios niveles en las pruebas de software . A menudo se realizan pruebas de aceptación de unidades, sistemas y usuarios. Esta es un área gris, ya que existen muchas opiniones diferentes sobre cuáles son las etapas de prueba y cuánto, si ocurre alguna iteración. La iteración generalmente no es parte del modelo en cascada, pero los medios para rectificar defectos y validar arreglos antes de la implementación se incorporan en esta fase.

Los siguientes son tipos de pruebas que pueden ser relevantes, según el tipo de sistema en desarrollo:

Formación y transición

Una vez que un sistema se ha estabilizado a través de las pruebas adecuadas, el SDLC garantiza que se realice o documente la capacitación adecuada sobre el sistema antes de transferir el sistema a su personal de soporte y usuarios finales. La capacitación generalmente cubre la capacitación operativa para aquellas personas que serán responsables de respaldar el sistema, así como la capacitación para aquellos usuarios finales que utilizarán el sistema después de su entrega a un entorno operativo de producción.

Una vez que la capacitación se ha completado con éxito, los ingenieros de sistemas y los desarrolladores hacen la transición del sistema a su entorno de producción final, donde está destinado a ser utilizado por sus usuarios finales y respaldado por su personal de operaciones y soporte.

Operaciones y mantenimiento

El despliegue del sistema incluye varios cambios y mejoras antes del desmantelamiento o puesta del sol del sistema. El mantenimiento del sistema es un aspecto muy importante de SDLC. A medida que el personal clave cambie de puesto en la organización, se implementarán nuevos cambios. Hay dos enfoques para el desarrollo de sistemas: el enfoque tradicional (estructurado) y el orientado a objetos . La ingeniería de la información incluye el enfoque de sistema tradicional, que también se denomina técnica de análisis y diseño estructurado. El enfoque orientado a objetos ve el sistema de información como una colección de objetos que se integran entre sí para hacer un sistema de información completo y completo.

Evaluación

La fase final del SDLC es medir la eficacia del sistema y evaluar las posibles mejoras.

Análisis y diseño de sistemas

El análisis y diseño de sistemas (SAD) es el proceso de desarrollo de sistemas de información (SI) que utilizan de manera efectiva hardware, software, datos, procesos y personas para respaldar los objetivos comerciales de la empresa. Es un proceso de planificación de un nuevo sistema comercial o reemplazo de un sistema existente definiendo sus componentes o módulos para satisfacer requisitos específicos. El análisis y el diseño de sistemas pueden considerarse la actividad de metadesarrollo, que sirve para preparar el escenario y delimitar el problema. El SAD se puede aprovechar para establecer el equilibrio correcto entre los requisitos de alto nivel en competencia en los dominios de análisis funcional y no funcional. El análisis y el diseño del sistema interactúan fuertemente con la arquitectura empresarial distribuida, la arquitectura de TI empresarial y la arquitectura empresarial, y se basa en gran medida en conceptos como particiones, interfaces, personas y roles, y modelado operativo / de implementación para llegar a una descripción del sistema de alto nivel. Esta descripción de alto nivel se desglosa luego en los componentes y módulos que pueden analizarse, diseñarse y construirse por separado e integrarse para lograr el objetivo comercial. SDLC y SAD son piedras angulares de la planificación de sistemas y productos de ciclo de vida completo.

Análisis orientado a objetos

El análisis orientado a objetos (OOA) es el proceso de analizar una tarea (también conocido como dominio de problemas ), para desarrollar un modelo conceptual que luego se puede utilizar para completar la tarea. Un modelo OOA típico describiría un software de computadora que podría usarse para satisfacer un conjunto de requisitos definidos por el cliente. Durante la fase de análisis de la resolución de problemas, un programador puede considerar una declaración de requisitos por escrito, un documento de visión formal o entrevistas con las partes interesadas u otras partes interesadas. La tarea a abordar puede dividirse en varias subtareas (o dominios), cada una de las cuales representa un negocio, tecnología u otras áreas de interés diferentes. Cada subtarea se analizaría por separado. Las restricciones de implementación (por ejemplo, concurrencia , distribución , persistencia o cómo se construirá el sistema) no se consideran durante la fase de análisis; más bien, se abordan durante el diseño orientado a objetos (OOD).

El modelo conceptual que resulta de OOA consistirá típicamente en un conjunto de casos de uso , uno o más diagramas de clases UML y varios diagramas de interacción . También puede incluir algún tipo de maqueta de interfaz de usuario .

La entrada para el diseño orientado a objetos es proporcionada por la salida del análisis orientado a objetos . Tenga en cuenta que un artefacto de salida no necesita estar completamente desarrollado para que sirva como entrada del diseño orientado a objetos; el análisis y el diseño pueden ocurrir en paralelo y, en la práctica, los resultados de una actividad pueden alimentar a la otra en un breve ciclo de retroalimentación a través de un proceso iterativo. Tanto el análisis como el diseño se pueden realizar de forma incremental, y los artefactos pueden crecer continuamente en lugar de desarrollarse completamente de una sola vez.

Algunos artefactos de entrada típicos (pero comunes a todos los tipos de análisis de diseño) para la orientación a objetos:

  • Modelo conceptual : El modelo conceptual es el resultado del análisis orientado a objetos, captura conceptos en el dominio del problema. El modelo conceptual se elige explícitamente para que sea independiente de los detalles de implementación, como la concurrencia o el almacenamiento de datos.
  • Caso de uso : El caso de uso es una descripción de secuencias de eventos que, en conjunto, llevan a que un sistema haga algo útil. Cada caso de uso proporciona uno o más escenarios que transmiten cómo el sistema debe interactuar con los usuarios llamados actores para lograr una función o objetivo comercial específico. Los actores del caso de uso pueden ser usuarios finales u otros sistemas. En muchas circunstancias, los casos de uso se elaboran con más detalle en diagramas de casos de uso. Los diagramas de casos de uso se utilizan para identificar al actor (usuarios u otros sistemas) y los procesos que realizan.
  • Diagrama de secuencia del sistema : El diagrama de secuencia del sistema (SSD) es una imagen que muestra, para un escenario particular de un caso de uso, los eventos que generan los actores externos, su orden y posibles eventos entre sistemas.
  • Documentación de la interfaz de usuario (si corresponde): documento que muestra y describe la apariencia de la interfaz de usuario del producto final. No es obligatorio tener esto, pero ayuda a visualizar el producto final y, por lo tanto, ayuda al diseñador.
  • Modelo de datos relacionales (si corresponde): un modelo de datos es un modelo abstracto que describe cómo se representan y se utilizan los datos. Si no se utiliza una base de datos de objetos , el modelo de datos relacionales generalmente debe crearse antes del diseño, ya que la estrategia elegida para el mapeo relacional de objetos 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 orientados a objetos en paralelo, y el crecimiento de un artefacto puede estimular el refinamiento de otros artefactos.

Ciclo vital

Gestión y control

Fases de SPIU relacionadas con los controles de gestión

Las fases de SDLC sirven como una guía programática para la actividad del proyecto y brindan una manera flexible pero consistente de llevar a cabo proyectos a una profundidad que coincida con el alcance del proyecto. Cada uno de los objetivos de la fase SDLC se describe en esta sección con entregables clave, una descripción de las tareas recomendadas y un resumen de los objetivos de control relacionados para una gestión eficaz. Es fundamental que el director del proyecto establezca y supervise los objetivos de control durante cada fase de SDLC mientras ejecuta los proyectos. Los objetivos de control ayudan a proporcionar una declaración clara del resultado o propósito deseado y deben usarse durante todo el proceso SDLC. Los objetivos de control pueden agruparse en categorías principales (dominios) y relacionarse con las fases de SDLC como se muestra en la figura.

Para administrar y controlar cualquier iniciativa SDLC, se requerirá que cada proyecto establezca algún grado de estructura de desglose del trabajo (WBS) para capturar y programar el trabajo necesario para completar el proyecto. La EDT y todo el material programático deben mantenerse en la sección "descripción del proyecto" del cuaderno del proyecto. El formato WBS se deja principalmente al gerente del proyecto para que lo establezca de la manera que mejor describa el trabajo del proyecto.

Hay algunas áreas clave que deben definirse en la WBS como parte de la política SDLC. El siguiente diagrama describe tres áreas clave que se abordarán en la EDT de la manera establecida por el gerente del proyecto. El diagrama muestra que la cobertura abarca numerosas fases del SDLC, pero el MCD asociado tiene un subconjunto de asignaciones primarias a las fases del SDLC. Por ejemplo, el análisis y el diseño se realiza principalmente como parte del dominio de adquisición e implementación y la construcción y el prototipo del sistema se realiza principalmente como parte de la entrega y el soporte.

Organización estructurada de desglose del trabajo

Estructura de desglose del trabajo

La sección superior de la estructura de desglose del trabajo (WBS) debe identificar las principales fases e hitos del proyecto de forma resumida. Además, la sección superior debe proporcionar una descripción general del alcance completo y el cronograma del proyecto y será parte del esfuerzo inicial de descripción del proyecto que conducirá a la aprobación del proyecto. La sección central de la EDT se basa en las siete fases del ciclo de vida del desarrollo de sistemas como guía para el desarrollo de tareas de la EDT. Los elementos de la WBS deben consistir en hitos y "tareas" en lugar de "actividades" y tener un período definitivo (generalmente dos semanas o más). Cada tarea debe tener un resultado medible (ex documento, decisión o análisis). Una tarea de WBS puede depender de 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 internas o externas al proyecto. Cualquier parte del proyecto que necesite el apoyo de los contratistas debe tener una declaración de trabajo (SOW) escrita para incluir las tareas apropiadas de las fases del SDLC. El desarrollo de una SOW no ocurre durante una fase específica de SDLC, pero se desarrolla para incluir el trabajo del proceso de SDLC que puede ser realizado por recursos externos como contratistas.

Líneas de base

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

  • Línea de base funcional: establecida después de la fase de diseño conceptual.
  • línea de base asignada: establecida después de la fase de diseño preliminar.
  • línea de base del producto: establecida después de la fase de diseño y desarrollo de detalle.
  • Línea base de producto actualizada: establecida después de la fase de construcción de producción.

Metodologías complementarias

Los métodos de desarrollo de software complementarios al ciclo de vida del desarrollo de sistemas son:

Comparación de enfoques metodológicos (Post y Anderson 2006)
SDLC RAD Fuente abierta Objetos JAD Creación de prototipos Usuario final
Control Formal MAL Débil Estándares Articulación Usuario Usuario
Periodo de tiempo Largo Pequeño Medio Alguna Medio Pequeño Pequeño

-

Usuarios Muchos Pocos Pocos Varía Pocos Uno o dos Uno
Personal de MIS Muchos Pocos Cientos Separar Pocos Uno o dos Ninguno
Transacción / DSS Transacción Ambos Ambos Ambos DSS DSS DSS
Interfaz Mínimo Mínimo Débil Ventanas Crucial Crucial Crucial
Documentación y formación Vital Limitado Interno En objetos Limitado Débil Ninguno
Integridad y seguridad Vital Vital Desconocido En objetos Limitado Débil Débil
Reutilización Limitado Algunos Quizás Vital Limitado Débil Ninguno

Fortalezas y debilidades

Pocas personas en el mundo de la informática moderna usarían un modelo de cascada estricto para su SDLC, ya que muchas metodologías modernas han reemplazado este pensamiento. Algunos argumentarán que el SDLC ya no se aplica a modelos como la computación ágil, pero sigue siendo un término de uso generalizado en los círculos tecnológicos. La práctica SDLC tiene ventajas en los modelos tradicionales de desarrollo de sistemas que se presta más a un entorno estructurado. Las desventajas de utilizar la metodología SDLC es cuando se necesita un desarrollo iterativo o (es decir, desarrollo web o comercio electrónico) cuando las partes interesadas deben revisar periódicamente el software que se está diseñando.

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

Fortalezas y debilidades de SDLC
Fortalezas Debilidades
Control Mayor tiempo de desarrollo
Supervisar grandes proyectos Mayor costo de desarrollo
Pasos detallados Los sistemas deben definirse por adelantado
Evaluar costos y objetivos de finalización Rigidez
Documentación Es difícil estimar los costos, el proyecto se sobrepasa
Entrada de usuario bien definida La entrada del usuario a veces es limitada
Facilidad de mantenimiento Poco paralelismo
Estándares de desarrollo y diseño La automatización de la documentación y los estándares es limitada
Tolera cambios en el MIS de la dotación de personal No tolera cambios en los requisitos
Los proyectos enlatados desde el principio dan como resultado poco o ningún valor

Una alternativa al SDLC es el desarrollo rápido de aplicaciones, que combina la creación de prototipos, el desarrollo de aplicaciones conjuntas y la implementación de herramientas CASE. Las ventajas de RAD son la velocidad, el costo de desarrollo reducido y la participación activa del usuario en el proceso de desarrollo.

Ciclo de vida del sistema

El ciclo de vida del sistema en la ingeniería de sistemas es una vista de un sistema o sistema propuesto que aborda todas las fases de su existencia para incluir la concepción, diseño y desarrollo del sistema, producción y / o construcción, distribución, operación, mantenimiento y soporte, retiro, eliminación y eliminación.

Diseño conceptual

La etapa de diseño conceptual es la etapa en la que se examina una necesidad identificada, se definen los requisitos para las posibles soluciones, se evalúan las posibles soluciones y se desarrolla una especificación del sistema. La especificación del sistema representa los requisitos técnicos que proporcionarán una guía general para el diseño del sistema. Debido a que este documento determina todo el desarrollo futuro, la etapa no se puede completar hasta que una revisión del diseño conceptual haya determinado que la especificación del sistema aborda adecuadamente la necesidad motivadora.

Los pasos clave dentro de la etapa de diseño conceptual incluyen:

  • Necesita identificación
  • Análisis de viabilidad
  • Análisis de requisitos del sistema
  • Especificación del sistema
  • Revisión de diseño conceptual

Diseño preliminar del sistema

Durante esta etapa del ciclo de vida del sistema, los subsistemas que realizan las funciones deseadas del sistema se diseñan y especifican de acuerdo con la especificación del sistema. Se definen las interfaces entre los subsistemas, así como los requisitos generales de prueba y evaluación. Al finalizar esta etapa, se produce una especificación de desarrollo que es suficiente para realizar un diseño y desarrollo detallados.

Los pasos clave dentro de la etapa de diseño preliminar incluyen:

  • Análisis funcional
  • Asignación de requisitos
  • Estudios detallados de compensaciones
  • Síntesis de opciones del sistema
  • Diseño preliminar de modelos de ingeniería
  • Especificación de desarrollo
  • Revisión preliminar del diseño

Por ejemplo, como analista de sistemas de Viti Bank, se le ha asignado la tarea de examinar el sistema de información actual. Viti Bank es un banco de rápido crecimiento en Fiji. Los clientes de las zonas rurales remotas tienen dificultades para acceder a los servicios bancarios. Les toma días o incluso semanas viajar a una ubicación para acceder a los servicios bancarios. Con la visión de satisfacer las necesidades de los clientes, el banco ha solicitado sus servicios para examinar el sistema actual y proponer soluciones o recomendaciones de cómo se puede proporcionar el sistema actual para satisfacer sus necesidades.

Diseño y desarrollo de detalle

Esta etapa incluye el desarrollo de diseños detallados que llevan el trabajo de diseño inicial a una forma completa de especificaciones. Este trabajo incluye la especificación de interfaces entre el sistema y su entorno previsto y una evaluación integral de los requisitos logísticos, de mantenimiento y de soporte del sistema. El diseño y desarrollo de detalle es responsable de producir el producto, proceso y especificaciones de material y puede resultar en cambios sustanciales a la especificación de desarrollo.

Los pasos clave dentro de la etapa de diseño y desarrollo de detalles incluyen:

  • Diseño detallado
  • Síntesis detallada
  • Desarrollo de modelos de ingeniería y prototipos
  • Revisión de la especificación de desarrollo
  • Especificación de producto, proceso y material
  • Revisión de diseño crítico

Producción y construcción

Durante la etapa de producción y / o construcción, el producto se construye o ensambla de acuerdo con los requisitos especificados en las especificaciones del producto, proceso y material, y se implementa y prueba dentro del entorno operativo objetivo. Las evaluaciones del sistema se llevan a cabo para corregir las deficiencias y adaptar el sistema para una mejora continua.

Los pasos clave dentro de la etapa de construcción del producto incluyen:

  • Producción y / o construcción de componentes del sistema.
  • Test de aceptación
  • Distribución y operación del sistema
  • Prueba y evaluación operativa
  • Evaluación del sistema

Utilización y soporte

Una vez implementado por completo, el sistema se utiliza para su función operativa prevista y se mantiene dentro de su entorno operativo.

Los pasos clave dentro de la etapa de utilización y soporte incluyen:

  • Funcionamiento del sistema en el entorno del usuario
  • Gestión del cambio
  • Modificaciones del sistema para mejorar
  • Evaluación del sistema

Eliminación y eliminación

La efectividad y la eficiencia del sistema deben evaluarse continuamente para determinar cuándo el producto ha cumplido su ciclo de vida efectivo máximo. Las consideraciones incluyen: existencia continua de la necesidad operativa, correspondencia entre los requisitos operativos y el rendimiento del sistema, la viabilidad de la eliminación del sistema frente al mantenimiento y la disponibilidad de sistemas alternativos.

Ver también

Referencias

Otras lecturas

  • Cummings, Haag (2006). Sistemas de gestión de la 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
  • Computer World, 2002 , recuperado el 22 de junio de 2006 de la World Wide Web:
  • Management Information Systems, 2005 , recuperado el 22 de junio de 2006 de la World Wide Web:
  • Este artículo se basa en material extraído del Diccionario de Computación en línea gratuito antes del 1 de noviembre de 2008 e incorporado bajo los términos de "renovación de licencias" de la GFDL , versión 1.3 o posterior.

enlaces externos