01 Clase IS445 Semana 1
-
Upload
keber-quispe-gamboa -
Category
Documents
-
view
213 -
download
0
description
Transcript of 01 Clase IS445 Semana 1
Sistemas de Información II (IS445) Primera Semana
Introducción a la Metodología ICONIX MSc. Ing. Efraín Elías Porras Flores Página 1
CAPITULO I
INTRODUCCION A LA METODOLOGIA ICONIX
La metodología ICONIX se encuentra entre el proceso unificado (PU) y la
programación extrema (XP). ICONIX está conducido por casos de uso, igual
que el proceso unificado, pero sin la sobrecarga del PU. Es relativamente
pequeño y ligero, igual que XP, pero no descarta el análisis y diseño formal
como la XP. ICONIX usa racionalmente el lenguaje unificado de modelado
(Rumbaugh et al., 2005), haciendo referencia a la trazabilidad de los requisitos.
Las actividades principales de ICONIX son: análisis de requisitos, diseño
preliminar, diseño e implementación (Rosenberg, et al., 2005).
1.1 EL ENFOQUE ICONIX
Esta compuesto por los lineamientos siguientes:
a. Modelado de objetos conducido por casos de uso.
b. Se descompone en fronteras de datos.
c. Basado en escenarios que descomponen los casos de uso.
d. Enfoque iterativo e incremental.
e. Proporciona trazabilidad de requisitos.
f. Uso directo de UML.
1.2 RAZONES PARA USAR ICONIX EN UN PROYECTO DE SOFTWARE
La mayoría de negocios que existen son PYMES y, requieren software de
calidad (Caballero, 2007). Al afrontar un proyecto para desarrollar software, se
debe usar una metodología ágil y formal como ICONIX, en tiempos cortos, con
recursos financieros limitados y, equipos de desarrollo de 10 a 20 personas. Al
escribir los casos de uso inconsistentes, generamos ambigüedad, si esta no se
controla, los casos de uso, el diseño y, el código fuente está mal enfocado.
Esto, origina errores y sobre costos durante el desarrollo y mantenimiento del
software (Pressman, 2001), (Sommerville, 2005).
Sistemas de Información II (IS445) Primera Semana
Introducción a la Metodología ICONIX MSc. Ing. Efraín Elías Porras Flores Página 2
1.3 RESUMEN DE LA METODOLOGIA ICONIX
El proceso ICONIX se divide en una parte estática y otra dinámica, que
son iterativos, podemos hacer una iteración de todo el proceso para un par de
casos de uso, hasta codificar y hacer las pruebas. Por esto, el proceso ICONIX
es ideal para proyectos pequeños y medianos, en resumen la metodología
ICONIX es:
a. Primer paso.- Identificar el mundo real y los objetos de dominio del
negocio (modelo de dominio).
b. Segundo paso.- Definir los requisitos de comportamiento (casos de uso).
c. Tercer paso.- Realizar análisis de robustez para eliminar la ambigüedad
de los casos de uso y determinar los defectos del modelo de dominio
(diagrama de robustez).
d. Cuarto paso.- Asignar comportamiento a los objetos (diagrama de
secuencia).
e. Quinto paso.- Finalizar el modelo estático (diagrama de clases).
f. Sexto paso.- Escribir y generar el código (código fuente).
g. Séptimo paso.- Realizar pruebas de aceptación (prueba).
ANALISIS DE REQUISITOS
a. Requisitos funcionales.- Define lo que el software debe ser capaz de
hacer, la creación de requisitos funcionales debe ser realizada por el
usuario o cliente, analista y experto del negocio.
b. Modelo de dominio.- Debe comprender el ámbito del problema sin
ambigüedad.
c. Requisitos de comportamiento.- Define la forma en que el usuario y el
software interactúan. Escribir el primer proyecto de casos de uso,
comenzar con un prototipo GUI e identificar todos los casos de uso o
por lo menos, tener una primera lista de casos de uso, que cambiará a
medida que se explora los requisitos en mayor profundidad.
Etapa 1: Revisión de Requisitos
En esta etapa la descripción de los casos de uso debe coincidir con los
requisitos del cliente. Revisar los casos de uso por grupos pequeños, antes de
diseñarlos. Luego, en cada iteración, para un pequeño grupo de casos de uso,
Sistemas de Información II (IS445) Primera Semana
Introducción a la Metodología ICONIX MSc. Ing. Efraín Elías Porras Flores Página 3
hacer lo que describimos a continuación.
DISEÑO PRELIMINAR
a. Dibujar diagrama de robustez.- Es una "imagen del objeto" descripción
por pasos de un caso de uso, reescribir los casos de uso a medida que
avanza.
b. Actualizar modelo de dominio.- Mientras escribe los casos de uso y
dibuja el diagrama de robustez, descubrirá algunas clases “perdidas”,
corregir las ambigüedades y, añadir atributos a los objetos de dominio.
c. Nombrar controladores.- Nombre todas las funciones lógicas del
software, necesarios para que los casos de uso funcionen.
d. Escribir.- Reescribir el borrador de los casos de uso.
Etapa 2: Revisión del Diseño Preliminar
DISEÑO DETALLADO
a. Diagrama de secuencia.- Dibuje un diagrama de secuencia, uno para
cada caso de uso, diagrama que muestra en detalle cómo va a
implementarse el caso de uso. La función principal de un diagrama de
secuencia es asignar comportamiento a sus clases.
b. Actualizar modelo de dominio.- Al dibujar los diagramas de secuencia,
añadir operaciones a los objetos entidad, el modelo de dominio debe
convertirse en un modelo estático o diagrama de clases.
c. Depurar el modelo estático.- Quitar inconsistencias diagrama de clases.
Etapa 3: Revisión Crítica del Diseño
IMPLEMENTACION
a. Código y pruebas unitarias.- Escribir el código fuente y formular las
pruebas unitarias o, escriba las pruebas unitarias y luego el código.
b. Integración y pruebas de escenario.- Base las pruebas de integración
en los casos de uso, para probar los cursos básico y alterno.
c. Revisar código y actualizar el modelo.- prepararse para la siguiente
iteración del proceso ICONIX, con otro pequeño grupo de casos de uso.