UNIVERSIDAD BICENTENARIA DE ARAGUA

SISTEMA DE INFORMACIÓN
LISBETH RODRIGUES
30.411.416
 Los métodos orientados a objeto acortan la distancia existente entre el
espacio de conceptos (lo que los expertos o usuarios conocen) y el espacio de
diseño (lo que conocen los desarrolladores) e implementación, ya que los
objetos del mundo real tienen una correspondencia bastante clara con los
objetos del sistema informático, evitando así los grandes abismos existentes
entre el análisis y el diseño en el enfoque estructurado, esto es la falta de
continuidad en la representación de los conceptos en una y otra fase, por
ejemplo los DFDs y los diagramas de estructura.

 Por su parte, en los desarrollos orientados al objeto se tiene una mayor

continuidad entre las diferentes fases, con unas fronteras entre fases muy poco
marcadas que dan lugar a desarrollos más iterativos e incrementales. Todo esto
es posible gracias a una característica de vital importancia, el modelo
subyacente a todas las fases es el mismo, el modelo objeto, que tiene como
elemento central al objeto, que es la entidad que encapsula elementos
estructurales y de comportamiento. De esta forma, los objetos semánticos
identificados en la fase de análisis se refinarán durante la fase de diseño e
implementación, a la vez que se añaden objetos de interfaz y de utilidad para
constituir la aplicación final.

 Proceso de desarrolló:
El marco de desarrollo de una aplicación software estaría formado por las
tres fases tradicionales: análisis, diseño e implementación.

El análisis es la fase cuyo objetivo es estudiar y comprender el dominio del

problema, es decir, el análisis se centra en responder al interrogante ¿QUÉ
HACER?

El diseño, por su parte, dirige sus esfuerzos en desarrollar la solución a los

requisitos planteados en el análisis, esto es, el diseño se haya centrado en
el espacio de la solución, intentando dar respuesta a la cuestión ¿CÓMO
HACERLO?

Por último, la fase de implementación sería la encarga de la traducción

del diseño de la aplicación al lenguaje de programación elegido, adaptando
por tanto la solución a un entorno concreto.
 Lineamientos:
Debe tener una arquitectura que a) se haya creado con el empleo de
estilos o patrones arquitectónicos reconocibles, b) esté compuesta de
componentes con buenas características de diseño y c) se implementen en
forma evolutiva de modo que faciliten la implementación y las pruebas.

Debe ser modular, es decir, el software debe estar dividido de manera

lógica en elementos o subsistemas.

Debe contener distintas representaciones de datos, arquitectura,

interfaces y componentes.

Debe conducir a estructuras de datos apropiadas para las clases que se

van a implementar y que surjan de patrones reconocibles de datos.

 Lineamientos:
Debe llevar a componentes que tengan características funcionales
independientes.

Debe conducir a interfaces que reduzcan la complejidad de las conexiones

entre los componentes y el ambiente externo.

Debe obtenerse con el empleo de un método repetible motivado por la

información obtenida durante el análisis de los requerimientos del
software.

Debe representarse con una notación que comunique con eficacia su

significado.

Ciclo de vida
 Ciclo de vida:
Planificación: Realizar una serie de tareas previas que influirán decisivamente
en la finalización con éxito del proyecto.

Análisis: Averiguar qué es exactamente lo que tiene que hacer el sistema. La

etapa de análisis en el ciclo de vida del software corresponde al proceso
mediante el cual se intenta descubrir qué es lo que realmente se necesita y se
llega a una comprensión adecuada de los requerimientos del sistema.

Diseño: Se han de estudiar posibles alternativas de implementación para el

sistema de información que hemos de construir y se ha de decidir la estructura
general que tendrá el sistema (su diseño arquitectónico).

 Ciclo de vida:
Implementación: Seleccionar las herramientas adecuadas, un entorno de
desarrollo que facilite nuestro trabajo y un lenguaje de programación
apropiado para el tipo de sistema que vayamos a construir.

Pruebas: Tiene como objetivo detectar los errores que se hayan podido
cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos).

Instalación o despliegue: Debemos de planificar el entorno en el que el

sistema debe funcionar, tanto hardware como software: equipos necesarios y
su configuración física, redes de interconexión entre los equipos y de acceso a
sistemas externos, sistemas operativos y bibliotecas.

 Dominio del problema:

Identificar aquellas cosas que utilizan los usuarios, para describir el problema
o la solución.

Para cada abstracción hay que identificar un conjunto de responsabilidades

bien repartidas.

Al ir aumentando de tamaño los modelos, muchas de las clases tienden a

agruparse en grupos relacionados conceptual y semánticamente.

Una vez que se ha modelado, habrá que asegurarse que se tenga un equilibrio
de responsabilidades. Esto es que no se desea que ninguna clase sea
demasiado grande ni demasiado pequeña.

El resultado, tras los mencionados descartes, conseguirá obtener la relación

definitiva de clases correctas. Con ellas estaremos en condiciones de generar un
diagrama de objetos para afrontar el problema de nuestro dominio.
 Metodología RUP:
El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de
ingeniería de software que suministra un enfoque para asignar tareas y
responsabilidades dentro de una organización de desarrollo. Su objetivo es
asegurar la producción de software de alta y de mayor calidad para satisfacer
las necesidades de los usuarios que tienen un cumplimiento al final dentro de
un limite de tiempo y presupuesto previsible. Es una metodología de desarrollo
iterativo que es enfocada hacia “ diagramas de los casos de uso, y manejo de
los riesgos y el manejo de la arquitectura” como tal.

El RUP mejora la productividad del equipo ya que permite que cada miembro
del grupo sin importar su responsabilidad específica pueda acceder a la misma
base de datos incluyendo sus conocimientos.

 Caracteristicas RUP:

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué,

cuándo y cómo).
Pretende implementar las mejores prácticas en Ingeniería de Software.
Desarrollo iterativo‍‍‍.
Administración de requisitos.
Uso de arquitectura basada en componentes.
Control de cambios.
Modelado visual del software.
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de uso.
 Fases del Método RUP:

Objetivos y alcances Arquitectura del

del proyecto sistema
Inicio Elaboración

Depurar y entregar Transición Construcción Culminar la

al usuario funcionalidad del
sistema