Metodologías de Desarrollo de Sistemas

Luis Lara Plaza – Sistemas de Informaciòn.

 ciclo de vida del software
• El término ciclo de vida del software describe el desarrollo de
software, desde la fase inicial hasta la fase final. El propósito
de este programa es definir las distintas fases intermedias que
se requieren para validar el desarrollo de la aplicación, es
decir, para garantizar que el software cumpla los requisitos
para la aplicación y verificación de los procedimientos de
desarrollo: se asegura de que los métodos utilizados son
apropiados.
• Estos programas se originan en el hecho de que es muy
costoso rectificar los errores que se detectan tarde dentro de
la fase de implementación. El ciclo de vida permite que los
errores se detecten lo antes posible y por lo tanto, permite a
los desarrolladores concentrarse en la calidad del software, en
los plazos de implementación y en los costos asociados.
 Ciclo vida del software

• El ciclo de vida básico de un software consta de los siguientes procedimientos:

• Definición de objetivos: definir el resultado del proyecto y su papel en la
estrategia global.
• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los
requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
• Diseño general: requisitos generales de la arquitectura de la aplicación.
• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
• Programación (programación e implementación): es la implementación de un
lenguaje de programación para crear las funciones definidas durante la etapa de
diseño.
• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para
garantizar que se implementaron de acuerdo con las especificaciones.
• Integración: para garantizar que los diferentes módulos se integren con la
aplicación. Éste es el propósito de la prueba de integración que está
cuidadosamente documentada.
 Ciclo vida de software
• Prueba beta (o validación), para garantizar que el software
cumple con las especificaciones originales.
• Documentación: sirve para documentar información
necesaria para los usuarios del software y para desarrollos
futuros.
• Implementación
• Mantenimiento: para todos los procedimientos correctivos
(mantenimiento correctivo) y las actualizaciones secundarias
del software (mantenimiento continuo).
• El orden y la presencia de cada uno de estos procedimientos
en el ciclo de vida de una aplicación dependen del tipo de
modelo de ciclo de vida acordado entre el cliente y el equipo
de desarrolladores.
 Metodologías de Desarrollo de Sistemas

Tradicional (secuencial o en cascada)

Iterativas (RUP)

Agiles (Scrum)
 Tradicional o Secuencial
(método en cascada)
Características:
• Entender completamente el problema, sus requisitos y restricciones,
escribirlo y conseguir que todos los interesados estén de acuerdo;
• Diseñar una solución que cumpla con todos los requisitos y
restricciones, y asegurarse que todos los interesados estén de acuerdo;
• Implementar la solución;
• Verificar que la implementación cumple con los requisitos establecidos;
• Entregar.
 Método cascada
• El modelo de ciclo de vida en cascada
comenzó a diseñarse en 1966 y se terminó
alrededor de 1970. Se define como una
secuencia de fases en la que al final de cada
una de ellas se reúne la documentación para
garantizar que cumple las especificaciones y
los requisitos antes de pasar a la fase siguiente
 El proceso secuencial, o “de cascada”
Requisitos
/ Análisis

Análisis /
Diseño

Implemen-
tación
➢ Captura de requerimientos: es donde el cliente
expone sus necesidades y requerimientos. Testeo
➢ Análisis: se modelan los requerimientos del
usuario.
➢ Diseño: se planea una solución al problema, tiene Entrega
en cuenta como va a ser
implementado.
➢ Implementación: se implementa el sistema.
➢ Testeo: se prueba que el sistema funcione
correctamente.
 Metodologías Iterativas
RUP – Rational Unified Process

Características:
• Desarrollo Iterativo : Es muy bueno conocer las especificaciones al inicio,
pero muchas veces no se puede, hay que iterar.

• Administrar los requerimientos: Siempre construya cosas que alguien

haya pedido.

• Usar componentes : Desarrollo orientado a objetos para promover la

reutilización

• Modelar Visualmente : Los lenguages de modelación visual facilitan la

interacción con los usuarios.

• Verificar la Calidad: Testing frecuente orientado a controlar la calidad.

• Controlar los Cambios: Mantener el control del proyecto.
Descripción general:

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor
o menor hincapié en las distintas actividades.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de

modelado del negocio y de requisitos. En la fase de elaboración, las iteraciones
se orientan al desarrollo de la línea base de la arquitectura, abarcan más los
flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis,
diseño y una parte de implementación orientado a la línea base de la
arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por

medio de una serie de iteraciones. Para cada iteración se seleccionan algunos
Casos de Uso, se refinan su análisis y diseño y se procede a su implementación
y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan
iteraciones hasta que se termine la implementación de la nueva versión del
producto.

En la fase de transición se pretende garantizar que se tiene un producto

preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero
dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
Descripción de fases

Fase de Inicio : En esta fase desarrollará los requisitos del producto desde la
perspectiva del usuario, los cuales serán establecidos en el artefacto Visión. Los
principales casos de uso serán identificados y se hará un refinamiento del Plan de
Desarrollo del Proyecto. La aceptación del cliente / usuario del artefacto (documento)
Visión y el Plan de Desarrollo marcan el final de esta fase.

Fase de Elaboración: En esta fase se analizan los requisitos y se desarrolla un prototipo

de arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Al
final de esta fase, todos los casos de uso correspondientes a requisitos que serán
implementados en el primer release de la fase de Construcción deben estar analizados
y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo
de la arquitectura del sistema marca el final de esta fase.
Fase de Construcción: Durante la fase de construcción se terminan de analizar y
diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño. El
producto se construye en base a iteraciones, cada una produciendo un release al cual
se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboración
de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión del
release, con la capacidad operacional parcial del producto que se haya considerado
como crítica, lista para ser entregada a los usuarios para pruebas beta.

Fase de Transición: En esta fase se prepararán los releases para distribución,

asegurando una implantación y cambio del sistema previo de manera adecuada,
incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase
incluye, la entrega de toda la documentación del proyecto con los manuales de
instalación y todo el material de apoyo al usuario, la finalización del entrenamiento de
los usuarios y el empaquetamiento del producto.
 Metodologías Agiles
SCRUM

• Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto
valor de negocio en el menor tiempo.

• Nos permite rápidamente y en repetidas ocasiones inspeccionar software real

de trabajo (cada dos semanas o un mes).

• El negocio fija las prioridades. Los equipos se auto-organizan a fin de

determinar la mejor manera de entregar las funcionalidades de más alta
prioridad.

• Cada dos semanas o un mes, cualquiera puede ver el software real

funcionando y decidir si liberarlo o seguir mejorándolo en otro sprint
(iteración).
 24 horas

Sprint
Objetivo del Sprint 2-4 semanas

Sprint
Backlog Incremento del producto
Return potencialmente entregable

Product
Backlog
Descripción General:

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones

de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración
(Sprint) tiene que proporcionar un resultado completo, un incremento de producto
final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente
cuando lo solicite.

El proceso parte de la lista (Product Backlog) de objetivos/requisitos priorizada del

producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los
objetivos balanceando el valor que le aportan respecto a su coste y quedan
repartidos en iteraciones (sprint backlog) y entregas. De manera regular el cliente
puede maximizar la utilidad de lo que se desarrolla y el retorno de
inversión mediante la replanificación de objetivos del producto, que realiza durante
la iteración con vista a las siguientes iteraciones.
 Roles principales en
proceso de desarrollo de software

Administrador de proyecto : El administrador de proyecto es la persona que administra

y controla los recursos asignados a un proyecto, con el propósito de que se cumplan
correctamente los planes.

Cliente es aquella persona responsable de llevar a cabo la evaluación del buen

desempeño del proyecto, debe estar presente en todas las fases del desarrollo del
producto, y realizar todas las actividades que se esperan de él, tales como la definición
de requisitos, aceptación provisional y final del producto, acompañamiento en pruebas
e implementación del software.
Analista: Estudia y analiza el problema a resolver y debe transformar los requisitos de
usuario en requisitos de software, y producir el documento de requisitos de software.
deben identificar las necesidades y objetivos del cliente, la información que será
suministrada al sistema, las funcionalidad del sistema y el rendimiento requerido,
además de determinar si los requisitos especificados son esenciales para su
funcionamiento, de acuerdo a lo anterior el rol de analista es muy importante, debido a
que el éxito del proyecto dependerá de una buena especificación de requisitos, para
ejecutar sus actividades el analista tiene diferentes metodologías de análisis.

Arquitecto/Diseñador: Es el encargado de generar el diseño del sistema. Entre sus

funciones está: Generar el diseño arquitectónico y diseño detallado del sistema,
basándose en los requisitos. ; Generar prototipos rápidos del sistema (con analistas y
programadores) para chequear los requisitos. ; Generar el documento de diseño
arquitectónico de software y mantenerlo actualizado durante el proyecto.

Los programadores deben convertir la especificación del sistema en código fuente

ejecutable utilizando uno o más lenguajes de programación, así como herramientas
de software de apoyo a la programación. El programador dentro de sus actividades
tiene diferentes metas y/o objetivo como lo es reducir la complejidad del software,
aumentar la eficiencia en el mantenimiento del software, reducir los tiempos de
desarrollo, disminuir el numero de errores encontrados durante el ciclo de vida del
proyecto.
Tésters deben utilizar tener habilidades que le permitan definir y ejecutar una
metodología que en forma sistemática, organizada y estructurada, les permita detectar
y establecer documentación con ideas funcionales e integrales para la corrección de los
errores y inconsistencias conceptuales y/o funcionales encontradas en el proceso de
desarrollo del sistema.

Analistas de Calidad (QA) deben tener las habilidades necesarias para descubrir
errores en funciones, lógica e implementación en cualquiera de las representaciones
del software; verificar que el software bajo revisión cumple con los requisitos,
asegurarse que el software ha sido representado de acuerdo al estándar en uso; hacer
el proyecto más manejable.
 Principales Artefactos/Documentos en
proceso de desarrollo de software
• Plan de Desarrollo del Software
Este documento provee una visión global del enfoque de desarrollo propuesto a ser seguido
a lo largo del proyecto.

• Plan de proyecto: Las suposiciones principales que puedan afectar el plan deberán ser
documentadas aquí. También el alcance, fases y restricciones y los responsables que formarán
parte del mismo.

• Visión
Este documento define la visión del producto desde la perspectiva del cliente, especificando
las necesidades y características del producto. Constituye una base de acuerdo en cuanto a los
requisitos del sistema. Determina la viabilidad del proyecto.

• Plan de gestión de riesgo. Documento para disminuir la posibilidad que un evento

perjudicial y previsible dañe el proyecto. En este se define el alcance propósito del proyecto
con sus planes de evitación, minimización de consecuencias, impacto y planes de contingencia

• Modelo de Casos de Uso

El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso
de ellas. Se representa mediante Diagramas de Casos de Uso.
• Especificaciones de Casos de Uso
Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste
con una simple descripción narrativa) se realiza una descripción detallada utilizando una
plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de
eventos, requisitos no-funcionales asociados. También, para casos de uso cuyo flujo de
eventos sea complejo podrá adjuntarse una representación gráfica mediante un Diagrama de
Actividad.

• Prototipos de Interfaces de Usuario

Se trata de prototipos que permiten al usuario hacerse una idea más o menos precisa de
las interfaces que proveerá el sistema y así, conseguir retroalimentación de su parte respecto
a los requisitos del sistema. Estos prototipos se realizarán como: dibujos a mano en papel,
dibujos con alguna herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese
orden de acuerdo al avance del proyecto.
• Documento de Arquitectura
Este modelo establece la realización de los casos de uso en clases y pasando desde una
representación en términos de análisis (sin incluir aspectos de implementación) hacia una de
diseño (incluyendo una orientación hacia el entorno de implementación), de acuerdo al avance
del proyecto. También describe la representación lógica de los datos persistentes, de acuerdo con
el enfoque para modelado relacional de datos. Incluye al Modelo Conceptual, Diagramas de
Clase, Diagrama de Secuencia, Diagrama de Base de Datos.

• Modelo de Implementación
Este modelo es una colección de componentes y los subsistemas que los contienen. Estos
componentes incluyen: ficheros ejecutables, ficheros de código fuente, y todo otro tipo de
ficheros necesarios para la implantación y despliegue del sistema.

• Modelo de Despliegue
Este modelo muestra el despliegue la configuración de tipos de nodos del sistema, en los
cuales se hará el despliegue de los componentes.

• Plan de pruebas : El Plan de pruebas describe la estrategia, recursos y planificación de las

pruebas. La estrategia de prueba incluye la definición del tipo de pruebas a realizar para cada
iteración y sus objetivos, el nivel de cobertura de prueba y el porcentaje de prueba que deberían
ejecutarse con un resultado específico.
• Material de Apoyo al Usuario Final
Corresponde a un conjunto de documentos y facilidades de uso del sistema, incluyendo: Guías
del Usuario, Guías de Operación, Guías de Mantenimiento y Sistema de Ayuda en Línea

• Producto
Los ficheros del producto empaquetados y almacenadas en un CD con los mecanismos
apropiados para facilitar su instalación. El producto, a partir de la primera iteración de la fase de
Construcción es desarrollado incremental e iterativamente, obteniéndose una nueva release al
final de cada iteración.

• Acta de aceptación de entregables: En este documento se registra la aceptación de cada

entregable del proyecto.