5TO SISTEMAS
CATEDRATICO: Ing. Juan
Espinoza
METODOLOGÍA RUP
El Proceso Unificado Racional, Rational
Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de
software y junto con el Lenguaje Unificado de Modelado UML, constituye la
metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos. El RUP no es un sistema con
pasos firmemente establecidos, sino que trata de un conjunto de metodologías
adaptables al contexto y necesidades de cada organización, donde el software es
organizado como una colección de unidades atómicas llamados objetos, constituidos
por datos y funciones, que interactúan entre sí.
RUP es un proceso para el desarrollo de un
proyecto de un software que define claramente quien, cómo, cuándo y qué debe
hacerse en el proyecto
RUP Como proceso de desarrollo
• RUP es explícito en la definición de
software y su trazabilidad, es decir, contempla en relación causal de los
programas creados desde los requerimientos hasta la implementación y pruebas.
• RUP identifica claramente a los
profesionales (actores) involucrados en el desarrollo del software y sus
responsabilidades en cada una de las actividades.
Fases de desarrollo del software
· Inicio
· Elaboración
· Construcción
· Transición
FASE DE INICIO
Se hace un plan de fases, donde se
identifican los principales casos de uso y se identifican los riesgos. Se
concreta la idea, la visión del producto, como se enmarca en el negocio, el
alcance del proyecto. El objetivo en esta etapa es determinar la visión del
proyecto.
·
Modelado
del negocio
En esta fase el equipo se familiarizará más
al funcionamiento de la empresa, sobre conocer sus procesos.
· Entender la estructura y la dinámica de
la organización para la cual el sistema va ser desarrollado.
· Entender el problema actual en la
organización objetivo e identificar potenciales mejoras.
· Asegurar que clientes, usuarios finales y
desarrolladores tengan un entendimiento común de la organización objetivo.
·
Requisitos
En esta línea los requisitos son el
contrato que se debe cumplir, de modo que los usuarios finales tienen que
comprender y aceptar los requisitos que especifiquemos.
· Establecer y mantener un acuerdo entre
clientes y otros stakeholders sobre lo que el sistema podría hacer.
· Proveer a los desarrolladores un mejor
entendimiento de los requisitos del sistema.
· Definir el ámbito del sistema.
· Proveer una base para estimar costos y
tiempo de desarrollo del sistema.
· Definir una interfaz de usuarios para el
sistema, enfocada a las necesidades y metas del usuario.
FASE DE ELABORACION
Se realiza el plan de proyecto, donde se
completan los casos de uso y se mitigan los riesgos. Planificar las actividades
necesarias y los recursos requeridos, especificando las características y el
diseño de la arquitectura. En esta etapa el objetivo es determinar la
arquitectura Óptima.
·
Análisis
y Diseño
En esta actividad se especifican los
requerimientos y se describen sobre cómo se van a implementar en el sistema.
· Transformar los requisitos al diseño del
sistema.
· Desarrollar una arquitectura para el
sistema.
· Adaptar el diseño para que sea consistente
con el entorno de implementación.
FASE DE CONSTRUCCION
Se basa en la elaboración de un producto
totalmente operativo y en la elaboración del manual de usuario. Construir el
producto, la arquitectura y los planes, hasta que el producto está listo para ser
enviado a la comunidad de usuarios. En esta etapa el objetivo es llevar a
obtener la capacidad operacional inicial.
·
Implementación
Se implementan las clases y objetos en
ficheros fuente, binarios, ejecutables y demás. El resultado final es un
sistema ejecutable.
· Planificar qué subsistemas deben ser
implementados y en qué orden deben ser integrados, formando el Plan de
Integración.
· Cada implementador decide en qué orden
implementa los elementos del subsistema.
· Si encuentra errores de diseño, los notifica.
· Se integra el sistema siguiendo el plan.
·
Pruebas
Este flujo de trabajo es el encargado de
evaluar la calidad del producto que estamos desarrollando, pero no para aceptar
o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado
en todo el ciclo de vida.
· Encontrar y documentar defectos en la
calidad del software.
· Generalmente asesora sobre la calidad del
software percibida.
· Provee la validación de los supuestos
realizados en el diseño y especificación de requisitos por medio de
demostraciones concretas.
· Verificar las funciones del producto de
software según lo diseñado.
· Verificar que los requisitos tengan su
apropiada implementación.
ETAPA DE TRANSICION
El objetivo es llegar a obtener el release
del proyecto. Se realiza la instalación del producto en el cliente y se procede
al entrenamiento de los usuarios. Realizar la transición del producto a los
usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y
mantenimiento del producto, hasta que el cliente quede satisfecho, por tanto en
esta fase suelen ocurrir cambios.
·
Despliegue
Esta actividad tiene como objetivo producir
con éxito distribuciones del producto y distribuirlo a los usuarios. Las
actividades implicadas incluyen:
· Probar el producto en su entorno de
ejecución final.
· Empaquetar el software para su
distribución.
· Distribuir el software.
· Instalar el software.
· Proveer asistencia y ayuda a los
usuarios.
· Formar a los usuarios y al cuerpo de
ventas.
· Migrar el software existente o convertir
bases de datos.
Cada una de estas etapas es desarrollada
mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de
vida en cascada a menor escala. Los objetivos de una iteración se establecen en
función de la evaluación de las iteraciones precedentes.
A medida que se avanza en el proyecto, es
decir, cuando se va pasando de una fase a otra, la importancia relativa de cada
uno de los Flujos de Trabajo va cambiando. Así, en las iteraciones de la Fase
de Inicio el trabajo se centra principalmente en el Modelamiento del Negocio y
en la captura y especificación de requisitos. Pero en la fase de Construcción
el desarrollo está enfocado en la Implementación (codificación) y, en menor
medida, en el Diseño
BIBLIOGRAFIA
METODOLOGIA AGIL MSF (Microsoft
Solution FrameWork)
La metodología MSF es del tipo de metodologías agiles, está enfocada a
dirigir proyectos o soluciones de innovación, en ella no se detalla ni se hace énfasis
de la organización ni el tamaño del equipo de desarrollo, está más bien
centrada en la gestión y administración del proyecto para lograr el impacto
deseado.
Involucra indudablemente la calidad ya que prevé liberar una solución si
esta aún tiene fallos o desperfectos para ello propone seleccionar un grupo de
prueba piloto el cual es una VERSION BETA y cumplido un tiempo de prueba ya es
liberada la version formal o VERSION ALFA en la cual está garantizada la
calidad.
Consta de 5 fases:
FASE DE VISION
En esta fase se debe realizar un estudio de lo que
pretendemos en el futuro que haga nuestra aplicación o nuestro proyecto para
ello debemos realizar un documento de estrategia y alcance donde debe quedar
pactada la necesidad de funcionalidad y servicio que se debe contar en la solución.
Debemos crear los equipos de trabajo junto con el plan de trabajo, Para
asegurar el éxito del proyecto es importante tener en cuenta el análisis de
riesgos y plan de contingencia.
FASE DE
PLANIFICACION
En esta fase básicamente debemos concretar
claramente como va a estar estructurada nuestra solución para ello debemos
crear un documento de planificación y diseño de la arquitectura, diseñar las
pruebas de concepto donde se plantean los diferentes escenarios para probar la
validez de los criterios utilizados para el diseño, debemos establecer métricas.
FASE DE
DESARROLLO
En la etapa de desarrollo debemos codificar las
aplicaciones y realizar las configuraciones necesarias para que la solución
funcione, es importante hacer pruebas continuamente asi se verifica la calidad
del producto continuamente a lo largo del desarrollo y no únicamente al final
del proceso.
FASE DE
ESTABILIZACION
Esta fase debemos seleccionar el entorno de prueba
piloto y lo que pretendemos con esto es identificar las deficiencias con un
grupo reducido de usuarios para corregirlas y así en el futuro no tener
problemas cuando se use la solución por todos, ocasionalmente a esta etapa se
le llama BETA, debemos crear un plan de gestión de incidencias, realizar una revisión
de documentación final de la arquitectura y Elaboración de plan de despliegue o
implementación.
ETAPA DE DESPLIEGUE O IMPLEMENTACION
En esta etapa final ya se ha comprobado la calidad
de la solución por lo cual está lista para ser publicada, en este sentido
debemos liberar la solución y crear un registro de mejoras y sugerencias,
revisar las guías y manuales y entrega de proyecto final.
Este ciclo se puede llevar a cabo de forma iterativa, de manera que cuando
liberamos una solución podemos iniciar nuevamente la metodología para darle más
funcionalidad.
BIBLIOGRAFIA
METODOLOGIA
MVC
El Modelo Vista Controlador (MVC) es un patrón
de arquitectura de software que separa los datos y
la lógica de negocio de una aplicación de la interfaz de
usuario y el módulo encargado de gestionar los eventos y las
comunicaciones. Para ello MVC propone la construcción de tres componentes distintos
que son el modelo, la vista y el controlador,
es decir, por un lado define componentes para la representación de la
información, y por otro lado para la interacción del usuario. Este patrón
de diseño se basa en las ideas de reutilización de código y
la separación de conceptos, características que buscan facilitar la tarea
de desarrollo de aplicaciones y su posterior mantenimiento.
MVC es una
arquitectura que divide la implementación de una aplicación Web en 3
componentes basados en los conceptos: modelos, vistas y controladores.
MODELOS
En una
aplicación basada en MVC son los componentes responsables de mantener el estado
en una aplicación. Son tambien llamados “entidades de aplicación” (por ejemplo:
podríamos manejarnos con entidades no tipiadas en una aplicación, entidades
tales como un DataTable, pero realmente estaríamos perdiendo cierta coherencia
al pasar datos desde nuestra capa de negocio hasta nuestra capa de
presentación)
VISTAS
En una
aplicación basada en MVC son los componentes responsables de mostrar el
interfaz de usuario de la aplicación.
CONTROLADORES
En una
aplicación basada en MVC son los componentes responsables del manejo de la
interacción del usuario. Para una request determinada, manipulan los modelos, y
finalmente eligen una vista para renderizar los datos del modelo.
Uno de los
beneficios del uso de la metodología MVC, es que ayuda a asegurar la separación
de conceptos (SoC: Separation of Concepts) entre modelos, vistas y
controladores en una aplicación.
Mantener esta separación
de conceptos, hace que el testeo de aplicaciones sea mucho mas sencillo, ya que
se pueden testear más fácilmente las aplicaciones Web creando tests unitarios
sobre los controladores.
BIBLIOGRAFIA
·
http://social.msdn.microsoft.com/Forums/es-ES/88811066-e41f-4ade-9c6b-c4c3bed93d33/metodologia-mvc
