Está en la página 1de 31

CONSTRUCCIÓN

DEL SOFTWARE
GESTION DE CONSTRUCCION, CONSTRUCCION EN
LOS MODELOS DE CICLO DE VIDA
Administración de la
construcción de Software
Administración de la
construcción de Software
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.1 Modelo Cascada

El modelo cascada es el que


Ha servido como base de
Construcción de los modelo recientes,
Y sirve como bloque de construcción
Para los demás modelos de construcción.

La visión del modelo cascada del desarrollo de


software es muy simple; dice que el desarrollo de
software puede ser a través de una secuencia simple de
Fases.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

El modelo de ciclo de vida


cascada, proporciona algunos
principios básicos:

 Planear un proyecto antes de establecer


un compromiso con el mismo.
 Definir el comportamiento externo
deseado del sistema antes de diseñar su
arquitectura interna.
 Documentar los resultados de cada
actividad.
 Diseñar un sistema antes de codificarlo.
 Evaluar un sistema después de
construirlo.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.2 Modelo De Desarrollo Incremental.


El desarrollo incremental es el proceso de construcción que consiste en incrementar
nuevas especificaciones de requerimientos al diseño del sistema original.
Típicamente, un documento de requerimientos es escrito al capturar todos los
requerimientos para el sistema completo. Sin embargo, este modelo permite agregar
nuevas funcionalidades interdependientes a las ya hechas.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.2 Modelo De Desarrollo Incremental.


El modelo de desarrollo incremental provee
algunos beneficios significativos
para los proyectos de desarrollo de software:

 Construir sistemas pequeños.


 Si un error importante es detectado, sólo el último
cambio realizado necesita ser descartado, es decir, la
versión anterior a los últimos cambios es la que puede ser
utilizada.
 Reducción del tiempo de desarrollo, lo cual evita la
redefinición del requerimiento.
 Los errores de desarrollo cometidos en un incremento o
cambio, pueden ser arreglados antes del comienzo del
próximo incremento.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.4 Modelo de Prototipado de Requerimientos.


El prototipado de requerimientos es la
creación de una implementación
parcial de un sistema, para el
propósito explícito de aprender sobre
los requerimientos del sistema
definidos por los usuarios.
Un prototipo es construido de una manera rápida tal como
sea posible. Esto es dado a los usuarios, clientes o
representantes de ellos, posibilitando que ellos experimenten
con el prototipo.
A diferencia del modelo evolutivo donde los requerimientos mejor
entendidos están incorporados, un prototipo generalmente se construye con
los requerimientos entendidos más pobremente.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.4 Modelo de Prototipado de Requerimientos.


Sin Embargo, el Modelo de Prototipado de Requerimientos también es funcional con el
Modelo de Desarrollo Evolutivo, de hecho, en combinación con este, alcanza su mayor
grado de funcionalidad
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.5 Modelo Espiral

Es un modelo del ciclo de meta-vida. En


este modelo, el esfuerzo de desarrollo
es repetitivo. Tan pronto como uno
completa un esfuerzo de desarrollo,
otro comienza.

El Modelo Espiral define los


siguientes objetivos:

 Determinar qué es lo que se quiere lograr.


 Determinar las rutas alternativas, analizar los
riesgos y resultados finales de cada una, y
seleccionar la mejor.
 Implementar la alternativa seleccionada en el paso 2.
 Establecer qué es lo que se logró y evaluar los resultados obtenidos.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.5 Modelo Espiral

Durante el primer viaje alrededor de la espiral, se


analiza la situación y se determina que los
mayores riesgos son la interfaz con el usuario.
Después de un cuidadoso análisis de las formas
alternativas de solucionar el problema, dichas
alternativas pueden ser:
• Construir un sistema y esperar lo mejor.
• Escribir una especificación de requerimientos.
• Construir un prototipo.
Después del despliegue, el cliente proveerá nuevamente de retroalimentación
que dirá si los requerimientos son correctos. El tercer viaje alrededor de la espiral
comienza.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.6 Modelo Evolutivo Concurrente

La contribución del modelo concurrente es su capacidad


de describir las múltiples actividades del software
ocurriendo simultáneamente.

Los requerimientos son usualmente "líneas base",


cuando la mayoría de estos comienzan a ser bien
entendidos, se dedica un esfuerzo considerable en el
tema de diseño. Una vez que comienza el diseño,
cambios a los requerimientos son comunes y frecuentes.
Construcción de Software
2.1 Modelos de Construcción Tradicionales

2.1.6 Modelo Evolutivo Concurrente

En algunos proyectos, las etapas de un producto se


pueden desarrollar concurrentemente.
No es inusual dar mantenimiento a la etapa 1 de un
producto, y al mismo tiempo dar mantenimiento a un
componente 2, mientras que se está haciendo
codificación al componente 3, mientras se realiza diseño
sobre una etapa 4, y especificación de requisitos sobre
un componente 5.
.
En todos estos casos, diversas actividades están
ocurriendo simultáneamente.
Eligiendo seguir un proyecto usando técnicas de
modelación concurrente, se posibilita el conocimiento
del estado verdadero en el que se encuentra el proyecto
Construcción de Software
2.2 Metodologías de Construcción
En la actualidad existen nuevas metodologías que permiten hacer un análisis y diseño
estructurado muy eficiente, entre las más importantes están las siguientes:.

 Metodología RUP.
 Metodología ASML.
 Metodología CASE.
 Metodología XP.
 Metodología MSF.

Cuando los proyectos que se van a desarrollar son de mayor complejidad, ahí si toma
sentido el basarnos en una de estas metodologías de desarrollo, y empezamos a buscar
cual sería la más apropiada para nuestro caso.

Al realizar el diseño del software de manera rígida, cuando el cliente en la etapa final solicita
un cambio, resulta muy difícil realizarlo, pues se alteran muchas cosas que no habíamos
previsto, y es justo éste, uno de los factores que ocasiona un atraso en el proyecto y por
tanto la incomodidad del desarrollador por no cumplir con el cambio solicitado y el malestar
por parte del cliente por no tomar en cuenta su pedido.
Construcción de Software
2.2.1 Metodología RUP (Rational Unified Process- Proceso Unificado
Racional)
La Metodología RUP, divide en 4 fases el desarrollo del software:
Inicio.- El Objetivo en esta etapa es determinar la visión del proyecto.
Elaboración.- El objetivo es determinar la arquitectura óptima.
Construcción.- Desarrollar la capacidad operacional inicial.
Transición.- El objetivo es llegar a obtener el release del proyecto.

La Metodología RUP aplica 2 Disciplinas:

1) Disciplina de Desarrollo.- Contiene las siguientes características:


 Ingeniería de Negocios: Entendiendo las necesidades del negocio.
 Requerimientos: Formalizar las necesidades del negocio.
 Diseño: Traslado de los requerimientos a una arquitectura de software.
 Implementación: Creando software que se ajuste a la arquitectura.
 Pruebas: Asegurándose que el comportamiento requerido es el correcto.
Construcción de Software
2.2.1 Metodología RUP (Rational Unified Process- Proceso Unificado
Racional)
2) Disciplina de Soporte.- Contiene las siguientes características:

 Administración del cambio: Guardando todas las versiones del proyecto.


 Administrando el proyecto: Administrando horarios y recursos.
 Ambiente: Administrando el ambiente de desarrollo.
 Distribución: Hacer todo lo necesario para la salida del proyecto.

Cada una de estas iteraciones se debe clasificar y


ordenar según su prioridad, y que cada una se
convierte luego en un entregable al cliente.

Los elementos del RUP son:


 Actividades.- Procesos que se llegan a determinar
en cada iteración.
 Trabajadores.- Personas o entes involucrados en
cada proceso.
 Artefactos.- Documento, un modelo, o un elemento
de modelo.
Construcción de Software
2.2.2 Metodología ASML (A System Modelling Language-Sistema de
Lenguaje Modelado)
ASML es una metodología que integra todas las ideas involucradas en el
análisis y diseño estructurado. Involucra las técnicas y herramientas de
modelado usadas en el Análisis y Diseño Estructurado Moderno.

Los objetivos fundamentales que busca la Metodología ASML son:

 Obtener una buena comprensión del problema.


 Diseñar una solución de buena calidad.

La Metodología ASML separa el diseño de un sistema en una jerarquía de


modelos necesarios para comprender diferentes propiedades del mismo.
Construcción de Software
2.2.2 Metodología ASML (A System Modelling Language-Sistema de
Lenguaje Modelado)
Dicha jerarquía de modelos se presenta en la siguiente figura:

Como podemos observar,


el Modelo del Sistema
está dividido en dos
modelos generales:

 El Modelo Esencial.
 El Modelo de Implementación.
Construcción de Software
2.2.2 Metodología ASML (A System Modelling Language-Sistema de
Lenguaje Modelado)
Dicha jerarquía de modelos se presenta en la siguiente figura:

Como podemos observar,


el Modelo del Sistema
está dividido en dos
modelos generales:

 El Modelo Esencial.
 El Modelo de Implementación.
Construcción de Software
2.2.2 Metodología ASML (A System Modelling Language-Sistema de
Lenguaje Modelado)

 El Modelo Esencial.

Dos Componentes conforman el Modelo Esencial:

 Ambiente: Declaración de los objetivos. Creación de un Diagrama de


Contexto y de una Lista de Eventos, describe las pruebas hechas a
un sistema y los resultados obtenidos. Definición del Diccionario de
Datos inicial.

 Comportamiento: Creación de un DFD (Diagrama de Flujo de


Datos), y un DER (Diseño Entidad-Relación) por cada uno de los
eventos de la Lista de Eventos. Los DFDs por eventos se unen en un
único DFD (el Modelo Funcional) y los DERs por eventos se unen en
un único DER (el Modelo de Datos).
Construcción de Software
2.2.2 Metodología ASML (A System Modelling Language-Sistema de
Lenguaje Modelado)

 El Modelo de Implementación.
Se debe considerar ahora, las imperfecciones de la tecnología y determinar
los siguientes aspectos:
• La cantidad de procesadores necesarios.
• Las cualidades de estos procesadores.
• El tamaño de disco necesario de acuerdo al volumen de la información.
Luego se diseña la solución sobre la base de esas restricciones tecnológicas.
Construcción de Software
2.2.3 Metodología CASE

CASE plantea una secuencia de etapas


más detallada, y además proporciona
para cada etapa su descripción, definición
de objetivos y metas, productos de la
etapa, factores críticos de éxito, y la lista
de tareas que conviene realizar.

Además es posible auxiliarse de


herramientas CASE que facilitan
grandemente la puesta en práctica del
método.

CASE se basa en un análisis y desarrollo


del tipo descendiente en que el ciclo
de vida se compone de las etapas que
observamos en la siguiente Figura:
Construcción de Software
2.2.3 Metodología CASE

1) Estrategia.-
Tiene por objetivo lograr un entendimiento claro
de las necesidades de la organización y del
ambiente en que operará el sistema o sistemas
a implantar.

2) Análisis.-
La etapa de análisis toma y verifica los
descubrimientos de la etapa de estrategia y
expande estos en suficiente detalle para
asegurar la precisión de los modelos de la
empresa, posibilitando un fundamento sólido
para el diseño, dentro del alcance de la
organización y tomando en cuenta sistemas
existentes.
Construcción de Software
2.2.3 Metodología CASE

5) Producción.-
Aquí se asegura que el sistema funcione
correctamente en la mayoría de los
casos, y con intervención mínima de los
administradores del sistema.

Para esto se realizan nuevas pruebas, se


evalúan los resultados y se hacen refinamientos
del sistema, los cambios necesarios deberán
ser introducidos sin afectar a los usuarios, y
deberá conseguirse la máxima confianza de los
usuarios.

El resultado de esta etapa un sistema listo para


su operación.
Construcción de Software
2.2.3 Metodología XP (Extreme Programing).
5) Producción.-
Es una de las metodologías de Construcción de desarrollo de software más
exitosas en la actualidad utilizados para proyectos de corto plazo, corto equipo
y cuyo plazo de entrega era ayer.

Consiste en una programación rápida o extrema, cuya particularidad es tener


como parte del equipo, al usuario final, pues es uno de los requisitos para
llegar al éxito del proyecto.

Etapas de la
Metodología XP
Construcción de Software
2.2.3 Metodología XP (Extreme Programing).
Características XP

 Pruebas Unitarias: se basa en las pruebas realizadas a los principales


procesos, adelantándonos en algo hacia el futuro, podamos hacer
pruebas de las fallas que pudieran ocurrir.

 Refabricación: se basa en la reusabilidad de código, para lo cual se


crean patrones o modelos estándares, siendo más flexible al cambio.

 Programación en pares: una particularidad de esta metodología es


que propone la programación en pares, la cual consiste en que dos
desarrolladores participen en un proyecto en una misma estación de
trabajo.

Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento.
Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.
Construcción de Software
2.2.3 Metodología XP (Extreme Programing).
Características XP

 Pruebas Unitarias: se basa en las pruebas realizadas a los principales


procesos, adelantándonos en algo hacia el futuro, podamos hacer
pruebas de las fallas que pudieran ocurrir.

 Refabricación: se basa en la reusabilidad de código, para lo cual se


crean patrones o modelos estándares, siendo más flexible al cambio.

 Programación en pares: una particularidad de esta metodología es


que propone la programación en pares, la cual consiste en que dos
desarrolladores participen en un proyecto en una misma estación de
trabajo.

Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento.
Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.
Construcción de Software
2.2.3 Metodología XP (Extreme Programing).
¿Qué es lo que propone XP? Derechos del Cliente
• Empieza en pequeño y añade funcionalidad con • Decidir que se implementa .
retroalimentación continua. • Saber el estado real y el progreso del
• El manejo del cambio se convierte en parte proyecto.
sustantiva del proceso. • Añadir, cambiar o quitar requerimientos
• El costo del cambio no depende de la fase o etapa. en cualquier momento.
• No introduce funcionalidades antes que sean • Obtener lo máximo de cada semana de
necesarias. trabajo.
• El cliente o el usuario se convierte en miembro del • Obtener un sistema funcionando cada 3
equipo o 4 meses.
Derechos del Desarrollador
• Lo fundamental en este tipo de metodología
• Decidir cómo se implementan los procesos. es:
• Crear el sistema con la mejor calidad posible. • La comunicación, entre los usuarios y los
• Pedir al cliente en cualquier momento desarrolladores .
aclaraciones de los requerimientos. • La simplicidad, al desarrollar y codificar los
• Estimar el esfuerzo para implementar el sistema. módulos del sistema.
• Cambiar los requerimientos en base a nuevos • La retroalimentación, concreta y frecuente del
descubrimientos. equipo de desarrollo, el cliente y los usuarios
finales

La metodología XP se recomienda para proyectos de corto plazo


Construcción de Software
2.2.4 Metodología MSF (Microsoft Solution Framework).

Metodología flexible relacionada con una serie de conceptos y prácticas de uso,


que controlan la planificación, el desarrollo y la gestión de proyectos
tecnológicos. Se centra en los modelos de proceso y de equipo dejando en un
segundo plano las elecciones tecnológicas.
Construcción de Software
2.2.4 Metodología MSF (Microsoft Solution Framework).

MSF tiene las siguientes características:

 Adaptable: es parecido a un compás, usado en cualquier parte como


un mapa, del cual su uso es limitado a un específico lugar.

 Escalable: puede organizar equipos tan pequeños entre 3 o 4


personas, así como también, proyectos que requieren 50 personas a
más.

 Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

 Tecnología Agnóstica: porque puede ser usada para desarrollar


soluciones basadas sobre cualquier tecnología.
Construcción de Software
2.2.4 Metodología MSF (Microsoft Solution Framework).

MSF se compone de varios modelos encargados de planificar las diferentes partes


implicadas en el desarrollo de un proyecto:

 Modelo de Arquitectura del Proyecto.-  Modelo de Gestión del Riesgo.- Proporciona un


Define las pautas para construir proyectos entorno estructurado para la toma de decisiones y
empresariales a través del lanzamiento de acciones valorando los riesgos provocados.
versiones.
 Modelo de Diseño del Proceso.- Proporciona un
 Modelo de Equipo.- Proporciona una modelo centrado en el usuario para obtener diseño
estructura flexible para organizar los equipos eficiente y flexible a través de iteraciones.
de un proyecto.
 Modelo de Aplicación.- Proporciona un modelo
 Modelo de Proceso.- Proporciona pautas a para diseñar y desarrollar aplicaciones software.
seguir en el ciclo de vida del proyecto, Los servicios utilizados en este modelo son
describiendo fases, actividades, liberación de escalables, y pueden ser usados en una varias
versiones y explicando su relación con el computadoras.
Modelo de equipo.

La metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología.

También podría gustarte