INTRODUCCION El proceso de Ingeniería de Software se basa en modelos,... como una guía para los ingenieros del software durante el...

INTRODUCCION
El proceso de Ingeniería de Software se basa en modelos, métodos y herramientas que sirven
como una guía para los ingenieros del software durante el proceso de desarrollo, con la
finalidad de mejorar la calidad de los proyectos, procesos y productos mediante la evolución y
medición de los mismos.
Para cualquier desarrollo de software de cualquier producto se realizan una serie de tareas
entre las ideas iníciales y el producto final. Un modelo de desarrollo de software establece el
orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y
salida par a cada una de las actividades.
Tanto el ciclo de vida como el modelo de desarrollo ambos se complementan para generar el
producto desde el punto de vista técnico y administrativo
Los Modelos de Desarrollo son:
 El Modelo de Cascada ó Modelo Lineal Secuencial.
 Prototipos
 El Modelo DRA

El Modelo de Espiral.

El Modelo de Procesos.
 Desarrollo incremental ó Concurrente
 El Modelo en V.

En Flor.
EL MODELO EN CASCADA
Llamado algunas veces «ciclo de vida básico», el modelo lineal secuencial sugiere un
enfoque5 sistemático, secuencial, para el desarrollo del software que comienza en un nivel de
sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento secuencial
para la ingeniería del software.
El modelo lineal secuencial comprende las siguientes actividades:
-
El ciclo de desarrollo de software.
Este modelo tiene una secuencia ordenada.
El trabajo de una etapa previa es la entrada del siguiente proceso.
Provee de un gran control sobre las fechas de entrega y entregables.
Establece criterios de entrada y salida en cada fase claramente definidos.
Dado que provee pocos puntos de visibilidad da la impresión de que es lento.
VENTAJAS
-
Excelente cuando se tiene un producto estable y se conoce la tecnología.
Es un método muy estructurado que funciona bien con gente de poca experiencia.
Provee estabilidad en los requerimientos.
La planeación se puede hacer anticipadamente.
Para proyectos grandes.
DESVENTAJAS
-
Tiene poca flexibilidad.
Los proyectos en la práctica raramente siguen un flujo secuencial.
Siempre es difícil para el cliente mostrar todos los requerimientos explícitamente y con
mucha anticipación.
El cliente debe tener paciencia.
Es inflexible y no motiva al cambio.
Poco apropiado para aplicaciones para la toma de decisiones.
Los usuarios tienen una participación limitada
MODELO DE CONTRUCCION DE PROTOTIPOS
Este modelo comienza con la recolección de requisitos, el desarrollador y el cliente definen los
objetivos globales para el software, originándose un diseño rápido que se centra en una
representación de esos aspectos del software que sean visibles para el usuario/cliente. De
este diseño surge la construcción de un prototipo y este es evaluado por el cliente/usuario. La
interacción ocurre cuando el prototipo satisface las necesidades del cliente.
Los pasos necesarios para la construcción de prototipos son los siguientes:
-
Evaluar la solicitud del software para determinar si el sistema es candidato para la
construcción de un prototipo. Considerando si es necesario presentar la interacción
usuario-sistema y tomando en cuenta la complejidad del desarrollo del propio prototipo.
-
Elaborar una representación abreviada de los requisitos. Utilizando alguno de los
modelos mencionados anteriormente.
-
Crear un conjunto de especificaciones de diseño para el prototipo. Centrándose en los
aspectos de mas alto nivel y no en el detalle.
-
Crear y probar el software del prototipo. De ser posible utilizar herramientas
automatizadas para tal efecto, como lenguajes de cuarta generación, módulos de
código
reusables, herramientas RAD o paquetes especializados en prototipos.
- Presentar el prototipo al usuario y orientarlo a que sea él quien lo “opere”. Aquí es
donde el usuario podrá validar sus propios requerimientos y sugerir las modificaciones
necesarias.
- Repetir los pasos IV y V hasta que todos los requisitos queden formalizados.
El modelo de construcción de prototipos se recomienda especialmente cuando los
requerimientos cambian frecuentemente, cuando no se tiene la suficiente participación del
usuario o cuando no se tienen suficientemente especificados los requerimientos. Una ventaja
importante es que el usuario va “viendo” la evolución del sistema.
El principal inconveniente es que se desconoce el tiempo que se tardará en crear un producto
aceptable. No se sabe cuantas iteraciones se tendrán que realizar. Otro inconveniente es que
se pueden adoptar prácticas de programación de prueba-y-error, sin un análisis y diseño
formales previos.
VENTAJAS
-
Versión opretiva casi desde el inicio
Alta integración del usuario con el proceso del desarrollo
Coste relativamente bajo para cada versión
Cambios de dirección en el desarrollo fáciles de realizar
DESVENTAJAS
-
El usuario no valora adecuadamente el trabajo
El sistema puede crecer desmedidamente
No aplica ingeniería
Se confunde el producto final con el prototipo
EL MODELO EN ESPIRAL
-
Los productos de software son creados a través de múltiples repeticiones del proceso
del ciclo de vida. Se rompen un mini-proyectos.
Estos modelos han sido aplicados al desarrollo de software.
Aun no han madurado al punto de ser aplicados como modelos de desarrollo con
tiempos y limitaciones de costos.
VENTAJAS
-
El producto avanza a pasos firmes solucionado riesgos en cada iteración.
El producto termina con todos los riesgos resueltos.
Se pueden incluir otros métodos de desarrollo en las iteraciones.
A medida que el costo aumenta, los riesgos se reducen.
Se tienen puntos de control en cada interacción.
DESVENTAJAS
-
Es complicado.
Requiere de mucha administración.
Difícil de definir los objetivos, metas que indiquen que podemos avanzar al siguiente
ciclo.
Se puede caer en un desarrollo de nunca acabar.
MODELO DE DESARROLLO INCREMENTAL
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una
forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos
para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre
incrementando subconjuntos de requerimientos del sistema. Típicamente, 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 específica de observar el desarrollo de algún 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 pequeño es siempre menos riesgoso que construir un sistema
grande.
Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los
requerimientos planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, sólo la última iteración 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 próximo incremento.
VENTAJAS
-
La solución se va mejorando en forma progresiva a través de las múltiples iteraciones.
Incrementa el entendimiento del problema y de la solución por medio de los
refinamientos sucesivos.
DESVENTAJAS
-
Requiere de mucha planeación, tanto administrativa como técnica.
Requiere de metas claras para conocer el estado del proyecto.
MODELO DRA (DESARROLLO RÁPIDO DE APLICACIONES)
Es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de
desarrollo extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” del
modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción
basada en componentes. Si se comprenden bien los requisitos y se limita el ámbito del
proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente
funcional” dentro de períodos cortos de tiempo. Cuando se utiliza principalmente para
aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:
modelado de gestión, de datos, del proceso, generación de aplicaciones, pruebas y entregas.
MODELO ESPIRAL
El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso
de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas
expresiones que son obtenidas transformando otras dadas son examinadas para ver si
representan progresos hacia el objetivo.
Este método está basado en dos importantes principios:
1. la práctica de diseño profesional es caracterizar en términos de conocer, actuar en
situaciones, conversación con la situación y reflexión en acción. Hay un distinto medio
de proceso - orientación en esta aproximación al diseño. Es raro que el diseñador
tenga el diseño en su cabeza por adelantado y que después meramente lo transcriba.
Gran parte del tiempo del diseñador está inmiscuido en una progresiva relación con su
entorno. Una buena metáfora para describirlo es "la conversación con el material",
como un escultor, quien está ocupado en una conversación con el medio. El escultor
modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser.
2. la necesidad para diseñadores de tomar la práctica de trabajo seriamente, de
supervisar las formas en las que el trabajo se está haciendo, en el sentido de una
solución abierta y desplegada para aumentar la complejidad de una situación que el
diseñador sólo entiende parcialmente. El hecho por el cual se está tratando con
"actores humanos". Los sistemas necesitan tratar o estar en contacto con las
preocupaciones del usuario. Es, definitiva, el reconocimiento de que el trabajo es
fundamentalmente social, envolviendo cooperación y comunicación.
MODELO EN ESPIRAL WIN & WIN
Una variante interesante del Modelo Espiral previamente visto es el "Modelo espiral Win-Win".
El Modelo Espiral previo sugiere la comunicación con el cliente para fijar los requisitos, en que
simplemente se pregunta al cliente qué necesita y él proporciona la información para
continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y
desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento,
calidad, etc.
"Es así que la obtención de requisitos requiere una negociación, 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 también gane
consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere
fuertes habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso
alrededor de la espiral; se definen las siguientes actividades:
1. Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
2. Determinación de "condiciones de victoria" de los directivos (saber qué necesitan y los
satisface)
3. Negociación de las condiciones "victoria" de los directivos para obtener condiciones
"Victoria & Victoria" (negociar para que ambos ganen).
(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por
la organización si tiene éxito o criticado si no.
El modelo Win&Win hace énfasis en la negociación inicial, también introduce 3 hitos en el
proceso llamados "puntos de fijación", que ayudan a establecer la completitud de un ciclo de la
espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del
software.
EL MODELO DE PROCESO CONCURRENTE
El modelo de proceso concurrente se puede representar en forma de esquema como una
serie de actividades técnicas importantes, tareas y estados asociados a ellas.
La figura siguiente proporciona una representación esquemática de una actividad dentro del
modelo de proceso concurrente. La actividad "análisis" se puede encontrar en uno de los
estados destacados anteriormente en cualquier momento dado. De forma similar otras
actividades se pueden representar de una forma análoga. Todas las actividades existen
concurrentemente, pero residen en estados diferentes. Por ejemplo: al principio del proyecto,
la actividad de comunicación con el cliente (no mostrada en la figura) ha finalizado su primera
interacción y existe en el estado de cambios en espera. La actividad de análisis (que existía
en el estado ninguno mientras que comenzaba la comunicación inicial con el cliente) ahora
hace una transición al estado bajo desarrollo. Sin embargo, si el cliente indica que se deben
hacer cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al estado
cambios en espera.
El modelo de proceso concurrente define una serie de acontecimientos que dispararan
transiciones de estado a estado para cada una de las actividades de la ingeniería del software.
Por ejemplo, durante las primeras etapas del diseño, no se contempla una inconsistencia del
modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que
disparara la actividad de análisis del estado hecho al estado cambios en espera.
EL MODELO EN V
Una reexaminación del modelo del ciclo de vida desde el punto de vista de aseguramiento de
calidad.
Cuando cada proceso termina su producto, las especificaciones de prueba para la probar los
procesos están también completas.
Entre las características del MODELO V tenemos que también es llamado como el modelo de
4 niveles:
-
-
-
El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto
constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y
especificaciones, se traduce en un documento de requisitos y especificaciones.
El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede
considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas
funciones que son directa o indirectamente visibles por el usuario final, se traduce en
un documento de análisis funcional.
El nivel 3 define los componentes hardware y software del sistema final, a cuyo
conjunto se denomina arquitectura del sistema.
El nivel 4 es la fase de implementación, en la que se desarrollan los elementos
unitarios o módulos del programa.
VENTAJAS
Entre las características del MODELO V tenemos que también es llamado como el modelo de
4 niveles: El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto
constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y
especificaciones, se traduce en un documento de requisitos y especificaciones. El nivel 2 se
dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema
como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o
indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.
El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se
denomina arquitectura del sistema. El nivel 4 es la fase de implementación, en la que se
desarrollan los elementos unitarios o módulos del programa.
DESVENTAJAS
-
-
El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de
aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber
terminado la implementación, lo que puede traer como consecuencia un “roll-back” de
todo un proceso que costó tiempo y dinero.
El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores,
cosa que en la realidad puede ocurrir.
Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de
desarrollo, lo que disminuye el riesgo.
A pesar de todo lo antes mencionado, definitivamente se trata de un modelo más robusto y
completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el
modelo de cascada.
MODELO EN FLOR
-
El propósito del desarrollo de software es el de desarrollar un producto de software.
Los equipos no deben de estar preocupados por el proceso de desarrollo mismo.
Deben de desarrollarse todas las etapas un poco al mismo tiempo hasta que el producto final
es alcanzado.
CONCLUSION
Finalmente se puede concluir acerca del tema, que los procesos de ingeniería de software
están basados en los procesos y métodos, a la definición, evaluación y medición de del
cliente. Existen modelos y procesos aplicados en las diferentes etapas del proceso de
software.
OBJETIVO GENERAL

Comprender los distintos proceso de desarrollo de software
OBJETIVOS ESPECIFICOS

Comprender los componentes que debe considerar un proceso de desarrollo de
software

Obtener un conocimiento básico y tecnológico sobre los distintos procesos de
software.

Desarrollar cada uno de los modelos y utilizar el más adecuado.
TRABAJO DE
:
Modelos de desarrollo de Software.
ASIGNATURA
:
Ingeniería de Software I
LICENCIADO
:
Marvin Antonio Romero
INTEGRANTES
:
Jaime Aurelio Manzanares
Walter Israel Benítez Campos
William Alcides Ayala Vásquez SMTS110510
FECHA DE ENTREGA:
26 de Agosto de 2010.