SESION 1

UNIVERSIDAD PERUANA LOS

ANDES

FACULTAD DE INGENIERÍA

CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS

INGENIERÍA DE SOFTWARE

Docente: Mg. Ing. Angel Fernando Navarro Raymundo

SESIÓN

01

Presentación

• Asignatura : Ingeniería de Software

• Horario : Martes 6:00 a 8:15 pm.

y Viernes 6:00 a 7:30 pm.

• Docente : Mg. Ing. Angel Fernando Navarro Raymundo

• Contenido: 4 unidades

Ingeniería de Software - Mg. Ing. Angel F. Navarro Raymundo

Contenido

METODOLOGIAS DE DESARROLLO DE SOFTWARE

GESTION DE PROYECTOS DE TI

PRUEBAS Y MANTENIMIENTO DEL SOFTWARE

TOPICOS AVANZADOS DE INGENIERIA DE SOFTWARE


METODOLOGIAS DE

DESARROLLO DE

SOFTWARE

Ingeniería de Software Sesión 1

Mg. Ing. Angel Fernando Navarro Raymundo

AGENDA

1. Definición de Ingeniería de Software.

2. Historia de la Ingeniería de Software.

3. Proceso de Ingeniería de Software.

4. Elementos de la Ingeniería de Software.

5. Herramientas CASE. .


Definición de Ingeniería de Software

El termino Ingeniería de Software fue acuñado en 1969 en el transcurso de un curso de verano de la OTAN en Garmisch. Disciplina o área de la Ingeniería que ofrece métodos y técnicas para desarrollar y mantener software.


Definición de Ingeniería de Software • Ingeniería de Software trata del establecimiento de los principios y métodos de la

ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).

• Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976).

• Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)

• Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

Según Alan Davis como “la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios”…


Historia de la Ingeniería de Software

La era pionera

De 1945 a 1965: Los orígenes

De 1965 a 1985: La Crisis del Software

De 1985 a 1989: No hay balas de plata. Proyectos de software

De 1990 a 1999: Prominencia de Internet

De 2000 en adelante: Metodologías ligeras

Tendencias actuales en la ingeniería de

software

La ingeniería de software hoy

1940 2013

Software Engineering Body of Knowledge SWEBOK ha sido presentado como un estándar ISO durante 2006 (ISO/IEC TR 19759)

• Aspectos • Ágil • Experimenta • Model-driven • Líneas de productos de

software


Figuras prominentes en la historia Charles Bachman (nacido en 1924) es particularmente conocido por su trabajo en el área de bases de datos. Laszlo Belady (nacido en 1928) el editor en jefe de la IEEE Transactions on Software Engineering en la década de 1980 Fred Brooks (nacido en 1931) conocido por el desarrollo del OS/360. Peter Chen conocido por el desarrollo del modelo entidad-relación. Edsger Dijkstra (1930–2002) desarrolló el marco para la programación adecuada. David Parnas (nacido en 1941) desarrolló el concepto de ocultamiento de información en la programación modular. Michael A. Jackson (nacido en 1936) experto en Ingeniería de software responsable del método de diseño de programa JSP; el método de desarrollo de sistema JSD (con John Cameron); y marcos de problema para el análisis y estructuración de los problemas de desarrollo de software. Ingeniería de Software - Mg. Ing. Angel F.

Navarro Raymundo

http://es.wikipedia.org/wiki/Charles_Bachman

http://es.wikipedia.org/wiki/Charles_Bachman

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/w/index.php?title=Laszlo_Belady&action=edit&redlink=1



http://es.wikipedia.org/wiki/Fred_Brooks

http://es.wikipedia.org/wiki/OS/360

http://es.wikipedia.org/wiki/Peter_Chen

http://es.wikipedia.org/wiki/Peter_Chen

http://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n



http://es.wikipedia.org/wiki/Edsger_Dijkstra



http://es.wikipedia.org/w/index.php?title=David_Parnas&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=David_Parnas&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Ocultamiento_de_informaci%C3%B3n&action=edit&redlink=1

http://es.wikipedia.org/wiki/Programaci%C3%B3n_modular

http://es.wikipedia.org/w/index.php?title=Michael_A._Jackson&action=edit&redlink=1

Proceso de Ingeniería de Software Proceso Es un conjunto de actividades interrelacionadas que transforman entradas en salidas. (ISO 12207/UNE 77104). Proceso de Ingeniería de Software Es un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir, desarrollar, instalar y mantener un producto software. (Fugetta, 2000).


Proceso de Ingeniería de Software

Conjunto estructurado de actividades requeridas para desarrollar un software.

• Especificación: que debe hacer el software y cuales son sus

especificaciones de desarrollo.

• Desarrollo: producción del sistema de software.

• Validación: verificar que el software hace lo que el cliente pide.

• Evolución: cambiar/adaptar el software a las demandas

• Especificación: Establecer los requerimientos y restricciones del sistema.

• Diseño: Producir un modelo en papel del sistema.

• Manufactura: Construir el sistema.

• Prueba: Verificar que el sistema cumpla con las especificaciones

requeridas.

• Instalación: Entregar el sistema al usuario y asegurar su operacionalidad.

• Mantenimiento: Reparar fallos en el sistema.


Lo que el director

desea

Cómo lo define el

director de proyecto Cómo se diseña el

sistema

Cómo lo desarrolla el

programador

Cómo se ha realizado la

instalación Lo que el usuario

quería

Desarrollo de Software


• Entendible

¿Se encuentra el proceso bien definido y es entendible? .

• Visible

¿El proceso es visible al exterior ?

• Aceptable

¿El proceso es aceptado por aquellos involucrados en el ?

• Confiable

¿Los errores del proceso son descubiertos antes de que se conviertan en errores del producto?

• Robusto

¿Puede continuar el proceso a pesar de problemas inesperados?

• Mantenible

¿Puede el proceso evolucionar para cumplir con los objetivos organizacionales?

• Rapidez

¿Qué tan rápido puede producirse el sistema ?

Características del Proceso del Software


Un modelo de ciclo de vida define el estado de las fases a través de las

cuales se mueve un proyecto de desarrollo de software.

“Una aproximación lógica a la adquisición, el suministro el desarrollo, la

explotación y el mantenimiento del software”.

IEEE 1074

“Un marco de referencia que contiene los procesos, las actividades y las

tareas involucradas en el desarrollo, la explotación y el mantenimiento de un

producto de software, abarcando la vida del sistema desde la definición de los

requisitos hasta la finalización de su uso”

ISO 12207

Ciclo de Vida de Software.


“Establece un marco de referencia común para los procesos del ciclo de vida del software, con una terminología bien definida,

que puede ser referenciada por la industria del software”.

• Define los procesos, actividades (que forman cada proceso) y tareas (que constituyen cada actividad) presentes en la adquisición, suministro, desarrollo, operación y mantenimiento del software. • Según esta norma, un proceso es un conjunto de actividades interrelacionadas que transforman entradas en salidas. Un proceso define quién, qué, cuándo, y cómo, para alcanzar un determinado objetivo.

ISO 12207

ISO/IEC 12207: Information Technology / Software Life Cycle Processes. 1995.


Procesos del Ciclo de Vida - ISO 12207


Ciclos de Vida Tradicionales (Modelos)

• Modelo Cascada (Bennington 1956) • Modelo V (Ministerio de Defensa de Alemania, 1992): • Modelo Incremental • Modelo prototipo Gomaa en 1984 • Modelo en Espiral Barry Boehm en 1988 • MODELOS PARA DESARROLLO DE SISTEMAS ORIENTADOS A OBJETOS

• MODELO FUENTE Henderson-Sellers Edwars 1990 • MODELO CLUSTER (Meyer 1990)

Ingeniería de Software - Mg. Ing. Angel F.

Navarro Raymundo

Modelo Cascada (Bennington 1956):

El más conocido, esta basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades.

Ingeniería y Análisis

del Sistema

Análisis de

los Requisitos

Diseño

Codificación

Prueba

Mantenimient

o

Desventajas: • No refleja realmente el proceso de desarrollo del software • Se tarda mucho tiempo en pasar por todo el ciclo • Perpetua el fracaso de la industria del software en su comunicación

con el usuario final • El mantenimiento se realiza en el código fuente • Las revisiones de proyectos de gran complejidad son muy difíciles • Impone una estructura de gestión de proyectos


Modelo V (Ministerio de Defensa de Alemania, 1992):

El Modelo V tiende a ser muy relacionado con el Modelo de Cascada puesto que es una evolución del mismo.

ANALISIS DE

REQUERIMIENT

OS

DISEÑO

DEL

SISTEMA

DISEÑO

DETALLAD

O

IMPLEMENTACIO

N

DE PROGRAMAS

Y

PRUEBA

UNITARIA

PRUEBA

DEL

SISTEMA

PRUEBA

DE

ACEPTACI

ON

OPERACION

Y

MANTENIMIENTO

PRUEBA DE

INTEGRACIO

N

Plan de

Pruebas

de

Integración

Verificar diseño

Plan de

Pruebas

del Sistema

Validar requerimientos

Plan de

Pruebas

de

Aceptación

Los planes de prueba son

el nexo entre el desarrollo

y la verificación

Desventajas: • El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de

aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación, lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero.

• El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir.

• Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.


Desventajas • Se evitan proyectos largos y se entrega

“Algo de valor” a los usuarios con cierta frecuencia

• El usuario se involucra más • Difícil de evaluar el coste total • Difícil de aplicar a sistemas

transaccionales que tienden a ser integrados y a operar como un todo

• Requiere gestores experimentados • Los errores en los requisitos se

detectan tarde. • El resultado puede ser muy positivo

Modelo Incremental

En este modelo se desarrolla el sistema para satisfacer un subconjunto de requisitos especificados y en posteriores versiones se incrementa el sistema con nuevas funcionalidades que satisfagan mas requisitos


Desventajas • El cliente puede quedar convencido con las

primeras versiones y, quizás, no vea la necesidad de completar el sistema o rediseñarlo con la calidad necesaria.

• Requiere trabajo del cliente para evaluar los distintos prototipos y traducirlo en nuevos requisitos

• Requiere un tiempo adicional para definir adecuadamente el sistema

• No se sabe exactamente cuánto será el tiempo de desarrollo ni cuantos prototipos se tienen que desarrollar

• Si un prototipo fracasa, el coste del proyecto puede resultar muy caro

Modelo prototipo Gomaa en 1984. Es un método normal para el desarrollo de nuevas

aplicaciones produce mejores sistemas y con costes más bajos.


Modelo en Espiral Barry Boehm en 1988.

En la que cada bucle o iteración (acción de repetir una serie

de pasos un cierto número de veces). representa un

conjunto de actividades.

Desventajas. • Requiere una considerable

habilidad para reconocer los riesgos.

• Si no se detectan los riesgos a tiempo, surgirán problemas.

• Es nuevo y no se ha utilizado tanto como otros modelos.

• Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.


MODELOS PARA DESARROLLO DE SISTEMAS ORIENTADOS A OBJETOS

MODELO FUENTE Henderson-Sellers Edwars 1990

• Es el mas conocido en el desarrollo Orientado a Objetos. Presenta alto grado de solapamiento/iteración entre fases. Cada clase/agrupamiento tiene un ciclo de vida propio. La “piscina sw” (repositorio de clases) refleja reutilización: el ciclo de desarrollo “brota” de la piscina sw.


MODELO CLUSTER (Meyer 1990)

Cluster: Conjunto de clases relacionadas con un objetivo común.

Cada subciclo de vida: Especificación, Diseño y Realización, Validación y Generalización.


CONSIDERACIONES SOBRE MODELOS OO ™ • Se eliminan fronteras entre fases debido a la naturaleza

iterativa del desarrollo orientado al objeto. • ™Aparece una nueva forma de concebir los lenguajes de

programación y su uso al incorporarse bibliotecas de clases y otros componentes reutilizables.

• ™Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo muy dinámica



1. Métodos o técnicas: Indican como construir técnicamente el software.

2. Herramientas: Proporcionan un soporte para el proceso y los métodos del desarrollo del

software.

3. Procedimientos: Define una forma de trabajo para un conjunto de áreas claves.

4. Enfoque de Calidad: Son la base o cimientos de la Ingeniería de Software.

Elementos de la Ingeniería de Software


Herramientas CASE (Computer Aided Software Engineering).

Desde principios de la década de 1990, los analistas empezaron a beneficiarse de las herramientas de productividad, denominadas herramientas de ingeniería de Software Asistida por Computadora (CASE, Competer-Aided Software Engineering), que se crearon explícitamente para mejorar su trabajo rutinario mediante apoyo automatizado.

Uso de herramientas case Son instrumentos o sistemas automatizados para realizar algo de la mejor manera posible. Esta manera óptima puede significar que la herramienta produce resultados más exactos, más eficientes, más productivos, o que refuerza la calidad del producto resultante. Proporcionan un soporte automático o semiautomático para todas las fases del desarrollo y sistemas que integran las herramientas de cada fase de manera que sirven para todo el proceso. Estas herramientas se denominan CASE.

RAZONES PARA EL USO DE LAS HERRAMIENTAS CASE

• Mejora de la comunicación analista-usuario.

• Integración de las actividades del ciclo de vida.

• Evaluar de manera precisa los cambios en el mantenimiento.


HERRAMIENTAS CASE DE ALTO NIVEL

• Una herramienta CASE de alto nivel da al analista la posibilidad de crear y modificar el diseño del sistema. Toda la información relacionada con el proyecto se almacena en una enciclopedia denominada deposito CASE, una enorme colección de registros, elementos, diagramas, pantallas, informes e información diversa Con la información del deposito se podrían generar informes que muestren donde esta incompleto el diseño o donde contiene errores.

• Las herramientas CASE de alto nivel también pueden apoyar la modelación de los requerimientos funcionales de una organización, ayudar a los analistas y usuarios a definir el alcance de un proyecto determinado y a visualizar la forma en que el proyecto se combina con otras partes de la organización. Además, algunas herramientas CASE de alto nivel pueden ayudar en la creación de prototipos de diseños de pantallas e informes


HERRAMIENTAS CASE DE BAJO NIVEL

• Las herramientas CASE de bajo nivel se utilizan para generar código fuerte de computadora, eliminando así la necesidad de programar el sistema. La generación de código tiene varias ventajas.


CICLO DE VIDA DE DESARROLLO DE SISTEMAS TRADICIONAL VS. CASE

Las partes de codificación, prueba y

depuración del programa se han

eliminado en el ciclo de vida CASE.


INGENIERIA INVERSA Y REINGENIERIA DE SOFTWARE

• Son métodos para alargar la vida de programas anteriores, conocidos como software de reingeniería asistida por computadora (CARE, Competer–Assisted Reengineering) para analizar y reestructurar el código de computadora existente. En el mercado hay varios conjuntos de herramientas de ingeniería inversa.

• La ingeniería inversa es lo opuesto a la generación de código. El código fuente de la computadora es examinado, analizado y convertido en actualidades para el depósito. El primer paso de la ingeniería inversa de software es cargar, en el conjunto de herramientas el código de programa existe (tal como se haya escrito cualquier otro lenguaje de alto nivel). Según el conjunto de herramientas producen algunos o todos los elementos siguientes:


INGENIERIA INVERSA Y REINGENIERIA DE SOFTWARE


SESION 1

Documents

Transcript of SESION 1