Desarrollo de sistemas de información

Ing. Carlos Avalos Ruiz 1

Tema Nro.1:

Desarrollo de sistemas de información

“Una guía para la automatización de las funciones de la organización para la obtención de ventajas competitivas”


Introducción

• El desarrollo de los sistemas de información se basan en ciclo de vida del desarrollo del software.

• La disciplina encargada de proveer los medios necesarios para la construcción de una software es la ingeniería de software.

• Por ende el desarrollo de los sistemas de información están basado en procesos de desarrollo de software que la ingeniería de software propone.

• Para ello existen dos enfoques paradigmáticos: estructurado y orientado a objetos.


La Ingeniería de Software (IS)

• La IS es una disciplina que integra métodos, herramientas y procedimientos para el desarrollo del software de computadoras.

• Se han propuesto varios paradigmas, entre ellos podemos mencionar: estructurado,orientado a objetos ,sala limpia, cliente/servidor, reutilización del software, reingeniería del software, software asistido por computadoras, etc.

• El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos.


Paradigma Orientado a Objetos• Con frecuencia se alude a la Orientación a Objetos

como un nuevo paradigma (Paradigma de Objetos) y al término Orientado a Objeto ( OO ) como la aplicación de este paradigma al mundo de la computación.

• El paradigma para los programadores, es la manera como se maneja la complejidad.

• Desde este punto de vista el paradigma es el modelo o la estructura dentro del software solución de un problema.


• Superficialmente OO significa la organización del software como una colección de Objetos discretos que incorpora tanto la estructura de datos como su comportamiento.

• Para cada entidad del dominio, hay un objeto que representa ese concepto en el modelo.

• Finalmente, OO modela mirando en alguna parte realidad o dominio que es de interés, y busca las abstracciones claves y las relaciones entre esas abstracciones claves.


• La Orientación a Objetos se aplica a otros disciplinas dentro del mundo de la computación, tal como se aprecia en la siguiente ilustración :


En resumen la Orientación a Objetos:

Orientadoa

objetos

abstracciónde la realidad

ConceptosObjetosClasesEstructuras -jerárquicasMétodos/ope-raciones/servicios

AbstracciónEncapsulamientoHerenciaPolimorfismoMensajeIdentidadAsociación

en función

y que mediante

permite manejarla complejidad


Tecnología Orientada a Objetos

• La Tecnología de Objetos (TO), una de las más recientes técnicas de desarrollo de sistemas y se basa en la OO; cuenta con cuatro bases fundamentales :– Análisis Orientado a Objetos (AOO). – Diseño Orientado a Objetos (DOO). – Programación Orientada a Objetos (POO).– Base de Datos Orientado a Objetos (BDOO).


Tecnología orientada a

objetos

Nuevos métodos de

programación.

Nuevos métodos de

análisis

Nuevos métodos de

diseño

Reutilizar el código

Mas calidad

Mas productividad

Menos costo

Situación Actual en la TOO


Desarrollo de la Tecnología Orientada a Objetos

• Con el universo de métodos, se ha formado un cos- mo dinámico con el mundo de objeto en el que un método evoluciona en una estrella nítida u otra cesa para ser destacado y llega a ser un gigante rojo antes de desaparecer enteramente.

• De aquí en adelante, una organización debería prime ra comprender completamente qué significa para pen sar desde el punto de vista de objetos.


Método, Metodología y Proceso en el desarrollo de software

• Un método es la aplicación particular de una método logia de desarrollo de software pero que no abarca el ciclo de vida de desarrollo de software ni cuenta con herramientas tecnológica de soporte.

• Una metodología es una marco general basado en un paradigma que sirve de base para el desarrollo de software y que abarca todo el ciclo de vida.

• Un proceso de desarrollo de software esta basado en una metodología, abarca todo el ciclo de vida y provee herramientas tecnológica de soporte.


¿Problemas en el desarrollo de software?

• Retrasos en los plazos• Proyectos cancelados• Rápido deterioro del sistema instalado• Tasa de defectos o fallos• Requisitos mal comprendidos• Cambios frecuentes en el dominio del problema• Muchas de las interesantes características del software no

proporcionan beneficios al cliente• Buenos programadores se cansan y dejan el equipo


El Modelado

• El modelado es una tecnica de ingeniería probada y bien aceptada.

• El modelado no solo es parte de la industria de la construcción.

• Un modelo es una abstracción del sistema, especificando el sistema desde un cierto punto de vista y en un determinado nivel de abstracción.

• Un modelo es una simplificacion de la realidad.


¿Por qué las empresas no hacen modelado?

• La mayor parte de las empresas software no realizan ningún modelado.

• El modelado requiere:– aplicar un proceso de desarrollo– formación del equipo en la técnicas– ¿tiempo?

• ¿Se obtienen beneficios con el modelado?


¿Por qué modelamos?

• Los modelos :• Ayudan a visualizar como es o queremos que sea el

sistema.• Especifican la estructura o comportamiento de un

sistema• Proporcionan plantilla que nos guian en la

construccion de un sistema.• Documentan las decisiones que hemos adoptado.

Construimos modelos para comprender mejor el sistema que estamos desarrollando.


Principio de Modelado

• La elección de que modelos crear tiene una profunda influencia sobre como se define un problema y como se da forma a una solucion.

• Todo modelo puede ser expresado a diferentes nive les de expresion.

• Los mejores modelos están ligados a la realidad.• Un único modelo no es suficiente.• El modelado no es sólo para los grandes sistemas.


Sistema de Computo

Procesos del Negocio

Order

Item

Ship via

“El modelado captura la parte escencial de un sistema.” Dr. James Rumbaugh

El Modelado Visual es un modelamiento usando notaciones graficas estandares

Modelado Visual


Arquitectura del Software

• La visualización, especificación, construcción y documentación de un sistema con gran cantidad de software requiere que el sistema sea visto desde varias perspectivas.

• La arquitectura de un sistema es quizás el artefacto mas importante que puede emplearse para manejar estos diferentes puntos de vista y controlar el desarrollo iterativo e incremental.


• La arquitectura es un conjunto de decisiones significativas sobre:– La organización de un sistema software.– La selección de elementos estructurales y sus

interfaces a través de los cuales se constituye el sistema.

– Su comportamiento, como se especifica en la colaboraciones entre esos elementos.

– La composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente mas grandes.

– El estilo arquitectónico que guía esta organización: los elementos.


• estáticos y dinámicos y sus interfases, sus colaboraciones y su composición.

• La arquitectura del software no tiene que ver sola mente con la estructura y el comportamiento, sino también con el uso, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas y de tecnología y los compromisos entre alternativas, así como de los aspectos estáticos.


Modelado de la arquitectura de un sistema software

Vista de Diseño Vista de Implementación

Vista de Procesos Vista de Despliegue

Vista de casos de uso

vocabulariofuncionalidad

ensambladogestión conf.

topologíaentregadistribucióninstalación

Funcionamientoescalabilidadrendimiento

comportamiento


• La vista de casos de uso de un sistema comprende los casos de uso que describen el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas, y encargados de las pruebas.

• La vista de diseño de un sistema comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y las solución.

• La vista de procesos de un sistema comprende los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema.


• La vista de implementación de un sistema compren de los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema físico.

• La vista de despliegue de un sistema contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema.

Cada una de estas cinco vistas pueden existir por si misma, de forma que diferentes usuarios pueden centrarse en las cuestiones de la arquitectura del sistema que mas le interese.


Por qué es necesaria la arquitectura

• Un sistema software grande y complejo requiere una arquitectura para que los desarrolladores puedan progresa hasta tener una visión común.

• Se necesita una arquitectura para:– Comprender el sistema.– Organizar el desarrollo.– Fomentar la reutilización.– Hacer evolucionar el sistema.


Unified Modeling Language (UML)

• UML es un lenguaje estandar para la visualiza cion , especificacion, construccion, y documenta cion de artefactos de un sistema.

• UML combina lo mejor de :– Modelamiento conceptual de datos (Diagrama Entidad

Relacion)– Modelamiento del flujo de actividades.– Modelamiento de Objetos – Modelamiento de Componentes


• UML Significa Lenguaje Unificado de Modelado. Un lenguaje de modelado es lenguaje cuyo voca bulario y reglas se centra en la representación conceptual y física de un sis tema.

• UML consiste en Reglas de simbología que se aplican a cualquier tipo de modelo hecho bajo este lenguaje.

• UML es un Lenguaje estandar para escribir planos o modelos de software.


• UML tiene una sintaxis y una semántica bien definida. La parte mas visible de UML es su notación gráfica.

• Puede utilizarse con todos los procesos y a lo largo del ciclo de vida del desarrollo de softwa re, y con diferentes tecnologias de implementa cion.

• UML puede utilizarse para: – Visualizar el límite de un sistema y sus fun

ciones importantes.


– Ilustrar realizaciones de un sistema.– Representar la estructura estática de un siste

ma .– Modelar el comportamiento de objetos. – Conocer la arquitectura física de la implemen

tación. – Extender su funcionalidad con estereotipos.

• El vocabulario y las reglas de un lenguaje como UML indican como crear y leer modelos bien for mados, pero no dicen “que” ni “cuando” estos mo delos se deben crear.


• UML es sólo un lenguaje y por lo tanto estan sólo una parte de un método de desarrollo de Software. UML es independiente del proceso.

• Un proceso bien definido guiará a sus usuarios al decidir qué artefactos producir, qué activida des y qué personal emplear para crearlo y ges tionarlo.

• Un artefacto es una pieza de información que es utilizada o producida por un proceso de desarro llo de software.


Antecedentes de UML

• Originalmente desarrollado por Rational, Grady Booch y James Rumbaugh.

• Posteriormente se tiene la contribución de Ivar Jacobson.

• Esta aceptada por OMG (Object Manage ment Group)

• UML se ha publicado en las siguientes versiones: 0.8, 0.9, 0.91, 1.0, 1.1,1.2,1.3.......


Los tres amigos (y otros)

• Ivar Jacobson -- Objectory and use cases.• Jim Rumbaugh -- OMT and UML.• Grady Booch -- Booch Method and UML.• Hewlett-Packard, Texas Instruments, Oracle.• Microsoft -- Repository, visual modeling. • Platinum -- OPEN Modeling Language.• IBM/ObjectTime -- OCL/ROOM.


ContribucionesMeyer

Before and after conditions

Harel

Statecharts

Gamma, et al

Frameworks and patterns,

HP Fusion

Operation descriptions and message numbering

Embley

Singleton classes andhigh-level view

Wirfs-Brock

ResponsibilitiesOdell

Classification

Shlaer - Mellor

Object lifecycles

Rumbaugh

OMT

Booch

Booch method

Jacobson

OOSE


Historia de UML

Booch method OMT

Unified Method 0.8OOPSLA ´95

OOSEOther methods

UML 0.9Web - June ´96

publicfeedback

Final submission to OMG, Sep ‘97

First submission to OMG, Jan ´97

UML 1.1OMG Acceptance, Nov 1997

UML 1.3

UML 1.0UML partners


Donde puede utilizarse UML

• UML esta pensado principalmente para sistemas de gran cantidad de software.

• UML es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones distribuidas basadas en Web, e incluso para sistemas empotrados de tiempo real muy exigentes.

• UML no esta limitado al modelado de software, es lo sufientemente expresivo para modelar sistemas que no son software.


Classesapplication partitioning

Business ObjectsRelationships

Business Process

Objects

Use Cases

large scale system

ScenariosComponentsMicrosoft

ActiveX/COMMicrosoft

ORDBMSOracle

CORBAOMG

UML: Soporte para el desarrollo de cualquier tipo de aplicaciones


Utilidad de UML

• Permite especificar todas las decisiones de análisis, diseño e implementación, construyéndose modelos precisos, no ambiguos y completos.

• UML puede conectarse a lenguajes de programación:– Ingeniería directa e inversa

• Permite documentar todos los artefactos de un proceso de desarrollo (requisitos, arquitectura, pruebas, versiones,..)


Metamodelo UML

• ¿Cómo se expresa la semántica del modelo?– Informalmente– Formalmente

• El metamodelo UML define la notación de un modo riguroso, a través de diagramas de la propia notación y con OCL.


Metamodelo UML: Ejemplo

Relación

AsociaciónGeneralización

Role de asociación

1

2..*ordered


Modelo Conceptual de UML

• Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto requiere aprender tres elementos principales:– Los bloques de construcción.– Las reglas que dictan como se pueden combinar

estos bloques básicos.– Algunos mecanismos comunes que se pueden

aplicar.


UML

Elementos

Estructural

Use caseClases

Clases ActivasInterfaces

ComponentesColaboraciones

Nodos

Comportamiento Agrupación Anotación

Relaciones DiagramasEspecificaciones

AdornosDivisionescomunes

Mecanismosde extensión

InteracciónMaquina de

Estado

PaqueteModelo

SubsistemaFramework

Notas

DependenciaAsociación

GeneralizaciónRealización

Use caseClases

ObjetosSecuencia

ColaboracionesEstado

ActividadComponentes

DespliegueEstereotipos

Valores etiquetadosRestricciones

Bloques de Construcción Reglas

NombresAlcance

VisibilidadIntegridad

MecanismosComunes


Elementos del modelo conceptual de UML

• Elementos estructurales: modelan partes estáticas y representan cosas conceptuales y materiales, son: Clases, una interfaz, una colaboración, un use case, componentes y nodos.

• Elementos de comportamiento: son las partes dinámi cas de los modelos, representan comportamiento en el tiempo y el espacio, son: una interacción y una máquina de estados.


• Elementos de agrupación: son las partes organizati vas, el elemento de agrupación principal son los pa quetes.

• Elementos de anotación: son las partes explícitas, se usan para describir, clarificar o hacer observaciones, esta es una nota


Elementos EstructuralesVentana

origentamaño

abrir()cerrar()mover()dibujar()

clase

IAvisable<<Interface>>

IAvisable

InterfaceValidarTransacción

caso de uso

Gestor Eventos

suspender()

vaciarCola()

clase activa

Gestión Pedidos

colaboración componente

Hola Mundo.class

Servidor

nodo


Elementos de ComportamientoInteracción

Conjunto de mensajes intercambiados entre un conjunto de objetos con un propósito particular.

mensajedibujar

Máquina de estadosSecuencia de estados por las que pasa un objeto durantesu vida en respuesta a eventos.

estadoactivado


Elementos de Agrupamiento

Modelo del Negocio Paquete

Un paquete incluye un conjunto de elementos de cualquiernaturaleza.

Tiene una naturaleza conceptual.


Elementos de Notación

Son las partes explicativas de los modelos UML

NotaRetorna 0 si no existe el valor


Relaciones del modelo concpetual de UML

Dependencias

Asociacionespatrón empleado

0..1 *

Generalizaciones

Realización


DiagramaUse Case

Diagramade

ColaboracionColaboracion

Diagramade

Componentes

Diagramade

Despliegue

Diagramade

Objetos

Diagramade

Estado

Diagramade

Secuencia

Diagramade

Clases

Diagramade

Actividad

Un modelo es una descripción completa de un sistema desde una perspectiva particular

Modelos

Modelos y Diagramas de UML


atributos

operaciones

dependencia

Empresa

generalización

Oficina Principal

1

1..**

0..1

clase

**

miembro

rol

11..*

{subgrupo}asociación

administrador

restricción

multiplicidad

agregación

nombre1..*

sitio

Empleado

Nombre: MaríaIDEmpleado: 2568Cargo: Gerente

obtenerFoto(f:Foto)obtenerSonido()obtenerContacto()obtenerRegistroEmpleados()

Contacto

Dirección: Pizarro 254

RegistroEmpleados

IdImpuestoHistorialempleadosueldo/salario

Departamento

Nombre: Ventas *

Oficina

Dirección : Sucre 360Código: 2358

*

Diagrama de Clases• Muestra un conjunto de clases, interfaces y colabora

ciones con sus relaciones.


e: Empresa

objeto anónimo

valor de atributo

enlace

objeto

d1: Departamento

Nombre: “Ventas”

d2: Departamento

Nombre: “RRHH”

d3: Departamento

Nombre: “Ventas a Crédito”

p: Personal

Nombre = “Eddi”IDEmpleado = “4356”Cargo = “Vendedor”

: Contacto

Dirección:“Pio265”

Diagrama de Objetos• Muestra un conjunto de objetos y sus relaciones.


Red celular

Usuario

actor

Emitiendollamadas deconferencia

Recepcionandollamadaadicional

Usando horario

Recibiendollamada

Emitiendollamada

Relación extendida

<<extend>>

<<extend>>

use-case

límites del sistema

Telefonía Celularasociación

Diagrama de Use Case• Muestra un conjunto de Casos de Uso (Use Case),

actores y sus relaciones, presenta una descripción de la conducta de un sistema para un usuario en un punto determinado.


h : hilo : herramientas

p : par

a1 : ejecutar(3)

ejecutar()

<<create>>

<<destroy>>

pideIdent()

rellamada()

objeto

etiqueta dela secuencia

mensaje

línea de vida

creacion

llamada

recursiónretorno/rspta

destrucción

enfoque de control

interacción

Diagrama de Secuencia• Es un diagrama de interacción que resalta el orden tem

poral de los mensajes, es decir, muestra el dinamismo de la interacción entre objetos, en función al tiempo.


Diagrama de Colaboraciones• Es un diagrama de interacción que resalta el orden tem

poral de los mensajes, es decir, muestra el dinamismo de la interacción entre objetos, en función al tiempo.

c:Cliente

:Transacción p:ODBDProxy

1: <<create>>2: grupoAcciones(a,d,o)3: <<destroy>>

<<global>>

2.1: grupoValores(d,3.4)2.2: grupoValores(a,”CO”)

objeto

mensajeenlace

<<local>>

{transitorio}

Diagrama de Colaboración


estado inicial

conectado

conectando

Trabajandolisto(3) [señal OK]

Inactivo

encender

apagar/reconectar()

activado/revisar()

apagado

estado final

estado

eventoacción

transición

transición interna

guardar

estado anidado

Máquina de Estado

Diagrama de Estado• Muestra una máquina de estados, que consta de: esta

dos, transiciones, eventos y actividades. Estos diagra mas cubren la vista dinámica del sistema. Son importan tes para modelar el comportamiento de una interfaz, cla se o colaboración.


estado inicial

Seleccionar lugar

Comisionar a arquitectos

Desarrollar plan

Ofertar plan

Fin de construcción

Trabajar el plan Negociar el plan()

:Certificado de ocupación[terminado]

ramas de secuencia

[no aceptado][else]

flujo de objeto

estado de actividad con submáquina

estado final

bifurcación concurrente

unión concurrente

estado de la acción

Diagrama de Actividades

• Es un tipo especial de diagrama de estado que muestra el flujo de actividades dentro de un sistema. Son especialmente impor tantes al mode lar el funcionamiento de un sistema pues resaltan el flujo de control entre objetos.


hallar.exe

índice.html

hallar.html

accesoBd.dll busca.dll

<<hiperenlace>>

ejecutablepágina web

librería

componente

Diagrama de Componentes

• Muestra la orga nización y las dependencias entre un conjun to de componen tes. Presentan la vista estática de implementación del sistema.


<<processor>>servidorprimario

<<processor>>servidor



<<network>> red local

<<processor>>servidor de

caché

<<processor>>servidor de

caché nodo

conexión

internet Modem

nodo

Diagrama de Despliegue

• Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.


Mecanismos comunes del modelo conceptual de UML

• Especificaciones– Proporcionan una base semántica para cada

elemento– Los diagramas son proyecciones de esa base

• Adornos– La notación gráfica básica de cada elemento puede

incluir adornos textuales o gráficos para resaltar algunas propiedades de la especificación.


• Divisiones Comunes– Dicotomía clasificador

/instancia

Persona

nombre

dirección

teléfonoElena :

Persona

: Persona

Elena

• Divisiones Comunes– Dicotomía interfaz /

implementación

IOrtografía

asistente

Ortográfico.dll


Mecanismos de extension del modelo conceptual de UML

• Mecanismos de extensibilidad– Estereotipos

• Extienden el vocabulario de UML, permitiendo añadir nuevos tipos de bloques de construcción.

– Valores etiquetados• Extienden las propiedades de un bloque de

construcción, añadiendo nueva información.


– Restricciones• Extiende la semántica de un bloque, añadiendo reglas

o modificando las existentes.

Overflow<<Exception>>

ColaEventos {version 3.2; autor: jgm}

añadir()

quitar()

vaciar()

{ordenado}

estereotipovalor etiquetado

restricción


Sistema, modelo, vista, diagrama• Un sistema es aquello que se está desarrollando y

para lo que se crean modelos.• Un subsistema es una parte de un sistema.• Un modelo es una abstracción de un sistema que

ayuda a comprenderlo.• Una vista es una proyección de la estructura y

organización de un modelo del sistema, centrada en algún aspecto.

• Un diagrama es una representación de un conjunto de elementos.


Vistas UML en términos de Elementos

Vista de DiseñoVista de Implementación



clasesinterfacescolaboraciones componentes

nodosclases activas

casos de uso


Vistas UML en términos de Diagramas

Vista de DiseñoVista de Implementación



Diagramas de claseDiagramas de interacciónDiagramas de estado

Diagramas de componentesDiagrama de interacciónDiagramas de estado

Diagramas de despliegueDiagrama de interacciónDiagramas de estado

Diagramas de casos de uso

Diagramas de claseDiagramas de interacciónDiagramas de estado


Ejemplo: Hola mundo!

import Java.awt.Graphics;class HolaMundo extends java.applet.Applet {

public void paint (Graphics g) {g.drawString (“¡Hola, Mundo!”,10,10);

}}

HolaMundo

paint()

g.drawString

("Hola, mundo”)

Abstracción de clases para hola mundo


Applet

HolaMundo

paint () Graphics

Object

Component

Container

Panel

Applet

HolaMundo

ImageObserver

Clase relacionadasCon Holamundo

Jerarquía de laHerencia deHola mundo


java

lang

awt

AppletHolaMundo

Organización de paquetes de Holamundo


:Thread :Toolkit target:HolaMundo:ComponentPeer

runrun

handleExpose paint

callbackLoop

Mecanismo para dibujar de Holamundo


HolaMundo.classhello.java

hello.html

Componentes de Holamundo


Equipo base dedesarrollo

Pero UML no es suficiente

Unified Modeling Language

Developmentprocess


Proceso de Desarrollo de Software

• Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software.

Proceso de desarrollo de software

Requisitos delusuario

Sistema software


Un Proceso Iterativo e Incremental

• Un proceso de desarrollo de software debe tener una secuencia de hitos claramente articulados para ser eficaz, que proporcionen a los director y al resto del equipo del proyecto los criterios que necesitan para autorizar el paso de una fase a la siguiente dentro del ciclo del producto.

• Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.


• Un proceso incremental es aquel que involucra la continua integración de la arquitectura del sistema para producir esos ejecutables, donde cada nuevo ejecutable incorpora mejoras incrementales sobre los otros.

• En conjunto, un proceso iterativo e incremental esta dirigido por el riesgo, lo que significa que cada nueva versión se encarga de atacar y reducir los riesgos mas significativos para el éxito del proyecto.


Lo que es una Iteración

• Una iteración es un miniproyecto (un recorrido mas o menos completo a lo largo de todos los flujos de trabajo fundamenta) que obtiene como resultado una versión interna.

• El resultado de una iteración es un incremento ( un in cremento es la diferencia entre la versión interna de una iteración y la versión interna de la siguiente).

• Los modelos evolucionan con las iteraciones ( construyen los modelos incremento por incremento).


Las Iteraciones sobre el ciclo de vida

• Las iteraciones se realizan en cuatro fases.• Cada una de las cuatro fases termina con un hito

principal.– Inicio: Objetivos del ciclo de vida.– Elaboración: arquitectura del ciclo de vida. – Construcción: Funcionalidad operativa inicial.– Transición : versión del producto



¿Por qué un Desarrollo Iterativo e Incremental?

• Para tomar la rienda de los riesgos críticos y significativos desde el principio.

• Para poner en marcha una arquitectura que guíe el desarrollo del software.

• Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos.


• Para construir el sistema a lo largo del tiempo en lugar en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso.

• Para proporcionar un proceso de desarrollo a través del cual el personal pueda trabajar de manera mas eficaz.

En resumen: “para obtener un software mejor”


Fases del Ciclo de vida

time

Inicio Elaboración Construcción Transición

• Inicial: define el alcance del proyecto y el límite del sistema.

• Elaboración: Plan del proyecto, características, y la línea base de la arquitectura.

• Construcción: Se construye el producto• Transición: entrega del producto al usuario


Fases e Iteraciones

Una fase es el intervalo de tiempo entre dos hitos importantes del proceso.Una iteración es una sucesión de actividades con un plan establecido y criterio de evaluación, mientras se va produciendo las versiones del sistema.

ArchIteration

... Dev Iteration

Dev Iteration

... TransIteration

...

Release Release Release Release Release Release Release Release

PrelimIteration

...

Inception Elaboration Construction TransitionElaboration Construction Transition


Creando el Proceso Unificado

Functional testingPerformance testingRequirements mgmtConf. and change mgmtBusiness engineeringData engineeringUI design

Rational Unified Process 5.01998

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995

The Ericsson Approach

The Rational Approach UML

Unified ProcessUnified Software Development Process

Iconix Unified Process

Rationa Unified Process 5.5

Desarrollo de sistemas de información

Technology