Clase 1 Y 2 Introducción

Ing. Juan Carlos Carreño Gamarra

IS 453 Ingeniería de Software

INTRODUCCIÓN

La primera referencia que describe ampliamente el

procedimiento de la Ingeniería de Sistemas fue publicada

en 1950 por Melvin J. Kelly.

En opinión de Arthur D. Hall, "la función de Ingeniería de

Sistemas se había practicado durante muchos años en las

Organizaciones”.

¿Qué es ingeniería de SW?

“La aplicación de un enfoque sistemático,

disciplinado y cuantificable hacia el desarrollo,

operación y mantenimiento del Software, es

decir, la aplicación de la ingeniería al Software”

[IEEE]

Niveles de la Ingeniería de Software

Procesos de desarrollo de SW.

Ciclo de vida: Sucesión de etapas por las que atraviesa un producto software a lo largo de su desarrollo y existencia.

Existen distintas formas o paradigmas de ciclo de vida: Secuencial, cascada.

Orientado a prototipos

Evolutivo Incremental

Espiral

Componente


Secuencial

•Comprender la naturaleza del dominio.

•Especificación de los requisitos

•Estructura de datos

•Arquitectura de SW

•Representaciones de la Interfaz

•Algoritmos

•Construcción del SW. En base al diseño

•Prueba de procesos lógicos internos.

•Pruebas funcionales

Análisis Prueba Diseño Código


Cascada

Análisis

Diseño

Codificación y pruebas unitarias

Integración del sistema

Operación y mantenimiento


Prototipos

Mecanismo de especificación de requisitos.

Cuando solo se tienen requisitos muy generales por parte del cliente, es práctico utilizar este paradigma.

Sistemas muy complejos de entender.

Prototipear consiste en construir una versión inicial de un producto, en la cual se describe la interacción hombre-máquina sin implementar completamente la funcionalidad del sistema (prototipo sin funcionalidad).


Prototipos

Utilidad:

Ayuda a los analistas a establecer las

necesidades del cliente.

Ayuda a los desarrolladores a mejorar

los productos.

Ciclo que primero, revisa los

requerimientos del cliente. Luego, se

construye un prototipo y finalemnte el

cliente lo prueba, para iniciar

nuevamente el ciclo.


Prototipos

Clases de prototipos:

Vertical: desarrolla completamente algunas de las facetas del

producto.

Horizontal: desarrolla parcialmente todas las facetas del

producto.

Evolutivo: La versión final es el producto ya construido.

Desechable: Se usa sola para la captación de requerimientos y

funcionalidad.


Modelos evolutivos

Modelos evolutivos son iterativos.

Permite al equipo de desarrollo generar versiones mas

completas del software.

Tipos de modelos:

Incremental

Espiral

Ensamblaje de componentes


Modelos evolutivos: Incremental

Los riesgos asociados en el desarrollo de grandes

sistemas son altos.

Construir solo una parte del sistema, dejando otras

funciones para futuras versiones.

Requerimientos

Desarrollo Primera versión

Desarrollo Segunda versión

Requerimientos

Desarrollo Primera versión

Desarrollo Segunda versión

Requerimientos

Modelos evolutivos: Espiral

Espiral se divide en 6 regiones, llamadas

regiones de tarea.

1. Comunicación con el cliente

2. Planificación

3. Análisis de riesgo

4. Ingeniería

5. Construcción y adaptación

6. Evaluación del cliente


Modelos evolutivos: Espiral


Modelos evolutivos: Componentes

Más adecuado para la construcción de SW orientado a

objeto.

Orientación a objetos encapsula datos y métodos.

Centrado a la construcción de componentes que no están

en una biblioteca de clases.

Si el componente no existe se sigue un paradigma de

desarrollo.


Modelos evolutivos: Componentes


RUP: Rational Unified Process

Proceso de desarrollo propuesto por Rational

basado en buenas prácticas.

Consiste en un conjunto de templates, blueprints

y documentación que cubren todo el proceso de

desarrollo.

Metodologías de Análisis y Diseño

(OOA/OOD)

Booch (OOAD)

Rumbaugh (OMT)

Jacobson (OOSE)

UML (Unified Modelling Language)

Lenguaje visual

Unión de los tres anteriores

Estándar internacional (OMG)

Versión actual: 2.0

UP (Unified Process)

Metodología de diseño iterativo

Basada en casos de uso

Incorpora UML de forma natural

OOAD (Booch)

Tipos de relaciones

Herencia o Generalización

Agregación o Composición

Asociación

Metaclase

Instanciación (plantillas)

Cliente-Servidor (acceso)

OOAD (Grady Booch)

Clases ordinarias

Metaclases

Categorías de clases

Clases parametrizadas (plantillas)

Clases instanciadas (plantillas)

Utilidades de clase: subprogramas libres y clases estáticas

Tipos de clases

Partes de UML

Vistas

Conjunto de diagramas

Diagramas

9 tipos de grafos

Combinan los elementos del modelo

Elementos del modelo

Clases, objetos, mensajes, relaciones

Mecanismos generales

Comentarios, información, semántica, extensiones y

adaptaciones

VISTAS

Vista de Casos de Uso

Funcionalidad externa del sistema

Vista Lógica

Estructura estática y conducta dinámica del sistema

Vista de Componentes (software)

Organización de las componentes

Vista de Concurrencia

Comunicaciones y sincronización

Vista de Despliegue (deployment)

Arquitectura física

Las Vistas en UML

Casos uso

lógica

comp

despliegue

Conc

Vista de Casos de Uso

Dirigida al Análisis de Requisitos (lo que quiere hacer el usuario)

Describe la funcionalidad del sistema, como la perciben los actores externos

Dirige el desarrollo de las otras vistas

Define los objetivos finales del sistema

Permite validar el sistema

Actor externo:

Usuario

Otro sistema

Se plasma en diagramas

de Casos de Uso

de Actividad

Vista Lógica

Describe la funcionalidad interna

Dirigida a diseñadores y desarrolladores

Define la estructura estática

Clases, objetos y relaciones

Define las colaboraciones dinámicas

Mensajes y funciones

Propiedades adicionales

Persistencia y concurrencia

Interfaces y estructura interna de las clases

Vista Lógica


Estáticos

de Clases

de Objetos

Dinámicos

de Estado

de Secuencia

de Colaboración

de Actividad

Vista de Componentes

Describe los módulos del sistema y sus

dependencias

Dirigida a desarrolladores


de Componentes

Vista de Concurrencia

Describe la división del sistema en procesos y procesadores

Dirigida a desarrolladores e integradores

Resuelve problemas de

uso eficiente de los recursos

ejecución en paralelo (hilos)

comunicación y sincronización de hilos


dinámicos

de Componentes

de Despliegue

Vista de Despliegue

Muestra la distribución física del sistema

(ordenadores, dispositivos) y sus conexiones

Dirigida a desarrolladores, integradores y

probadores

Se plasma en

el diagrama de Despliegue

el mapa de asignación de componentes a la

arquitectura física

Tipos de Diagramas

De Casos de Uso

Estáticos

de Clases

de Objetos

Dinámicos

de Estado

de Secuencia

de Colaboración

de Actividad

De Componentes

De Despliegue (deployment)

ANALISIS Es un conjunto o disposición de procedimientos o programas

relacionados de manera que juntos forman una sola unidad.

Un conjunto de hechos, principios y reglas clasificadas y dispuestas

de manera ordenada mostrando un plan lógico en la unión de las

partes.

Un método, plan o procedimiento de clasificación para hacer algo.

ANALISIS DE SISTEMAS

El análisis de sistemas es el estudio de una aplicación del sistema de

información y de empresa actual y la definición de las necesidades y las

prioridades de usuario para conseguir una aplicación nueva o mejorada

Función del ANALISIS La función del Análisis puede ser dar soporte a las actividades de

un negocio, o desarrollar un producto que pueda venderse para

generar beneficios.

1. Software.

2. Hardware,

3. Personal

4. Base de Datos

5. Documentación

6. Procedimientos

Objetivos del Análisis

1. Identificación de las necesidades del Cliente.

Algunos autores suelen llamar a esta parte ¨ Análisis de

Requisitos ¨ y lo dividen en cinco partes:

Reconocimiento del problema.

Evaluación y Síntesis.

Modelado.

Especificación.

Revisión.


2. Estudio de Viabilidad

Evalúe que conceptos tiene el cliente del sistema para establecer su

viabilidad.

Viabilidad económica.

Viabilidad Técnica.

Viabilidad Legal.


3. Análisis Técnico y económico.

El Análisis económico incluye lo que se conoce

como, el análisis de costos – beneficios.

En el Análisis Técnico, el Analista evalúa los

principios técnicos del Sistema.


4. Modelado de la arquitectura del Sistema

Todos los Sistemas basados en computadoras pueden

modelarse como transformación de la información

empleando una arquitectura del tipo entrada y salida.


5. Especificaciones del Sistema

Describe la función y rendimiento de un Sistema

basado en computadoras y las dificultades que estarán

presente durante su desarrollo

DISEÑO DE SISTEMAS

El Diseño de Sistemas se define como el proceso de aplicar

ciertas técnicas y principios con el propósito de definir un

dispositivo, un proceso o un Sistema, con suficientes detalles

como para permitir su interpretación y realización física.

ETAPAS DEL DISEÑO

El Diseño de los datos.

El Diseño Arquitectónico.

El Diseño de la Interfaz.

El Diseño de procedimientos.

OTROS ELEMENTOS DEL DISEÑO

Diseño de Salida.

Diseño de Archivos.

Diseño de Interacciones con la Base de Datos.

Herramientas para el Diseño de Sistemas.

Herramientas de especificación.

Herramientas para presentación.

Herramientas para el desarrollo de Sistemas.

Herramientas para Ingeniería de Software.

Generadores de códigos.

Herramientas para pruebas.

Proyecto de Sistema o Software.

Es el Proceso de gestión para la creación de un

Sistema o software, la cual encierra un conjunto de

actividades, una de las cuales es la estimación,

Objetivos de la Planificación del

Proyecto.

El objetivo de la Planificación del proyecto de Software

es proporcionar un marco de trabajo que permita al

gestor hacer estimaciones razonables de recursos costos

y planificación temporal.

Actividades asociadas al proyecto

de software

1. Ámbito del Software.

En esta etapa se evalúa la función y el rendimiento que se

asignaron al Software durante la Ingeniería del Sistema de

Computadora para establecer un ámbito de proyecto que

no sea ambiguo, e incomprensible para directivos y

técnicos

2. Recursos

Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de

un proyecto de software solo puede ser determinado

después de hacer una estimación del esfuerzo de

desarrollo

Recursos o componentes de software

reutilizables.

Se debe estudiar la reutilización, esto es la creación y la

reutilización de bloques de construcción de Software.

El Autor Bennatan sugiere cuatro categorías de recursos de

software que se deberían tener en cuenta a medida que se avanza

con la planificación:

Componentes ya desarrollados.

Componentes ya experimentados.

Componentes con experiencia Parcial.

Componentes nuevos.

Recursos de entorno.

El entorno es donde se apoya el proyecto de Software,

llamado a menudo entorno de Ingeniería de Software,

incorpora Hardware y Software.

3. ESTIMACION DEL PROYECTO DE SOFTWARE.

Para realizar estimaciones seguras de costos y esfuerzos

tienen varias opciones posibles:

Deje la estimación para mas adelante

Base las estimaciones en proyectos similares ya

terminados.

Utilice técnicas de descomposición relativamente

sencillas.

Desarrolle un modelo empírico para él calculo de

costos y esfuerzos del Software.

DIFERENTES MODELOS DE

ESTIMACION.

Los Modelos Empíricos

Donde los datos que soportan la mayoría de los

modelos de estimación obtienen una muestra

limitada de proyectos.

El Modelo COCOMO. Barry Boehm, en su libro clásico sobre economía de la

Ingeniería del Software, introduce una jerarquía de modelos

de estimación de Software con el nombre de COCOMO, por

su nombre en Ingles (Constructive, Cost, Model) modelo

constructivo de costos.

JERARQUÍA DE MODELOS DE

BOEHM

Modelo I. El Modelo COCOMO básico calcula el esfuerzo y

el costo del desarrollo de Software en función del tamaño del programa,

expresado en las líneas estimadas.

Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del

desarrollo de software en función del tamaño del programa y de un

conjunto de conductores de costos que incluyen la evaluación subjetiva del

producto, del hardware, del personal y de los atributos del proyecto.

JERARQUÍA DE MODELOS DE

BOEHM

Modelo III. El modelo COCOMO avanzado incorpora

todas las características de la versión intermedia y lleva a cabo una

evaluación del impacto de los conductores de costos en cada caso

(análisis, diseño, etc.) del proceso de ingeniería de Software.

Orientado a Objetos

En la programación convencional los datos asumen

cualquier estructura y los procesos hacen de los datos

todo lo que el programador desee.

En el mundo orientado a objetos las estructuras de datos

se relacionan con los objetos y sólo pueden ser utilizadas

mediante los métodos diseñados para ese tipo de objeto.

En las técnicas orientadas a objetos con herramientas

CASE, el diseñador piensa en términos de objetos y su

comportamiento.

Se construyen tipos de objetos a partir de tipos de

objetos más sencillos. Una vez que los tipos de objetos

funcionan bien, el diseñador los considera como cajas

negras de modo que nadie pueda ver su interior.

LA VERDADERA INGENIERIA DEL

SOFTWARE

El software se vende no cuando está libre de errores. sino

cuando éstos aparecen con una frecuencia bastante baja.

Cuando un programa para hojas de cálculo se sale de control

sólo tiene un código de 400.000 líneas. Muy pronto se

utilizara software con 50 millones de líneas de código.

BENEICIOS DE LAS TECNICAS OO Reutilización

Estabilidad

El diseñador piensa en términos del comportamiento de objetos y no en detalle de bajo nivel.

Se construyen clases cada vez más complejas

Un diseño más rápido

Mantenimiento mas sencillo

Mejores Herramientas CASE

Problemas actuales en el desarrollo de

SW

El desarrollo de software es un negocio riesgoso.

Muchas historias de fracaso [Larman] 31 % Proyectos no se concluyen

53 % Rebasa en un 200% el costo estimado

Carencia de estándares.

Dificultad en la estimación de costos.

Poca reutilización de código.

Proceso no definido.


SW

Curva típica de fallos de Software [Pressman].

Ín

dic

e d

e f

all

os

Tiempo

Cambio

Curva Real

Curva Ideal

Incremento del

índice de fallos

por efectos

laterales


SW

El impacto del cambio [Pressman]

Co

sto

s d

el

ca

mb

io

Fase

Definición Desarrollo Después de la

entrega

1 x

1.5 -6

60-100 x

Mitos del Software [Pressman]

Mitos de Gestión

Mito 1: Tenemos un libro lleno se estándares y procedimientos para construir software. Mi gente ya tiene todo para hacer lo que tiene que hacer. Saben que existe?, lo usan?, es completo?. Experiencia es

también valiosa.

Mito 2: Tenemos todo lo que necesitamos, HW y SW de última generación. El desarrollo implica mucho mas que herramientas.

Mitos de Gestión

Mito 3: Si fallamos en la planificación, agregamos

más programadores y asunto solucionado.

En general mas gente agrega más caos no mas

eficiencia.


Mitos del cliente

Mito 1: Una declaración general de los objetivos es suficiente para comenzar a escribir programas, los detalles se dejan para más adelante. Una mala definición inicial es la principal causa de la pérdida de

trabajo en SW.

Mito 2: Los requisitos del proyecto cambian continuamente, pero estos pueden acomodarse fácil puesto que el software el flexible. El impacto del cambio varía según en el momento que se

introduzca.

Mitos del cliente

Mito 3: No es necesario involucrarse en el diseño del

SW. Basta con dar las especificaciones y ver los resultados

finales.


Mitos del desarrollador

Mito 1: Una vez que escribimos el programa y hacemos que funcione nuestro trabajo ya está hecho.

-Cuanto más pronto se comience a escribir código, más se tardará en terminarlo.

Mito 2: Hasta que no tengo el programa ejecutándose, realmente no tengo forma de comprobar su calidad.

Existen mecanismos efectivos para ser aplicados desde el principio del proyecto durante todas las fases.

Mitos del desarrollador

Mito 3: Lo único que se entrega al terminar el proyecto es el

programa funcionando.

Un parte fundamental para la mantención es la

documentación.

ANÁLISIS Y DISEÑO OO

Es identificar el dominio del problema y su solución lógica dentro de la perspectiva de la Orientación a Objetos.

Análisis Orientado a Objeto: Identificar y definir los objetos (conceptos) dentro del dominio del problema.

Diseño Orientado a Objetos: Definir los objetos lógicos de Software (con atributos y métodos) que serán programados el un lenguaje de programación idóneo.

Diferencia con el modelo estructurado: El análisis y diseño estructurado son orientado a los procesos.

Características Importantes del AyD OO

1. Cambian nuestra forma de pensar sobre los sistemas.

2. Los usuarios finales y las personas de las empresas piensan de manera natural en términos de objetos, eventos y mecanismos de activación ( triggers).

3. Los sistemas suelen construirse a partir de objetos ya existentes.

4. La complejidad de los objetos que podemos utilizar sigue en aumento puesto que nuevos objetos se construyen a partir de otros.

5. El depósito CASE debe contener una creciente biblioteca de tipos de objetos, algunos comprados y otros construidos en casa.

6. La creación de sistemas con un funcionamiento correcto es más fácil con las técnicas OO.

7. Las técnicas 00 se ajustan de manera natural a la tecnología CASE.

CICLO DE VIDA DEL SOFTWARE

Ciclo tradicional

Modelo en cascada

Análisis (qué)

Diseño (cómo)

Codificación (hacerlo)

Pruebas (¿funciona?)

Mantenimiento

CICLO DE VIDA DEL SW

Requisitos del usuario Sistema de software Proceso de desarrollo de software

Proceso de desarrollo de software: Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo

(quién hace qué, cuándo y cómo).

Objetivos: Asegurar la producción de software de calidad dentro de plazos

y presupuestos predecibles.

PROCESO DE DESARROLLO

DE SOFTWARE:


DE SOFTWARE Planificación Construcción Aplicación

Ciclo de Ciclo de . . .

desarrollo 1 desarrollo 2

Perfeccionar

plan Análisis Diseño Construcción Pruebas

De dos semanas a dos meses


DE SOFTWARE

Ciclo de Ciclo de Ciclo de . . .

desarrollo 1 desarrollo 2 desarrollo 3

Caso de uso A:

Versión

simplificada

-------

-------

Caso de uso A:

Versión

completa

-------

-------

Caso de uso B

-------

-------

-------

-------

Caso de uso C

-------

-------

-------

-------


DE SOFTWARE

Planificación Construcción Aplicación

Ciclo de Ciclo de . . .

desarrollo 1 desarrollo 2

Perfeccionar


De dos semanas a dos meses

ANÁLISIS OO

Perfeccionar


Definir los

requisitos

Definir los casos

esenciales de uso

Crear diagramas

de casos de uso

Crear modelo

conceptual

Crear el

glosario

Definir diag.

de secuencia

Definir los

contratos

Algunas de las tareas a realizarse en la etapa de análisis

(dominio del problema) son las siguientes:

DISEÑO OO

Perfeccionar


Definir casos

reales de uso

Definir reportes,

interfaz de usuario,

secuencia de pantallas

Perfeccionar la

arquitectura

Definir diag.

de interacción Definir diagramas

diseño de clases

Definir esquema

base de datos

Algunas de las tareas a realizarse en la etapa de diseño

(dominio de la solución) son las siguientes:

Lenguajes y herramientas OO Lenguajes de programación más comunes que soportan la Orientación a

Objetos: Java

C ++

C #

Plataforma .net

Smalltalk

Herramientas case: Rational Rose.

Poseidon (Profesional Edition)

Herramientas de modelado Visio 2002

Umbrella (Open Source)

Poseidon (Comunity Edition)

Clase 1 Y 2 Introducción

Documents

Transcript of Clase 1 Y 2 Introducción