INSTITUTO TECNOLGICO SUPERIOR CIUDAD

SERDN
MATERIA:

ADMINISTRACIN DE LOS RECURSOS Y FUNCIN

INFORMTICA
DOCENTE:

MTRO. ADN CANICO HERNNDEZ

UNIDAD:

MODELOS DE DESARROLLO DE SOFTWARE

TRABAJO:

RESUMEN

ALUMNA:

JENNIFER GARCA ESTVEZ (16CS0034)

CARRERA:

INGENIERA INFORMTICA (HORARIO FLEXIBLE)

GRADO:

SEGUNDO SEMESTRE
CICLO ESCOLAR:

2016-2017

MODELOS DE PROCESO DE SOFTWARE

 MODELO DE CASCADA

Se define como una secuencia de actividades donde la estrategia principal es seguir el proceso
del desarrollo de SW hacia checkpoints o mediante entregas calendarizadas.

Creencias:

Las metas se logran mejor cuando se tiene puntos de revisin bien preestablecidos y
documentados.

Los documentos tcnicos son comprensibles para usuarios y administradores no tcnicos.

Cada detalle de los requisitos se conoce de antemano antes de desarrollar el SW, y los
detalles son estables durante el desarrollo.

Las pruebas y evaluaciones se realizan eficientemente al final del desarrollo.

MODELOS EVOLUTIVOS

Se adaptan ms fcilmente a los cambios introducidos a lo largo del desarrollo.

Iterativos:

En cada iteracin se obtienen versiones ms completas del SW.

MODELO INCREMENTAL
MODELO EN ESPIRAL
MODELO WINWIN

MODELO INCREMENTAL

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma
de reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para
niveles posteriores. El desarrollo incremental es el proceso de construccin siempre
incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de
requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo
incremental no demanda una forma especfica de observar el desarrollo de algn otro
incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de
desarrollo, como se muestra en la figura.

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

Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande.
 Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos
planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.

Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema)
decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante
el desarrollo.

Si un error importante es realizado, el incremento previo puede ser usado.

Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del
comienzo del prximo incremento.

En la figura se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener
finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades
genricas asociadas. Aqu se observa claramente cada ciclo cascada que es aplicado para la
obtencin de un incremento; estos ltimos se van integrando para obtener el producto final
completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la
figura 5 se muestra como secuencial puro.

Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en
paralelo o concurrentemente, as por ejemplo, en la figura, mientras se realiza el diseo detalle
del primer incremento ya se est realizando en anlisis del segundo.

MODELO EN ESPIRAL
Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza iterativa de la
construccin de prototipos, pero conservado aquellas propiedades del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe as:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo
que se emplea para conducir sistemas intensivos de ingeniera de software concurrente y a la
vez con muchos usuarios.
Caractersticas:

Un enfoque cclico para el crecimiento incremental del grado de definicin e implementacin

de un sistema, mientras que disminuye su grado de riesgo.

Un conjunto de puntos de fijacin para asegurar el compromiso del usuario con soluciones de
sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente
compatibles.
Funcionamiento del modelo espiral
En cada vuelta tomamos en cuenta:

Los Objetivos: Que necesidad debe

envolver el programa.
Alternativas: Los varios mtodos de
alcanzar los objetivos de manera exitosa, a
travs de diferentes puntos como son:
o Caractersticas: experiencia del personal,
exigencias a efectuar.
o Formas de gestin del programa.
o Riesgo tomado con cada alternativa.
Desarrollar y Verificar: Programar y
probar el programa.
Se planificaran los siguientes pasos y se
volver a empezar la espiral. La espiral tiene una forma de caracola y se dice que mantiene
dos dimensiones la radial y la angular:

o Angular=Avance del proyecto Software, dentro de un ciclo.

o Radial=Aumento del coste del proyecto, ya que con cada nueva iteracin se pasa ms
tiempo desarrollando.

Este sistema es muy utilizado en proyectos largos como pueden ser la creacin de un Sistema
Operativo. Y que necesitan constantes cambios.

Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los aspectos
fundamentales de su xito radica en que el equipo que lo aplique sea capaz de detectar y
catalogar correctamente dicho riesgo.

MODELO WINWIN

Una variante interesante del Modelo Espiral previamente visto es el "Modelo Espiral Win-Win"
(Barry Boehm). El Modelo Espiral previo (clsico) sugiere la comunicacin con el cliente para
fijar los requisitos, en que simplemente se pregunta al cliente qu necesita y l proporciona la
informacin para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente
cliente y desarrollador entran en una negociacin, se negocia coste frente a funcionalidad,
rendimiento, calidad, etc.

"Es as que la obtencin de requisitos requiere una negociacin, que tiene xito cuando ambas
partes ganan".

Las mejores negociaciones se fuerzan en obtener "Victoria & Victoria" (Win & Win), es decir que
el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador tambin gane
consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere
fuertes habilidades de negociacin.
El modelo Win-Win define un conjunto de actividades de negociacin al principio de cada paso
alrededor de la espiral; se definen las siguientes actividades:

1 - Identificacin del sistema o subsistemas clave de los directivos(*) (saber qu quieren).

2 - Determinacin de "condiciones de victoria" de los directivos (saber qu necesitan y
los satisface)
3 - Negociacin de las condiciones "victoria" de los directivos para obtener condiciones
"Victoria & Victoria" (negociar para que ambos ganen).

(*) Directivo: Cliente escogido con inters directo en el producto, que puede ser premiado por
la organizacin si tiene xito o criticado si no.

El modelo WinWin hace nfasis en la negociacin inicial, tambin introduce 3 hitos en el proceso
llamados "puntos de fijacin", que ayudan a establecer la completitud de un ciclo de la espiral,
y proporcionan hitos de decisin antes de continuar el proyecto de desarrollo del software.

MODELOS ESPECIALES
A continuacin se expondrn dos enfoques hbridos, especialmente diseados 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 repeticin 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 combinacin 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.

Modelo de desarrollo iterativo incremental.

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 ms importantes del sistema son entregadas primero, por lo cual se realizan
ms pruebas en estos mdulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas).
Cada incremento debe aumentar la funcionalidad.
Es difcil establecer las correspondencias de los requisitos contra los incrementos.
Es difcil detectar las unidades o servicios genricos para todo el sistema.

DESARROLLO EN ESPIRAL
El modelo de desarrollo en espiral es actualmente uno de los ms 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. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso
y del producto. Se realiza un diseo detallado del plan administrativo. Se identifican los
riesgos y se elaboran estrategias alternativas dependiendo de estos.
2. Evaluacin y reduccin de riesgos: Se realiza un anlisis 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 validacin: Se escoge el modelo de desarrollo despus de la evaluacin del
riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende
del riesgo identificado para esa fase.
4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del
proyecto.
Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo, esta es
una actividad importante en la administracin del proyecto.

El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se
determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las
alternativas. Se evalan los riesgos con actividades como anlisis detallado, simulacin,
prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

Modelo de desarrollo en Espiral

PROCESO UNIFICADO

Es una extensin al proceso objectory. Se basan principalmente en la especificacin de

requerimientos de un sistema mediante casos de uso. El proceso integra ciclos, fases, flujos de
trabajo, mitigacin de riesgo, control de calidad, administracin de proyecto y control de
configuracin.

Creencias:

Para construir un programa exitoso se deben conocer qu quieren y necesitan los

usuarios potenciales.
 El desarrollo de un producto comercial puede significar un gran esfuerzo durante meses,
e incluso aos.

MODELO DE PROCESO DE SOFTWARE IEEE

A travs de la historia de la ingeniera del software ha evolucionado un conjunto de conceptos

fundamentales de diseo de software, aunque el grado de inters en cada concepto ha variado
con los aos, han pasado la prueba de tiempo ofreciendo cada uno al ingeniero de software
fundamentos sobre el cual pueden aplicarse mtodos de diseo ms elaborados.

El diseo de software juega un papel importante en el desarrollo del software lo cual permite al
ingeniero de software producir varios modelos del sistema o producto de que se va a construir
el mismo que forma una especie de plan de la solucin de la aplicacin.

Estos modelos pueden evaluarse en relacin con su calidad y mejorarse antes de generar
cdigo, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El
diseo es el sitio en que se establece la calidad del software.
Diseo es definido como: el proceso de definicin de la arquitectura, componentes, interfaces
y otras caractersticas de un sistema o componente que resulta de este proceso [IEEE610.12-
90].

Se desarrolla y se centra su el diseo, con una existencia lgica, de instrucciones sobre un

soporte. Es un producto que no se gasta con el uso como otros y repararlo no significa
restaurarlo al estado original, sino corregir algn defecto de origen lo que significa que el
producto entregado posee defectos, que podrn ser solucionados en una etapa de
mantenimiento.

El diccionario IEEE estndar de ingeniera del software [IEEE, 1990] da la definicin de calidad
como el grado con el que un sistema, componente o proceso cumple con los requisitos
especificados y las necesidades o expectativas del cliente o usuario.
Pressman la define como concordancia del software con los requisitos explcitamente
establecidos, con los estndares de desarrollo expresamente fijados y con los requisitos
implcitos, no establecidos formalmente que desea el usuario.

La aplicacin de estndares de desarrollo y de normas para el software permitir lograr calidad

tcnica del mismo. La calidad del software se puede ver a nivel empresa como implantacin de
un sistema de calidad y a nivel de proyecto aplicando las tcnicas de evaluacin y control de
calidad del software a lo largo del ciclo de vida.

REFERENCIAS ELECTRNICAS
http://todounidad3fsi.blogspot.mx/
http://jenniferarriaga.blogspot.mx/2012/07/ventajas-y-desventajas-de-los-modelos-sw.html
https://prezi.com/p8leo9yntbas/proceso-unificado-de-desarrollo-de-software/
http://marytor-javisan-robley.blogspot.mx/2014/04/33-modelos-especiales.html
 REFERENCIAS BIBLIOGRAFICAS
Ian Somerville: Ingeniera de Software. Editorial Pearson Addison Wesley. Sptima Edicin.
Madrid, 2005.

S. Pressman, Roger: INGENIERA DEL SOFTWARE, UN ENFOQUE PRCTICO. Editorial

Mc-Graw Hill. Quinta Edicin. 2002.

Weitzenfeld, Alfredo: Ingeniera de Software, Orientada a Objetos con UML, Java e Internet.
Editorial Thomson.