Ingeniera de Software

Unidad 1 - Introduccin, Arquitecturas y metodologas para la construccin del Sw. Conocer las diferentes metodologas de desarrollo de software para distinguir en que proyectos pueden aplicarse. Unidad 2 - Gestin de Proyectos de Sw. Aplicar los conceptos sobre gestin de proyectos al iniciar la planeacin de un proyecto de sw. Unidad 3 - Planeacin de Proyectos de Sw. Aplicar los conceptos sobre planeacin para realizar estimaciones de recursos, tamao y costos de un proyecto de sw, identificar las herramientas CASE. Unidad 4 - Anlisis y Gestin de Riesgo, Calidad del Sw. Aplicar los conceptos sobre anlisis, gestin de riesgo y calidad del software para identificar los riesgos que amenazan el proyecto y garantizar la eficiencia del software.

Bibliografa 1. Pressman Roger S., Ingeniera de Software. Un enfoque prctico, 5ta. Edicin, McGraw Hill, 2004. 2. Ian Summerville, Ingeniera de Software 8 Edicin, Pearson Adisson Wesley 3. Shari Lawrence Pfleeger Ingeniera de Software, Teora y Prctica, Prentice Hall, 2002, Argentina 4. Bernard Bruegge, Ingeniera de Software. Orientada a Objetos, 1ra Edicin, Prentice Hall, 2002 5. Richard E Fairley. Ingeniera de sw . McGraw Hill, 1988.

UNIDAD DE COMPETENCIA I
Introduccin, Arquitecturas y metodologas para la construccin del Sw. 1.1 Introduccin El software de computadora es un conjunto de programas, instrucciones y reglas informticas para ejecutar ciertas tareas en una incluye programas que se ejecutan dentro de una computadora de cualquier tamao y arquitectura Es importante porque afecta cualquier aspecto de nuestra vida diaria, y est muy extendido en nuestro comercio, cultura y en nuestras actividades cotidianas. Para construir software de calidad se debe aplicar un enfoque de Ingeniera de Software. Propsito General de la Unidad Conocer las diferentes metodologas de desarrollo de software para distinguir en que proyectos pueden aplicarse.

ORGANIZADOR AVANZADO DE LA UNIDAD DE COMPETENCIA

Unidad de competencia I Introduccin, Arquitecturas y metodologas para la construccin del Sw. Contenido Temtico 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 La evolucin del sw el modelo secuencial lineal el modelo de prototipos el modelo RAD el modelo incremental el modelo en espiral el modelo de ensamblaje de componentes el modelo de 4 Generacin el modelo de mtodos formales El futuro del sw

Unidad 1

1.1 Actividad Previa

Ahora que conoces que existen diferentes metodologas de desarrollo de sw Entra al foro para escuchar la opinin de tus compaeros y emite una opinin en tus propias palabras. Para que sirve la Ingeniera de Sw, cul es su aportacin a la Informtica? Qu metodologa te resulta conocida y porque ? Tema 1.1 La evolucin del sw Evolucin del Desarrollo del Software

El software ha superado al hardware como la clave del xito de muchos sistemas basados en computadora: Durante las 3 primeras dcadas, el principal desafo era el desarrollo del hardware de las computadoras, de forma que se redujera el costo, y se aumentara el almacenamiento. El problema de hoy es diferente. El principal desafo es mejorar la calidad del software y reducir costos, de las soluciones basadas en computadoras que se implementan con software. Lnea del tiempo haz clic o posiciona el mouse sobre cada etapa para conocer la evolucin de sw en el tiempo. 3 Etapa 2 Etapa 1 Etapa 4 Etapa

1950

1960

1970

1980

1990

2000

Tecnologas: Realizar una animacin que despliegue en la parte inferior de la grfica la informacin de cada etapa al posicionar el mouse sobre cada una. 1 Etapa Hardware de propsito especial Software a la medida Distribucin de software, relativamente pequea. La misma persona lo diseaba, lo escriba y lo ejecutaba. No exista documentacin 2 Etapa Ya hubo software como producto Es decir los sistemas ya se vendan, porque haba familias de computadoras en diferentes organizaciones entonces, los sistemas se podan instalar en diferentes computadoras y se podan vender. Aparecieron casas de software. Es decir empresas que se dedicaron a proveer del sw que empleaban las computadoras en las organizaciones, tanto del sw de base como de los sistemas que se empleaban en las organizaciones Apareci el mantenimiento de software 3 Etapa Proceso distribuido (mltiples computadoras, cada una ejecutando funciones concurrentemente y comunicndose con alguna otra). La llegada y amplio uso de los microprocesadores y las computadoras personales. En muchos casos la tecnologa del software es integrada en stos productos por equipos tcnicos que conocen el hardware pero que a menudo no tienen experiencia en el desarrollo del software. Hardware de bajo costo. Impacto Incremento en el consumo (+ en hardware que en software) del hardware a comparacin de software 4 Etapa. Arquitecturas de clculo totalmente diferentes y su correspondiente software tendrn un profundo impacto en el equilibrio de la potencia poltica e industrial de todo el mundo. Por fin, los sistemas expertos y el software de Inteligencia Artificial se han trasladado del laboratorio a las aplicaciones prcticas.

Conforme nos movemos hacia la 4 Etapa, continan intensificndose los problemas asociados con el software de computadoras (tambin llamada crisis del software): La sofisticacin del hardware ha dejado desfasada nuestra capacidad de construir software que pueda explotar el potencial del Hardware. La capacidad de construir nuevos programas, no da abasto a la demanda de stos. Nuestra capacidad de mantener los programas existentes est amenazada por el mal diseo y uso de recursos inadecuados.

Como respuesta a la crisis del software, muchas industrias estn adoptando prcticas de ingeniera de software.

Paradigmas de la Ingeniera del Sw La Ingeniera del Software est compuesta por una serie de pasos que abarcan los mtodos, las herramientas y los procedimientos para el desarrollo de software. Estos pasos se denominan frecuentemente Paradigmas de la ingeniera de software. La eleccin del paradigma se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicacin, los mtodos y herramientas a usar y los controles y entregas requeridos. Los paradigmas de la ingeniera de sw son 1. 2. 3. 4. 5. 6. 7. 8. modelo secuencial lineal modelo de prototipos modelo RAD modelo incremental modelo en espiral modelo de ensamblaje de componentes modelo de 4 Generacin modelo de mtodos formales

1.2 El modelo secuencial lineal

El ciclo de Vida Clsico Modelo Secuencial Lineal

Anlisis Ingeniera de sistemas

Diseo

Cdigo Prueba

El ciclo de vida clsico es el paradigma ms antiguo y ms ampliamente usado en la Ingeniera de Software. Caractersticas de este paradigma: Los proyectos o desarrollos raramente siguen el flujo secuencial que propone el modelo. Porque la informacin no fluye de la misma forma que en la grfica, porque las etapas no estn as de definidas en el tiempo. Es difcil para el cliente establecer explcitamente al principio todos los requisitos, an si tiene la experiencia de trabajar con sistemas porque no sabe que producto tendr al finalizar. El cliente debe tener paciencia. Hasta llegar a etapas finales del desarrollo del proyecto no estar disponible una versin operativa de este programa. Los errores importantes no sern detectados hasta que el programa est funcionando, esto es hasta las fases finales de desarrollo y esto puede ser desastroso.

1.3 El modelo de prototipos

Es una metodologa que facilita al programador la tarea del modelado del software. El modelo tomar una de las siguientes formas: 1.- Un prototipo en papel o un modelo basado en PC que describa la interaccin hombre-mquina, de forma que facilite al usuario la comprensin. 2.- Un prototipo que implemente algunas partes de la funcin requerida del programa. 3.- Un programa que ejecute parte o toda la funcin deseada, pero que tenga otras caractersticas que deban ser mejoradas en el nuevo trabajo de desarrollo.

Escuchar al Cliente Construir / revisar prototipo

El cliente prueba la maqueta

Creacin de Prototipos Este modelo tiene varias etapas: Escuchar al cliente. En esta etapa realizamos las entrevistas con el cliente, realizamos el anlisis de su sistema, y regresamos a esta etapa tantas veces como se necesite para realimentar el sistema con los comentarios del cliente. Construir/Revisar prototipo. El equipo de desarrollo realiza un sistema rpido para ser probado por el cliente, con la intencin de recoger de manera ms objetiva comentarios del cliente acerca del sistema, el sistema es un desarrollo rpido, que no est bien construido, desarrollado exclusivamente para que el usuario lo pueda observar y comentar. Prueba de la maqueta. El usuario observa el sistema para realizar comentarios despus. Caractersticas :

1.- El cliente ve funcionando algo que no est terminado o que no cumple con sus requerimientos?, y quiere que as se quede, y a menudo los diseadores se dejan influenciar por los deseos del cliente y se concede demasiada importancia a aspectos menos funcionales, y se resta importancia a los aspectos tcnicos, que debera ser lo mas importante. 2.- El tcnico de desarrollo, frecuentemente impone ciertos compromisos con el fin de obtener un prototipo que funcione rpidamente. Despus de algn tiempo, el tcnico puede haberse olvidado de las razones por las que eran inapropiados y al final la eleccin menos ideal forma parte integral del sistema. La construccin de prototipos es un paradigma efectivo, la clave est en definir al comienzo las reglas del juego; que el cliente y el tcnico estn de acuerdo en que el prototipo se construya para servir slo como un mecanismo de definicin de requisitos. Posteriormente ha de ser descartado y debe construirse el software real, pensando en calidad y mantenimiento. FIN DE NODO INICIO DE NODO

1.4 el modelo de RAD

El Desarrollo Rpido de Aplicaciones (Rapid Aplication Development) es un modelo de proceso de desarrollo del software lineal secuencial, que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo es una adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rpido utilizando un enfoque de construccin basado en componentes. Si se comprenden bien los requisitos y se limita el mbito del proyecto, el proceso RAD permite crear un sistema completamente funcional dentro de perodos cortos (60 a 90 das). Utilizado principalmente para aplicaciones de sistemas de informacin. Modelo RAD Equipo no 2 Equipo no. 1
Modelado de gestin

Equipo no. 3
Modelad o de gestin Modelado de Datos

Modelado de gestin

Modelado de Datos Modelado de Procesos

Modelado de Procesos

Modelado de Datos

Generaci n de Aplicacion es Pruebas y Volumen

Generacin de Aplicaciones

Modelado de Procesos

Pruebas

Generacin de Aplicaciones

Pruebas

De 60 o 90 das

Comprende las siguientes fases:

Modelado de Gestin.- El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas Qu informacin se genera?, Quin la genera? Modelado de datos.- El flujo de informacin generado anteriormente se refina, se definen las caractersticas (atributos) de cada uno de los objetos y las relaciones entre stos. Modelado del Proceso.- Los objetos de datos definidos en la fase anterior para lograr el flujo de informacin necesario para implementar la funcin de gestin (aadir, modificar, suprimir o recuperar un objeto de datos). Generacin de Aplicaciones.- El RAD asume la utilizacin de tcnicas de cuarta generacin. El RAD trabaja para volver a utilizar componentes de programas ya existentes o crear programas reutilizables. Pruebas y Entrega. Como el proceso RAD enfatiza la reutilizacin, se han comprobado muchos de los componentes reduciendo tiempo de pruebas.

Caractersticas: Para proyectos grandes, el RAD requiere de recursos humanos suficientes como para crear el nmero correcto de equipos de RAD. Esto significa que si se quiere desarrollar un proyecto de 5 mdulos, se necesitan 5 equipos para asignarle a cada equipo un mdulo de desarrollo. Requiere de clientes y desarrolladores comprometidos en las rpidas actividades necesarias, sin esto fracasa. No todos los tipos de aplicaciones son apropiados? para RAD. Si un sistema no se puede modularizar adecuadamente, la construccin de los componentes necesarios para RAD ser problemtico. No es adecuado cuando los riesgos tcnicos son altos (uso de tecnologas nuevas, o se requiere un alto grado de interoperatividad con programas de computadora ya existentes). Enfatiza el desarrollo de componentes reutilizables.

1.5 Modelo Incremental Ese modelo pertenece a los modelos de procesos Evolutivos de Software y de este mtodo en adelante las metodologas contemplan la evolucin del sw. Se reconoce que el software al igual que todos los sistemas complejos evolucionan con el tiempo. Las personas que desarrollan software necesitan un modelo de proceso que se haya diseado explcitamente para acomodarse a un producto que evolucione con el tiempo. Los modelos evolutivos son iterativos, se caracterizan porque permiten desarrollar versiones cada vez ms completas del software. Caractersticas del Modelo Incremental Combina elementos del modelo secuencial lineal, con la filosofa iterativa del modelo de prototipos. Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial, cubre requisitos bsicos. Como un resultado de utilizacin se desarrolla un plan para el incremento siguiente. A diferencia del de prototipos, se centra en la entrega de un producto operacional, con cada incremento. Este modelo es particularmente til cuando no hay muchas personas para la entrega del proyecto. Se pueden planear mejor para gestionar los riesgos tcnicos.

Diagrama del Modelo Incremental

ingeniera_de sistemas/informacin n Anlisis Diseo

incremento 1

Cdigo

Prueba

entrega de incremento entrega de incremento

1er

Anlisis

Diseo

Cdigo

Prueba

2o

Anlisis

Diseo

Cdigo

Prueba

entrega de incremento

3er

Anlisis

Diseo

Cdigo

entrega de Prueba incremento

4o

Tiempo de calendario

1.6 Modelo en Espiral Es un modelo de proceso de software evolutivo que acompaa la naturaleza interactiva de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Se proporciona el potencial para el desarrollo rpido de versiones incrementales del software. El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de tareas, como lo muestra la siguiente imagen: Haz clic para comenzar; Planeacin Comunicacin con el cliente Anlisis de riesgos

Ingeniera Evaluacin del cliente Construccin y adaptacin

Comunicacin con el cliente.- Se refiere a las tareas requeridas para establecer comunicacin entre desarrollador y el cliente. Planeacin.- Tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Anlisis de riesgos.- Tareas requeridas para evaluar riesgos tcnicos y de gestin. Ingeniera.- Tareas requeridas para construir la aplicacin. Construccin y adaptacin.- Para construir, probar, instalar y proporcionar soporte al usuario (ejemplo: documentacin y prctica)

 Evaluacin del cliente.- Tareas requeridas para obtener la reaccin del cliente. Modelo en espiral tpico El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El modelo en espiral utiliza la construccin de prototipos como mecanismo de reduccin de riesgos, permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto. Este modelo es relativamente nuevo.

1.7 Modelo de Ensamblaje de Componentes Las tecnologas de objetos proporcionan el marco de trabajo tcnico para un modelo de proceso basado en componentes para la Ingeniera del Software. El paradigma de orientacin a objetos enfatiza la creacin de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones de sistema basadas en computadora.

Planeacin Comunicacin con el cliente Anlisis de riesgos Identificar componentes candidatos Construir n interacciones del sistema Buscar componentes en biblioteca

Evaluacin del cliente

Construccin y adaptacin de la El modeloIngeniera ensamblador de componentes lleva a la reutilizacin del software, y la reutilizacin

poner componentes nuevos en la biblioteca

Extraer componentes si estn disponibles

construir componentes si no estn disponibles

proporciona beneficios a los ingenieros del software. Segn estudios de reutilizacin se dice que 1 ensamblaje de componentes lleva a una reduccin del 70% de tiempo de ciclo de desarrollo, un 84 % por ciento del costo del proyecto. Aunque estos resultados estn en funcin de la robustez de la biblioteca de componentes. 1.8 Modelo de 4. Generacin Las Tcnicas de Cuarta Generacin (T4G) abarcan un amplio espectro de herramientas de software que tienen algo en comn: todas facilitan la especificacin de software de alto nivel. Luego la herramienta genera automticamente el cdigo fuente basndose en la especificacin del tcnico. Cada vez parece ms evidente que cuanto mayor sea el nivel en el que se especifique el software, ms rpido se podr construir el programa. Actualmente un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas : lenguajes no procedimentales de consulta a base de datos, generacin de informes, manejo de datos, interaccin y definicin de pantallas, generacin de cdigos , capacidades grficas de alto nivel y capacidades de hoja de clculo. Para aplicaciones pequeas se puede ir directamente desde el paso de recoleccin de requisitos al paso de implementacin, usando un lenguaje de cuarta generacin no procedimental. Ejemplos de lenguajes de 4 generacin , informix, Los lenguajes SQL y QBE son ejemplos de 4GL. Hay otros tipos de lenguajes de 4G: Un generador de formularios es una herramienta interactiva que permite crear rpidamente formularios de pantalla para introducir o visualizar datos. Un generador de informes es una herramienta para crear informes a partir de los datos almacenados en la base de datos. Se parece a un lenguaje de consultas en que permite al usuario hacer preguntas sobre la base de datos y obtener informacin de ella para un informe. Sin embargo, en el generador de informes se tiene un mayor control sobre el aspecto de la salida. Un generador de grficos es una herramienta para obtener datos de la base de datos y visualizarlos en un grfico mostrando tendencias y relaciones entre datos. Normalmente se pueden disear distintos tipos de grficos: barras, lneas, etc.

Un generador de aplicaciones es una herramienta para crear programas que hagan de interface entre el usuario y la base de datos.

El uso de T4G sin diseo para grandes proyectos causar las mismas dificultades (poca calidad, mantenimiento pobre, mala aceptacin por el cliente) que se encuentran cuando se desarrolla software mediante los enfoques convencionales.

El uso de T4G ha crecido considerablemente en la ltima dcada y ahora es un enfoque viable para muchas de las diferentes reas de aplicacin. Junto con las herramientas de software asistido por computadora (CASE) y los generadores de cdigo, T4G ofrece una solucin fiable a muchos problemas del software. Los datos recogidos en compaas que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeas y de tamao medio, y que la cantidad de anlisis, diseo para las aplicaciones pequeas tambin se reduce. Sin embargo el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o ms tiempo de anlisis, diseo y prueba, perdindose as un tiempo sustancial que se ahorra mediante la eliminacin de la codificacin. Modelo de mtodos formales

1.9

Acompaa a un conjunto de actividades que conducen a la especificacin matemtica del software de computadora. Los mtodos formales permitan, que se especifique, desarrolle y verifique un sistema basado en computadora aplicando una notacin rigurosa y matemtica, algunas organizaciones de desarrollo de software aplican una variacin de este enfoque, llamado Ingeniera de Software de Sala Limpia. Cuando se utilizan mtodos formales durante el desarrollo, proporcionan un mecanismo para eliminar muchos de los problemas que son difciles de superar con otros paradigmas de ingeniera de software. La ambigedad, lo incompleto y la inconsistencia se descubren y se corrigen ms fcilmente, no mediante una revisin a propsito, sino mediante la aplicacin del anlisis matemtico. Los mtodos formales ofrecen la promesa de software libre de defectos. Es bastante caro y lleva mucho tiempo. Pocos desarrolladores tienen los antecedentes para formales. aplicar mtodos

 Es difcil utilizar los modelos como un mecanismo de comunicacin con clientes que no tienen muchos conocimientos tcnicos. Es probable que tenga ms partidarios entre desarrolladores que tengan que construir software con mucha seguridad.

1.10 El futuro del Sw La tecnologa del software y de sistemas sigue siendo todo un desafo para los profesionales del software y para toda compaa que construya sistemas basados en computadoras. Siempre que una tecnologa tiene un impacto amplio, un impacto que puede salvar vidas o ponerlas en peligro, construir negocios o destruirlos, informar a los jefes de gobierno o confundirlos, es preciso manejarlos con cuidado. El nuevo Proceso del Software: El software que se desarrollaba en las dos primeras dcadas de la prctica de la Ingeniera de Software, era de tipo lineal, sin embargo ste enfoque no funciona actualmente, ahora los sistemas complejos se desarrollan de manera evolutiva, incremental. La utilizacin de tecnologas orientadas a objetos es un resultado natural de la tendencia a modelos de procesos evolutivos. Los ensamblajes basados en la reutilizacin de componentes tendrn un profundo impacto en la productividad del desarrollo del software y la calidad del producto. La reutilizacin de componentes proporciona beneficios inmediatos, y cuando sta se usa con herramientas CASE se logran desarrollos ms rpidos, que mediante los mtodos convencionales. Nuevos modos para representar la informacin Hace veinte aos el trmino procesamiento de datos era la frase operativa para describir la utilizacin de computadoras en un contexto de negocios. En la actualidad el proceso de datos ha dado lugar a otra frase: tecnologa de la informacin, que implica lo mismo pero que ha dado un sutil desplazamiento del centro de nuestra atencin. La importancia ya no est en procesar grandes cantidades de datos sino ms bien en extraer informacin significativa a partir de stos datos.

Hasta la fecha la mayora del software que se ha construido tena como misin procesar datos o informacin. La Ingeniera de Software del siglo XXI seguir preocupada por sistemas que procesen conocimiento. El conocimiento es bidireccional. La informacin recogida acerca de una amplia gama de temas relacionados y aparentemente no relacionados se relaciona para formar un cuerpo de hechos al que se denomina conocimiento. La clave es nuestra capacidad para asociar informacin de una gama de fuentes distintas que puedan no poseer conexiones evidentes entre s, y combinarlas, de modo que nos proporcione algn beneficio definido. Hemos estado procesando datos durante casi cuarenta aos, y se ha extrado informacin durante ms de dos dcadas. Uno de los desafos ms significativos, consiste en construir sistemas que den el paso siguiente en el espectro: sistemas que extraigan el conocimiento de los datos en formacin de forma que sea prctica y beneficiosa. El espectro de la informacin muestra la manera en la que la informacin se puede presentar y la manera en la que los sistemas han evolucionado, en su manera de representarla.

Espectro de informacin.

Datos: No hay asociatividad

Informacin: Asociatividad en un slo contexto.

Conocimiento: Asociatividad entre Contextos mltiples

Sabidura: Creacin de principios generalizados basndose en el conocimiento procedente de distintas fuentes

La tecnologa como impulsor Las personas que construyen y utilizan software, el proceso de Ingeniera del Software que se aplica y la informacin que se produce se ven afectados todos ellos por los avances de la tecnologa del software y hardware. Histricamente el hardware ha sido el impulsor de la tecnologa en computacin. La Ingeniera de Software va a cambiar, de eso podemos estar seguros, pero independientemente de los cambios podemos estar seguros de que la calidad nunca perder importancia y de que anlisis y diseo, efectivos y una comprobacin competente siempre tendrn un lugar en el desarrollo de sistemas basados en computadoras. Bibliografa 6. Pressman Roger S., Ingeniera de Software. Un enfoque prctico, 5ta. Edicin, McGraw Hill, 2004. 7. Shari Lawrence Pfleeger Ingeniera de Software, Teora y Prctica, Prentice Hall, 2002, Argentina 8. Bernard Bruegge, Ingeniera de Software. Orientada a Objetos, 1ra Edicin, Prentice Hall, 2002 9. Richard E Fairley. Ingeniera de sw . McGraw Hill, 1988.