SDLC - Software Development Life Cycle

Hola chavoz, esta vez les compartiré un poco de lo que es SDLC, todos los conceptos yo los desarrolle y los escribí para entenderle un mejor de lo que se trata y lo que involucra SDLC. Y pues sin mas por el momento, les dejo la Información:

//Historia

La Metodologia SDLC como tal es ya una metodologia usada en las grandes naciones desde hace ya unas cuantas decadas; como tal SDLC no tiene una fecha o un año especifico de creacion aunque Elliott & Strachan & Radford sostienen que SDLC se origino en 1960, debido al impacto que empezaron a tener todos los sistemas de informacion en la vida cotidiana; pero fue hasta 1980 cuando el gobierno de UK decidio aplicar las metodologias SDLC y SSADM en todos sus sistemas de informacion.

Elliott & Strachan & Radford sostienen que en 1960, los conglomerados y grandes empresas de ese tiempo decidieron aplicar la metodologia que utilizaban para manufacturar sus productos en el desarrollo de sus sistemas de infomacion, para asi asegurar que tanto sus productos fisicos (vremas, juguetes, armas, etc.) y sus productos logicos (Sistemas de Informacion o software) tuviesen la informacion necesaria para su uso asi como asegurar su nivel de calidad. Fue en ese entonces cuando estos autores sostienen que SDLC nacio.

Aunque en mi opinion personal, cosnidero que la metodologia SDLC nacio de 1960 a 1980, ya que en ese tiempo la metodologia SDLC se perfecciono, es decir, en 1960 no podemos asegurar que la metodologia como tal nacio ya que no se tiene registros palpales de su existencia, fue hasta 1980 que el gobierno de UK lo utilizo e iso publica la existencia de la metodologia SDLC.

//Informacion General

SDLC es una metodologia que basa el desarrollo de un software en varias etapas. Estas etapas varias dependiendo el autor o el modelo que se este usando, aunque la mayoria de los autores concuerdan que el modelo cascada o waterfall(por su nombre en ingles) tiene las etapas basicas del SDLC, considerando asi al modelo en cascada como el padre de todos los modelos de SDLC. Estas etapas son:

· Analisis de Requerimientos
· Diseño
· Codificacion o Programacion
· Testing
· Implementacion
· Mantenimiento

Aunque no todos los modelos siguen estas etapas, cada modelo tiene una o varias de las etapas antes mencionadas.

Existen muchos modelos que siguen la metodologia de SDLC, pero todos estos modelos se clasifican dentro de la siguiente clasificacion:

· Modelos Estructurados

Todos los modelos en esta categoria son modelos secuenciales, es decir, para pasar de etapa es necesario concluir la etapa anterior.

· Modelos Agiles

Los modelos dentro de la categoria Agil o tambien llamados agiles no se apeguan del todo al SDLC, es decir, no es necesario culminar una etapa para seguir con la siguiente, se pueden omitir etapas o incluir etapas de otros modelos para adecuar el modelo al proyecto.

//Etapas

Análisis de Requerimientos

Esta etapa esta enfocada completamente en la recopilacion de informacion del sistema a desarrollar. Esta etapa se encuentra conformada por 4 sub etapas:

Obtencion de requerimientos

En esta fase es cuando la informacion sobre el proyecto se obtiene, es decir el cliente y el desarrollador se reunen y se tocan temas con respecto al proyecto a desarrollar para conseguir toda la informacion necesaria para su desarrollo

Analisis de la Informacion

Una vez reunida toda la informacion refrente al proyecto, esa informacions e clasifica y se ubica la informacionr ealmente util y la informacion que simplemente no impacta en nada al proyecto

Especificacion de la informacion

La informacion ya analizada es plasmada en un documento llamado SRS (Software Requirement Specification por sus siglas en ingles) o Especificacion de los Requerimientos de Software. En este documento se plasma todo lo que se va a desarrollar y se mapea a los requerimientos del cliente creando otro documento llamado RTM (Requirements Traceability Matrix) o Matrix de Trazabilidad de Requerimientos.

Validacion de la Informacion

En esta etapa los documentos creados son mostrados al cliente y el cliente da su aprobacion o desaprobacion a los documentos. Si es necesario los documentos se modifican o se crean de nuevo, para su modificacion o recreacion es necesario pasar nuevamente por las 4 fases.

Diseño

En esta fase, los documentos creados en la primer etapa: SRS y RTM son traducidos a documentos de diseño, dentro de todos los documentos de diseño que se pueden realizar, es necesario realizar documentos de alto y bajo nivel.

Diseño de Bajo Nivel

En estos documentos se plasma el algoritmo o la logica a usar en el proyecto, es decir, en estos documentos describen en fondo la funcionalidad del sistema, los documentos mas utilizados son:

· Pseudocodigo
· Diagrama de Clases

Diseño de Alto Nivel

En estos documentos se plasma mediante diagramas el flujo de la informacion, se plasma como la informacion va cambiando de proceso a proceso. Los diagramas utilizados varian de empresa a empresa, pero los mas usados son:

· Diagramas de Contexto
· Diagramas Entidad-Relacion
· Diagramas de Flujo de Datos
· Diagrama de Transicion de Estados

Codificación o Programación

La codificacion o Programacion es la etapa en la que los documentos de diseño son traducidos a lenguaje de programacion.

Esta fase es quisas la mas “simple” debido a que solo hay que crear o construir lo que en el diseño se penso aunque no solo se codifica, se tiene que validar y verificar el codigo.

La validacion es tambien llamada “Unit Testing” o Testing de unidad. El programador verifica que el programa realice exactamente lo que se pide en el SRS ya que este documento son las reglas del negocio; en pocas palabras el programador valida que el programa realice exactamente lo que tiene que hacer. Esta etapa la puede hacer el mismo programador(Desk Check o Prueba de Escritorio) o un colega(Peer Review o Revizion de Compañero).

La verificacion es verificar que el codigo cumpla con las especificaciones o estandares, ya sean propios de la empresa que lo desarrolla, Los estandares del cliente o en todo caso ambos estandares.

Por obvias razones de valida primero el programa, para certificar su funcionamiento, para despues dar paso a aplicar los estandares ya sean de codigo o de Interfaces o cualquier estandar que aplique al proyecto en realizacion.

Testing

Esta etapa, es crucial en cualquier proyecto de desarrollo o manufactura debido a que la etapa de Testing o Pruebas certifica la calidad del producto y entre mas calidad el producto tenga, mas costoso el producto es.

El QA Team o Equipo de Calidad es el encargado de llevar acabo esta fase ya que un programador no lo puede realizar, no debido a su falta de habilidad o conocimiento, se refiere mas a un aspecto de objetividad, para ejemplificar esto voy a citar la frase del primer entrenador que tuve:

…”El programador no puede testear su programa porque es como su bebe, el lo creo, lo vio crecer y no lo quiere ver caer por eso no le va a encontrar fallas porque el lo realizo, es su bebe!”…

Por lo tanto varias empresas tienen un equipo dedicado completamente al Testing, para que no se pierda la objetividad y se reporten los defectos encontrados.

Debido a lo anterior existen “batallas” mejor llamadas controversias entre los testers y los desarrolladores, debido que los testers encontraran defectos y los desarrolladores defenderan su programa; Es en esta etapa del proyecto donde se encuentran mas problemas, pero para evitar controversias innecesarias el Lider de proyecto debe de tener las habilidades decesarias para mediar entre estos 2 equipos y definir si en realidad es un defecto o no, una vez que ambos equipos exponen sus puntos de vista.

Para poder llevar acabo el Testing se necesitan 2 cosas:

· La version beta del programa
· Documento donde se certifique que se alcanzo un 100% de cobertura de código

Una vez que los Testers tengan estos documentos en sus manos, el Lider de Proyecto Realiza los siguientes documentos:

· Strategy Plan
· Test Plan
· Traceability Matrix

Y en base a estos 2 doucmentos los Testers realizan los siguientes documentos:

· Test Data
· Test Suites
· Test Cases
· Test Scripts

Concluida la Fase de Testing, el leader en base a la informacion generada, genera un Test Execution Report o Reporte de Ejecucion de Pruebas, el cual sera utilizado por el Lider de Proyecto para decidir si el programa esta listo para su implementacion o necesita algunas mejoras o correcciones.

Strategy Plan

Este Documento es usado para determinar que es lo que se va a medir, El ambiente de prueas necesario y los criterios para detener la etapa del Testing y para reanudar esta etapa. Este documente requiere la firma tanto del Lider como del cliente para que ambos esten enterados de la Estrategia a seguir durante esta fase.

Test Plan

En este documento se determinan el acance de lo que se va a probar, que entre y que no en este apartado es importante para asi dedicar el tiempo que se necesita a las partes que realmento lo necesitan. Tambien se definen los tipos de pruebas que se realizaran y que se necesita para realizar cada Prueba; Un cronograma es definido para determinar los tiempos que se dedicaran a cada prueba. Al igual que el documento Anterior, este tambien necesita la firma de ambos, el lider de proyecto y el cliente para que ambos esten enterados y en comun acuerdo se decida los alcances de esta etapa.

Traceability Matrix

Este documento se crea para tener un “mapping” o mapeo de los TC´s con los requerimientos, para determinar su prioridad, severidad y los tiempos necesarios para cada TC y en caso de que surgan problemas o dudas, verificar con mayor velocidad el requerimiento que es cubierto por el TC con dudas.

Test Data

En este documento se define la informacion que sera usada para esta etapa, es decir, la informacion y/o datos necesarios para ejecutar un TC

Test Suite

Este documento es opcional, ya que este solo contendra un recopilado de ciertos TC que cumplan con el escenario de pruebas.

Con escenario de pruebas nos referimos a un escenario en especifico, una accion que se debe de realizar en el sistema, por ejemplo: Podemos crear un Escenario de prueba para la accion de Agregar, otro mas para Buscar y asi sucesivamente.

Aunque en teoria los Test Suites son creados para especificas acciones, en ocasiones se crean para ciertas regiones, es decir si el sistema va a ser usado tanto en Jalisco como en Guanajuato, se puede crear un Test Suite para Jalisco y otro mas para Guanajuato.

Test Case

Este es el documento en el cual se especifica que accion o movimiento se va a probar, en esencia se puede decir que es el documento mas “pequeño” que se crea en esta fase, ya que se describe una especifica situacion a probar.

Test Script

Este documento se puede crear por separado o dentro del Test Case, ya que este documento define la serie de pasos a seguir para poder ejecutar un determinado TC.

Este documento siempre va ligado a uno o varios TC´s

Implementacion

En esta etapa el programa ya se encuentra listo, donde el 95% o mas de los defectos se han encontrado y se han corregido y el programa se encuentre preparado para su implementacion en el ambiente de produccion.

Durante esta etapa se generan varios documentos, entre los que destacan:

· Roll-Back plan o Plan de Revertir

· Trainning o Capacitacion

· Release Notes o Notas de Liberacion

Roll-back Plan

Documento en el cual se indica que pasos a seguir en caso de que la instalacion o la implementacion halla fracasado para “desinstalar” y regresar el ambiente de produccion al momento anterior a su instalacion

Training

El training como tal no es un documento, pero se genera documentación necesaria para que el usuario final entienda el funcionamiento del programa.

En algunos casos la capacitación es dada por un tester por cierto tiempo, donde este demuestra como es el manejo de la aplicación y enseño a los usuarios el correcto uso de esta y en caso de que surjan problemas “esperados” como manejarlos.

Release Notes

Documento en el cual se indican todas las notas referentes al release actual, pueden ser notas, comentarios o incluso un manual en el que se indique como resolver dudas o problemas

Mantenimiento

En esta etapa el programa es tomado y ya dependiendo del caso que sea, se actualiza, adapta o corrige o mantiene, es decir, se toma el programa se vuelve a codificar, se vuelve a testear y se vuelve a dar la implementacion dependiendo de los requerimientos o necesidades actuales del sistema. Para explicar este proceso, favor de ver la Imagen 1

//Modelos Estructurados

Estos modelos son muy usados en proyectos grandes ya que su desarrollo es secuencial y por lo tanto “predecibles”.

Modelo Iterativo

En este modelo las fases se ven de manera ciclica y en cada iteracion que se de puede o no haber un release, dependiendo si el cliente da la aprobacion o no.

Existen 3 tipos de iteraciones en este modelo:

· Paso de Iteracion
· Iteracion Final
· Iteracion Inicial

Y lo que define cada iteracion es el documento llamado: Project List; en este documento se vacian todas las tareas a realizar, durante la duracion del proyecto. Cada iteracion se “Palomean”, se marcan o borran las tareas ya realizadas. Cuando la lista se encuentra sin marcar o borrar, se dice que es la iteracion Inicial, Cuando la lista se encuntre limpia o completamente tachada, dependiendo sea el caso, se le llama Iteracion Final; mientras no se cumplan ninguna de estas 2 condiciones se le llama Paso de Iteracion.

Modelo Protipo

Este modelo esta basado en crear un prototipo o un voceto de lo que se quiere realizar debido a que el cliente no tiene clara la idea de lo que quiere realizar.

Existen 4 Tipos de Modelos a Prototipo:

· Tipo “throwaway”
· Tipo Incremental
· Tipo Evolutivo
· Tipo Capas

Este Modelo tiene una importante desventaja: No cuenta con la documentacion suficiente, debido a que en este modelo se salta las primeras 2 fases debido a que el cliente no cuenta con la claridad en sus requerimientos, el proyecto carece de calidad y la documentacion base para su actualizacion, mejora o mantenimiento.

Tipo “throwaway”

Este tipo una vez que el cleinte da el visto bueno es desechado, es decir, solo sirve para aclarar las ideas del cliente.

Tipo Incremental

La caracteristica principal de este tipo, es que se va trabajando con la retroalimentacion del cliente, es decir, se va mostrando al cliente con cada mejora o correccion, es decir, su desarrollo es “incremental”.

Tipo Evolutivo

Este modelo se diferencia de los demas es que se desarrollan distintos prototipos, cada prototipo con una funcionalidad distinta y al final del proyecto se integran para conformar el sistema.

Tipo Capas

Este modelo, como su nombre lo dice, trabaja en capas es mas usual ver este tipo de modelo en proyectos orientados a web.

Modelo Evolutivo

Este tipo de modelo es de tipo iterativo y una de sus principales caracteristicas es que divide el proyecto en pequeños modelos de tipo cascada y los usuarios proveen retroalimentacion con cada release.

Aunque a punto personal considero que su principal caracteristica es que evoluciona conforme al tiempo, es decir, “nunca” se termina de desarrollar ya que con cada “release” surgen nuevas mejoras o actualizaciones

Modelo Incremental

En este tipo de modelo los requerimientos son separdos de acuerdo a su prioridad para ser desarrollados acorde a su prioridad; Una vez trabajados esos requerimientos, esos requerimientos son “congelados” evitando asi cualquier cambio, seguiendo el siguiente orden:

Criticos
Altos
Medios
Bajos

El modelo incremental es de tipo iterativo y con cada avance se desarrolla un ligera mejora a lo entregado con anterioridad.

Con cada avance de proyecto se entrega un “release” el cual ya es un producto funcional

Modelo en Cascada

Este modelo es padre de todos los demas modelos, ya que en base a este se basan los demas. Muchos autores lo consideran el padre de los modelos del SDLC debido a que fue el primero en implementar todas las fases del SDLC.

Fue llamado modelo en cascada, debido a que es un modelo secuencial y de hay toma la forma de una cascada. En cada fase se crea documentacion, la cual es necesaria para la correcta realizacion de la fase que le sigue

Modelo en V

Este modelo esta basado en el Testing, basicamente es un modelo en cascada pero en cada fase se realiza un tipo de Testing, ya sea estatico o dinamico. A lo largo de cada fase se crean los documentos de Testing.

Este modelo tambien es muy usado debido a que sigue las bases del modelo en cascada y se empela un mejor Testing a lo alrgo de todo el proyecto

Testing Estatico

Este tipo de testing es realizado a toda la documentacion, inclusive a la documentacion de testing

Testing Dinamico

Este tipo de testing es el realizado como tal al producto.

Modelo en Espiral

Este modelo al igual que el modelo incremental es de tipo iterativo y es utilizado para sistemas de alto riesgo o muy complejos y debido a que considera los riesgos, existen muy pocas probabilidades de que surgan problemas.

Sin embargo usar este tipo de modelo requiere gente con cierta experiencia en el ramo y las herramientas ya que si no se maneja con el control adecuado se corre el riesgo de que el proyecto no sea controlado adecuadamente.

Tambien este tipo de modelos requiere mucho tiempo y esfuerzo y solo puede haber un “release”, el cual es depues de todas las iteraciones al contrario del incremental donde cada iteracion hay un “release”.

//Modelos Agiles

Este tipo de modelos confian en los prototipos y dan un mejor resultado en los proyectos pequeños a diferencia que los modelos estructurados.

Tambien son muy utiles debido a que se adaptan mas rapido y mejor a los cambios en los requerimientos, pero su documentacion es mínima.

Scrum

El scrum esta basado en Sprints, que son los trabajos o tareas a realizar por el equipo por un tiempo, generalmente por mes. Podemos definir que este modelo esta basado en Roles, Artefactos y Reuniones

Roles

· Scrum Master

Administra todas las actividades, gente dentro del Sprint

· Product Owner

Mejor conocido como el “cliente”, el cual es el que necesita su producto en los proximos 30 dias o ciclo de Sprint

· Team

La gente que desarrolla la aplicacion

Artefactos

Los artefactos es mejor entenderlos en este modelo como los documentos necesarios o que se realizan durante el desarrollo del producto.

· Backlog de Producto

En este documento se vacian todos los requerimientos del sistema prioritizados. Este documento es creado durante la reunion de la planeacion del Sprint

· Backlog de Sprint

En este documento de vacian los requerimientos a trabajar durante el Sprint en curso

· Burn Down Chart

Este documento es creado diario, ya que en este se vacian todos los problemas detectados para darle el seguimiento necesario. Tambien se vacian las tareas realizadas, inconclusas o no realizadas

Reuniones

· Reunion de la planeacion del Sprint (Scrum Planning Meeting)

Reunion donde se decide como distribuir las tareas y como se realizaran los sprints

· Reunion diaria (Daily Standup Meeting)

Reunion donde se da el estatus de lo que se realizo en todo el dia

· Revicion de Sprint (Sprint Review)

Reunion para revizar los problemas encontrados durante el Sprint

· Retrospectiva de Sprint (Sprint Retrospective)

Se realiza despues de cada Sprint para revizar lo que se realizo bien, que necesita mas trabajo y cosas por el estilo.

RUP

Rational Unified Process o RUP es un framework de IBM, en este framwork se pueden seleccionar las fases que se deseen o se requieran y es utilizado cuando existe el “dinero” para comprarlo

RAD

Rapid Application Development o RAD es el modelo mas rapido de todos, ya que se va desarrollando “junto” con el cliente, debido a esto necesita una cosntante participacion del cliente.

DSDM

Dynamic System Development Method o DSDM se enfoca en la entrega constante y los cambios son reversibles, es decir, es un modelo muy maleable que permite los cambios y cada vez que haya cambios se hara un “release” nuevo.

//¿Qué modelo Elegir?

Para elegir el metodo que mas se acople a nuestras necesidades, tenemos que contemplar lo siguiente:

· Alcance del proyecto
· Presupuesto
· Ambiente de la organización
· Recursos Disponibles
· Requerimientos Disponibles

Bueno chavoz eso es todo por hoy, espero les haya gustado y cualquier duda o comentario, por favor compartanlo en la zona designada y pues por lo pronto es todo, adios ^_^/