PROCESOS PRESCRIPTIVOS

INGENIERA DE SOFTWARE
INTEGRANTES: DARWIN U. CRUZ QUIONES
WALTER A. HERNANDEZ POOT
INGENIERIA EN SISTEMAS COMPUTACIONALES.
INSTITUTO TENOLOGICO SUPERIOR DE FELIPE C. PUERTO.
26 DE AGOSTO DE 2014
DOCENTE: PALOMA GONGORA SABIDO
GRADO Y GRUPO: 5B

1 26 de agosto de 2014

INDICE


INTRODUCCION.
2
CONTENIDO..
3
TABLA COMPARATIVA
3
REDACCION DE ARGUMENTOS
6
BIBLIOGRAFIA..
7























2 26 de agosto de 2014
INTRODUCCION


Cualquier organizacin de ingeniera de software debe describir un conjunto de actividades
dentro del marco de trabajo para el o los procesos que adopte para sus distintos proyectos.
Los procesos deben llenar cada actividad del marco de trabajo con un conjunto de acciones
de ingeniera. Y definir cada accin en cuanto a un conjunto de tareas que identifique el
trabajo y los productos de trabajo, que deben lograrse para alcanzar las metas de
desarrollo.
Despus la organizacin debe adoptar el modelo de procesos resultante y ajustarlo a la
naturaleza especfica de cada proyecto, personas y ambiente en donde se ejecutar el
trabajo.
Estos modelos son los modelos prescriptivos de proceso, los cuales definen un conjunto
distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que se
requieren para desarrollar software de alta calidad. Estos modelos de proceso no son
perfectos, pero proporcionan una gua til para el trabajo de la ingeniera del software.
El uso de modelos prescriptivos es de suma importancia ya que estos proporcionan
estabilidad, control y organizacin a una actividad que si no se controla puede volverse
catica.
En el siguiente trabajo analizaremos las caractersticas, ventajas y desventajas que poseen
dos distintos modelos prescriptivos, los cuales nos permitirn observar las diferencias que
posee cada modelo frente al otro en los distintos procesos establecidos para alcanzar las
metas de desarrollo de software.









3 26 de agosto de 2014
CONTENIDO

TABLA COMPARATIVA

PROCESO CARACTERISTICAS Y
PARTICULARIDADES
VENTAJAS DESVENTAJAS
MODELO EN
ESPIRAL
1. Modelo de proceso de
software evolutivo, que
conjuga la naturaleza de
construccin de prototipos
con los aspectos
controlados y sistemticos
del modelo en cascada.

2. Enfoque cclico, para el
crecimiento incremental
del grado de definicin e
implementacin de un
sistema, mientras
disminuye su grado de
riesgo.

3. Se adapta y aplica en el
ciclo de vida completo de
una aplicacin, desde el
desarrollo del concepto
hasta el mantenimiento de
la misma.

4. La diferencia principal,
entre el modelo espiral y
los dems es que contiene
una nueva etapa que es el
anlisis de riesgos, no
incluida anteriormente. El
riesgo es todo lo que
pueda salir mal en un
proyecto de desarrollo de
software.


5. Conjunto de puntos de
fijacin, para asegurar el
1. No requiere una
definicin completa, de los
requerimientos del software
a desarrollar para comenzar
su funcionalidad.

2. Es muy factible aprobar
los requisitos, en la
terminacin de un producto,
desde el final de la primera
iteracin.

3. Sufrir retrasos corre un
riesgo menor, porque se
comprueban los conflictos
presentados
tempranamente y existe la
forma de poder corregirlos a
tiempo.

4. Es posible tener en
cuenta mejoras y nuevos
requerimientos sin romper
con la metodologa, ya que
este ciclo de vida no es
rgido ni esttico.


1. La espiral puede ser un
problema, si la administracin
exige que el desarrollo tenga
un presupuesto fijo, cada vez
que se completa un circuito se
considera y revisa el costo del
proyecto.

2. Existe complicacin,
cuando se evala los riesgos.

3. Requiere experiencia en la
identificacin de riesgos.

4. Se requiere la participacin
continua por parte del
cliente.

5. Se pierde tiempo, al volver
producir inicialmente una
especificacin completa de los
requerimientos cuando se
modifica o mejora el
software.
6. Genera mucho tiempo en
el desarrollo del sistema
7. Modelo costoso.






4 26 de agosto de 2014
compromiso del usuario
con soluciones de sistema
que sean factibles y
mutuamente
satisfactorias.

6. Este modelo es el
indicado, para desarrollar
software con diferentes
versiones actualizadas
como se hace con los
programas modernos de
PC s.

DESARROLL
O BASADO
EN
COMPONEN
TES
1.-Componentes
independientes, que son
completamente
especificados por sus
interfaces. Debera haber
una clara separacin entre
la interfaz de los
componentes y su
implementacin para que
una implementacin de un
componente pueda
reemplazarse por otro sin
cambiar el sistema,

2.-Implementacin de
middleware, esto
proporciona soportes
software para la
integracin de
componentes. Para
conseguir que
componentes
independientes y
distribuidos trabajen
juntos, se necesita un
soporte middleware que
maneje las
comunicaciones de los
componentes.

3.-Reutilizacin del
software. Nos lleva a
alcanzar un mayor nivel de
reutilizacin de software.
1.-Simplifica las
pruebas. Permite que las
pruebas sean ejecutadas
probando cada uno de los
componentes antes de
probar el conjunto completo
de componentes
ensamblados.

2.-Simplifica el
mantenimiento del
sistema. Cuando existe un
dbil acoplamiento entre
componentes, el
desarrollador es libre de
actualizar y/o agregar
componentes segn sea
necesario, sin afectar otras
partes del sistema.

3.-Mayor calidad. Dado que
un componente puede ser
construido y luego
mejorado continuamente
por un experto u
organizacin, la calidad de
una aplicacin basada en
componentes mejorar con
el paso del tiempo.

4.-Ciclos de desarrollo ms
cortos. La adicin de una
pieza dada de funcionalidad
1.- Confiabilidad de los
componentes. Los
componentes son cajas
negras de unidades de
programas, y el cdigo de los
componentes puede no estar
disponible para los usuarios
de dichos componentes.

2.-Certificacin de
componentes. Estrechamente
relacionada con la
confiabilidad se halla la
cuestin de la certificacin. Se
ha propuesto que asesores
independientes deberan
certificar los componentes
para asegurar a los usuarios
que los componentes son
confiables. Sin embargo, no
est claro cmo se puede
hacer esto. Quin pagara
por la certificacin?, quin
sera responsable si el
componente no funciona de
acuerdo con la certificacin?.

3.-Prediccin de propiedades
emergentes. Todos los
sistemas tienen propiedades
emergentes, y el intentar
predecir y controlar estas
propiedades emergentes es
importante en el proceso de
desarrollo del sistema. Debido
a que los componentes son
opacos, predecir sus

5 26 de agosto de 2014
tomar das en lugar de
meses aos.
5.-Mejor ROI. Usando
correctamente esta
estrategia, el retorno sobre
la inversin puede ser ms
favorable que desarrollando
los componentes uno
mismo.

6.-Funcionalidad
mejorada. Para usar un
componente que contenga
una pieza de funcionalidad,
solo se necesita entender su
naturaleza, ms no sus
detalles internos. As, una
funcionalidad que sera
imprctica de implementar
en la empresa, se vuelve
ahora completamente
asequible.

propiedades emergentes es
particularmente difcil. Como
consecuencia, es posible
encontrarse con que, cuando
se integran componentes, el
sistema resultante tiene
propiedades no deseadas que
limitan el uso.

4.-Equilibrio de
requerimientos.
Normalmente se tiene que
encontrar un equilibrio entre
los requerimientos ideales y
los componentes disponibles
en el proceso de
especificacin y diseo del
sistema. Por el momento,
alcanzar este equilibrio es un
proceso intuitivo.
Necesitamos un mtodo de
anlisis de equilibrio
sistemtico y ms
estructurado para ayudar a
los diseadores a seleccionar
y configurar componentes.















6 26 de agosto de 2014
ARGUMENTACION

- Mtodo en espiral
La razn por la cual se escogi el modelo de espiral es debido a que es un modelo de
desarrollo de software el cual posee caractersticas que comparte con otros modelos como
lo que sea de carcter evolutivo y basado en iteraciones al igual que poseer una
caractersticas nicas como lo es que sea un proceso cclico y considere el anlisis de riesgos,
el cual es analizar todo lo que pudiera salir mal en el desarrollo del software.

Creemos que las caractersticas que posee este modelo en el desarrollo de software son
muy tiles, ya que al ser un proceso cclico y de iteraciones, nos permite repetir el ciclo del
proceso de desarrollo tantas veces como sea necesario hasta cumplir con las expectativas
planteadas en un principio, realizando as un software ms completo y que haya pasado por
varios prototipos de prueba hasta su producto final. Destacamos que este modelo se
considera como un enfoque realista para el desarrollo de software y de sistemas a gran
escala, esto dado a su robustez y la cantidad de iteraciones que se haga uso en el ciclo.

- Mtodo de desarrollo basado en componentes

La reutilizacin informal es independiente del proceso de desarrollo con el cual se trabaje.
Sin embargo, en los ltimos aos, ha surgido un enfoque de desarrollo de software CBSE
(Ingeniera del software basada en componentes), esta se basa principalmente en la
reutilizacin del cdigo, que ltimamente se est usando de forma frecuente.
Elegimos el modelo de desarrollo de software basado en componentes por la considerable
reutilizacin de software que se implementa, siendo esta su caracterstica ms importante.
Otros aspecto importantes son: la calidad del software al implementar este modelo, la
simplicidad al momento de ejecutar el proceso de pruebas, el proceso de mantenimiento,
la reduccin de gastos al implementar cdigo o componentes ya desarrollados y el tiempo
para concluir el proyecto resulta ms corto y por ende los gastos disminuyen de forma
considerable.






7 26 de agosto de 2014
BIBLIOGRAFIA


Roger S. Pressman (2007). Ingeniera del software, un enfoque prctico. (6.ed.). Mxico: McGraw-
Hill/Interamericana Editores S.A de C.V
Ian Sommerville (2002). Ingeniera de software. (6.ed.) Mxico: Editorial Pearson Educacin.
Ian Sommerville (2005). Ingeniera de software. (7.ed.) Mxico: Editorial Pearson Educacin.