Presentación 1

Descargar como pptx, pdf o txt
Descargar como pptx, pdf o txt
Está en la página 1de 25

Modelos de proceso

software
Codificar y corregir (Code-and-Fix)

Contiene dos pasos:


 Escribir código.
 Corregir problemas en el código.

Este modelo tiene tres problemas principales :


 Después de un número de correcciones, el código puede tener una muy mala
estructura, hace que los arreglos sean muy costosos.
 Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del
usuario, por lo que es rechazado o su reconstrucción es muy cara.
 El código es difícil de reparar por su pobre preparación para probar y modificar.
Modelo en cascada
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con
los usuarios del sistema.
2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se
establece la arquitectura total del sistema.
3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de
software.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en
conjunto. Se entrega el conjunto probado al cliente.
5. Operación y mantenimiento: El sistema es puesto en marcha y se realiza la corrección de
errores descubiertos. Se identifican nuevos requisitos.
Algunos problemas que se observan en el modelo de cascada son:

 Las iteraciones son costosas e implican rehacer trabajo debido a la producción y


aprobación de documentos.
 Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las
siguientes fases.
 Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean
ignorados o corregidos de una forma poco elegante.
 Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario
por el largo tiempo de entrega del producto.
 Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil
responder a cambios en los requisitos.
Desarrollo evolutivo
Existen dos tipos de desarrollo evolutivo:
 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los
requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que
se tiene más claras
 Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y
trabajar para mejorar la calidad de los requisitos.

Entre los puntos favorables de este modelo están:


 La especificación puede desarrollarse de forma creciente.
 Los usuarios y desarrolladores logran un mejor entendimiento del sistema.
 Es más efectivo que el modelo de cascada, ya que cumple con las necesidades
inmediatas del cliente.
Desde una perspectiva de ingeniería y administración se identifican los siguientes
problemas:
 Proceso no Visible: Si el sistema se necesita desarrollar rápido, no es efectivo producir
documentos que reflejen cada versión del sistema.
 Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales
para la estructura del software haciendo costoso el mantenimiento.
 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan
herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.
Desarrollo basado en reutilización
A continuación se describe cada fase:
1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el
sistema en cuestión.
2. Modificación de requisitos: Si no se puede realizar modificaciones en los requisitos, hay
que seguir buscando componentes más adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el
sistema.
4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran
los componentes y subsistemas.

Las ventajas de este modelo son:


 Disminuye el costo y esfuerzo de desarrollo.
 Reduce el tiempo de entrega.
 Disminuye los riesgos durante el desarrollo.
Desventajas de este modelo:
 Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software
no cumpla las expectativas del cliente.
 Las actualizaciones de los componentes adquiridos no están en manos de los
desarrolladores del sistema.

Procesos iterativos

A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el


soporte de las iteraciones:
 Desarrollo Incremental.
 Desarrollo en Espiral.
Desarrollo basado en
reutilización
Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4
fases ilustradas. A continuación se describe cada fase:

1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en
cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de
la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando
componentes más adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe
tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.
4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y
subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

 
Las ventajas de este modelo son:
· Disminuye el costo y esfuerzo de desarrollo.
· Reduce el tiempo de entrega.
· Disminuye los riesgos durante el desarrollo.

Desventajas de este modelo:


· Los “compromisos” en los requisitos son inevitables,
por lo cual puede que el software no cumpla las
expectativas del cliente.
· Las actualizaciones de los componentes adquiridos no
están en manos de los desarrolladores del sistema.
Procesos iterativos
A continuación se expondrán dos enfoques híbridos,
especialmente diseñados para el soporte de las
iteraciones:
· Desarrollo Incremental.
· Desarrollo en Espiral.

Desarrollo incremental
Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso
de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el
sistema. Es una combinación del Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta
tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del
conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar
por cascada, si es dudoso, evolutivo.
Entre las ventajas del modelo incremental se encuentran:

· Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el
primer incremento.
· Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.
· Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.
· Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos
módulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

· Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
· Cada incremento debe aumentar la funcionalidad.
· Es difícil establecer las correspondencias de los requisitos contra los incrementos.
· Es difícil detectar las unidades o servicios genéricos para todo el sistema.
Desarrollo en espiral
El modelo de desarrollo en espiral es actualmente uno de los más conocidos y fue propuesto por Boehm . El ciclo de
desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una
actividad a otra.
Cada ciclo de desarrollo se divide en cuatro fases:
1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza
un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas
dependiendo de estos.
2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden
desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los
riesgos.
3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se
utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.
4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.
Este modelo a diferencia de los otros toman en consideración explícitamente el riesgo, esta es una actividad
importante en la administración del proyecto.
¿CUAL ES EL MODELO DE
PROCESO MAS ADECUADO?
Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en
cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de
criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos
identificados, entre otros).

Desempeño si no se Permite cambio sobre la


Modelo de proceso / Criterio Produce software fiable Gestión de riesgos Visibilidad del progreso
predefinen requisitos marcha

Codificar y corregir Bajo Bajo Bajo Alto Medio

Desarrollo en cascada Bajo Alto Bajo Bajo Bajo

Desarrollo Evolutivo Alto Medio Medio Alto Alto

Desarrollo formal de sistemas Bajo Alto Bajo a Medio Bajo Bajo

Desarrollo basado en reutilización Medio Bajo a Alto Bajo a Medio Alto Alto

Desarrollo Incremental Bajo Alto Medio Medio Bajo

Desarrollo Espiral Alto Alto Alto Medio Medio


METODOLOGÍAS PARA DESARROLLO DE SOFTWARE

Definición

 Define como se divide un proyecto en fases y las tareas a realizar en cada una.
 Para cada una de las fases está especificado cuales son las entradas que reciben y las salidas que
producen.
 Tienen alguna forma de gestionar el proyecto.

Finalidad de una metodología

Atributos deseables en el producto final son:

1. Adecuación.
2. Mantenibilidad.
3. Usabilidad.
4. Fiabilidad.
5. Corrección.
6. Eficiencia.
METODOLOGÍAS

Si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en
actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos:
Metodologías Estructuradas y Metodologías Orientadas a Objetos.

Considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la


planificación y control del proyecto, en especificación precisa de requisitos y modelado,
reciben el apelativo de Metodologías Tradicionales.

Metodologías Ágiles, están mas orientadas a la generación de código con ciclos mas
cortos de desarrollo.
METODOLOGÍAS ESTRUCTURADAS

Técnica en la cual  la estructura de un programa tan solo emplea tres estructuras lógicas de control:
secuencia, selección e iteración. La programación estructurada se basa en el teorema del programa
estructurado demostrado por Böhm-Jacopini, el cual establece que cualquier programa con una entrada
y una salida exclusivamente es equivalente a un programa que contiene solamente las estructuras
lógicas mencionadas anteriormente.

lenguajes para la programación estructurada. Los más famosos son: Cobol, Fortran, C, Pascal, Modula 2, ALGOL
y Ada.

Ejemplos de metodologías estructuradas


MERISE (Francia)
MÉTRICA (España)
SSADM (Reino Unido).
Gane & Sarson.
Ward & Mellor.
Yourdon & DeMarco
Information Engineering.
METODOLOGÍAS ORIENTADAS A OBJETOS
 A fines de los 60 SIMULA, a fines de los 70 Smalltalk

Lenguajes de programación

 C++
 Java
 Visual Basic

METODOLOGIAS

 Diseño orientado a objetos de Grady Booch (OOD).


 Ingeniería de software orientado a objetos OOSE, (Ivar Jacobson).
 Object Modeling Technique OMT, (James Rumbaugh).
 Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process
(RUP), OPEN, MÉTRICA (que también soporta la notación estructurada).
METODOLOGÍAS TRADICIONALES (NO ÁGILES)

 Donde se realiza una intensa etapa de análisis y diseño antes de la construcción


del sistema.
 Todas las propuestas metodológicas antes indicadas pueden considerarse como
metodologías tradicionales.
 Aunque en el caso particular de RUP, por el especial énfasis que presenta en
cuanto a su adaptación a las condiciones del proyecto, podría considerarse Ágil.
METODOLOGÍAS ÁGILES
Tiene las siguientes características:

 Incremental

 Cooperativo

 Sencillo

 Adaptable

También podría gustarte