Lic. Cesar Espinoza Jiménez · PDF fileIngeniería del Software : Un enfoque...

Lic. Cesar Espinoza JiménezLic. Cesar Espinoza Jiménez

Objetivo de la Materia�� Introducir al estudiante a las metodologías existentes Introducir al estudiante a las metodologías existentes

en la Industria del Software para asegurar la calidad de en la Industria del Software para asegurar la calidad de los proyectos.los proyectos.

�� Desarrollar las habilidades del estudiante para medir Desarrollar las habilidades del estudiante para medir �� Desarrollar las habilidades del estudiante para medir Desarrollar las habilidades del estudiante para medir sus procesos personales de Softwaresus procesos personales de Software

Bibliografía Básica� Ingeniería del Software : Un enfoque práctico.

Roger S. Pressman. Mc Graw Hill 6ta Edición

� Ingeniería del Software: orientado a objetos. Erick Braude. Alfa-Omega 1era EdiciónBraude. Alfa-Omega 1era Edición

� Ingeniería del Software.

Ian Sommerville Preston Education 8ta Edición

¿ Podemos iniciar?

Autodiagnóstico� De manera individual

defina los siguientes conceptos:� Calidad � MetodologíaCalidad� Software� Desarrollo� Proceso� Paradigma

� Metodología� UML� Madurez� Capacidad� Modelo

Retroalimentación� En grupos de 4

personas discuta sus personas discuta sus definiciones y lleguen a un consenso.

Contenido Temático1. Ingeniería de Software y Calidad

1.1 Conceptos básicos de Calidad

1.2 Factores que determinan la calidad del Software

1.3 Características del Software1.3 Características del Software

1.4 Modelos de desarrollo de Software

1.5 Importancia de las diferentes etapas en el Desarrollo de Software

Contenido Temático2. Métricas y Procesos (PSP)

2.1 Introducción al Personal Software Process (PSP)

2.2 Estructura del PSP

2.3 Métricas del PSP2.3 Métricas del PSP

Contenido Temático3. CMM-I Capability Maturity Model - Integration

3.1 Inmadurez y madurez en los procesos de Creación de Software

3.2 Los cinco niveles de madurez en los Procesos de 3.2 Los cinco niveles de madurez en los Procesos de Creación de Software

3.3 Definición operacional del modelo CMM

3.4 ¿ Porqué usar el modelo CMM – I?

Ingeniería de Software y CalidadIngeniería de Software y Calidad

Objetivo de la Unidad� Introducir al alumno en el análisis de los diferentes

modelos de desarrollo de Software, así como su relación con los conceptos básicos de calidad en el desarrollo de sistemas.desarrollo de sistemas.

1.1 Conceptos Básicos de Calidad1.1 Conceptos Básicos de Calidad

1. 1 Conceptos básicos de calidad

� Clasifique las siguientes marcas en base a su calidad:

1. 1 Conceptos básicos de calidad� Calidad

“Conjunto de propiedades y de características de un producto o servicio, que le confieren aptitud para satisfacer unas necesidades explícitas o implícitas”. (Norma ISO 9000:8402)(Norma ISO 9000:8402)

� “Característica o atributo de algo”( American Heritage Dictionary).

1. 1 Conceptos básicos de calidad� Calidad

� Características � Características mensurables: cosas que se pueden comparar con estándares conocidos como: longitud , color, maleabilidad.


� Control de Calidad

“Conjunto de técnicas y actividades de carácter “Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto requerimientos relativos a la calidad del producto requerimientos relativos a la calidad del producto requerimientos relativos a la calidad del producto o servicio”o servicio”

1. 1 Conceptos básicos de calidad� ¿ Qué control de

calidad aplicarías, por calidad aplicarías, por ejemplo, para comprar un par de zapatos deportivos (tennis)?


� Garantía de calidad

“Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisface adecuada de que un producto o servicio satisface los requerimientos dados sobre calidad.”


� Garantía de calidad

En software es un diseño de acciones planificado y sistemático, que se requiere para asegurar la calidad del software.calidad del software.


� Calidad del Software

“Es el grado con el que un sistema, componente o proceso cumple con los requerimientos y las necesidades o expectativas del cliente o usuario”necesidades o expectativas del cliente o usuario”(IEEE 610/1990)


� Calidad del Software

“Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente que desea el usuario”.( Pressman, 2006).

1.2 Factores que determinan la calidad del SW

1. 2 Factores que determinan la calidad del software

a) Factores que se pueden medir directamente (objetivo: cualitativo)

b) Factores que se pueden medir indirectamente b) Factores que se pueden medir indirectamente (subjetivo)

1. 2 Factores que determinan la calidad del software

Factores de Calidad de McCall

� Características Operativas

� Capacidad de soportar cambios

Adaptabilidad a nuevos entornos� Adaptabilidad a nuevos entornos

Características Operativas� Corrección

¿ HACE LO QUE QUIERO?Hasta donde satisface un programa una especificación Hasta donde satisface un programa una especificación y logra los objetivos del cliente.

Características Operativas� Fiabilidad

¿ Lo hace de forma fiable todo el tiempo?todo el tiempo?Hasta donde se puede esperar que un programa lleve a cabo su función pretendida con la exactitud requerida

Características Operativas� Eficiencia

¿ Se ejecutará en mi HW lo mejor que se pueda?mejor que se pueda?La cantidad de recursos informáticos y código necesaria para que un programa realice su función.

Características Operativas� Seguridad

¿ Es seguro?Hasta donde se puede controlar el acceso al software o Hasta donde se puede controlar el acceso al software o a los datos por personas no autorizadas.

Características Operativas� Usabilidad

¿ Es fácil de manejar?El esfuerzo necesario para aprender, operar , preparar El esfuerzo necesario para aprender, operar , preparar datos de entrada e interpretar salidas (resultados) de un programa.

Capacidad de soportar cambios� Facilidad de mantenimiento

¿Puedo corregirlo?El esfuerzo necesario para localizar y arreglar un error El esfuerzo necesario para localizar y arreglar un error en un programa.

Capacidad de soportar cambios� Flexibilidad

¿Puedo cambiarlo?El esfuerzo necesario para modificar un programa El esfuerzo necesario para modificar un programa operativo.

Capacidad de soportar cambios� Facilidad de prueba

¿Puedo probarlo?El esfuerzo necesario para probar un programa y El esfuerzo necesario para probar un programa y asegurarse de que realiza la función pretendida.

Adaptabilidad a nuevos entornos� Portabilidad

¿Podré usarlo en otra máquina?máquina?El esfuerzo necesario para transferir el programa de un entorno de sistema de HW y/o SW a otro.

Adaptabilidad a nuevos entornos

� Reusabilidad

¿Podré reutilizar alguna parte ¿Podré reutilizar alguna parte del software?Hasta donde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones, en relación con el empaquetamiento y alcance de las funciones que realiza el programa.

Adaptabilidad a nuevos entornos

� Interoperabilidad

¿Podré hacerlo interactuar con otro sistema?con otro sistema?El esfuerzo necesario para acoplar un sistema con otro.

1.3 Características del SW1.3 Características del SW

1.3 Características del Software� Crisis del SW

� Software

� Características del SW

La industria del software no ha podido satisfacer la demanda.

La industria del software no ha podido satisfacer la demanda.

Crisis del Software

La complejidad del software producido y

demandado se incrementa

constantemente.

La complejidad del software producido y

demandado se incrementa

constantemente.

demanda.demanda.

Crisis del Software

SíntomasSíntomasSíntomasSíntomasSíntomasSíntomasSíntomasSíntomas

1. Baja Calidad del Software.2. Tiempo y Presupuesto

Excedido.3. Confiabilidad Cuestionable.4. Altos Requerimientos de

Personal para desarrollo y mantenimiento.

1. Baja Calidad del Software.2. Tiempo y Presupuesto

Excedido.3. Confiabilidad Cuestionable.4. Altos Requerimientos de

Personal para desarrollo y mantenimiento.

Crisis del Software

Factores de influenciaFactores de influenciaFactores de influenciaFactores de influenciaFactores de influenciaFactores de influenciaFactores de influenciaFactores de influencia

1. Aumento del poder computacional.2. Reducción del costo del hardware.3. Rápida obsolescencia de hardware y

software.

1. Aumento del poder computacional.2. Reducción del costo del hardware.3. Rápida obsolescencia de hardware y

software.

Crisis del SoftwareFactores de influenciaFactores de influencia

4. Aceptación de la computarización en las empresas.

5. Incremento en el número de usuarios de los sistemas de software.

6. Tipo de usuario no homogéneo aun en sistemas hechos a la medida.

4. Aceptación de la computarización en las empresas.

5. Incremento en el número de usuarios de los sistemas de software.

6. Tipo de usuario no homogéneo aun en sistemas hechos a la medida.

Crisis del Software


7. Personal de desarrollado y mantenimiento diferente.

8. La magnitud del proyecto impacta en:a. Tiempo costo y número de desarrolladores, b. Control administrativo y detalles técnicos

9. Aumento en el conocimiento del problema.

7. Personal de desarrollado y mantenimiento diferente.

8. La magnitud del proyecto impacta en:a. Tiempo costo y número de desarrolladores, b. Control administrativo y detalles técnicos

9. Aumento en el conocimiento del problema.

Crisis del Software


10. Cambios en el entorno:a. Tecnológicos (Internet,redes,ERP,CRM,SCM..)b. Económicos (crisis económicas, globalización,..)c. Sociales (nuevas necesidades, costumbres nuevas,..)d. Ambientales (...)e. ...

10. Cambios en el entorno:a. Tecnológicos (Internet,redes,ERP,CRM,SCM..)b. Económicos (crisis económicas, globalización,..)c. Sociales (nuevas necesidades, costumbres nuevas,..)d. Ambientales (...)e. ...

Preguntas1. ¿Cómo desarrollar software?2. ¿Cómo dar mantenimiento al creciente volumen de

software?3. ¿Cómo poder mantenerse al corriente a la creciente

1. ¿Cómo desarrollar software?2. ¿Cómo dar mantenimiento al creciente volumen de

software?3. ¿Cómo poder mantenerse al corriente a la creciente 3. ¿Cómo poder mantenerse al corriente a la creciente

demanda de software?4. ¿Porqué lleva tanto tiempo terminar los programas?5. ¿Porqué tan caro?6. ¿Porqué no podemos encontrar todos los errores?7. ¿Porqué es tan difícil evaluar el avance?

3. ¿Cómo poder mantenerse al corriente a la creciente demanda de software?

4. ¿Porqué lleva tanto tiempo terminar los programas?5. ¿Porqué tan caro?6. ¿Porqué no podemos encontrar todos los errores?7. ¿Porqué es tan difícil evaluar el avance?

Preguntas por equipo:1. ¿Cómo desarrollan el software en las

organizaciones?1. ¿Cómo desarrollan el software en las

organizaciones?organizaciones?2. ¿Los desarrolladores de hoy en día están

concientes del problema del ciclo de software?

organizaciones?2. ¿Los desarrolladores de hoy en día están

concientes del problema del ciclo de software?

Producto de softwareConjunto de elementos de software (programas, tablas, reportes, documentación, etc.) que tienen un propósito

Producto de softwareConjunto de elementos de software (programas, tablas, reportes, documentación, etc.) que tienen un propósito

ProgramasEstructura de datos + algoritmos

ProgramasEstructura de datos + algoritmos

1.3.1 Software

específico y completo desde el punto de vista del usuario, de tal manera que la sustracción de cualquiera de los elementos del conjunto daría como resultado que el propósito no se cumpliera.

específico y completo desde el punto de vista del usuario, de tal manera que la sustracción de cualquiera de los elementos del conjunto daría como resultado que el propósito no se cumpliera.

a) Instrucciones (programas de computadora) que cuando se ejecutan proporcionan la función y el rendimiento

deseadosb) Estructuras de datos que permiten a los programas

manipular adecuadamente la informaciónc) Documentos que describen la operación y uso de los

a) Instrucciones (programas de computadora) que cuando se ejecutan proporcionan la función y el rendimiento

deseadosb) Estructuras de datos que permiten a los programas

manipular adecuadamente la informaciónc) Documentos que describen la operación y uso de los

1.3.1 Software

c) Documentos que describen la operación y uso de los programas.

c) Documentos que describen la operación y uso de los programas.

Productos de Software� Productos genéricos

(sw de mostrador)(sw de mostrador)

� Desarrollados por una organización para ser vendidos al mercado.

Productos de Software� Productos hechos a medida

� Desarrollados bajo pedido a una empresa desarrolladora de software.

Productos de Software� La mayor parte del gasto del software es en productos

genéricos, pero hay más esfuerzo en el desarrollo de los sistemas hechos a medida.

1.3.2 Características del SW

� Como Como Como Como ProductoProductoProductoProducto

� Como Como Como Como ProductoProductoProductoProductoProductoProductoProductoProducto

� Como ProcesoComo ProcesoComo ProcesoComo Proceso� Como Como Como Como ProyectoProyectoProyectoProyecto

ProductoProductoProductoProducto� Como ProcesoComo ProcesoComo ProcesoComo Proceso� Como Como Como Como ProyectoProyectoProyectoProyecto

PRODUCTO

� Tiene definidas una fecha � Tiene definidas una fecha � Tiene definidas una fecha de inicio de desarrollo y una fecha esperada o estimada de terminación.

� Apoya alguna función del usuario hacia el cual está dirigido.

� Tiene definidas una fecha de inicio de desarrollo y una fecha esperada o estimada de terminación.

� Apoya alguna función del usuario hacia el cual está dirigido.

Diferencias como producto

� Se desarrolla y no se � Se desarrolla y no se � Se desarrolla y no se fabrica como otros productos.

� No se estropea.

� No se “desgasta”.

� Hecho por humanos.

� Se desarrolla y no se fabrica como otros productos.

� No se estropea.

� No se “desgasta”.

� Hecho por humanos.

Atributos de los productos de SW� Facilidad de mantenimiento

� Debe ser posible que el software evolucione y que siga cumpliendo con sus especificaciones.

� Confiabilidad� El software no debe causar daños físicos o económicos en el caso de

fallas.fallas.� Eficiencia

� El software no debe desperdiciar los recursos del sistema.� Utilización adecuada

� El software debe contar tanto con una interfaz de usuario adecuada como con una documentación clara y precisa.

Importancia de los Atributos del Producto de Software� La importancia relativa de las características depende del

tipo de producto y en el ambiente en el que será utilizado.� En algunos casos, algunos atributos pueden dominar.

� En sistemas de seguridad críticos de tiempo real, los atributos clave pueden ser la confiabilidad y la eficiencia.pueden ser la confiabilidad y la eficiencia.

� Los costos tienden a crecer exponencialmente si se requieren altos niveles de alguna característica.

Costos

Costos de eficiencia

Eficiencia

• Mantenibilidad• MantenibilidadProductividad

Metas de un producto

• Mantenibilidad• Usabilidad• Confiabilidad• Reusabilidad • Portabilidad

• Mantenibilidad• Usabilidad• Confiabilidad• Reusabilidad • Portabilidad

Calidad

Costos

Tiempo

Clasificación del Software

� Externas� Externas� Externas� Internas� Del producto

� Del proceso

� Externas� Internas� Del producto

� Del proceso

Propiedades del Software� Correctividad, Confiabilidad, Robustez.� Desempeño (performance)� Amigabilidad (Uso amigable)� Verificabilidad (Facilidad de verificar)� Mantenibilidad. Facilidad de mantenimiento:

� Correctividad, Confiabilidad, Robustez.� Desempeño (performance)� Amigabilidad (Uso amigable)� Verificabilidad (Facilidad de verificar)� Mantenibilidad. Facilidad de mantenimiento:� Mantenibilidad. Facilidad de mantenimiento:

� Para su reparación → REPARABILIDAD� Para su evolución → VIGENCIA

� Reusabilidad� Portabilidad� Comprensibilidad (Comprehensibility): Facilidad de

entenderse� Interoperabilidad

� Mantenibilidad. Facilidad de mantenimiento:� Para su reparación → REPARABILIDAD� Para su evolución → VIGENCIA

� Reusabilidad� Portabilidad� Comprensibilidad (Comprehensibility): Facilidad de

entenderse� Interoperabilidad

Formas de categorizar el software:

� Por tipo de Aplicación o Disciplina.Por tipo de Arquitectura

� Por tipo de Aplicación o Disciplina.Por tipo de Arquitectura� Por tipo de Arquitectura

� Por área Funcional� Por nivel Jerárquico� Por tipo de Estructura Organizacional� Por Tiempo de Respuesta

� Por tipo de Arquitectura� Por área Funcional� Por nivel Jerárquico� Por tipo de Estructura Organizacional� Por Tiempo de Respuesta

Aplicación o disciplina

� Para sistemas� Sistemas tiempo real� Para sistemas� Sistemas tiempo real� Sistemas tiempo real� Negocios� Ingeniería/científico� Empotrado (Embebido)� PC´s� Inteligencia artificial� Aplicaciones Web.

� Sistemas tiempo real� Negocios� Ingeniería/científico� Empotrado (Embebido)� PC´s� Inteligencia artificial� Aplicaciones Web.

Tipo de arquitectura

� Stand Alone� Stand Alone� Stand Alone� Main Frame� Red: LAN, WAN� Internet� Intranet� Extranet

� Stand Alone� Main Frame� Red: LAN, WAN� Internet� Intranet� Extranet

Niveles o áreas funcionalesDirectivo

Administración

Conocimiento

OperacionalOperacional

Contabilidad Finanzas VentasMercadotecnia

Recursos Humanos

Manufactura

Niveles o áreas funcionalesDirectivo Sistema Soporte Ejecutivo (SSE)

Administración Sistema Soporte de Decisiones (SSD)Sistema Información Admo. (SIA)

Conocimiento Sistema de Automatización de Oficinas. (SAO) / Apoyo Trabajadores del Conocimiento (SATC)

Operacional Sistema de Transacción de Operaciones(STO)

Nivel Jerárquico

� Sistema de Transacción de Operaciones� Sistema de Apoyo a Trabajadores del Conocimiento� Sistema de Transacción de Operaciones� Sistema de Apoyo a Trabajadores del Conocimiento� Sistema de Apoyo a Trabajadores del Conocimiento� Sistema para la Automatización de Oficinas� Sistema de Información Administrativo� Sistema para Soporte de Decisiones� Sistema de Soporte Ejecutivo� Sistema de Soporte de Grupo� Sistema de Soporte Inteligente

� Sistema de Apoyo a Trabajadores del Conocimiento� Sistema para la Automatización de Oficinas� Sistema de Información Administrativo� Sistema para Soporte de Decisiones� Sistema de Soporte Ejecutivo� Sistema de Soporte de Grupo� Sistema de Soporte Inteligente

Actividad Soportada

� Sistemas OperacionalesSistemas OperacionalesSistemas OperacionalesSistemas Operacionales� Orientado hacia transacciones diarias.

� Sistemas OperacionalesSistemas OperacionalesSistemas OperacionalesSistemas Operacionales� Orientado hacia transacciones diarias.diarias.

� Sistemas TácticosSistemas TácticosSistemas TácticosSistemas Tácticos� Orientados a apoyar actividades de mandos intermedios: Estadísticas/ Reportes de excepción/Reportes Periódicos/Análisis Comparativos/Proyecciones/Detección Temprana de Problemas/Decisiones Rutinarias.

� Sistemas estratégicosSistemas estratégicosSistemas estratégicosSistemas estratégicos

diarias.

� Sistemas TácticosSistemas TácticosSistemas TácticosSistemas Tácticos� Orientados a apoyar actividades de mandos intermedios: Estadísticas/ Reportes de excepción/Reportes Periódicos/Análisis Comparativos/Proyecciones/Detección Temprana de Problemas/Decisiones Rutinarias.

� Sistemas estratégicosSistemas estratégicosSistemas estratégicosSistemas estratégicos

Estructura organizacional� Sistemas de Información Departamentales

� Sistemas de

� Sistemas de Información Departamentales

� Sistemas de � Sistemas de Información Empresariales

� Sistemas de Información Interorganizacionales

� Sistemas de Información Empresariales

� Sistemas de Información Interorganizacionales

Tiempo de Respuesta

�Tiempo �Tiempo �Tiempo Real

�En línea

�Batch

�Tiempo Real

�En línea

�Batch

Actividad

� Proporcione ejemplos de sistemas:� operacionales,

� Proporcione ejemplos de sistemas:� operacionales, � operacionales, � soporte a trabajadores del conocimiento,

� administrativos, � directivos.

� ¿Qué utilidad tendrá el clasificar los productos de software?

� ¿Cuál es el orden de importancia de las propiedades de un sistema de información?

� operacionales, � soporte a trabajadores del conocimiento,

� administrativos, � directivos.

� ¿Qué utilidad tendrá el clasificar los productos de software?

� ¿Cuál es el orden de importancia de las propiedades de un sistema de información?

PROCESO

� Características importantes:

� Características importantes:Características importantes:� Productividad

� Calendarización

� Visibilidad

Características importantes:� Productividad

� Calendarización

� Visibilidad

PROYECTO DE SOFTWARE

Un proyecto está integrado por un conjunto deactividades para lograr uno o más productos desoftware. Puede dividirse en uno o mássubproyectos conformados por subconjuntos deactividades.

Un proyecto está integrado por un conjunto deactividades para lograr uno o más productos desoftware. Puede dividirse en uno o mássubproyectos conformados por subconjuntos deactividades.

Proyecto de Software

� Características:� Tiene una fecha de inicio definida y una

� Características:� Tiene una fecha de inicio definida y una � Tiene una fecha de inicio definida y una fecha de terminación. Sin embargo en la práctica, la fecha de terminación se puede alargar.

� Se calendarizan entregas de “productos” concretos y específicos.

� Número de personas variable en el tiempo.

� Su propósito es proporcionar un conjunto de facilidades que apoyen a un conjunto de actividades del usuario que lógicamente están relacionadas entre sí.

� Tiene una fecha de inicio definida y una fecha de terminación. Sin embargo en la práctica, la fecha de terminación se puede alargar.

� Se calendarizan entregas de “productos” concretos y específicos.

� Número de personas variable en el tiempo.

� Su propósito es proporcionar un conjunto de facilidades que apoyen a un conjunto de actividades del usuario que lógicamente están relacionadas entre sí.

Mitos del Software

3 puntos de vista

3 puntos de vistavista

3 expectativas3 intenciones

1. El Gestor2. El Cliente o

Usuario3. El

Desarrollador

vista3 expectativas3 intenciones

1. El Gestor2. El Cliente o

Usuario3. El

Desarrollador

Mitos del Software

� Gestor� Gestor� Gestor� Se tienen libros llenos de estándares y procedimientos para desarrollar software

� Tienen lo mas avanzado en cómputo; tienen super computadoras.

� Si se falla en la planeación, se incluye mas personal.

� Gestor� Se tienen libros llenos de estándares y procedimientos para desarrollar software

� Tienen lo mas avanzado en cómputo; tienen super computadoras.

� Si se falla en la planeación, se incluye mas personal.

Mitos del Software

� Cliente� Cliente� Cliente� Una declaración general de objetivos es suficiente para empezar la programación del sistema.

� Los requisitos cambian, pero se pueden acomodar con facilidad.

� Cliente� Una declaración general de objetivos es suficiente para empezar la programación del sistema.

� Los requisitos cambian, pero se pueden acomodar con facilidad.

Mitos del Software

Desarrollador� Escrito y funcionando el

Desarrollador� Escrito y funcionando el funcionando el programa ya terminó el proyecto

� Solo funcionando el programa se puede evaluar la calidad del sistema.

� Lo único que se entrega es el código funcionando.

funcionando el programa ya terminó el proyecto

� Solo funcionando el programa se puede evaluar la calidad del sistema.

� Lo único que se entrega es el código funcionando.

Impacto del cambio

“Cuando se puede medir y cuantificar aquello

sobre lo que uno habla y expresarlo en

números, se sabe algo

“Cuando se puede medir y cuantificar aquello

sobre lo que uno habla y expresarlo en

números, se sabe algo números, se sabe algo acerca de eso; cuando

no puede ser expresado en números el conocimiento es

escaso e insatisfactorio...”

Lord Kelvin

números, se sabe algo acerca de eso; cuando

no puede ser expresado en números el conocimiento es

escaso e insatisfactorio...”

Lord Kelvin

Actividad

� Describir un proyecto de desarrollo de software y catalogarlo de

� Describir un proyecto de desarrollo de software y catalogarlo de de software y catalogarlo de acuerdo a la clasificación vista.

� Ordene los mitos vistos de acuerdo con la creencia popular de las organizaciones

� ¿Qué acciones se deben realizar en su organización para eliminar y/o atenuar los mitos del software?

de software y catalogarlo de acuerdo a la clasificación vista.

� Ordene los mitos vistos de acuerdo con la creencia popular de las organizaciones

� ¿Qué acciones se deben realizar en su organización para eliminar y/o atenuar los mitos del software?

Ingeniería del Software

� Definición� Importancia� Definición� Importancia� Importancia� Sistemas de Calidad� Ciclo de vida� Documentos asociados� Modelos de Desarrollo� Aseguramiento de Calidad. Pruebas. Verificación y Validación

� Importancia� Sistemas de Calidad� Ciclo de vida� Documentos asociados� Modelos de Desarrollo� Aseguramiento de Calidad. Pruebas. Verificación y Validación

Propuesta de soluciónPropuesta de soluciónPropuesta de soluciónPropuesta de solución

Establecer y usar principios robustos de ingeniería con el fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales

Propuesta de soluciónPropuesta de soluciónPropuesta de soluciónPropuesta de solución

Establecer y usar principios robustos de ingeniería con el fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales

Definición

sobre máquinas realessobre máquinas reales

Ingeniería en Software (ISW)Ingeniería en Software (ISW)Ingeniería en Software (ISW)Ingeniería en Software (ISW)

Aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software, esto es, la aplicación

de la ingeniería al software

Ingeniería en Software (ISW)Ingeniería en Software (ISW)Ingeniería en Software (ISW)Ingeniería en Software (ISW)

Aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software, esto es, la aplicación

de la ingeniería al software

Ingeniería del Software

La La La La Ingeniería Ingeniería Ingeniería Ingeniería

de de de de

La La La La Ingeniería Ingeniería Ingeniería Ingeniería

de de de de

Analizar, diseñar, construir y dar mantenimiento a grandes y complejos sistemas de software.

Analizar, diseñar, construir y dar mantenimiento a grandes y complejos sistemas de software.

de de de de Software Software Software Software pretende:pretende:pretende:pretende:

de de de de Software Software Software Software pretende:pretende:pretende:pretende:

Importancia de la Ingeniería de Software

��LA INDUSTRIA DEL SOFTWARE, LA INDUSTRIA DEL SOFTWARE, LA INDUSTRIA DEL SOFTWARE, LA INDUSTRIA DEL SOFTWARE, UNA NUEVAS AREA DE UNA NUEVAS AREA DE OPORTUNIDAD (PARA MEXICO)OPORTUNIDAD (PARA MEXICO)

Mercado Mundial $541 mmusd.

Entorno Internacional

Principales Mercados:NORTEAMÉRICA 48 %

EUROPA 26 %

JAPÓN 12 %

OTROS 14 %

Principales Segmentos:�Administración de Negocios�Servicios de Administración


�India�USA�Irlanda�Israel

Principales Proveedores:

�Servicios de Administración�Servicios de Integración y Desarrollo de Sistemas�Servicios de Consultoría�Servicios de Mantenimiento y Soporte

�China�Rusia�Pakistán�Filipinas�Otros

Crecimiento cercano al 15 % anual en los

próximos 5 años.


próximos 5 años.

Severa escasez de personal capacitado en

Tecnologías de la Información.

�770,000 en USA1

�1,000,000 en Europa1

�1,000,000 en Japón1

1 Puestos vacantes

Intensa competencia entre los países de mayor

oferta por los mercados mas importantes.


Fuerte tendencia hacia servicios E-Commerce:

�Integración de aplicaciones en Internet

�Conversión a modelos basados en Internet

�Desarrollo y mantenimiento de sitios WEB

Tendencia hacia la demanda de servicios

integrales.

Mercado total $1,584.2 musd

Sectores Principales:�Financiero�GubernamentalIndustrial

Principales Servicios:

�Industrial�Educación�Otros

�Desarrollo de aplicaciones

�Mantenimiento de sistemas.

�Servicios de consultoría.

�Integración de sistemas.

�Aplicaciones de Internet.

�Soluciones e-business.

�Aplicaciones empaquetadas.

No. DE EMPRESAS 257

TIPO DE EMPRESA� Nivel Internacional 15� Con estructura formal 75

CERTIFICACIONES☺ Certificación ISO 5☺ Certificación CMM 5

� Con estructura formal 75� Sin estructura formal 167

MICRO 90%

GRANDES 2.8%MEDIANAS 3.2%

PEQUEÑAS 4.0%

• Mercado viable en Norteamérica de $20,000 mdd.

Oportunidades

mdd.

• Potencial para atraer entre 500 y 1,000 nuevas empresas.

• Creación de nuevos polos de desarrollo.

• Creación de un flujo neto de divisas positivo.

Sistema de Calidad del Software� Estándares� RevisionesPruebas

� Estándares� RevisionesPruebas� Pruebas

� Análisis de defectos� Administración de la configuración

� Seguridad� Educación� Administración de contrataciones

� Pruebas� Análisis de defectos� Administración de la configuración

� Seguridad� Educación� Administración de contrataciones

Procesos

Métodos

Herramientas

Ingeniería de Software: Elementos

Procesos

Métodos

Herramientas

ELEMENTOS

Métodos� Los métodos indican cómo construir técnicamente el software.

� Tareas que componen los métodos.

� Planificación; Estimación de proyectos.Planificación; Estimación de proyectos.

� Análisis de requerimientos del software y hardware.

� Diseño de estructuras de datos, Arquitectura de los programas.

� Procedimientos algorítmicos.

� Codificación , prueba y mantenimiento.

Herramientas y procesos� Las herramientas son un soporte automático o semiautomático para el

proceso y los métodos. � Microsoft Project ( Planificación).� UML ( Modelado).� RationalRose, visio (Modelado soportan UML).

Designer 2000. � Designer 2000. � Erwin (Bases de datos).� MAGERI (Seguridad).

� Los procesos son los encargados de integrar los métodos y herramientas, además de definir la secuencia en la que se aplican los métodos, las entregas que requieren, los controles de calidad y las guías para el desarrollo.

Fases Genéricas de la ISW

Enfoque

Enfoque

Enfoque

Enfoque

de calidad

de calidad

de calidad

de calidad

Enfoque

Enfoque

Enfoque

Enfoque

de calidad

de calidad

de calidad

de calidad

1. La totalidad de características de un producto que surgen de su habilidad de satisfacer necesidades dadas �

cumplir con las especificaciones.

1. La totalidad de características de un producto que surgen de su habilidad de satisfacer necesidades dadas �

cumplir con las especificaciones.

2. Grado en que el software posee una combinación deseada de atributos.

2. Grado en que el software posee una combinación deseada de atributos.

3. Grado en que un cliente o 3. Grado en que un cliente o

ANSI/IEEE Std 729-1983 “IEEE Standard Glossary of Software Engineering Terminology

Enfoque

Enfoque

Enfoque

Enfoque

de calidad

de calidad

de calidad

de calidad

Enfoque

Enfoque

Enfoque

Enfoque

de calidad

de calidad

de calidad

de calidad

3. Grado en que un cliente o usuario percibe que el software alcanza sus expectativas compuestas.

3. Grado en que un cliente o usuario percibe que el software alcanza sus expectativas compuestas.

4. Las características compuestas del software que determinan el grado en que el software en uso cumple con las expectativas del cliente.

4. Las características compuestas del software que determinan el grado en que el software en uso cumple con las expectativas del cliente.

1.4 Modelos de Desarrollo de Software1.4 Modelos de Desarrollo de Software

Conjunto estructurado de actividades requeridas para desarrollar un sistema de

Conjunto estructurado de actividades requeridas para desarrollar un sistema de

El Proceso de Software

desarrollar un sistema de software.

Especificación.Diseño.

Validación.

Evolución.

desarrollar un sistema de software.

Especificación.Diseño.

Validación.

Evolución.Debe estar explícitamente modelado para ser bien administrado.

Debe estar explícitamente modelado para ser bien administrado.

EspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificación: Establecer los requerimientos

y restricciones del sistema.

DiseñoDiseñoDiseñoDiseñoDiseñoDiseñoDiseñoDiseño: Producir un modelo en papel del

sistema.

ManufacturaManufacturaManufacturaManufacturaManufacturaManufacturaManufacturaManufactura: Construir el sistema.

EspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificaciónEspecificación: Establecer los requerimientos

y restricciones del sistema.

DiseñoDiseñoDiseñoDiseñoDiseñoDiseñoDiseñoDiseño: Producir un modelo en papel del

sistema.


Modelo de Ingeniería del Proceso


PruebaPruebaPruebaPruebaPruebaPruebaPruebaPrueba: Verificar que el sistema cumpla con las especificaciones requeridas.

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

MantenimientoMantenimientoMantenimientoMantenimientoMantenimientoMantenimientoMantenimientoMantenimiento: Reparar fallos en el sistema cuando sean descubiertos; mejorar el sistema; adaptar el sistema.


PruebaPruebaPruebaPruebaPruebaPruebaPruebaPrueba: Verificar que el sistema cumpla con las especificaciones requeridas.

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

MantenimientoMantenimientoMantenimientoMantenimientoMantenimientoMantenimientoMantenimientoMantenimiento: Reparar fallos en el sistema cuando sean descubiertos; mejorar el sistema; adaptar el sistema.

DefiniciónDefinición

Proceso de Desarrollo

DesarrolloDesarrollo

MantenimientoMantenimiento

Definición

� Ingeniería del sistema� Definición de Objetivos� Análisis� Especificación de Requerimientos

� Ingeniería del sistema� Definición de Objetivos� Análisis� Especificación de Requerimientos

Desarrollo

�Diseño:� PreliminarDetallado

�Diseño:� PreliminarDetallado

� Preliminar� Detallado� Externo� Interfaz� Interno

�Codificación�Pruebas:

� Modulares� Integración

� Preliminar� Detallado� Externo� Interfaz� Interno



Mantenimiento

� Pruebas de Validación

� Pruebas de ValidaciónValidación

� Manual de Operación

� Manual de Usuario� Código fuente, objeto y ejecutable

Validación� Manual de Operación


Documentación asociada a cada etapa del ciclo de vida

Tipos de Tipos de Tipos de Tipos de DocumentosDocumentosDocumentosDocumentosTipos de Tipos de Tipos de Tipos de

DocumentosDocumentosDocumentosDocumentos� Previos al desarrollo� Enmarcando al desarrollo

� Para cada una de las fases o etapas del desarrollo.

� Previos al desarrollo� Enmarcando al desarrollo

� Para cada una de las fases o etapas del desarrollo.

DocumentosDocumentosDocumentosDocumentosDocumentosDocumentosDocumentosDocumentos

Documentos para la etapa de DEFINICIÓN

� Definición de objetivos� Análisis del sistema: Factibilidad

� Especificación de requerimientos

� Definición de objetivos� Análisis del sistema: Factibilidad

� Especificación de requerimientos

Documentos fase de DESARROLLO

�Diseño:� Preliminar� Detallado

�Diseño:� Preliminar� Detallado� Detallado� Interfaz� Externo� Interno



� Detallado� Interfaz� Externo� Interno



Documentos para la etapa de MANTENIMIENTO

� Pruebas de Validación

� Pruebas de ValidaciónValidación

� Manual de Operación


Validación� Manual de Operación


Modelos de Desarrollo

� Tipos de modelosTipos de modelosTipos de modelosTipos de modelos� Lineal o secuencial� Construcción de

� Tipos de modelosTipos de modelosTipos de modelosTipos de modelos� Lineal o secuencial� Construcción de � Construcción de Prototipos

� Desarrollo Rápido de Aplicaciones (DRA óRAD)

� Procesos Evolutivos� Métodos Formales� Técnicas de 4ª Generación

� Modelos que incluyen a un 3ero

� Construcción de Prototipos

� Desarrollo Rápido de Aplicaciones (DRA óRAD)

� Procesos Evolutivos� Métodos Formales� Técnicas de 4ª Generación

� Modelos que incluyen a un 3ero

Modelo Lineal Secuencial o Cascada

Ingeniería de

Análisis Diseño Código Prueba

Ingeniería de Sistemas/Información

Modelo lineal secuencial(ciclo de vida básico, cascada)

� Sugiere un enfoquesistemático, secuencial

� Sugiere un enfoquesistemático, secuencialsistemático, secuencialde desarrollo desoftware que comienzaen un nivel de sistemasy progresa con elanálisis, diseño,codificación, pruebas ymantenimiento

sistemático, secuencialde desarrollo desoftware que comienzaen un nivel de sistemasy progresa con elanálisis, diseño,codificación, pruebas ymantenimiento

Etapa de análisis� Análisis de los requerimientos del software: es la fase

en la cual se reúnen todos los requisitos que debe cumplir el software.

Etapa de diseño:� Es una etapa dirigida hacia la estructura de datos, la

arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo).

Etapa de código:� Es la etapa en la cual se traduce el diseño para que sea

comprensible por la máquina. Esta etapa va a depender estrechamente de lo detallado del diseño.

Etapa de Prueba� El proceso de pruebas se centra en los procesos

lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales; es decir realizar las procesos externos funcionales; es decir realizar las pruebas para la detección de errores y asegurar que la entrada definida produce resultados requeridos.

Etapa de mantenimiento� Se producirán cambios porque se han encontrado

errores, porque el software debe adaptarse para acoplarse a los cambios de su entorno externo (por ejemplo se requiere un cambio debido a un sistema ejemplo se requiere un cambio debido a un sistema operativo o dispositivo periférico nuevo), el cliente requiere mejoras funcionales o de rendimiento.

Ingeniería y Análisis del

Sistema

Análisis de los

Requisitos

Evolución 1

Diseño

Codificación

Prueba

Mantenimiento

ANALISIS DE REQUERIMIENTOS PRUEBA DE

ACEPTACION

OPERACIONY MANTENIMIENTO

VALIDAD REQUERIMIENTOS

Plan de Pruebas de Aceptación

Los planes de prueba son el nexo entre el desarrollo y la verificación

Evolución 2

DISEÑO DEL SISTEMA

DISEÑO DETALLADO

IMPLEMENTACION DE PROGRAMAS Y PRUEBA UNITARIA

PRUEBA DEL SISTEMA

PRUEBA DE INTEGRACION

Plan de Pruebas de Integración

VERIFICAR DISEÑO

Plan de Pruebas del Sistema

Documentación

Producto Entrada

ProcesoProducto

SalidaRequerimientos Comunicados

Ingenieria de RequerimientosEspecificación de

requerimientos (documentos)

Especificación de requerimientos (documentos)

DiseñoEspecificación de Diseño (

documento)

Especificación de Diseño ( documento)

ProgramaciónModulos ejecutables de

Software

Modulos ejecutables de Software

IntegraciónProducto de Software

Integrado

Producto de Software Integrado

EntregaProducto de Software

Entregado

Producto de Software Entregado

Mantenimiento Requerimientos para cambio

¿POR QUÉ FALLA ALGUNAS VECES EL MODELO LINEAL?

1.- Como resultado, los cambios pueden causar confusión cuando el equipo del proyecto comienza.equipo del proyecto comienza.

2.-El modelo lineal secuencial requiere dificultades a la hora de afrontar la incertidumbre natural al comienzo de muchos proyectos.

3.-Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.

Cada uno de estos errores es real. Tiene un lugar definido e importante en el trabajo de la ingeniería del software proporciona una plantilla en la que se encuentran métodos para análisis, diseño, codificación, y mantenimiento.

EscucharEscuchar Construir/Construir/

Modelo de construcción de prototipos

Escucharal clienteEscucharal cliente

Construir/revisar

maqueta

Construir/revisar

maqueta

El clienteprueba

la maqueta

El clienteprueba

la maqueta


� Problemas de suconstrucción:� El cliente ve lo que pareceser una versión de trabajo

� Problemas de suconstrucción:� El cliente ve lo que pareceser una versión de trabajoEl cliente ve lo que pareceser una versión de trabajodel software.

� Con la prisa de hacer quefuncione no se ha tenido encuenta la calidad delsoftware global o lafactibilidad de mantenimientoa largo plazo.

� El desarrollador a menudohace compromisos deimplementación para hacer queel prototipo funcionerápidamente.

El cliente ve lo que pareceser una versión de trabajodel software.

� Con la prisa de hacer quefuncione no se ha tenido encuenta la calidad delsoftware global o lafactibilidad de mantenimientoa largo plazo.

� El desarrollador a menudohace compromisos deimplementación para hacer queel prototipo funcionerápidamente.

¿ Por qué se usar este modelo?� El cliente no puede especificar todos los

requerimientos al principio.

� Existen dudas de alguna parte del sistema.

� Facilita un modelo al programador � Facilita un modelo al programador

Tipos de prototipos� Totales

� Parciales� Interfases

Modelos� Modelos

� Estructuras de datos

Problemas del modelo� El cliente lo quiere , aunque no es un producto de SW.

� Módulos ineficientes se convierten en parte del sistema.

� El modelo RAD es unaadaptación de “alta velocidad”de modelo lineal secuencial enel que se logra el desarrollorápido utilizando un enfoque deconstrucción basado en

� El modelo RAD es unaadaptación de “alta velocidad”de modelo lineal secuencial enel que se logra el desarrollorápido utilizando un enfoque deconstrucción basado en

Modelo RAD (Rapid Modelo RAD (Rapid Modelo RAD (Rapid Modelo RAD (Rapid ApplicationApplicationApplicationApplicationDevelopmentDevelopmentDevelopmentDevelopment))))

Modelo RAD (Rapid Modelo RAD (Rapid Modelo RAD (Rapid Modelo RAD (Rapid ApplicationApplicationApplicationApplicationDevelopmentDevelopmentDevelopmentDevelopment))))

construcción basado encomponentes.� Modelado de la aplicación� Modelado de datos� Modelado de proceso� Generación de aplicaciones� Pruebas y entrega

construcción basado encomponentes.� Modelado de la aplicación� Modelado de datos� Modelado de proceso� Generación de aplicaciones� Pruebas y entrega

Modelado degestión

Modelado de

Modelado degestión

Modelado dedatos

Modelado degestión

Modelado dedatos

Equipo # 1 Equipo # 2 Equipo # 3

Modelado dedatos

Modelado deprocesos

Generación de aplicaciones

Pruebas yvolumen

datos

Modelado deprocesos

Generación deaplicaciones

Pruebas y volumen

datos

Generación deaplicaciones

Modelado deprocesos

Modelado degestión

De 60 a 90 días

Modelado de gestión:� El flujo de información entre las funciones de gestión

se modela de forma que responda a las siguientes preguntas:

� ¿Qué información conduce el proceso de gestión? � ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

Modelado de datos:� El flujo de información definido como parte de la fase

de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa.

� Se definen las características (llamadas atributos) de � Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de proceso:� Los objetos de datos definidos en la fase de

modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. implementar una función de gestión.

� Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

Generación de Aplicaciones� El DRA asume la utilización de técnicas de cuarta

generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas de entrega

� Como el proceso DRA enfatiza la reutilización, ya se hancomprobado muchos de los componentes de los programas.Esto reduce tiempo de pruebas. Sin embargo, se debenEsto reduce tiempo de pruebas. Sin embargo, se debenprobar todos los componentes nuevos y se deben ejercitartodas las interfases a fondo. Obviamente la limitación detiempo impuestas en un proyecto DRA demanda "ámbito enescalas". Si una aplicación de gestión puede modularse seforma que permita completarse cada una de las funcionesprincipales en menos de tres meses (utilizando el enfoquedescrito anteriormente), es un candidato del DRA. Cada unade las funciones pueden ser afrontadas por un equipo DRAdiferente y ser integradas en un solo conjunto.

Desventajas� Al igual que todos los modelos de proceso, el enfoque DRA

tiene inconvenientes:� Para proyectos grandes aunque por escalas, el DRA requiere

recursos humanos suficientes como para crear el numero correcto de equipos DRA. correcto de equipos DRA.

� DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado.

� Si no hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasarán.

Desventajas� No todos los tipos de aplicaciones son apropiados para

DRA. Si un sistema no se puede modularizar adecuadamente , la construcción de los riesgos técnicos son altos.

� DRA no es adecuado cuando los riesgos técnicos son altos.� DRA no es adecuado cuando los riesgos técnicos son altos.� Esto ocurre cuando una nueva aplicación hace uso de

tecnologías, nuevas ,o cuando el software nuevo requiere un alto de interoperatividad con un programa de computadora ya existente.

� Se reconoce que el software al igualque todos los sistemas complejos,evoluciona con el tiempo.

� Los requisitos del sistema a menudocambian conforme a que el desarrolloproceda haciendo que el camino quelleva al producto final no sea real.

� Las estrictas fechas tope delmercado hacen que sea imposible

� Se reconoce que el software al igualque todos los sistemas complejos,evoluciona con el tiempo.

� Los requisitos del sistema a menudocambian conforme a que el desarrolloproceda haciendo que el camino quelleva al producto final no sea real.

� Las estrictas fechas tope delmercado hacen que sea imposible

Modelos de procesos Modelos de procesos Modelos de procesos Modelos de procesos evolutivos de softwareevolutivos de softwareevolutivos de softwareevolutivos de softwareModelos de procesos Modelos de procesos Modelos de procesos Modelos de procesos

evolutivos de softwareevolutivos de softwareevolutivos de softwareevolutivos de software

Las estrictas fechas tope delmercado hacen que sea imposiblefinalizar un sistema completo, por loque se debe introducir una versiónlimitada para cumplir la presióncompetitiva.

� Se comprende perfectamente elconjunto de requisitos de productoscentrales o del sistema, pero todavíase tienen que definir los detalles deextensiones del sistema.

Las estrictas fechas tope delmercado hacen que sea imposiblefinalizar un sistema completo, por loque se debe introducir una versiónlimitada para cumplir la presióncompetitiva.

� Se comprende perfectamente elconjunto de requisitos de productoscentrales o del sistema, pero todavíase tienen que definir los detalles deextensiones del sistema.

Modelo Incremental

� Combina elementos del modelolineal con la filosofía decreación de prototipos

� El primer incremento a menudo

� Combina elementos del modelolineal con la filosofía decreación de prototipos

� El primer incremento a menudo� El primer incremento a menudoes un producto esencial queel cliente utiliza o evalúa

� A partir de la evaluación seplanea el siguiente incrementoy así sucesivamente

� Es interactivo por naturaleza� Es útil cuando el personal noes suficiente para laimplementación completa.

� El primer incremento a menudoes un producto esencial queel cliente utiliza o evalúa

� A partir de la evaluación seplanea el siguiente incrementoy así sucesivamente

� Es interactivo por naturaleza� Es útil cuando el personal noes suficiente para laimplementación completa.

Análisis Diseño Código PruebasIncremento 1

Entrega de1.er incremento

Modelo Incremental

Análisis Diseño Código Pruebas



Tiempo de calendario

Entrega de2.o incremento

Entrega de3.er incremento

Entrega de4.o incremento

Incremento 2

Incremento 3

Incremento 4

Modelo Incremental

Modelo en Espiral

� Es un modelo de proceso desoftware evolutivo que acompañala naturaleza interactiva deconstrucción de prototipos conlos aspectos controlados y

� Es un modelo de proceso desoftware evolutivo que acompañala naturaleza interactiva deconstrucción de prototipos conlos aspectos controlados yconstrucción de prototipos conlos aspectos controlados ysistemáticos del modelo linealsecuencial.

� Durante las primeras iteraciones,la versión incremental podría serun modelo en papel o unprototipo.

� Durante las últimas iteraciones,se producen versiones cada vezmás completas de ingeniería desistemas.

construcción de prototipos conlos aspectos controlados ysistemáticos del modelo linealsecuencial.

� Durante las primeras iteraciones,la versión incremental podría serun modelo en papel o unprototipo.

� Durante las últimas iteraciones,se producen versiones cada vezmás completas de ingeniería desistemas.

Determine objetivosalternativas yrestricciones

Evalúe alternativas,identifique y resuelvariesgos

Análisis deRiesgos

Análisis de

Análisis deRiesgos

Análisis deRiesgos

AnálisisdeRiesgos

Planea la siguiente fase

Desarrolla y verificael siguiente nivel

del producto

PrototipoOperacionalPrototipo

3Prototipo2Proto

tipo 1

Plan de requerimientosPlan del ciclo de vida

REVISIÓN

Plan de Desarrollo

Plan de Integracióny Prueba

Concepto deOperación

Simulaciones, modelos y benchmarks

Requeri-mientos de

SWValidación deRequerimientos

DiseñoV &V

Servicio

Prueba deAceptación

Prueba deIntegración

Prueba deUnidades

Codificación

DiseñoDetallado

Diseñodel

Producto

� ComunicaciónComunicaciónComunicaciónComunicación conconconcon elelelel clienteclienteclientecliente:::: Paraestablecer comunicación entre eldesarrollador y el cliente.

� PlanificaciónPlanificaciónPlanificaciónPlanificación:::: Para definir los recursos, el

� ComunicaciónComunicaciónComunicaciónComunicación conconconcon elelelel clienteclienteclientecliente:::: Paraestablecer comunicación entre eldesarrollador y el cliente.

� PlanificaciónPlanificaciónPlanificaciónPlanificación:::: Para definir los recursos, el

Las tareas requeridasLas tareas requeridas

� PlanificaciónPlanificaciónPlanificaciónPlanificación:::: Para definir los recursos, eltiempo y otras informaciones relacionadascon el proyecto.

� AnálisisAnálisisAnálisisAnálisis dededede riesgosriesgosriesgosriesgos:::: Para evaluar riegostécnicos y operativos.

� IngenieríaIngenieríaIngenieríaIngeniería:::: Para construir una o másrepresentaciones de la aplicación.

� ConstrucciónConstrucciónConstrucciónConstrucción yyyy adaptaciónadaptaciónadaptaciónadaptación:::: Para construir,probar, instalar y proporcionar soporte alusuario (documentación y práctica).

� EvaluaciónEvaluaciónEvaluaciónEvaluación deldeldeldel clienteclienteclientecliente:::: Para obtener lareacción del cliente según la evaluación delas representaciones del software creadasdurante la etapa de ingeniería eimplementada durante la etapa deinstalación.

� PlanificaciónPlanificaciónPlanificaciónPlanificación:::: Para definir los recursos, eltiempo y otras informaciones relacionadascon el proyecto.

� AnálisisAnálisisAnálisisAnálisis dededede riesgosriesgosriesgosriesgos:::: Para evaluar riegostécnicos y operativos.

� IngenieríaIngenieríaIngenieríaIngeniería:::: Para construir una o másrepresentaciones de la aplicación.

� ConstrucciónConstrucciónConstrucciónConstrucción yyyy adaptaciónadaptaciónadaptaciónadaptación:::: Para construir,probar, instalar y proporcionar soporte alusuario (documentación y práctica).

� EvaluaciónEvaluaciónEvaluaciónEvaluación deldeldeldel clienteclienteclientecliente:::: Para obtener lareacción del cliente según la evaluación delas representaciones del software creadasdurante la etapa de ingeniería eimplementada durante la etapa deinstalación.

Espiral avanzado�Etapas�PLANIFICACIÓNANÁLISIS DE RIESGO�ANÁLISIS DE RIESGO

�INGENIERÍA�EVALUACIÓN DEL CLIENTE

Planificación

� Recolección de requisitos y planificación del proyecto inicial inicial

� Planificación basada en los comentarios del cliente� Evaluación del cliente

� EVALUACION DEL CLIENTE

Análisis de Riesgo

� Análisis de riesgo basado en los requisitos iniciales

� Análisis de riesgo basado en la reacción del cliente� Análisis de riesgo basado en la reacción del cliente

� Decisión de seguir o no

� Hacia el sistema final

� Prototipo inicial del software

� Prototipo del siguiente nivel

� Sistema de ingeniería

� INGENIERIA

Ventajas� Si es necesario repetir algún proceso, sólo se pierde el esfuerzo de una

iteración y no el valor del producto completo.

� Reduce el riesgo de no tener el producto en el mercado en la fecha deentrega pactada al comienzo del proyecto. Mediante la planificación delos riesgos más altos en las primeras fases del desarrollo, el tiempolos riesgos más altos en las primeras fases del desarrollo, el tiempoconsumido en resolverlos se invierte al principio del proceso cuando elequipo está menos apresurado.

� Acelera el ritmo del desarrollo global ya que los desarrolladorestrabajan de forma más eficiente cuando ven objetivos a corto plazo.

� Acepta el hecho de que las necesidades de los usuarios y por tanto losrequisitos, no se pueden definir completamente desde el principio, sinoque son refinados en iteraciones sucesivas.

Modelo de ensamble de componentes

� El modelo utiliza el marco detrabajo técnico del paradigmaorientado a objetos

� El modelo utiliza el marco detrabajo técnico del paradigmaorientado a objetosorientado a objetos

� Incorpora muchascaracterísticas del modelo enespiral

� La actividad de ingenieríacomienza con la identificaciónde clases candidatas

� Según estudios realizadoseste modelo:

✔ reduce el tiempo de desarrollo en un 70%

✔ reduce el costo del proyecto en un 84%

orientado a objetos� Incorpora muchascaracterísticas del modelo enespiral

� La actividad de ingenieríacomienza con la identificaciónde clases candidatas

� Según estudios realizadoseste modelo:

✔ reduce el tiempo de desarrollo en un 70%

✔ reduce el costo del proyecto en un 84%

Identificarcomponentes

candidatos

BuscarConstruir n

Modelo de ensamble de componentes

Buscarcomponentesen biblioteca

Extraercomponentes

si están disponibles

Construircomponentes

si no estándisponibles

Ponercomponentesnuevos en la

biblioteca

Construir ninteraccionesdel sistema

Bajodesarrollo

Modelo de desarrollo concurrente

Cambiosen espera

Bajorevisión

Cambiosen espera

En líneabase

Hecho

Representa un estado de unaactividad en ingeniería del software

Actividadesde análisis

CustomerCommunication

i

Planeaciónn Análisisde riesgo

Buscando clases en librerías

Extrayendo clases

Construyendo n-esima versión del sistema

Agregar

Identificandoclases candidatas

Comunicación con el cliente

Modelo del proceso orientado a objetos

CustomerEvaluation

IngenieríaConstrucción y rediseño

Extrayendo clases si estándisponibles

Ingeniería si las clases no disponibles

Agregar clase a las librerías

Análisis OODiseño OOCodificaciónOOPruebas OO

Evaluación del cliente

1.5 Importancia de las diferentes etapas del SW.

Ingeniería de SW VS Programación� La ingeniería de software es el proceso de construir

aplicaciones de tamaño o alcance prácticos, en las que predomina el esfuerzo del software y que satisfacen los requerimientos de funcionalidad y desempeño. La programación es una de las actividades de la ingeniería de programación es una de las actividades de la ingeniería de software. La diferencia entre la programación y la ingeniería de software se parece a la diferencia entre crear una mesa de jardín y crear un puente. Estos difieren mucho en el orden de magnitud y el conocimiento profesional requerido.

Actividades comunes para un proyecto de Ingeniería de SW

1.- Primero, es necesario entender la naturaleza del proyecto. Esto parece obvio, pero casi siempre lleva tiempo entender que desean los clientes, en especial cuando ellos mismo no saben por especial cuando ellos mismo no saben por completo que quieren. Debe entenderse la magnitud general del tiempo, los fondos y el personal disponible. Esto ayuda a aclarar el alcance del proyecto.

Actividades comunes para un proyecto de Ingeniería de SW2.- Los proyectos requieren documentación desde el

principio; es muy probable que esta documentación sufra muchos cambios. Por esta razón, desde el principio debe identificarse en un medio para mantener el control de los cambios tanto en los documentos como en el código. Este proceso, es conocido como administración de la cambios tanto en los documentos como en el código. Este proceso, es conocido como administración de la configuración. En seguida hay que desarrollar el plan global para el proyecto incluyendo la programación del calendario, este plan se va refinando durante la vida del proyecto conforme se conoce más de los requerimientos y el diseño.


3.- El siguiente paso es reunir los requerimientos para la aplicación. Gran parte de esta actividad consiste en conversar con los interesados, quienes tienen un interés en su resultado.interés en su resultado.


4.- El paso que sigue es el diseño e implementación del producto. Dependiendo del proceso de desarrollo que se use, es posible que los pasos 3 y 4 se repitan varias veces.veces.


5.- El producto inicial y el producto final deben probarse en forma exhaustiva de varias maneras.


6.- Una vez entregado el producto, entra el modo de mantenimiento, que incluye reparaciones y mejoras. El mantenimiento llega a consumir hasta el 80% de los recursos de ingeniería de software. recursos de ingeniería de software.

1.5.1. Análisis de SistemasEl análisis de sistemas implica determinar las necesidades del

cliente y /o usuario para poder especificar los requerimientos que sirvan como base para el desarrollo de un sistema o software siendo el "que" de un sistema informático. Esto se lleva a cabo teniendo en cuenta ciertos principios:

a) Debe presentarse y entenderse el dominio de la información de a) Debe presentarse y entenderse el dominio de la información de un problema.

b) Definir las funciones que debe realizar el Software.c) Representar el comportamiento del software a consecuencias de

acontecimientos externos. d) Divida en forma jerárquica los modelos que representan la

información, funciones y comportamiento.

1.5.1. Análisis de SistemasUn análisis de sistemas se lleva a cabo teniendo en cuenta los

siguientes objetivos en mente: Identificar las necesidadesdel cliente, evaluar los conceptos que tiene el cliente delsistema para establecer su viabilidad, realice un análisistécnico y económico, asignar funciones al hardware,software, personal, base de datos, y otros elementos deltécnico y económico, asignar funciones al hardware,software, personal, base de datos, y otros elementos delsistema, establezca las restricciones de presupuestos yplanificación temporal y crear una definición del sistemaque forme el fundamento de todo el trabajo de ingeniería.

1.5.2 Diseño de Sistemas� El Diseño del Software es un proceso y un

modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas.

Etapas del diseño de sistemas� La etapa del Diseño del Sistema consta de cuatro

etapas:� El diseño de los datos. Trasforma el modelo de dominio de la

información, creado durante el análisis, en las estructuras de información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software.

Etapas del diseño de sistemas� El Diseño Arquitectónico. Define la relación entre

cada uno de los elementos estructurales del programa.

� El Diseño de la Interfaz. Describe como se comunica � El Diseño de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean.

Etapas del diseño de sistemas� El Diseño de procedimientos. Transforma

elementos estructurales de la arquitectura delprograma. La importancia del Diseño delSoftware se puede definir en una sola palabraSoftware se puede definir en una sola palabraCalidad, dentro del diseño es donde se fomentala calidad del Proyecto. El Diseño es la únicamanera de materializar con precisión losrequerimientos del cliente.

1.5.2 Diseño de Sistemas� El diseño debe implementar todos los requisitos explícitos

contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente.

� Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el construyan el código y los que prueban y mantienen el Software y debe proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la implementación.

1.5.3 Prueba de sistemas� La prueba es un conjunto de actividades que se puede planificar

por adelantado y llevar acabo sistemáticamente. Por esta razón se debe definir en el proceso de la ingeniería de software una plantilla para la prueba de software: un conjunto de pasos en los que podamos situar los métodos de diseño de caso de prueba.

� La prueba es un proceso de ejecución de un programa con la � La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene una falta de probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

1.5.3 Prueba de sistemasEn el proceso de prueba existen dos conceptos que hay que

diferenciar: verificación y validación:� VERIFICACIÓN: Se refiere al conjunto de actividades que

asegure que el software se implementa correcta mente una función específica. ¿Estamos construyendo el producto función específica. ¿Estamos construyendo el producto correctamente?

� VALIDACIÓN: Se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. ¿Estamos construyendo el producto correcto?

1.5.4 Mantenimiento de Sistemas� Cuando un sistema es instalado en un ambiente que cambia, el ambiente

produce cambios en los requerimientos. Los sistemas deben tener mantenimiento si se quiere que sean útiles en el ambiente.

� El mantenimiento se puede dar a lo largo de todo el ciclo de vida utilizando una metodología de desarrollo para sistemas evolutivos, esto es debido a que usualmente es mas caro añadir funcionalidad después de que el sistema ha sido desarrollado, en vez de hacerlo cuando el sistema se esta que usualmente es mas caro añadir funcionalidad después de que el sistema ha sido desarrollado, en vez de hacerlo cuando el sistema se esta diseñando; el personal de mantenimiento a menudo no tiene experiencia o no esta familiarizado con el dominio de la aplicación; los programas pueden estar pobremente estructurados y difíciles de entender y porque además los cambios pueden introducir nuevas fallas si el sistema se hace más complejo. También es importante mencionar que el mantenimiento debe darse a lo largo de todo el proceso de desarrollo porque la estructura del software puede degradarse debido a cambios continuos y puede no haber documentación disponible que describa el software.

1.5.4 Mantenimiento de Sistemas� El mantenimiento se debe o se invoca debido a cambios

pedidos por los clientes o por los requerimientos del mercado. Los cambios normalmente se atienden en orden de pedido y se implementan en una nueva versión del sistema. Los programas algunas veces necesitan ser sistema. Los programas algunas veces necesitan ser reparados sin que se realice una iteración completa del proceso, lo cual provoca problemas ya que la documentación y los programas se desactualizan.

Fin de la Unidad !!!

Evaluación� 25 puntos por fin de semana

� exposición (15 exponer + 10 presentación digital)

� Firmas por actividad

Lic. Cesar Espinoza Jiménez · PDF fileIngeniería del Software : Un enfoque...

Documents

Transcript of Lic. Cesar Espinoza Jiménez · PDF fileIngeniería del Software : Un enfoque...