10.2: Modelo de ciclo de vida de desarrollo de sistemas (SDLC)
- Page ID
- 155508
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)Modelo de ciclo de vida de desarrollo de sistemas (SDLC)
SDLC se desarrolló por primera vez en la década de 1960 para administrar los grandes proyectos asociados con los sistemas corporativos que se ejecutan en mainframes. Se trata de un proceso muy estructurado diseñado para gestionar grandes proyectos con el esfuerzo de muchas personas, incluyendo profesionales técnicos, empresariales, de soporte. Estos proyectos suelen ser costosos de construir y tienen un gran impacto en la organización. Un proyecto fallido o una decisión comercial incorrecta de elegir un proyecto incorrecto para financiar puede ser una catástrofe comercial o financiera para una organización.
SDLC es un modelo que define un proceso de un conjunto de fases para planeación, análisis, diseño, implementación, mantenimiento. El capítulo 1 discute que un sistema de información (IS) incluye hardware, software, base de datos, redes, procesos y personas. SDLC se ha utilizado a menudo para administrar un proyecto de IS que puede incluir uno, algunos o todos los elementos de un IS. Vamos a recorrer cada una de las cinco fases de un SDLC como se muestra en la Figura 10.1:
- Planeación. En esta fase, una solicitud es iniciada por alguien que actúa como patrocinador de esta idea. Se forma un pequeño equipo para realizar una evaluación preliminar del mérito y factibilidad de la solicitud. Los objetivos de esta fase son:
- Determinar cómo encaja la solicitud con la estrategia u objetivos de negocio de la compañía.
- Realizar un análisis de factibilidad, que incluya un análisis de la factibilidad técnica (¿es posible crearlo?) , la viabilidad económica (¿podemos permitirnos hacerlo?) , y la factibilidad legal (¿se nos permite hacerlo?).
- Para recomendar un go/no ir por la solicitud. Si es un ir, entonces también se produce una propuesta de concepto para que la gerencia la apruebe.
- Análisis. Una vez aprobada la propuesta conceptual, el proyecto se formaliza con un nuevo equipo de proyecto (incluida la fase anterior). Utilizando la propuesta conceptual como punto de partida, los miembros del proyecto trabajan con diferentes grupos de interés para determinar los requisitos específicos del nuevo sistema. No se realiza programación ni desarrollo en este paso. Los objetivos de esta fase son:
- Identificar y entrevistar a los actores clave.
- Documentar procedimientos clave
- Desarrollar los requisitos de datos
- Elaborar un documento de requisitos del sistema como resultado de esta fase. Esto tiene los detalles para comenzar el diseño del sistema.
- Diseño. Una vez que se aprueben los requisitos del sistema, el equipo puede ser reconfigurado para traer más miembros. Esta fase tiene como objetivo que el equipo del proyecto tome el documento de requisitos del sistema creado en la fase anterior y desarrolle los detalles técnicos específicos requeridos para el sistema. Los objetivos son:
- Traducir los requerimientos del negocio en requerimientos técnicos específicos
- Diseñar la interfaz de usuario, base de datos, entradas y salidas de datos e informes
- Producir un documento de diseño del sistema como resultado de esta fase. Este documento tendrá todo lo que un programador necesitará para crear el sistema.
- Implementación. Una vez que se aprueba un diseño de sistema, el código de software finalmente se escribe en la fase de programación, y también ocurre el esfuerzo de desarrollo de otros elementos como el hardware. El propósito es crear un sistema de trabajo inicial. Los objetivos son:
- Desarrollar el código de software y otros componentes de IS. Usando el documento de diseño del sistema como guía, los desarrolladores comienzan a codificar o desarrollar todos los componentes del proyecto IS.
- Pruebe el sistema de trabajo a través de una serie de pruebas estructuradas como:
- La primera es una prueba unitaria, que prueba partes individuales del código en busca de errores o errores.
- Lo siguiente es una prueba del sistema, donde se prueban los diferentes componentes del sistema para garantizar que funcionen juntos correctamente.
- Finalmente, la prueba de aceptación del usuario permite a aquellos que estarán usando el software probar el sistema para asegurarse de que cumple con sus estándares.
- Vuelva a probar de forma iterativa cualquier corrección para abordar cualquier error, error o problema encontrado durante las pruebas.
- Capacitar a los usuarios
- Proporcionar documentación
- Realizar las conversiones necesarias de cualquier sistema anterior al nuevo sistema.
- Producir, como resultado, el sistema de trabajo inicial que cumpla con los requisitos establecidos en la fase de análisis y el diseño desarrollado en la fase de diseño.
- Mantenimiento. Esta fase se lleva a cabo una vez que se completa la fase de implementación. En esta fase, el sistema debe contar con un proceso de soporte estructurado para:
- Informar errores
- Implementar correcciones de errores
- Aceptar solicitudes de nuevas funciones
- Evaluar las prioridades de los errores reportados o las características solicitadas a implementar
- Identifique un horario predecible y regular para lanzar actualizaciones del sistema y realizar copias de seguridad.
- Desechar los datos y cualquier otra cosa que ya no sea necesaria
Las organizaciones pueden combinar o subdividir estas fases para adaptarse a sus necesidades. Por ejemplo, en lugar de una fase, Planeación, una organización puede optar por tener dos fases: Iniciación, Concepto; o dividir la implementación en dos fases: implementación y pruebas.
Modelo Cascada
Un modelo específico basado en SDLC es el modelo Waterfall, y a menudo se piensa que el nombre es el mismo que SDLC. Se utiliza para administrar proyectos de software como se representa en la Fig 10.2 con cinco fases: Requisitos, Diseño, Implementación, Verificación y Mantenimiento. Este modelo enfatiza que cada fase debe completarse antes de que pueda comenzar la siguiente (de ahí el nombre cascada). Por ejemplo, no se permiten cambios en los requisitos una vez iniciada la fase de implementación, o bien deben buscarse y aprobarse cambios a un proceso de cambio. Pueden requerir que el proyecto se reinicie desde la fase de requisitos ya que es necesario aprobar nuevos requisitos, lo que puede hacer que se revise el diseño antes de que pueda comenzar la fase de implementación.
La estructura rígida del modelo en cascada ha sido criticada por ser bastante rígida y hacer que los equipos sean reacios al riesgo para evitar volver a fases anteriores. Sin embargo, también hay beneficios en tal estructura. Algunas ventajas y desventajas de SDLC y Waterfall son:
Ventajas y desventajas de SDLC y Cascada
|
Ventajas |
Desventajas |
|
El sólido proceso para controlar y rastrear los cambios para minimizar la cantidad de riesgos puede descarrilar el proyecto sin saberlo. |
Tómese el tiempo para grabar todo, lo que conlleva un costo adicional y tiempo al horario. |
|
Los procesos estándar y transparentes ayudan a la gestión de equipos grandes. |
Demasiado tiempo dedicado a asistir a reuniones, buscar aprobación, etc. lo que conlleva un costo adicional y tiempo al horario. |
|
La documentación reduce los riesgos de perder personal, más fácil agregar personas al proyecto. |
A algunos miembros no les gusta dedicar tiempo a escribir, lo que lleva al tiempo adicional necesario para completar un proyecto. |
|
Es más fácil rastrear un problema en el sistema hasta su raíz siempre que se encuentren errores, incluso después de que se complete el proyecto. |
Es difícil incorporar cambios o comentarios de los clientes ya que el proyecto tiene que remontarse a una o más fases anteriores, lo que lleva a los equipos a volverse reacios al riesgo. |
A lo largo del tiempo se desarrollan otros modelos para abordar estas críticas. Discutiremos otros dos modelos: Desarrollo rápido de aplicaciones y Agile, como diferentes enfoques para SDLC.
Desarrollo rápido de aplicaciones (RAD)
El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software (o desarrollo de sistemas) que se centra menos en la planificación e incorporación de cambios de forma continua. RAD se enfoca en construir rápidamente un modelo de trabajo del software o sistema, obtener comentarios de los usuarios y actualizar el modelo de trabajo. Después de varias iteraciones de desarrollo, se desarrolla e implementa una versión final. Vamos a recorrer las cuatro fases en el modelo RAD como se representa en la Fig. 10.3.
- Planeación de Requisitos. Esta fase es similar a las fases de planeación, análisis y diseño del SDLC.
- Diseño de Usuario. En esta fase, los representantes de los usuarios trabajan con los analistas de sistemas, diseñadores y programadores para crear interactivamente el diseño del sistema. Una técnica para trabajar con todos estos diversos grupos de interés es la sesión de Desarrollo de Aplicaciones Conjuntas (JAD). Una sesión JAD permite que todos los usuarios relevantes que interactúen con los sistemas desde diferentes perspectivas, otros actores clave, incluidos los desarrolladores, tengan una discusión estructurada sobre el diseño del sistema. Los objetivos son que los usuarios comprendan y adopten el modelo de trabajo y que los desarrolladores comprendan cómo el sistema necesita funcionar desde la perspectiva del usuario para brindar una experiencia de usuario positiva.
- Construcción. En la fase de construcción, las tareas son similares a la fase de implementación de SDLC. Los desarrolladores continúan trabajando interactivamente con los usuarios para incorporar sus comentarios a medida que interactúan con el modelo de trabajo que se está desarrollando. Este es un proceso interactivo, y se pueden hacer cambios a medida que los desarrolladores están trabajando en el programa. Este paso se ejecuta en paralelo con el paso de Diseño de Usuario de manera iterativa hasta que se desarrolla una versión aceptable del producto.
- Cutover. Este paso es similar a algunas de las tareas de la fase de implementación de SDLC. El sistema se pone en marcha o está completamente desplegado. Aquí se completan todos los pasos necesarios para pasar del estado anterior al uso del nuevo sistema.
En comparación con el modelo SDLC o Waterfall, la metodología RAD está mucho más comprimida. Muchos de los pasos de SDLC se combinan, y el enfoque está en la participación e iteración del usuario. Esta metodología es más adecuada para proyectos más pequeños y tiene la ventaja adicional de brindar a los usuarios la capacidad de proporcionar retroalimentación a lo largo del proceso. SDLC requiere más documentación y atención al detalle y se adapta bien a proyectos grandes y intensivos en recursos. RAD es más adecuado para proyectos que requieren menos recursos y necesitan desarrollarse rápidamente. Estas son algunas de las ventajas y desventajas de RAD:
Ventajas y desventajas de RAD
|
Ventajas |
Desventajas |
|
Incrementar la calidad debido a la frecuencia de interacción con los usuarios |
Riesgos de implementación débil de características que no son visibles para los usuarios, como la seguridad |
|
Reducir los riesgos de rechazo de los usuarios a aceptar el producto terminado |
La falta de control sobre los cambios del sistema debido a la rápida respuesta de una versión en funcionamiento para abordar los problemas de los usuarios. |
|
Mejore las posibilidades de finalización puntual y dentro del presupuesto a medida que los usuarios se actualizan en tiempo real, evitando sorpresas durante el desarrollo. |
La falta de diseño ya que se están poniendo cambios en el sistema podría afectar, sin saberlo, a otras partes del sistema. |
|
Incrementar el tiempo de interacción entre desarrolladores/expertos y usuarios |
Los escasos recursos como desarrolladores están amarrados, lo que podría ralentizar otros proyectos. |
|
El más adecuado para equipos de proyectos de tamaño pequeño a mediano |
Difícil de escalar a equipos grandes |
Metodologías de desarrollo ágil
Las metodologías ágiles son un conjunto de metodologías que utilizan cambios incrementales enfocados en la calidad y la atención al detalle. Cada incremento se libera en un periodo de tiempo específico (llamado caja de tiempo), creando un calendario de lanzamiento regular con objetivos particulares. Si bien se consideran una metodología separada de la RAD, comparten algunos de los mismos principios: desarrollo iterativo, interacción con el usuario y cambiabilidad. Las metodologías ágiles se basan en el “Manifiesto Ágil”, lanzado por primera vez en 2001.
Las características de los métodos ágiles incluyen:
- pequeños equipos interfuncionales que incluyen miembros y usuarios del equipo de desarrollo;
- reuniones diarias de estado para discutir el estado actual del proyecto;
- incrementos cortos de plazos (de días a una o dos semanas) para cada cambio que se complete; y
- Al final de cada iteración, se completa un proyecto de trabajo para demostrar a los grupos de interés.
En esencia, el enfoque Agile pone un mayor valor a las tareas que promueven la interacción, construyen versiones de trabajo frecuentes, la colaboración cliente/usuario, y una respuesta rápida al cambio y menos énfasis en los procesos y la documentación. El objetivo de las metodologías ágiles es proporcionar la flexibilidad de un enfoque iterativo al tiempo que se garantiza un producto de calidad.
Hay una variedad de modelos que se construyen utilizando metodologías Agile. Un ejemplo de ello es el modelo de desarrollo de Scrum.
Modelo de desarrollo de Scrum
Este modelo es adecuado para equipos pequeños que trabajan para producir un conjunto de características dentro de interacciones de tiempo fijo, como de dos a cuatro semanas, llamadas sprints. Vamos a recorrer los cuatro elementos clave de un modelo Scrum como se representa en la Fig 10.4.
Fig 10.4. El método de gestión de proyectos Scrum. La imagen de Lakeworks tiene licencia CC BY-SA 4.0
- Backlog de productos. Esta es una lista detallada de los trabajos a realizar. Todo el trabajo se prioriza en base a criterios como riesgos, dependencias, misión crítica, etc. Los desarrolladores seleccionan sus propias tareas y se autoorganizan para hacer el trabajo.
- Backlog de Sprint. Esta es una lista de los trabajos a realizar en el próximo sprint.
- Sprint. Este es un tiempo fijo, como 1 día, 2 semanas o 4 semanas, según lo acordado por el equipo. Una reunión diaria de progreso se llama scrum diario, generalmente una reunión corta de 10-15 minutos facilitada por un maestro de scrum cuya función es eliminar los bloqueos para el equipo.
- Incremento de trabajo del softwar e. Esta es una versión de trabajo que se construye incrementalmente con las listas de desglose al final de los sprints.
Metodología Lean
Una última metodología que discutiremos es un concepto relativamente nuevo tomado del bestseller de negocios The Lean Startup, de Eric Reis.
Esta metodología se enfoca en tomar una idea inicial y desarrollar un producto mínimo viable (MVP). El MVP es una aplicación de software que funciona con la funcionalidad suficiente para demostrar la idea detrás del proyecto. Una vez desarrollado el MVP, se entrega a usuarios potenciales para su revisión. La retroalimentación sobre el MVP se genera de dos formas: (1) observación directa y discusión con los usuarios, y (2) estadísticas de uso recopiladas del propio software. Usando estas dos formas de retroalimentación, el equipo determina si deben continuar en la misma dirección o repensar la idea central del proyecto, cambiar las funciones o crear un nuevo MVP. Este cambio de estrategia se llama pivote. Se desarrollan varias iteraciones del MVP, con nuevas funciones agregadas cada vez en función de la retroalimentación, hasta completar un producto final.
La mayor diferencia entre la metodología lean y las demás metodologías es que se desconoce el conjunto completo de requisitos del sistema cuando se inicia el proyecto. A medida que se publica cada iteración del proyecto, se utilizan las estadísticas y los comentarios recopilados para determinar los requisitos. La metodología lean funciona mejor en un entorno emprendedor donde una empresa está interesada en determinar si vale la pena desarrollar su idea para una aplicación de software.
Referencias:
Manifiesto para el Desarrollo de Software Ágil (2001). Recuperado el 10 de diciembre del 2020 de http://agilemanifesto.org/
El Lean Startup. Recuperado el 9 de diciembre de 2020, de http://theleanstartup.com/