EL MODELO DE PROCESO DE

SOFTWARE
METODOLOGIAS EMERGENTES

Ciclo de Vida de desarrollo de sistemas (SDLC)

El SDLC es una metodologa en fases para

el anlisis y diseo, de acuerdo con la cual
los sistemas se desarrollan mejor al utilizar
un ciclo especfico de actividades del
analista y los usuarios.

FASES CICLO DE VIDA

Identificacin de los problemas,
oportunidades y objetivos
Determinacin de los requerimientos de
informacin del factor humano
Anlisis de las necesidades del sistema
Diseo del sistema recomendado
Desarrollo y documentacin del software
Prueba y mantenimiento del sistema
Implementacin y evaluacin del sistema

METODOLOGIA AGIL

Es una metodologa de desarrollo de

software que se basa en valores, principios
y prcticas bsicas. Los cuatro valores son
comunicacin, simpleza, retroalimentacin
y valenta.

FASES AGIL

Exploracin. Se explora el entorno para evaluar

su conviccin de que puede y debe lidiar con el
problema mediante el desarrollo gil, formara el
equipo y evaluara las habilidades de los
integrantes. Puede requerir desde unas semanas
hasta unos cuantos meses. Tambin se examina
las tecnologas potenciales necesarias para crear
el sistema. Durante esta etapa se debe practicar
con la estimacin del tiempo necesario para
realizar las tareas. Tambin se experimenta
escribiendo las historias de los usuarios.

Planeacin. En esta etapa el analista y los

clientes se ponen de acuerdo en una fecha,
que puede ser a partir de dos a seis meses
para entregar soluciones a sus problemas
empresariales. Esta etapa dura algunos
das. Si las actividades de exploracin
fueron suficientes, esta etapa debe ser muy
corta.

La estrategia que persigue el equipo de

desarrollo gil siempre tiene una incertidumbre
limitante. El equipo disea la solucin ms
simple posible, pone el sistema en produccin
tan pronto como sea posible, obtiene
retroalimentacin del cliente empresarial sobre
lo que est funcionando y adapta su diseo a
partir de ah. Los clientes deciden que debe
abordar primero el equipo de desarrollo sus
decisiones establecern prioridades y revisaran
la funcionalidad durante todo el proceso.

Iteraciones para la liberacin de la

primera versin. Esta etapa est
compuesta por las iteraciones (ciclos de
prueba, retroalimentacin y modificacin)
para la liberacin de la primera versin. Estas
iteraciones duran aproximadamente tres
semanas, donde se bosqueja toda la
arquitectura del sistema. Uno de los objetivos
es realizar pruebas funcionales escritas por el
cliente al final, de cada iteracin.

Puesta en produccin. Durante esta fase

el ciclo de retroalimentacin se agiliza de
forma que las revisiones se entregan por
semana. Se puede instituir sesiones
informativas diarias para que todos sepan lo
que los dems estn haciendo. El producto
se libera durante esta fase, pero se puede
mejorar si se le agregan otras
caractersticas.

Mantenimiento. Una vez liberado el

sistema, debe seguir funcionando sin
problemas. Es posible agregar
caractersticas, considerar las sugerencias
ms riesgosas de los clientes y rotar
miembros del equipo.

METODOS
ORIENTADOS A
OBJETOS

Metodo de Booch
Este mtodo abarca un microproceso y un
macro proceso de desarrollo. El nivel micro
define un conjunto de tareas de anlisis que
se aplican en cada etapa en el macro
proceso. Por lo que es un proceso evolutivo.
En micro proceso de desarrollo identifica
clases y objetos y la semntica de dichas
clases y objetos, define las relaciones entre
claes y objetos y realiza una serie de
refinamientos para elaborar el modelo de
anlisis.

Metodo de Rumbaugh
La actividad de anlisis crea tres modelos:
el modelo de objetos que da una
representacin de objetos, clases,
jerarquas y relaciones; el modelo dinmico
que es una representacin del
comportamiento del sistema y los objetos y
finalmente el modelo funcional que se
refiere a una representacin a alto nivel del
flujo de informacin a travs del sistema
similar al DFD.

Mtodo de Jacobson
Tambin llamado OOSE (Ingeniera del
Software Orientada a Objetos), este mtodo
es una versin simplificada de Objetory, un
mtodo patentado, tambin desarrollado
por Jacobson. Este mtodo se diferencia de
los otros por la importancia que da al caso
de uso (una descripcin o escenario que
describe como el usuario interacta con el
producto o sistema).

Mtodo de Coad y Yourdon

El mtodo de Coad y Yourdon se considera,
con frecuencia, como uno de los mtodos
del AOO ms sencillos de aprender. La
notacin del modeado es relativamente
simple y las reglas para desarrollar el
modelo de anlisis son evidentes. En
resumen su proceso es el siguiente:

Mtodo de Coad y Yourdon

Identificar objetos usando el criterio de
que buscar?
Definir una estructura de generalizacinespecificacin
Definir una estructura de todo-parte
Identificar temas(componentes de
subsistemas)
Definir atributos
Definir servicios

Metodo de Wirfs-Brock
Este mtodo no hace una distincin clara
entre las tareas de anlisis y diseo. En su
lugar, propone un proceso continuo que
comienza con la valoracin de una
especificacin del cliente y termina con el
diseo. Las tareas relacionadas son:

Metodo de Wirfs-Brock

Evaluar la especificacin del cliente

Usar un anlisis gramatical para extraer clases candidatas
de la especificacin.
Agrupar las clases en un intento de determinar
superclases
Definir responsabilidades para cada clase
Asignar responsabilidades a cada clase
Identificar relaciones entre clases
Definir colaboraciones entre clases basndose en sus
responsabilidades
Construir representaciones jerrquicas de clases para
mostrar relaciones de herencia.
Construir un grafo de colaboraciones para el sistema

Para realizar un anlisis orientado a objetos, un ingeniero de

software debera ejecutar las etapas genricas siguientes:

Obtener los requisitos del cliente para el sistema

Identificar escenarios o casos de uso
Seleccionar clases y objetos usando los
requisitos bsicos como guas
Identificar atributos y operaciones para cada
objeto del sistema
Definir estructuras y jerarquas que organicen
las clases
Construir un modelo objeto-relacin
Construir un modelo objeto-comportamiento
Revisar el modelo de anlisis OO con relacin a
los casos de uso/escenarios.

EL PROCESO DE DESARROLLO
UNIFICADO (RUP)

En 2000 la empresa Rational distribuye el

proceso de desarrollo empaquetado como
un producto denominado RUP (Rational
Unified Process). El proceso RUP es un
proceso de Ingenieria de software que
define un enfoque disciplinado para el
desarrollo de software con el objetivo de
asegurar la produccin de software de
calidad dentro de unos recursos de plazo y
presupuesto.

EL PROCESO DE DESARROLLO
UNIFICADO (RUP)

Sus caractersticas principales son:

Proporciona mltiples guas al personal de
desarrollo para facilitar el desempeo de su
funcin.
Los modelos creados en las diferentes actividades
utilizan de forma general la notacin de UML.
Estos modelos tienen un alto soporte por
herramientas de desarrollo.
Es un proceso configurable, por lo que se puede
ajustar a las caractersticas especificas de un
proyecto en cuanto a tamao y complejidad

EL PROCESO DE DESARROLLO
UNIFICADO (RUP)

Sus caractersticas principales son:

Utiliza un conjunto de buenas prcticas (practicas
asentadas y validadas en el desarrollo de
software)

Desarrollo iterativo
Gestin de requisitos
Utilizacin de arquitecturas basadas en componentes
Verificacin de la calidad
Control de cambios

DIMENSIONES DE RUP

Dimensin Temporal. El ciclo de vida se

divide en ciclos, periodos de tiempo en los
que se trabaja sobre una versin completa
del sistema. Cada ciclo se compone de 4
fases que se realizan de forma secuencial.

 Fase de Inicio. Aqu se estudia la viabilidad del

sistema, se establece el objetivo y se delimita su
alcance estimando recursos y un plan de tiempos
general. Al finalizar esta fase se decide si
continuar o no con el proyecto.
Fase de Elaboracin. Se analiza el dominio del
problema, se establece una arquitectura de
software se desarrolla el plan de proyecto. Se
debe disponer de un prototipo de la arquitectura
de software validado a partir del cual se pueda
desarrollar el sistema.

 Fase de Construccin. En esta fase se desarrolla el

sistema de forma iterativa e incremental hasta que
est listo para su puesta en operacin. Como
resultado se obtiene el sistema integrado en las
plataformas adecuadas, los manuales de usuario y
una descripcin de la versin actual.
Fase de Transicin. En esta fase se pone en operacin
el sistema a disposicin del usuario. Pueden sugir
nuevas cuestiones que requieran desarrollo adicional
para refinar y ajustar el sistema, corregir problemas o
finalizar aspectos que puedan haber sido aplazados.
Esta fase comienza con una versin Beta que se
remplaza al final con el sistema en produccin.

DIMENSIONES DE RUP

Dimensin Esttica. El proceso RUP describe

los perfiles de trabajo (quien) que realizan
productos intermedios (que), como
resultado de realizar un conjunto de
actividades (como), por medio de un flujo
de trabajo predefinido (cuando). RUP define
4 elementos de modelado principales

 Perfiles o papel de Trabajo (workers). Un papel o

rol de trabajo define el comportamiento y la
responsabilidad de una persona o grupo de
personas que trabajan como una unidad y en
equipo.
Actividad (activity). Una actividad de un papel
especifico es una unidad de trabajo que dicho
papel puede desempear.

 Producto intermedio (artifact). Es una pieza de

informacin que se produce, modifica o se utiliza
por un proceso.
Flujo de Trabajo (workflows). Secuencia de
actividades que produce un resultado de valor.

El lenguaje de modelado
unificado-UML
Al final de los 90s, Grady Booch, James
Rumbaugh e Ivar Jacobson empezaron a
colaborar para combinar y recopilar las
mejores caractersticas de cada uno de sus
mtodos de diseo y anlisis orientado a
objetos en un mtodo unificado. El
resultado, se denomino Lenguaje de
Modelado Unificado (UML), que actualmente
se ha convertido en el ms usado por la
industria.

En UML un sistema se representa por cinco

vistas diferentes que lo describen en
distintas perspectivas. En cada vista se
representa al sistema mediante un conjunto
de diagramas.
Vista del usuario. Representa al sistema desde la
perspectiva del usuario, el caso de uso es el
enfoque elegido para modelar esta vista.
Vista estructural. Los datos y la funcionalidad se
muestran desde dentro del sistema, se modela la
estructura esttica (Clases, objetos y relaciones).

 Vista del comportamiento. Representa los

aspectos dinmicos o de comportamiento del
sistema. Tambin muestra las interacciones o
colaboraciones entre los diversos elementos
estructurales descritos en las vistas anteriores.
Vista de implementacin. Aqu se representan los
aspectos estructurales y de comportamiento tal y
como van a ser implementados.
Vista del entorno. Aspectos estructurales y de
comportamiento en el que el sistema a
implementar se representa.

TAREA

REALIZAR UN CUESTIONARIO PARA EL

LUNES 12 SEPTIEMBRE