Ingeniería de Software

Unidad I

Gestión de Proyectos de Software

El proceso de software

Tema

Semana 2

Objetivos Generales:

Comprender correcta y eficientemente los conceptos y principios del espectro de técnicas de Ingeniería de Software que puedan ser aplicadas en proyectos de software.

Desarrollar una cultura de ingeniería de software.

Objetivos Específicos:

Aplicar correctamente los conceptos y principios relacionados a la Ingeniería de Software en la resolución de casos prácticos para la gestión de proyectos de software de calidad.

Utilizar herramientas para el modelado y gestión de proyectos de software.

Utilizar metodologías agiles en el desarrollo de software.

Objetivos Instruccionales:

Discutir los conceptos de proceso de software.

Describir los modelos de proceso de software.

Explicar la importancia de la visibilidad de los procesos.

Definir y aplicar estándares para la gestión y el desarrollo de proyectos en TI

Implementación de un Robot seguidor de línea …

ESCENARIO

Capas de la Ingeniería de Software

Un enfoque de calidad

Proceso

Métodos

Herramientas

• Cualquier enfoque de Ingeniería debe apoyarse sobre un compromiso de organización de calidad.

• El proceso es la unión que mantiene juntos las capas de tecnología y que permite un desarrollo racional y oportuno de la IS.

•Los métodos indican como construir técnicamente el software (incluye análisis de requerimientos, diseño. Construcción de programas, pruebas y mantenimiento).

•Las herramientas proporcionan un enfoque automático o semiautomático para el proceso y para los métodos. La integración de herramientas, establece un sistema de soporte para el desarrollo del enfoque llamado ‘Ingeniería del software asistida por computadora’ (CASE)

Vis

ión

de

l Pro

ceso

de

I.S

.

Visión General de la Ingeniería Software

Es el análisis, diseño, construcción, verificación y gestión de entidades técnicas.

Fases genéricas: Definición

Se centra en el que:

• Información será procesada.

• Función y rendimiento se desea.

• Interfaces van a ser establecidas.

• Restricciones de diseño existen.

• Criterios de validación se necesitan para definir un sistema correcto.

Vis

ión

de

l Pro

ceso

de

I.S

.

Se centra en el como:

• Han de diseñarse las estructuras de datos.

• Ha de implementarse la función dentro de una arquitectura de software.

• Han de implementarse los detalles procedimentales.

• Han de caracterizarse las interfaces.

• Ha de traducirse el diseño en un lenguaje de programación.

• Ha de realizarse la prueba.

Visión General de la Ingeniería Software

Fases genéricas: Desarrollo

Vis

ión

de

l Pro

ceso

de

I.S

.

Se centra en el cambio que va asociado a la corrección de errores:

Tipos de cambios:

• Corrección. Dada la probabilidad de que el cliente descubra defectos.

• Adaptación. Se ajusta a los cambios de su entorno externo.

• Mejora. El usuario requiere nuevas funciones adicionales.

• Prevención. El software se deteriora debido al cambio y por esto el mantenimiento preventivo(reingeniería) debe conducir a permitir que el software sirva para las necesidades de los usuarios finales.

Visión General de la Ingeniería Software

Fases genéricas: Mantenimiento

Vis

ión

de

l Pro

ceso

de

I.S

.

Se caracteriza porque:

Es un conjunto estructurado de actividades requeridas para desarrollar un sistema de software.

Especificación. Diseño. Validación. Evolución.

Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse.

Debe estar explícitamente modelado si va a ser bien administrado.

El P

roce

so d

e S

oftw

are

Características del proceso...

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

Visible ¿El proceso es visible al exterior ?.

Soportable ¿Puede el proceso ser soportado por herramientas CASE ?.

Aceptable ¿El proceso es aceptado por aquellos involucrados en el ?.E

l Pro

ceso

de

So

ftwa

re

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 ¿Que tan rápido puede producirse el sistema ?

El P

roce

so d

e S

oftw

are

...Características del proceso

El P

roce

so d

e S

oftw

are

Niveles de Madurez del Proceso

El P

roce

so d

e S

oftw

are

Enfoques del proceso

El P

roce

so d

e S

oftw

are

Marco de trabajo del proceso…

Marco de trabajo del proceso común

• Base para un proceso de software completo• Es como un libro de recetas de cocina• La adaptación es esencial

El P

roce

so d

e S

oftw

are

…Marco de trabajo del proceso…

• Aplicables a lo largo del proceso de software• Su objetivo: la gestión, el rastreo y el control

del proyecto• Garantizar la calidad del softwareActividades de protección

Marco de trabajo del proceso común

El P

roce

so d

e S

oftw

are

…Marco de trabajo del proceso…

Actividades de protección

Marco de trabajo del proceso común

Actividades del marco de trabajo

Aplicables a todos los proyectos

El P

roce

so d

e S

oftw

are

…Marco de trabajo del proceso

Actividades de protección

Marco de trabajo del proceso común

Actividades del marco de trabajo

Conjunto de tareas: Actividades que hacen que el marco de trabajo se adapte a las características particulares de cada proyecto de software y define el trabajo real a cumplirse

TAREASHITOS,

ENTREGASPUNTOS SQA (Software Quality

Assurance)

El P

roce

so d

e S

oftw

are

Marco de trabajo genérico del proceso

Marco de trabajo del proceso común

Actividades de protección

El P

roce

so d

e S

oftw

are

¿Que involucra el desarrollo de una actividad?

ACTIVIDAD PRODUCTO

DESARROLLADOR

HERRAMIENTAS

ROL DIRECCION

tiene-sub tiene-sub

tiene-entrada

tiene-intermedio

tiene-salida

emplea

obedece

necesita

juega

RECURSOS

ORGANIZACION

El P

roce

so d

e S

oftw

are

Actividades sombrilla

Actividades de protección

El Proceso se realiza a nivel…

ConceptualSe considera como un análisis de actividades y consiste en la solución de

negocios para el usuario

LógicoTraduce los escenarios creados en el diseño conceptual en un conjunto de

objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios.

FísicoTraduce el diseño lógico en una solución implementable y costo-efectiva o

económica.

Modelo de Ingeniería del Proceso

Especificación - establecer los requerimientos y restricciones del sistema

Diseño - Producir un modelo en papel del sistemaManufactura - construir el sistemaPrueba - verificar que el sistema cumpla con las

especificaciones requeridasInstalación - entregar el sistema al usuario y asegurar

su operacionalidadMantenimiento - reparar fallos en el sistema cuando

sea descubiertos

Problemas en el Modelo de Ingeniería del Proceso

Normalmente, las especificaciones son incompletas o anómalas

No existe una distinción precisa entre la especificación, el diseño y la manufactura

Solo hasta que el sistema se ha producido se puede probar

El software no se puede reemplazar siempre durante el mantenimiento

Modelos Genéricos de Desarrollo de Software

Modelo de Cascada Separar en distintas fases de especificación y desarrollo.

Desarrollo Evolutivo La especificación y el desarrollo están intercalados.

Prototipado Un modelo sirve de prototipo para la construcción del sistema final.

Transformación Formal Un modelo matemático del sistema se transforma formalmente en la

implementación.

Desarrollo basado en Reutilización El sistema es ensamblado a partir de componentes existentes.

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are

Modelo de CascadaDefinición de

Requerimientos

Diseño del Softwarey del Sistema

Implementación yPrueba de unidades

Integración y Prueba del Sistema

Operación yMantenimientoM

od

elo

s d

e P

roce

sos

de

So

ftwa

re

Fases del Modelo de CascadaIngeniería de Modelado de Sistemas-Información. Abarca los requisitos que se recogen en el nivel de empresa estratégico y en el nivel de área de negocio.

Análisis de requisitos del software.Se intensifica en la comprensión del dominio de información del software.

Diseño del software.Se centra en: estructura de datos, arquitectura del software, representaciones de interfaz y detalle procedimental (algoritmos).

Implementación - Generación de código.Se traduce en una forma legible por la maquina.

Integración - Pruebas.Se asegura que la entrada definida produce resultados reales de acuerdo a los resultados esperados.

Operación - Mantenimiento.El software indudablemente sufrirá cambios después de ser entregado

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are

Problemas y Riesgos del Modelo en Cascada.

• Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.

• A menudo es difícil que el cliente exponga explícitamente todos los requisitos.

• El cliente debe tener paciencia. Una versión del trabajo no estará disponible hasta que el proyecto este muy avanzado.

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are

Documentos del Modelo de Cascada

Actividad Documentos ProducidosAnálisis de Requerimientos Documento de RequerimientosDefinición de Requerimientos Documento de Requerimientos.Especificación del Sistema. Especificación Funcional, Plan de Pruebas

de Aceptación.Diseño Arquitectural Especificación de la Arquitectura, y Plan de

Pruebas del SistemaDiseño de Interfaces Especificación de la Interfaces y Plan de

pruebas de Integración.Diseño Detallado Especificación del diseño y Plan de prueba

de Unidades.Codificación Código de ProgramaPrueba de Unidades Reporte de prueba de unidadesPrueba de Módulos Reporte de prueba de módulosPrueba de Integración Reporte de prueba de integración y Manual

de usuario finalPrueba del Sistema Reporte de prueba del sistemaPrueba de Aceptación Sistema final mas la documentación.

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are

Modelo de Prototipos

Prototipado exploratorio El objetivo es trabajar con clientes hasta evolucionar a un sistema final,

a partir de una especificación inicial. Se debe comenzar con unas especificaciones bien entendidas.

Prototipado de “throw-away”. El objetivo es entender los requerimientos del sistema. Se puede

comenzar con especificaciones poco entendidas.

Construir – RevisarLa maqueta

Construir – RevisarLa maquetaEscuchar al clienteEscuchar al cliente

El cliente prueba lamaqueta

El cliente prueba lamaqueta

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are

La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al desarrollador comprender mejor lo que se necesita hacer.

Se aplica cuando: El cliente a menudo define un conjunto de objetivos generales para

el software, pero no identifica los requisitos detallados de entrada, proceso o salida.

El responsable del desarrollo de software no puede estar seguro de la eficacia de un algoritmo, de las capacidades de adaptación del sistema operativo.

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are Modelo de Prototipos

Problemas y Riesgos del Modelo de Prototipos.

• Lo ideal seria que el prototipo sirviera como un mecanismo para identificar los requisitos del software.

• El cliente ve lo que parece ser una versión de trabajo del software (no tiene en cuenta que el software esta junto al “chicle” y el cable de embalaje).

• El desarrollador, a menudo, hace compromisos de implementación para hacer que el prototipo funcione rápidamente.

• El desarrollador no tiene una gran visibilidad de lo que el cliente necesita.

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are

Trabajo Individual

Investigue sobre los siguientes modelos:

• Modelos Evolutivos:

Modelo Incremental.

Modelo Espiral.

Modelo Espiral WinWin (Victoria-Victoria).

Modelo de Desarrollo Concurrente.

• Modelo Basado en Componentes:

• Modelo de los Métodos Formales:

Nota: Se evaluara estos temas la siguiente sesión.

Mo

de

los

de

Pro

ceso

s d

e S

oftw

are

Abarca un amplio espectro de herramientas de software que tienen algo en común:Facilitan al Ingeniero de Software la especificación de alguna

característica del software a alto nivel.La herramienta genera automáticamente el código fuente

basándose en las especificaciones.

El paradigma T4G para la ingeniería de software se orienta hacia la posibilidad de especificar el software usando formas de lenguajes especializados o notaciones graficas que describa el problema que hay que resolver en términos que el cliente entienda.

Té

cnic

as

de

4ta

Ge

ne

raci

ón

Una T4G incluye:

•Lenguaje no procedimental de consulta a BD.

• Generación de informes.

• Manejo de datos.

• Interacción y definición de pantallas.

• Generación de código.

• Capacidad grafica de alto nivel.

• Generación automatizada de html.

Té

cnic

as

de

4ta

Ge

ne

raci

ón

Ventajas:•Reducción drástica en el tiempo de desarrollo.•Mejora significativa en la productividad de quienes construyen el software.

Desventajas:•Las herramientas de T4G no son mas fáciles de utilizar que los lenguajes de programación.

•El código fuente generado es ineficiente.•El mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.

Té

cnic

as

de

4ta

Ge

ne

raci

ón

Podemos mencionar

CalidadHabilidad individualComunicación del equipoComplejidad del productoNotación apropiadaEnfoque sistemáticoNivel de tecnologíaConfiabilidad requeridaTiempo disponibleEntendimiento del problema

Los sistemas de software son intangibles por lo que los administradores necesitan documentación para identificar el progreso en el desarrollo.

Esto puede causar problemas.. El tiempo planeado para entrega de resultados puede no

coincidir con el tiempo necesario para completar una actividad. La necesidad de producir documentos restringe la iteración entre

procesos. .El tiempo para revisar y aprobar documentos es significativo.

Vis

ibili

da

d d

el P

roce

so

Modelo de Proceso Visibilidad del ProcesoModelo de Cascada Buena visibilidad, cada actividad produce un

documento o resultadoDesarrollo Evolutivo Visibilidad pobre, muy caro al producir

docuementos en cada iteración.Modelos Formales Buena visibilidad, en cada fase deben

producirse documentos.Desarrollo orientado a la reutilización Visibilidad moderada. Importante contar con

documentación de componentes reutilizables.Modelo de Espiral Buena visibilidad, cada segmento y cada

anillo del espiral debe producir undocumento.

Vis

ibili

da

d d

el P

roce

so

El proceso…

Que es… Serie de pasos predecibles Una guía que ayuda a obtener el resultado en términos de

calidad y en forma oportuna

Quien lo hace… Los Ingenieros de software y sus gestores adaptando el proceso

a sus necesidades

Porque es importante… Proporciona estabilidad, control y organización, evitandose el

caos si es que se controla

En

re

sum

en

El proceso…

Cuales son los pasos… El proceso adoptado dependerá del tipo de software que se

pretende construir

Cual es el producto obtenido… Programas, documentos y datos como consecuencia de las

actividades definidas en el proceso

Como estar seguro que se ha hecho correctamente…

Los mejores indicadores de eficiencia son: calidad, oportunidad y viabilidad a largo plazo del producto.

En

re

sum

en

Ingeniería de Software

Unidad I

Gestión de Proyectos de Software

El Proceso de Software

Tema

Semana 2