Embed Size (px)
Citation preview
ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ
MANUEL FÉLIX LÓPEZ
CARRERA INFORMÁTICA
SEMESTRE SÉPTIMO PERIODO ABR. /SEP.-2015
INGENIERÍA DEL SOFTWARE
TEMA:
RESUMEN#3: MODELOS DEL PROCESO - CONTINUACIÓN
AUTORA:
DAYANA H. BAILÓN DELGADO
FACILITADORA:
ING. HIRAIDA SANTANA
CALCETA, MAYO 2015
CAPÍTULO I. INTRODUCCIÓN
Los equipos de desarrollo de software requieren de una metodología a seguir
para alcanzar control y constancia en sus proyectos. Se han creado modelos con
distintas fases que se adaptan a las especificaciones de los requerimientos de
cada sistema, dependiendo del tipo, naturaleza y tiempo de desarrollo, y a las
necesidades individuales y colectivas de los miembros del grupo de trabajo.
En el resumen anterior se expuso la importancia de los modelos de proceso y el
modelo más antiguo: el modelo de la cascada. En el presente informe se explican
los modelos faltantes: incremental, evolutivos: de hacer prototipos y espiral,
concurrentes, de proceso especializado: basado en componentes, de métodos
formales y desarrollo del software orientado a aspectos. Además se presenta el
proceso unificado y sus fases y los modelos de proceso personal (PPS) y del
equipo (PES).
1.1. OBJETIVOS
Determinar el modelo de proceso incremental.
Definir los modelos de proceso evolutivo: hacer prototipos y espiral.
Establecer los modelos concurrentes y de proceso especializado.
Determinar el proceso unificado.
Especificar los modelos del proceso personal y del equipo.
CAPÍTULO II. MARCO TEÓRICO
2.1. MODELO DE PROCESO INCREMENTAL
En las situaciones en las que a pesar de que los requerimientos iniciales están
bien definidos no se puede concretar con el producto final porque el esfuerzo de
desarrollo impide un proceso lineal o simplemente se requiere entregar un
avance funcional que será terminado después. Se elige el proceso destinado a
elaborar software en incrementos.
Este modelo combina los elementos del modelo explicado en el resumen anterior
aplicado en forma iterativa. Se sigue cada fase de forma secuencial hasta
terminar con un sistema funcional o primer incremento que no contiene todas las
características determinadas por el cliente. Porque en el segundo, tercer, cuarto
o incrementos necesarios se irán implementando las demás funcionalidades
hasta alcanzar el producto final.
El primer incremento debe ser el producto fundamental, es decir, debe contener
las funcionalidades básicas sin muchas características suplementarias
(conocidas o desconocidas). Este incremento servirá para que tanto el cliente
como el desarrollador lo evalúen con la finalidad de determinar los
requerimientos del siguiente incremento.
Fig. 2.1. Modelo de proceso incremental.
2.2. MODELO DE PROCESO EVOLUTIVO
Es un proceso iterativo muy utilizado porque los sistemas complejos evolucionan
con el tiempo. Por lo general las necesidades o requerimientos del negocio o
proyecto cambian con el transcurso del tiempo y del desarrollo, por ello no es
recomendable trazar una trayectoria reclínela hacia el producto final; los cortos
periodos de tiempo hacen que no sea posible desarrollar un producto perfecto,
pero es necesario presentar una versión funcional que alivie la presión de la
competencia o del negocio. Esta versión se compone por los requerimientos
funcionales del producto básico sin definir los detalles del sistema. En estos
casos se aplica el proceso que se adapta a las evoluciones del tiempo.
Los modelos más comunes son:
2.2.2. HACER PROTOTIPOS
Cuando el cliente define objetivos generales pero no conoce todos los
requerimientos específicos, los desarrolladores no están seguros de algún
algoritmo, sistema operativo a adaptar o forma de iteración entre la máquina y el
ser humano. Se puede aplicar el modelo de hacer prototipos.
Se puede utilizar como un modelo de proceso independiente o como una técnica
susceptible de implementarse dentro de otros modelos. Ayuda al ingeniero de
sistemas y al cliente a entender de mejor manera cual será el resultado de la
construcción cuando los requisitos estén satisfechos.
Hacer prototipos
El modelo espiral
Fig. 4.2. Modelos evolutivos.
El paradigma de hacer prototipos inicia en la comunicación. Se definen los
requerimientos imprescindibles para planificar una rápida iteración. Luego se
lleva a cabo el modelado en un “diseño rápido”. Lo cual lleva a la construcción
de un prototipo el cual se entrega y evalúa por parte de los participantes.
Luego de ser presentado el primer prototipo es casi imposible que este sea el
sistema final. Por lo general es muy lento, grande y/o difícil de utilizar. Por lo cual
algunos autores recomiendan desecharlos. Pero lo más útil es utilizarlo como la
fase inicial y amoldable de lo que después se convertirá en el producto final.
Los principales inconvenientes que se presentan al aplicar este modelo son:
El cliente no entiende la diferencia entre un prototipo y el sistema final.
El desarrollador puede adaptarse al lenguaje con el que elaboró el primer
prototipo, y tal vez este lenguaje no sea el más adecuado.
El desarrollador puede implementar un algoritmo ineficiente en el prototipo
y no cambiarlo para el sistema final.
La calidad del software se reduce.
A pesar de estos inconvenientes, hacer prototipos es un paradigma eficaz para
la ingeniería de software. Lo primordial es que desde el inicio todos los
participantes estén de acuerdo con aplicar este modelo y que comprendan cada
fase. Luego de lograr concretar los requerimientos básicos y fundamentales, los
desarrolladores deben basarse en la calidad del producto.
Plan rápido
Modelado Diseño rápido
Construcción del prototipo
Despliegue Entrega y
Retroalimentación
Comunicación
Fig. 2.3. Modelo basado en prototipos.
2.2.3. MODELO ESPIRAL
El modelo espiral conjuga la naturaleza iterativa de la construcción de prototipos
con los aspectos controlados y sistemáticos del modelo cascada. Proporciona el
material para el desarrollo rápido de versiones incrementales del software. A
diferencia de los modelos explicados anteriormente, este paradigma permite dar
mantenimiento al software durante toda su vida útil; desde el desarrollo hasta su
finalización o retiro del mundo real.
Permite aplicar cambios que se conocen en el transcurso del tiempo y desarrollo,
brindando un enfoque realista para el desarrollo de software y sistemas a gran
escala. Es importante recordar que se considera el riesgo en cada revolución y
se revisan los respectivos costos.
Las desventajas que presenta son:
Dificultad para convencer a los clientes de que el enfoque evolutivo se
puede controlar.
Personal con habilidad considerable para evaluar riesgos.
Es necesario conocer los riesgos más importantes, en el momento
adecuado porque de no ser así esto causaría serios problemas.
Fig. 2.4. Modelo espiral.
2.3. MODELOS CONCURRENTES.
Se representa en forma esquemática como una serie de actividades del marco
de trabajo, acciones y tareas de la ingeniería del software y sus estados
asociados. Es más apropiado para proyectos donde están implicados diferentes
equipos de ingeniería.
Todas las actividades existen de forma concurrente, pero se encuentra en
diferentes estados. Proporciona una visión exacta del estado actual del proyecto.
Los eventos generados en un punto de la red del proceso disparan transiciones
entre los estados.
Cambios en espera: cuando una actividad ya fue culminada pero está
pendiente de cambios en otras acciones que puedan afectar su progreso.
Ninguno/Inactivo: una fase se encuentra en espera de poder ser
ejecutada.
En desarrollo: una actividad está siendo realizada.
En revisión: cuando una tarea está siendo evaluada.
Fig. 2.5. Actividades del modelo concurrente.
En modificación: cuando una tarea que ya fue concluida está siendo
modificada.
Realizado: cuando una fase ha sido culminada.
2.4. MODELOS DE PROCESO ESPECIALIZADO
Se aplican cuando se ha elegido un enfoque de ingeniería del software definido
de una manera muy estrecha, es decir muy específicamente.
A continuación se detallan tres modelos de proceso especializado.
2.4.1. DESARROLLO BASADO EN COMPONENTES.
Incorpora muchas características del modelo espiral. Destaca la reutilización y
ensambladura de componentes, lo cual es una ventaja para los desarrolladores
porque pueden hacer uso de lo que ya está creado.
Se puede emplear cuando el software está en construcción. Proporciona
funcionalidad dirigida con interfaces bien definidas que permiten su integración
en el software.
Los pasos que se siguen para aplicar este paradigma son:
Investigar productos basados en componentes y evaluarlos.
Integaración de componentes.
Diseñar arquitectura del software.
Integrar los componentes a la arquitectura.
Aplicar pruebas para asegurar funcionalidad.
Fig. 2.6. Pasos del modelo basado en componentes.
2.4.2. MODELO DE MÉTODOS FORMALES.
Define un conjunto de actividades basadas en una especificación matemática.
Se verifica mediante notación matemática rigurosa. La variante de este enfoque
se denomina “ingeniería de software de quirófano”.
A través de un análisis matemático se descubre y corrige lo ambiguo, incompleto
e inconsistente del sistema. Los cuales son imposibles de detectar con otros
métodos.
No es el más seleccionado por los desarrolladores a pesar de sus claras
promesas, porque presenta los siguientes inconvenientes:
Es muy caro y consume mucho tiempo.
Se requiere una capacitación detallada al personal.
Dificulta la comunicación con los clientes.
A pesar de estas preocupaciones es aplicado por un amplio grupo de
desarrolladores que conocen la importancia de la calidad en seguridad.
2.4.3. DESARROLLO DEL SOFTWARE ORIENTADO A ASPECTOS.
También conocida como Programación Orientada a Aspectos (POA). Incluye los
intereses generales que cubren la arquitectura total del sistema. Proporciona un
proceso y enfoque metodológico para definir, especificar y construir aspectos.
Es decir, se desarrolla el software a partir de ciertos aspectos ya sean de
seguridad, interfaz de usuario, distribución, almacenamiento, transaccionales,
entre otros.
2.5. EL PROCESO UNIFICADO.
Es un ciclo de vida incremental e iterativo propuesto por los creadores de UML
(Unified Modeling Language). Especializado por los casos de uso y centrado en
la arquitectura.
Es un intento por obtener los mejores rasgos y características de los modelos
tradicionales del proceso de software, y que también implemente muchos de los
mejores principios de desarrollo ágil. Reconoce la importancia de la
comunicación con el cliente.
2.5.1. FASES DEL PROCESO UNIFICADO.
Un flujo de trabajo identifica las tareas primordiales para completar cada acción
importante y los productos que se alcanzan con la finalización exitosa de cada
una de éstas. Cada equipo adapta los procesos que cumplan sus necesidades.
Fase inicio
Abarca la comunicación con el cliente y actividades de planeación.
Destaca el desarrollo y el refinamiento de casos de uso como un modelo primario
Fase de elaboración
Comunicación con el cliente y modelado
con un enfoque en la creación de modelos de análisis y diseño con énfasis en las definiciones de clase y representaciones arquitectónicas.
Fase de construcción
Refina y después traduce el modelo de diseño
en componentes de software implementados.
Fase de transición
transfiere el software del desarrollador al usuio final
aplica pruebas beta y obtiene aceptación
Fase de producción
Monitoreo contínuo y soporte
Fig. 2.7. Fases del proceso unificado.
Fig. 2.8. Explicación de las fases del proceso unificado.
2.6. MODELOS DEL PROCESO PERSONAL Y DEL EQUIPO.
Es necesario adaptar un proceso que cubra las necesidades de los
requerimientos del software y que a su vez se adapte lo más posible a las
necesidades de los miembros del equipo, de forma individual y colectiva. Para
ello se han creado modelos de proceso personal de software y del equipo.
2.6.1. PROCESO PERSONAL DEL SOFTWARE (PPS)
Algunos desarrolladores siguen algún tipo de proceso, este proceso puede o no
funcionar. Pero para que un individuo logre cambiar un proceso personal
ineficaz, debe pasar por cierto proceso. El modelo PPS define cinco actividades
estructurales:
2.6.2. PROCESO DEL EQUIPO DE SOFTWARE (PES)
Se extendió la metodología de PPS para ser aplicada a un equipo de trabajo que
logre autonomía para alcanzar un producto final de calidad. Los objetivos son:
Pla
nea
ció
n Aisla los requerimientos
Desarrolla las estimaciones de los recursos y defectos.
Se identifican las tareas de desarrollo y se crea un programa para el proyecto.
Dis
eño
de
alto
niv
el Se desarrollan las especificaciones externes.
Se elaboran prototipos
Rev
isió
n d
iseñ
o a
.n. Se aplican
métodos de verificación formal.
Des
arro
llo
Se mejora y revisa el diseño del componente.
El código se genera, revisa, compila y prueba.
Post
mó
rtem
Se determina la eficacia del proceso por medio de medidas y mediciones obtenidas.
Fig. 2.9. Actividades estructurales.
Formar equipos autodirigidos.
Mostrar a los gerentes como motivar y dirigir a sus equipos.
Acelerar la mejora del proceso del software.
Brindar a las organizaciones muy maduras una gía para la mejora.
Facilitar la enseñanza universitara de aptitudes de equipo con grado industrial
Fig. 2.10. Objetivos del PES.
CAPÍTULO III. CONCLUSIONES
Al existir diferentes modelos de proceso, los integrantes de un equipo de trabajo
deben analizar cada uno de éstos, sus ventajas, desventajas y posibles riesgos
al ser aplicados. Luego, es necesario escoger el que más se acople al tipo de
sistema a desarrollar.
En la práctica las cosas no suelen ocurrir como la teoría lo demanda. Es decir,
aunque los programadores, diseñadores, analistas y clientes no siguen de forma
exacta las fases y actividades de los modelos de procesos, por la complejidad
en tiempo y espacio del mundo real, éstos son utilizados como guías con el fin
de obtener control y constancia en sus proyectos.
Es importante recordar la comunicación con el cliente donde se expone el
modelo a utilizar en el desarrollo del software para evitar futuros inconvenientes
o malos entendidos.
El modelo en espiral es el que más se acopla a las demandas de los usuarios, a
los cambios que pueden ocurrir con el pasar del tiempo en el sistema y a las
necesidades de los desarrolladores. Permitiendo además dar un mantenimiento
constante al sistema.
BIBLIOGRAFÍA
Peña, A. 2006. Ingeniería de Software: Una Guía para Crear Sistemas de Información. México. (En línea). Consultado, 16 de abr. 2015. Formato PDF. Disponible en http://www.wolnm.org/apa/articulos/ingenieria_software.pdf
Pressma, R. 2010. Ingeniería de Software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805.
Sonmerville, I. 2005. Ingeniería del software. 7 ed. España. Pearson. p 712.
