Ingeniera de SoftwareUNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BASICAS, TECNOLOGA E INGENIERIA PROGRAMA INGENIERIA DE SISTEMAS MODULO

Ingeniera de SoftwareAutor: Ing. Alexandra Aparicio Revisado y Editado: Ing. Jairo Martnez

ltima Actualizacin:Ing. Pilar Alexandra Moreno Enero 2012

1

Ingeniera de SoftwareTabla de Contenido INTRODUCCIN PRIMERA UNIDAD. INTRODUCCIN A LA INGENIERA DEL SOFTWARE INTRODUCCIN 1. EL PRODUCTO 1.1 El producto 1.2 Evolucin del Software 1.3 El software 1.4 Aplicaciones del Software 1.5 Mitos del Software 2. EL PROCESO 2.1 Definicin de Ingeniera del software 2.2 Esquema de la Ingeniera del Software 2.3 Esencia de la Ingeniera del Software 2.4 Procesos, mtodos y herramientas 2.5 El proceso del software 3. MODELOS DE PROCESO DE SOFTWARE 3.1 Modelo lineal secuencial 3.2 Modelo de construccin de prototipos 3.3 Modelo DRA 3.4 Modelos de procesos evolutivos de software 3.5 Modelo de mtodos formales y Tcnicas de cuarta generacin SEGUNDA UNIDAD. GESTIN Y PLANIFICACIN DE PROYECTOS SOFTWARE INTRODUCCIN 1. CONCEPTOS SOBRE GESTIN DE PROYECTOS 1.1 Gestin de proyectos 1.2 Personal 1.3 El producto 1.4 El proceso 1.5 El proyecto 2. EL PROCESO DE SOFTWARE Y MTRICAS DEL PROYECTO 2.1 Mtricas en el proceso y dominios del proyecto 2.2 Mejora estadstica del proceso del software 2.3 Mtricas del proyecto 2.4 Mediciones del software 2.5 Mtricas para la calidad del software 3. PLANIFICACION DE PROYECTOS DE SOFTWARE 3.1 mbito del software y Recursos 2 Pg. 4 6 6 7 7 8 9 9 11 13 13 15 16 17 19 20 20 22 25 27 31 34 34 35 35 36 38 39 40 42 43 45 48 49 53 58 Pg. 59

Ingeniera de Software3.2 Estimacin del proyecto de software y Tcnicas de Descomposicin 3.3 Modelos empricos de Estimacin 3.4 Riesgo del Software 3.5 Planificacin temporal del proyecto TERCERA UNIDAD. CONTROL DE CALIDAD DEL SOFTWARE INTRODUCCIN 1. GARANTIA DE CALIDAD DEL SOFTWARE 1.1 Conceptos de calidad 1.2 Tendencia de la calidad 1.3 Garanta y aseguramiento de la calidad del software 1.4 Revisiones del software 1.5 Garanta de calidad estadstica, Fiabilidad y Estndar ISO 9001 2. TECNICAS DE PRUEBA DEL SOFTWARE 2.1 Fundamentos de la prueba del software 2.2 Diseo de casos de prueba, pruebas de la caja blanca y del camino bsico 2.3 Prueba de la estructura de control 2.4 Prueba de caja negra 2.5 Prueba de entornos especializados, arquitecturas y aplicaciones 3. ESTRATEGIAS DE PRUEBA DEL SOFTWARE 3.1 Enfoque estratgico la prueba del software 3.2 Prueba de unidad 3.3 Pruebas de integracin del sistema 3.4 Mtricas tcnicas del software 3.5 Mtricas del modelo del software RECURSOS DE SOFTWARE LIBRE PARA INGENIERA DEL SOFTWARE RECURSOS BIBLIOTECA VIRTUAL UNAD BIBLIOGRAFA 61 64 70 80 89 89 90 91 94 96 97 101 109 109 111 114 115 116 119 119 124 126 132 139 147 154 157

3

Ingeniera de SoftwareINTRODUCCIN El curso Ingeniera de Software tiene como objetivo desarrollar habilidades y adquirir capacidades en la utilizacin de mtodos y tcnicas para desarrollar y mantener software de calidad. El curso tiene 3 crditos acadmicos los cuales comprenden el estudio independiente y el acompaamiento tutorial, con el propsito de:

Comprender los aspectos tcnicos y de gestin de la disciplina de ingeniera de software. Capacitar a los estudiantes en las tcnicas de gestin necesarias para planificar, organizar, supervisar y controlar proyectos de software. Fomentar en el estudiante tcnicas de gestin de calidad del software. Obtener un conjunto de tcnicas de prueba de software con el propsito de encontrar y corregir errores antes de entregar el software al cliente.

Este curso esta compuesto por tres unidades didcticas a saber: Unidad 1. Introduccin a la ingeniera de software: se presenta una vista general sobre la definicin de: ingeniera de software, producto de software, procesos de software, se determina las caractersticas del software, los mitos del software. Se presenta tambin los diferentes tipos de proceso y los modelos evolutivos del software. Unidad 2. Gestin y planificacin de proyectos de software: se trata de determinar como se debe gestionar el personal, el proceso y el problema durante un proyecto de software. Se identifican las mtricas de software y cmo pueden emplearse para gestionar el proceso de software y el proyecto llevado a cabo como parte del proceso. Unidad 3. Control de calidad del software: se contemplan los aspectos relacionados con la calidad del software, se identifican los aspectos de gestin y las actividades especficas del proceso de calidad del software. Se establece la importancia de la garanta de calidad del software as como se definen las estrategias para los planes de garanta de calidad del software.

4

Ingeniera de SoftwareLa ingeniera de software es el proceso de construir aplicaciones de tamao o alcance prcticos, en las que predomina el esfuerzo del software y que satisfacen los requerimientos de funcionalidad y desempeo. La ingeniera de software, ofrece mtodos y tcnicas para desarrollar, mantener, producir y asegurar software de calidad. Por tal razn, este curso terico pretende describir los aspectos tcnicos y de gestin de la Ingeniera de Software, as como de establecer la importancia de la garanta de calidad del software.

5

Ingeniera de Software

UNIDAD 1. INTRODUCCIN A LA INGENIERA DEL SOFTWAREINTRODUCCIN La ingeniera de software es una disciplina que integra procesos, mtodos y herramientas para el desarrollo de software. Varios son los modelos de procesos que se han propuesto para la ingeniera de software, cada uno presenta ventajas y desventajas, pero todos tienen en comn fases genricas que permiten llevar a cabo el proceso de la ingeniera de software.

OBJETIVOS GENERAL Comprender los aspectos tcnicos y de gestin de la disciplina de Ingeniera del Software

ESPECIFICOS Definicin de Ingeniera de software, producto de software, procesos de software. Identificar los mitos de software Determinar que es un proceso de software Identificar los procesos que se pueden aplicar al desarrollo del software Determinar la diferencia entre modelos de proceso lineales e iterativos

6

Ingeniera de SoftwareESTRUCTURA TEMTICA 1. EL PRODUCTO 1.1 Definicin del Producto Software. El software es el producto que disean y construyen los ingenieros del software de cualquier tamao y arquitectura.

El Software es importante

Porque

Afecta las actividades cotidianas Afecta cualquier aspecto de nuestras vidas Est muy extendido en el comercio

El producto obtenido (software)Desde

El punto de vista del Ingeniero del Softwarees El conjunto de programas, documentos y los datos que configuran el software de computadora

El punto de vista del Usuario

es La informacin resultante que hace el mundo mejor.

1.2 La evolucin del Software 7

Ingeniera de SoftwarePrimeros Aos 19501

Segunda Era 1960 1970

Tercera Era 1980 1990

Cuarta Era 2003

Primeros Aos El software estaba en su infancia El software era un aadido Existan pocos mtodos para la programacin No se tenia una planificacin para el desarrollo del software Los programadores trataban de hacer las cosas bien El software se diseaba a medida El software era desarrollado y utilizado por la misma persona u organizacin (entorno personalizado) El diseo de software era realizado en la mente de alguien y no exista documentacin

Segunda era Aparece la multiprogramacin y los sistemas multiusuario Establecimiento del software como producto y la llegada de las casas de software El software se desarrollaba para ser comercializado Se empez a distribuir software para grandes computadoras y minicomputadores Comenz a extenderse las bibliotecas de software El mantenimiento de software comenz a absorber recursos en una gran medida. Comenz una crisis del software porque la naturaleza personalizada de los programas hizo imposible su mantenimiento. Tercera era Cuarta era Complejidad alta en los sistemas Impacto colectivo del software informticos Sistemas operativos operativos Sistemas distribuidos sofisticados , en redes globales y locales Incorporacin de inteligencia Aplicaciones de software avanzadas Ejecucin de funciones concurrentes Entorno cliente/cliente servidor Desarrollo de software para redes y Superautopista de informacin y una comunicaciones conexin del ciberespacio Planificacin en el proceso del desarrollo La industria del software es la cuna de la de software economa Tecnologas orientadas a objetos Tcnicas de cuarta generacin para el desarrollo de software Software de redes neuronales Sistemas expertos e inteligencia artificial1

Roger S. Pressman. Ingeniera del software. Un enfoque prctico. Cuarta edicin.

8

Ingeniera de Software Programacin de realidad virtual y sistemas multimedia Algoritmos genticos Adopcin de prcticas de Ingeniera del software 1.3 El Software El software se ha convertido en el elemento clave de la evolucin de los sistemas y productos informticos, y por tal razn no se puede tomar como slo el conjunto de programas, instrucciones y estructuras de datos. A continuacin se presentan algunas caractersticas que permiten visualizar lo que en realidad es el software. Caractersticas del Software Se desarrolla, no se fabrica: se utiliza un modelo de proceso de desarrollo que comprende anlisis, diseo, desarrollo, implementacin y evaluacin para obtener un producto de calidad. El software No se estropea, pero se deteriora: El software durante su vida sufre cambios por lo que es probable que surjan fallos y defectos que si no se corrigen permiten que el software se vaya deteriorando. Se construye a medida: a medida que el software evoluciona se crean estndares de diseo. El software debe disearse e implementarse para que pueda ser reutilizable.

1.4 Aplicaciones del software El software tiene una gran amplitud de aplicaciones. A continuacin se relacionan: Software de sistemas Conjunto de programas creados como herramienta para otros programas. Por ejemplo: compiladores, Sistemas operativos Software de gestin

Gestin de grandes cantidades de informacin almacenadas, para facilitar la toma de decisiones. Por ejemplo Bases 9 datos y aplicaciones de gestin de de empresa

Ingeniera de Software

Software de ingeniera y cientfico

Utiliza algoritmos de manejo de nmeros, simulacin de sistemas, utiliza software en tiempo real. Por ejemplo: aplicaciones de astronoma, vulcanologa, fabricacin automtica.

Software de tiempo real

El software que coordina / analiza/ controla sucesos del mundo real conforme ocurren, se denomina de tiempo real.

Software empotrado

Reside en memoria de slo lectura y se utiliza para controlar productos y sistemas de los mercados industriales. Por ejemplo, el control de las teclas de un horno de microondas, funciones digitales en un automvil. Aplicaciones orientadas a usuarios individuales o multiusuarios. Por ejemplo: procesadores de texto, hojas de clculo, juegos, aplicaciones financieras, gestores de bases de datos.

Software para PC

Software de inteligencia artificial

Hace uso de algoritmos no numricos para resolver problemas complejos. Por ejemplo: sistemas expertos, redes neuronales, robtica, prueba de teoremas y juegos.

10

Ingeniera de Software1.5 Mitos del software Los mitos de software propagaron informacin errnea y confusin, lo que conllevo a la crisis del software durante los primeros aos del desarrollo del software. Mitos de gestin Tenemos ya un libro que est lleno de estndares y procedimientos para construir software, no le proporciona ya a mi gente todo lo que necesita saber? Mi gente dispone de las herramientas de desarrollo de software ms avanzadas, despus de todo, les compramos las computadoras ms modernas. Si fallamos en la planificacin, podemos aadir ms programadores y adelantar el tiempo perdido.

Mitos del Cliente Una declaracin general de los objetivos es suficiente para comenzar a escribir los programas. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fcilmente, ya que el software es flexible.

Mitos de los desarrolladores Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Hasta que no tengo el programa ejecutndose, realmente no tengo forma de comprobar su calidad. Lo nico que se entrega al terminar el proyecto es el programa funcionando.

11

Ingeniera de SoftwareACTIVIDADES COMPLEMENTARIAS 1. Muchos autores han tratado el impacto de la era de la informacin. D varios ejemplos (positivos y negativos) que indiquen el impacto del software en nuestra sociedad. 2. Escriba un informe que resuma las ventajas recientes en una de las reas de aplicaciones de software principales. Entre las selecciones potenciales se incluyen: aplicaciones avanzadas basadas en Web, realidad virtual, redes neuronales artificiales, interfaces humanas avanzadas y agentes inteligentes. 3. Analice y describa la Realidad para cada uno de los mitos descritos en el numeral 1.5.

CONSULTAS WEB http://www.rspa.com/spi/glossary.html , Glosario de trminos de software. http://books.google.com.co/books?id=ytdKQGJ8f_AC&lpg=PA4&ots=hSqsOPw078& dq=Software%20Myths&pg=PA5 , encuentra un libro con informacin sobre los mitos del software.

12

Ingeniera de Software2. EL PROCESO Es una serie de pasos a seguir para construir un producto o un sistema. El proceso del software es importante porque proporciona estabilidad, control y organizacin a una actividad que puede, si no se controla, volverse catica. 2.1 Ingeniera del Software Ingeniera de softwarees

el conjuntode

Principios

Mtodos

Tcnicas

para

Desarrollar

Mantener

Softwarede

Calidad A nivel internacional, la Ingeniera de Software empieza a tomar un papel fundamental y como un rea de la Ingeniera. A continuacin se relacionan algunas definiciones de Ingeniera del Software:

1

Zelkovitz. Principles of Software Engineering and Design. Ingeniera del software es el estudio de los principios y metodologas para 13 desarrollo y mantenimiento de sistemas de software.

Ingeniera de Software

2

Boehm. Software Engineering. Ingeniera del software es la aplicacin prctica del conocimiento cientfico en el diseo y construccin de programas de computadora y la documentacin asociada requerida para desarrollar, operar y mantenerlos. Bauer. Software Engineering. Ingeniera del software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje en mquinas reales. Pressman. Ingeniera del Software La Ingeniera de/l software es una disciplina o rea de la informtica o Ciencias de la Computacin, que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Braude. Ingeniera de Software La ingeniera de software es el proceso de construir aplicaciones de tamao o alcance prcticos, en las que predomina el esfuerzo del software y que satisfacen los requerimientos de funcionalidad y desempeo. IEEE La aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del software; es decir, la aplicacin de ingeniera al software.

3

4

5

6

14

Ingeniera de Software2.2 Esquema de la Ingeniera del Software

Es muy simple el esquema que consiste en desarrollar un programa sencillo que resuelve una tarea bien determinada. Lo normal es que se evolucione al desarrollo de un Sistema software: integra varios programas, o Producto software: programa usado en diferentes aplicaciones/entornos Ambos desarrollos "dan lugar a la Ingeniera del Software": Programas integrados que pueden trabajar en varios entornos.

15

Ingeniera de Software2.3 Esencia de la Ingeniera del Software

Tomada de http://www.um.es/docencia/barzana/IAGP/IAGP2-Metodologias-dedesarrollo.html Esta figura podra resumir buena parte de la esencia del curso: en el desarrollo de software (una entidad "compleja") se producen problemas de comunicacin a varios niveles: entre usuarios y desarrolladores y entre los componentes mismos del equipo de desarrollo. Estudiaremos las tcnicas, mtodos y herramientas de ingeniera que puedan hacer que estos problemas se minimicen, e incluso que desaparezcan.

16

Ingeniera de Software2.4 Proceso, mtodos y herramientas La ingeniera del software es una tecnologa multicapa, y que se apoya sobre un enfoque de calidad.

Herramientas Mtodos Proceso Enfoque de calidad

Enfoque de calidad Proceso Mtodos

Herramientas

Gestin total de calidad. Cultura continua de mejoras de procesos. Define un nmero de actividades del marco de trabajo aplicables a todos los proyectos del software. Indican cmo construir tcnicamente el software. Abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Soporte automtico o semi-automtico para el proceso y los mtodos

La ingeniera es el anlisis, diseo, construccin, verificacin y gestin de entidades tcnicas. El trabajo que se asocia a la ingeniera del software se puede dividir en tres fases, con independencia del rea de aplicacin, tamao o complejidad del proyecto.

17

Ingeniera de Software1 Fase de definicin Se centra sobre el qu. Identificar qu informacin ha de ser procesada, que funcin y rendimiento se desea, qu comportamiento del sistema, qu interfaces van a ser establecidas, qu restricciones de diseo existen, y qu criterios de validacin se necesitan para definir un sistema correcto. Identificar los requisitos del sistema y del software. Las tareas especficas de esta fase son: o Ingeniera de Sistemas o de informacin o o Planificacin del proyecto software o o Anlisis de requerimientos o Fase de desarrollo Se centra en el cmo. Definir cmo han de disearse las estructuras de datos, cmo ha de implementarse la funcin dentro de una arquitectura de software, cmo ha de implementarse los detalles procedimentales, cmo han de caracterizarse interfaces, cmo ha de traducirse el diseo en un lenguaje de programacin y cmo ha de realizarse la prueba. Las tareas especficas de esta fase son: o Diseo del software o o Generacin de cdigo o o Prueba del software o Fase de mantenimiento Se centra en el cambio. Correccin de errores Adaptaciones requeridas a medida que evoluciona el entorno del software Cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente Se encuentran cuatro tipos de cambio: o Correccin o o Adaptacin o o Mejora o o Prevencin o

2

3

2.5 El Proceso del Software 18

Ingeniera de SoftwareUn proceso de software se puede caracterizar as:

Aplicables a todos los proyectos de software, con independencia de su tamao o complejidad.

Marco de trabajo comn del procesoActividades del marco de trabajo Conjuntos de tareas Tareas Hitos, entregas Puntos SQA

Actividades de Proteccin Permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto del software y a los requisitos del proyecto.

Son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

19

Ingeniera de Software3. MODELOS DE PROCESO DEL SOFTWARE Es importante incorporar estrategias de desarrollo que acompae al proceso, mtodos y a las herramientas. Una estrategia a menudo de llama modelo de proceso o paradigma de ingeniera del software. Se selecciona un modelo de proceso para la ingeniera del software segn la naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse, y los controles y entregas que se requieren. 3.1 El modelo lineal secuencial Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal secuencial sugiere un enfoque sistemtico, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. Es un ciclo de vida en sentido amplio, que incluye no slo las etapas de ingeniera sino toda la vida del producto: las pruebas, el uso (la vida til del software) y el mantenimiento.

Ingeniera del Sistema Anlisis Diseo Codificacin Prueba Utilizacin Mantenimiento

Ingeniera Sistema

del Anlisis de las caractersticas y el comportamiento del sistema del cual el software va a formar parte. 20

Ingeniera de SoftwarePara un sistema nuevo: Se debe analizar cules son los requisitos funciones del sistema, y luego asignar un subconjunto de estos requisitos y funciones al software. Para un sistema ya existente: se debe analizar el funcionamiento de la organizacin y sus operaciones y se asigna al software aquellas funciones que se van a automatizar. Est formado por diagramas y por descripciones en lenguaje natural.

Anlisis

Diseo

Codificacin

Prueba

Utilizacin Mantenimiento

Se debe comprender cules son los datos que se van a manejar, cul va a ser la funcin que tiene que cumplir el software, cules son las interfaces requeridas y cul es el rendimiento y otros requisitos no funcionales que se esperan lograr. Los requisitos, tanto del sistema como del software deben documentarse y revisarse con el cliente. Como resultado del la fase de anlisis, se obtiene la especificacin de requisitos del software. Tambin est formado por diagramas y descripciones en lenguaje natural. El diseo se aplica a cuatro caractersticas distintas del software: la estructura de los datos, la arquitectura de las aplicaciones, la estructura interna de los programas y las interfaces. El diseo es el proceso que traduce los requisitos en una representacin del software de forma que pueda conocerse la arquitectura, funcionalidad e incluso la calidad del mismo antes de comenzar la codificacin. En el diseo, los requisitos del software se traducen a una serie de diagramas que representan la estructura del sistema software, de sus datos, de sus programas y de sus interfaces. Consiste en la traduccin del diseo a un formato que sea comprensible para la mquina. Si el diseo es lo suficientemente detallado, la codificacin es relativamente sencilla, y puede hacerse de forma automtica, usando generadores de cdigo. Se traducen los diagramas de diseo a un lenguaje fuente, que luego se traduce - se compila - para obtener un programa ejecutable. El objetivo es comprobar que no se hayan producido errores en alguna de las fases anteriores, especialmente en la codificacin. Se deben probar todas las sentencias, y todos los mdulos que forman parte del sistema. El software se entrega al cliente y comienza la vida til del mismo. El software sufrir cambios a lo largo de su vida til. Estos cambios pueden ser debidos a tres causas: 21

Ingeniera de SoftwareQue, durante la utilizacin, el cliente detecte errores en el software: los errores latentes. Que se produzcan cambios en alguno de los componentes del sistema. Que el cliente requiera modificaciones funcionales no contempladas en el proyecto.

3.2 El modelo de construccin de prototipos

Identificar los requerimientos conocidos

Desarrollar modelo que funcione

Utilizar el prototipo

No

Revisar el prototipo

Prototipo Terminado?

S

Abandonar la aplicacin Implantar la aplicacin Volver a desarrollar la aplicacin Comenzar un nuevo prototipo

Paso Descripcin Identificar los Los analistas y los usuarios trabajan juntos para identificar los requerimientos requerimientos conocidos que tienen que satisfacerse. conocidos Se debe: determinar los fines del sistema y el alcance de su capacidad. 22

Ingeniera de SoftwarePaso Descripcin Desarrollar Los desarrolladores explican a los usuarios: modelo que El mtodo funcione Las actividades a realizar La secuencia en que se llevar a cabo La responsabilidad de cada participante El proceso de construccin del prototipo se debe iniciar con el desarrollo de un plan general que permita conocer el proceso de desarrollo. Es importante definir un cronograma para el inicio y fin de la primera iteracin. Los reportes y documentos que el sistema debe proporcionar El formato de cada uno de ellos.

Primera Iteracin

Debe describir

El desarrollador estima los costos asociados con el desarrollo del prototipo. En el desarrollo del prototipo se preparan los siguientes componentes: El lenguaje de dilogo o conversacin entre el usuario y el sistema Pantallas y formatos para la entrada de datos Mdulos esenciales de procesamiento Salida del sistema En esta fase no se prepara la documentacin ni las especificaciones de salida o de diseo del software. Utilizar prototipo el La responsabilidad de trabajar con el prototipo y evaluar sus caractersticas y operacin es del usuario. La experiencia con el sistema bajo condiciones reales permite determinar los cambios o mejoras o eliminar caractersticas innecesarias.

23

Ingeniera de SoftwarePaso Descripcin Revisar el Se realiza la evaluacin y con la informacin obtenida se levantan prototipo las caractersticas que debe llevar la siguiente versin del prototipo. La evaluacin permite profundizar los rasgos de los usuarios y los de la organizacin que tienen influencia sobre la aplicacin y en su implementacin. Los cambios en el prototipo son planificados con los usuarios antes de llevarlos a cabo por el analista. Prototipo Los pasos anteriores se repiten varias veces (4 o 6 iteraciones) terminado? cuando los usuarios y desarrolladores estn de acuerdo en que el sistema ha evolucionado lo suficiente e incluye todas las caractersticas necesarias. Cuando el prototipo est terminado, el paso que sigue a continuacin es tomar la decisin sobre cmo proceder, para lo cual existen cuatro opciones:Abandonar la aplicacin Se descartan el prototipo y la aplicacin. El desarrollo del prototipo proporcion informacin a partir de la cual se determin que la aplicacin o el enfoque seleccionado son inapropiados para justificar un desarrollo adicional. Implantar el prototipo Las caractersticas y funcionamiento del prototipo satisfacen las necesidades de los usuarios ya sea en forma permanente o para un futuro. Volver a desarrollar la aplicacin El desarrollo del prototipo proporcion suficiente informacin para determinar las caractersticas necesarias de toda la aplicacin. La informacin se utiliza como punto de partida para el desarrollo de la aplicacin en forma tal haga el mejor uso posible de los recursos. Comenzar un nuevo prototipo La informacin ganada con el desarrollo del prototipo inicial sugiere otras opciones o circunstancia. Se construye un prototipo diferente para aadir informacin relacionada con los requerimientos de aplicacin.

24

Ingeniera de SoftwareUn prototipo puede tener alguna de las tres formas siguientes: 1 Un prototipo, en papel o ejecutable en computador, que describa la interaccin hombre-mquina y los listados del sistema. Un prototipo que implemente algn(os) subconjunto(s) de la funcin requerida, y que sirva para evaluar el rendimiento de un algoritmo o las necesidades de capacidad de almacenamiento y velocidad de clculo del sistema final. Un programa que realice en todo o en parte la funcin deseada pero que tenga caractersticas que deban ser mejoradas durante el desarrollo del proyecto.

2

3

3.3 El modelo DRA (Desarrollo Rpido de Aplicaciones)

DRAes un

modelo de procesodel

Desarrollo del softwareque

Enfatiza un Ciclo de desarrollo corto

25

Ingeniera de SoftwareEl proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de periodos cortos de tiempo (de 60 a 90 das). El enfoque DRA comprende las siguientes fases:Equipo N. 3 Modelado de gestin Modelado de datos Modelado de procesos Modelado de datos Modelado de procesos Generacin de aplicaciones Pruebas y entrega Generacin de aplicaciones

Equipo N. 2 Modelado de gestin

Equipo N. 1

Modelado de gestin Modelado de datos

Modelado de procesos Generacin de aplicaciones

Pruebas y entrega

Pruebas y entrega 60-90 das

Modelado gestin

de El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce al proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin la procesa?

26

Ingeniera de SoftwareModelado datos de Conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (atributos) de cada uno de los objetos y las relaciones entre estos objetos. Modelado del Los objetos de datos definidos en la fase de modelado de datos proceso quedan transformados para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir o recuperar un objeto de datos. Generacin de El DRA asume la utilizacin de tcnicas de cuarta generacin. En aplicaciones lugar de crear software con lenguajes de programacin de tercera generacin, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes o crear componentes reutilizables. Pruebas y Como el proceso DRA enfatiza la reutilizacin, ya se han Entrega comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

3.4 Modelos de procesos evolutivos de software

Los modelos evolutivosse

son

iterativos

caracterizan

por

desarrollar versiones

cada vez

ms completas del software

27

Ingeniera de Software3.4.1 El modelo incremental

El modelo incrementalcombinael y la

Modelo lineal secuencial

Construccin de prototipos

para

Entregar el softwareen

Partes pequeasllamadas

Incrementos

El modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad necesaria para su evaluacin.

28

Ingeniera de SoftwareIngeniera de Sistemas / Informacin incremento 1

Anlisis

Diseo

Cdigo

Prueba

Entrega 1er. Incremento

incremento 2

Anlisis

Diseo

Cdigo

Prueba

Entrega 2do. Incremento

incremento 3

Anlisis

Diseo

Cdigo

Prueba

Entrega 3er. Incremento Entrega 4to. Incremento

incremento 4

Anlisis

Diseo

Cdigo

Prueba

Tiempo

3.4.2 El modelo espiral

Modelo Espiral

es un

proceso de software evolutivo

construccin de prototiposconjuga

modelo lineal secuencial

proporciona Un desarrollo rpido de versiones incremntales del software

En las primeras iteraciones, la versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema diseado.

29

Ingeniera de SoftwareComunicacin con el cliente: Se establece comunicacin entre el desarrollador y el cliente. Planificacin: Se definen los recursos, el tiempo y otra informacin relacionados con el proyecto. Anlisis de riesgos: Se evalan riesgos tcnicos y de gestin Actividades del modelo en espiral Ingeniera: Se construyen una o ms representaciones de la aplicacin. Construccin y accin: Construir, proporcionar soporte al usuario. probar, instalar y

Evaluacin del cliente: Se obtiene la reaccin del cliente. Se realiza la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin.

30

Ingeniera de SoftwareEl equipo de ingeniera del software gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral puede producir el desarrollo de una especificacin de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software. Cada paso por la regin de planificacin produce ajustes en el plan del proyecto. El costo y la planificacin se ajustan con la realimentacin ante la evaluacin del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones requeridas para completar el software. 3.5 Modelo de mtodos formales y Tcnicas de cuarta generacin El modelo de mtodos formales comprende un conjunto de actividades que conducen a la especificacin matemtica del software de computadora. Los mtodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notacin rigurosa y matemtica. Este enfoque es llamado ingeniera del software de sala limpia. Cuando se utilizan mtodos formales se descubren y corrigen ambigedades, inconsistencias y errores. Las tcnicas de cuarta generacin, abarcan un conjunto de herramientas que facilitan al ingeniero del software la especificacin de las caractersticas del software a alto nivel. La herramienta genera automticamente el cdigo fuente basndose en la especificacin del tcnico. Cuanto mayor sea el nivel en el que se especifique el software, ms rpido se puede construir el programa. El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones grficas que describa el problema que hay que resolver en trminos que los entienda el cliente. Lenguajes no procedimentales de consulta a bases de datos Generacin de informes Manejo de datos Interaccin y definicin de pantallas Generacin de cdigos Capacidades grficas Generacin automatizada de HTML

El paradigma T4G

incluye

las etapas

Recoleccin de requisitos: descritos por los clientes Diseo de prototipo Desarrollo de prototipo operativo Implementacin Documentacin Mantenimiento 31

Ingeniera de Software

ACTIVIDADES COMPLEMENTARIAS 1. Las capas de la Ingeniera del Software sita las tres capas encima de la capa titulada enfoque de calidad. Esto implica un programa de calidad tal como Gestin de Calidad Total. Investigue y desarrolle un esquema de los principios clave de un programa de Gestin de Calidad Total. 2. Elabore y proporcione una tabla donde se especifiquen las ventajas y desventajas de los diferentes paradigmas de ingeniera de software. 3. Qu paradigmas de ingeniera del software de los presentados piensa que sera el ms eficaz? Por que? 4. Qu es ms importante, el producto o el proceso?

32

Ingeniera de SoftwareBIBLIOGRAFIA IMPRESA BRAUDE. Ingeniera de software, una perspectiva orientada a objetos. Mxico. 2003. Alfaomega grupo editor. S.A. GRUEGGE, BERND y DUTOIT, Allen H. Ingeniera de software orientado a objetos. Mxico. 2002. Pearson Educacin. HUMPHREY, Watts S. Introduccin al proceso de software personal. Pearson Addison wesley. 2001. MEYER, Bertrand. Construccin de software orientado a objetos. Segunda edicin. Madrid. 1999. Prentice Hall. NORRIS. Ingeniera de software explicada. Grupo Noriega editores de Colombia. PIATTINI, Mario. VILLALBA, Jos y otros. Mantenimiento del software: modelos, tcnicas y mtodos para la gestin del cambio. Editorial Alfaomega-Rama. PRESSMAN, Roger S. Ingeniera del Software. Un enfoque prctico. Quinta edicin. Espaa. 2002. Editorial McGraw Hill. PFLEEGER, Shari Lawrence. Ingeniera de software, teora y prctica. 1. Edicin. Buenos Aires. Pearson educacin. 2002 SOMMERVILLE, Ian. Ingeniera de software. 6. Edicin. Pearson Addison Wesley. 2001 ELECTRNICA http://www.pressman5.com http://www.wiley.com/college/braude http://www.minerva.uevora.pt/simposio/comunicacoes/rigomezmarino.html http://apuntes.rincondelvago.com/trabajos_global/informatica/9/ http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdf http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.php http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html http://www.monografias.com/trabajos5/inso/inso.shtml http://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.html

33

Ingeniera de Software

UNIDAD 2. GESTIN Y PLANIFICACIN DE PROYECTOS SOFTWAREINTRODUCCIN La gestin y planificacin de proyectos es una actividad que empieza antes de iniciar cualquier actividad tcnica y contina a lo largo de la definicin, del desarrollo y del mantenimiento del software. La actividad de gestin del proyecto comprende medicin y mtricas, estimacin, anlisis de riesgos, planificacin, seguimiento y control.

OBJETIVOS GENERALES Estudiar las tcnicas de gestin necesarias para planificar, organizar, supervisar y controlar proyectos de software. Estudiar las tcnicas de anlisis y gestin del riesgo. Estudiar las tcnicas de gestin necesarias para planificar proyectos de software.

ESPECIFICOS Determinar como se debe gestionar el personal, el proceso y el problema durante un proyecto de software. Identificar las mtricas de software y cmo pueden emplearse para gestionar el proceso de software y el proyecto llevado a cabo como parte del proceso. Determinar como se crea la planificacin temporal de un proyecto. Identificar la garanta de calidad del software. Determinar los riesgos del software. Identificar los riesgos del software. Determinar la proyeccin y evaluacin del riesgo.

34

Ingeniera de SoftwareESTRUCTURA TEMTICA 1. CONCEPTOS SOBRE GESTION DE PROYECTOS 1.1 Gestin de proyectos Gestin de proyectosimplica

Planificacin

Supervisinde

Control

Personal

Procesosmientras

eventos

Evoluciona el Software La gestin de un proyecto de software se centra en: 4 Ps

PersonalNecesidad de personal para el desarrollo de software

ProductoObjetivos y mbito del software

ProcesoEstructura que establece un plan detallado para el desarrollo del software

ProyectoProyectos de software planificados y controlados.

35

Ingeniera de Software1.2 Personal Recurso humano que participa y colabora en el proceso del software y su organizacin para el desarrollo de los proyectos software de manera eficaz.

Participantes

Se clasifican en: 1. Gestores Superiores: se encargan de definir los aspectos del negocio. 2. Gestores tcnicos del proyecto: se encargan de planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de desarrollo del software. 3. Profesionales: se encargan de proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o aplicacin. 4. Clientes: especifican los requisitos para la ingeniera del software. 5. Usuarios finales: Se encargan de interactuar con el software.

Jefes equipo

Equipo software

de Es el gestor de proyectos de software, el cual: Diagnostica los aspectos tcnicos y de organizacin ms relevantes. Tiene confianza para asumir el control del proyecto y permite que los buenos tcnicos aporten sus ideas. Promueve e incentiva las iniciativas y logros del equipo del proyecto. Hace saber a todos los miembros del equipo que la calidad es importante. de Mantei, propone 3 niveles de organizacin de equipos. Descentralizado democrtico Este equipo no tiene un jefe permanente y se nombran coordinadores a corto plazo. Las decisiones se hacen por consenso del grupo. La comunicacin entre los miembros del equipo es horizontal.

36

Ingeniera de SoftwareDescentralizado controlado Este equipo tiene un jefe definido que coordina tareas especficas y jefes secundarios que tienen responsabilidades sobre subtareas. La resolucin de problemas sigue siendo una actividad del grupo, pero la implementacin de soluciones se reparte entre subgrupos por el jefe de equipo. La comunicacin entre subgrupos e individuos es horizontal. Tambin hay comunicacin vertical a lo largo de la jerarqua de control. Centralizado controlado El jefe del equipo se encarga de la resolucin de problemas a alto nivel y la coordinacin interna del equipo. La comunicacin entre jefe y los miembros del equipo es vertical. Coordinacin y Comunicacin Se establecen mecanismos de comunicacin para coordinar al equipo de trabajo. Se deben tener: Comunicacin formal: se lleva a cabo por escrito, con reuniones organizadas y otros canales de comunicacin. Incluye documentos de ingeniera de software, memorandos tcnicos, documentacin, informes de seguimiento. Comunicacin informal: es ms personal. Incluye reuniones de grupo para la divulgacin de informacin y para la resolucin de problemas. Comunicacin electrnica: se leva a cabo por correos electrnicos, boletines, audioconferencias, videoconferencias.

1.3 Producto Al inicio de un proyecto, el gestor del proyecto debe examinar el producto y el problema a resolver. Por lo que se debe establecer el mbito del producto delimitarlo. 37

Ingeniera de Software

mbito

Se define: Contexto: Cmo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qu limitaciones se imponen como resultado del contexto? Objetivos de informacin: Qu objetos de datos visibles al cliente se obtienen del software? Qu objetos de datos son requeridos de entrada? Funcin y rendimiento: Qu funcin realiza el software para transformar la informacin de entrada en una salida? Hay caractersticas de rendimiento especiales que abordar?

Descomposicin Comprende el anlisis de requisitos del software. del problema La descomposicin se aplica en dos reas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se emplear para entregarlo. Un problema complejo se parte en problemas ms pequeos que resultan ms manejables.

38

Ingeniera de Software1.4 Proceso El gestor del proyecto decide qu modelo de proceso es el ms adecuado para: 1. Los clientes que han solicitado el producto y la gente que realizar el trabajo. 2. Las caractersticas del producto. 3. El entorno del proyecto.

Maduracin del Los miembros del equipo de software deben estructurar un problema y el conjunto de actividades que le permitan trabajar en cada funcin proceso del problema. Se pueden considerar las siguientes actividades: Comunicacin Se establece comunicacin entre el desarrollador y el cliente, con el propsito de obtener los requisitos del sistema. Planificacin Conjunto de tareas con el propsito de definir los recursos y la planificacin temporal del proyecto. Anlisis del riesgo Tareas requeridas para valorar los riesgos tcnicos y de gestin. Ingeniera Tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y entrega Tareas requeridas para construir, probar, instalar y proporcionar asistencia al usuario. Evaluacin del cliente Tareas requeridas para que el cliente evale las representaciones de software creadas durante la fase de ingeniera. El trabajo del gestor del proyecto es estimar los requisitos de recursos, poner fechas de inicio y finalizacin de las tareas y los productos a fabricar. Las actividades de: comunicacin, planificacin, anlisis de riesgo, ingeniera, construccin, entrega y evaluacin se adaptan al modelo o paradigma de desarrollo de software seleccionado.

Descomposicin del proceso

1.5 Proyecto Se deben gestionar proyectos software de calidad para que tengan xito. 39

Ingeniera de Software

Se debe:1 2

Comprender el problema a solucionar y establecer los objetivos.3

Mantener el desarrollo y incentivos.4

equipo de proporcionar

Realizar seguimiento a las actividades desarrolladas durante el proceso como parte de la calidad del mismo.5

Tomar decisiones junto con el gestor del proyecto y el equipo de desarrollo de software.

Evaluar la planificacin real y la prevista, reunir y analizar mtricas del proyecto de software y realimentar cada uno de los procesos.

ACTIVIDADES COMPLEMENTARIAS

40

Ingeniera de Software1. Se le ha nombrado gestor de proyecto dentro de una organizacin de sistemas de informacin. Su trabajo es construir una aplicacin que es bastante similar a otras que ha construido su equipo, aunque sta es mayor y ms compleja. Los requisitos han sido detalladamente documentados por el cliente. Qu estructura de equipo elegira y porqu? Qu modelo(s) de proceso de software elegira y por qu? 2. Se le ha nombrado gestor de proyecto de una pequea compaa de productos software. Su trabajo consiste en construir un producto innovador que combine hardware de realidad virtual con software innovador. Puesto que la competencia por el mercado de entretenimiento casero es intensa, hay cierta presin para terminar el trabajo rpidamente. Qu estructura de equipo elegira y porqu? Qu modelo(s) de proceso de software elegira y por qu?

41

Ingeniera de Software2. EL PROCESO DE SOFTWARE Y MTRICAS DEL PROYECTO

Mtricas del softwarecomprende

Una gamade se

Medicionespara el

aplican

al

Proceso del software Proyecto de softwarepara

Software

Ayudar en la estimacin, el control de calidad, la evaluacin de productividad y el control de proyectos

Las razones para medir los procesos del software, los productos y los recursos: son: Caracterizar: para comprender mejor los procesos, los productos, los recursos y los entornos Evaluar: para determinar el estado con respecto al diseo Predecir: para poder planificar Mejorar: la calidad del producto y el rendimiento del proceso.

42

Ingeniera de Software2.1 Mtricas en el proceso y dominios del proyecto Dentro de la Ingeniera del software se manejan los siguientes conceptos: Medida: Proporciona una indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. Medicin: es el acto de determinar una medida. Mtrica: Una medida cuantitativa del grado en que el sistema, componente o proceso posee un atributo dado.

Indicador: es una mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso del software, del proyecto de software o del producto en s. Un indicador proporciona una visin profunda que permite al gestor de proyectos o a los ingenieros de software ajustar el producto, el proyecto o el proceso. El objetivo principal de los indicadores de proceso es evaluar las condiciones de funcionamiento de un proceso y poder tener una visin de la eficacia de un proceso existente. Durante un tiempo considerable se recopilan las mtricas de todos los proyectos y se proporcionan los indicadores para obtener mejoras e el software. Los indicadores de proyectopermiten

1

2

3

4

5

Evaluar el estado del proyecto

Hacer seguimiento a los riesgos potenciales

Detectar las reas problemas antes de que se conviertan en crticas

Ajustar el flujo y las tareas del trabajo

Evaluar la habilidad del equipo para controlar la calidad de los productos software.

Para mejorar cualquier proceso se debe:

43

Ingeniera de Software Medir atributos del proceso Definir y desarrollar un juego de mtricas para esos atributos Utilizar las mtricas para encontrar indicadores para la estrategia de mejora

De acuerdo a la figura:ProductoCaractersticas del cliente Condiciones del negocio

Proceso

Personas

Entorno de desarrollo

TecnologaFigura tomada de Roger Presuman. Ingeniera de Software

El producto, la tecnologa y las personas tienen una fuerte influencia en el desarrollo y la calidad del software. El proceso se encuentra dentro de unas condiciones de entorno que incluyen: entornos de desarrollo, condiciones del negocio, y caractersticas del cliente. Estas condiciones, son de gran importancia puesto que permiten definir las reglas del proceso y poder contribuir a la calidad del software.

La eficacia de un proceso de software se mide a travs de un juego de mtricas segn los resultados que provienen del proceso. Dentro de stos resultados se debe incluir: Medida de errores detectados antes de la entrega del software Defectos detectados Productos de trabajo entregados Esfuerzo humano y tiempo consumido Ajuste con la planificacin 44

Ingeniera de Software

Tambin se debe incluir mtricas para medir las caractersticas de tareas especficas de la ingeniera del software. Medida del tiempo y del esfuerzo para llevar a cabo actividades de proteccin Actividades genricas de ingeniera del software

2.2 Mejora estadstica del proceso del software (MEPS) Para una organizacin es importante estar a gusto con la recopilacin y la utilizacin de mtricas de proceso, de stas se deriva la identificacin de indicadores llevando a un enfoque ms riguroso denominado Mejora estadstica de proceso del software (MEPS).

MEPSutiliza

Anlisis de fallosdel

Softwarepara

Recopilar informacinde y

Errores

Defectos

Para realizar un anlisis de fallos se deben seguir los siguientes pasos:1 2 3 Categorizar por origen, todos los errores y defectos. Registrar el costo de corregir cada error y el del defecto Contar el nmero de errores y de defectos de cada categora y se ordenar por orden descendente 45 Computar el costo global de errores y defectos de cada categora. Los datos resultantes se analizan para detectar las categoras que producen un

4 5

Ingeniera de Software

Error

Es alguna fisura descubierta por los ingenieros del software antes de que el software sea entregado al usuario final Es alguna fisura descubierta despus de la entrega del software al usuario final

Defecto

Para determinar las principales causas que pueden ocasionar defectos en el software y con base en ello extraer los indicadores que permitan a una organizacin de software modificar su proceso para reducir la frecuencia de errores y defectos se utiliza el diagrama de espina.

Causa potencial No. 1 Q1%

Causa potencial no. 2 Q2%

Ci, j

Problema Principal R%Ci, j

Causa potencial n Qi%

Causa potencial n+1 Qi%

Ci, j : Causa asociada a cada subproblema Qi %: Porcentaje de relevancia del subproblema R% : Porcentaje de relevancia del problema principal

46

Ingeniera de SoftwareEn un diagrama de espina: La lnea central, representa el factor de calidad o el problema en consideracin. Las lneas diagonales conectadas a la lnea central indican una causa potencial del problema de calidad.

Esta misma notacin se aplica para cada una de las lneas diagonales conectadas a la lnea central. Por ejemplo: Se han encontrado y determinado las siguientes causas y su origen en un proyecto de software:

Origen de errores / defectos Especificacin / requisitos

Causa Lgica Manejo de datos estndares Especificaciones Interfaz software Interfaz hardware Comprobacin de errores Interfaz de usuario

Diseo Cdigo

% 20 10.9 6.9 25.5 6.0 7.7 10.9 11.7

Si tomamos la causa Especificaciones y utilizamos un diagrama de espina para identificar las causas especficas para este problema, tenemos:

IncorrectoCliente consultado no adecuado El cliente dio informacin equivocada Insuficiente informacin solicitada Informacin desactualizada

Cambios

Defectos de especificacin 25.5%

Perdido

Ambiguo

47

Ingeniera de Software

2.3 Mtricas del Proyecto Mtricas de proyectoSe utilizan

Para minimizar la planificacin de desarrollo, ya que se realizan ajuste y se reduce los retrasos

Para evaluar la calidad de los productos. A medida que mejora la calidad se minimizan los defectos.

Las mtricas del proyecto de software sugieren que los proyectos deben medir:1 2

Entradas: la dimensin de los recursos que se requieren para realizar el trabajo Salidas: medidas de las entradas o productos creados durante el proceso de ingeniera del software Resultados: medidas que indican la efectividad de las entregas.

3

2.4 Mediciones del Software Las mtricas del software se pueden categorizar en:Medidas directas: Dentro de estas se pueden incluir: El costo y el esfuerzo aplicado Lneas de cdigo producidas (LCD) Velocidad de ejecucin, tamao de memoria y los defectos informados durante un periodo de tiempo establecido Medidas Indirectas: Incluyen: La funcionalidad, calidad, complejidad, eficiencia fiabilidad, facilidad, facilidad de mantenimiento

48

Ingeniera de SoftwareEl domino de las mtricas del software se dividen en mtricas de proceso, proyecto y producto. 2.4.1 Mtricas orientadas al tamao Provienen de la normalizacin de las medidas de calidad y/o productividad considerando el tamao del software que se haya producido. Los datos que se deben tener en cuenta, se pueden llevar en la siguiente tabla: Proyecto IRIS LDC 18.200 Esfuerzo Costo $ 24 Pginas de Errores Defectos Personas documentacin 200.000 945 134 86 4

Teniendo en cuenta los datos de la tabla, se pueden derivar otras mtricas para comparar varios proyectos. Por ejemplo: Errores por KLDC (miles de lneas de cdigo) Defectos por KLDC Pginas de documentacin por KLDC Errores por persona-mes LDC por persona-mes Costo ($) por pgina de documentacin

2.4.2 Mtricas orientadas a la funcinMtricas del software orientadas a la funcinpermiten Propuestas por

La medida de la funcionalidad de la aplicacin.

Allan Albrecht de IBM, comenz a analizar sistemas, a pedido del grupo de usuarios de IBM, buscando identificar los factores crticos que determinan el tamao del software y por consiguiente, estimar el esfuerzo y el costo de desarrollarlo. Luego de analizar cientos de sistemas, naci la tcnica de Anlisis de Puntos por funcin. La tcnica mide una aplicacin con base en las funciones que ste realiza para/por solicitud del usuario final.

49

Ingeniera de SoftwareLos puntos de funcin se obtienen utilizando una funcin emprica basado en medidas cuantitativas del dominio de informacin del software y valoraciones subjetivas de la complejidad del software. Los puntos de funcin se calculan utilizando la siguiente tabla: Parmetros Cuenta de medicin Nmero de entradas de usuario Nmero de salidas de usuario Nmero de peticiones de usuario Nmero de archivos Nmero de interfaces externas Factor de ponderacin Simple Medio Complejo 3 4 6 X 4 X 3 X X X 7 5 10 7 15 10 = Cuenta_total Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la posicin apropiada de la tabla. Los valores del mbito de informacin estn definidos de la siguiente manera: 1. Nmero de entradas de usuario: se cuenta cada entrada de usuario que proporcione al software diferentes datos orientados a la aplicacin. 2. Nmero de salidas de usuario: se cuenta cada salida que proporciona al usuario informacin orientada a la aplicacin. En este contexto las salidas se refieren a informes, pantallas, mensajes de error. 3. Nmero de peticiones de usuario: una peticin esta definida como una entrada interactiva que resulta de la generacin de algn tipo de respuesta en forma de salida interactiva. Se cuenta cada peticin por separado. 4. Nmero de archivos: se cuenta cada archivo maestro lgico. 5. Nmero de interfaces externas: se cuentan todas las interfaces legibles por la maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir informacin a otro sistema. 50 4 6 = = 5 7 = =

Ingeniera de Software

Cuando han sido recogidos los datos anteriores, se asocia el valor de complejidad a cada cuenta. Las organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para determinar si una entrada es denominada simple, media o compleja. No obstante la determinacin de la complejidad es algo subjetivo. Para calcular los puntos de funcin se utiliza la siguiente relacin: PF = Cuenta_total * [0.65 + 0.01 * (fi)] PF Punto de funcin Cuenta_total Es la suma de todas las entradas obtenidas fi Donde i=1 hasta 14. Son valores de ajuste de la complejidad basados en las respuestas a las cuestiones sealadas de la siguiente tabla: Evaluar cada factor en escala 0 a 5 0 No influencia Fi : 1 2 3 4 5 6 7 1 2 3 4 5 Incidental Moderado Medio Significativo Esencial

8 9

Requiere el sistema copias de seguridad y de recuperacin fiables? Se requiere comunicacin de datos? Existen funciones de procesamiento distribuido? Es crtico el rendimiento? Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? Requiere el sistema entrada de datos interactiva? Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? Se actualizan los archivos maestros de forma interactiva? Son complejas las entradas, las salidas, los 51

Ingeniera de Software10 11 12 13 archivos o las peticiones? Es complejo el procesamiento interno? Se ha diseado el cdigo para ser reutilizable? Estn incluidas en el diseo la conversin y la instalacin? Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?

14

Una vez calculado los puntos de funcin se usan como medida de la productividad, calidad y otros productos del software. Productividad = PF / persona-mes Calidad = Errores / PF Costo = Dlares / PF Documentacin = Paginas Documentadas / PF

52

Ingeniera de Software2.5 Mtricas para la calidad del software El objetivo de la ingeniera del software es desarrollar y producir software de alta calidad. Para lograr este objetivo, es fundamental aplicar mtodos y herramientas efectivos dentro del contexto de un proceso maduro de desarrollo de software. 2.5.1 Medidas de la Calidad Dentro de las medidas de calidad del software tenemos: Correccin Es el grado en que el software cumple su funcin. La medida ms comn es: Defectos por KDLC (miles de lneas de cdigo) Facilidad de mantenimiento Es la facilidad con la que se puede corregir un programa si se encuentra un error Se utilizan medidas indirectas como: Tiempo Medio de cambio (TMC) Es decir, el tiempo que se tarda en: Analizar una peticin Disear un modificacin Implementar el cambio Probar y realizar el cambio.

53

Ingeniera de SoftwareIntegridad Mide la capacidad del software para resistir ataques. Se debe tener en cuanta los siguientes atributos: AmenazaEs la probabilidad de que un ataque ocurra en un tiempo determinado.

Seguridad

Es la probabilidad de que se pueda repeler el ataque de un tipo determinado.

Se define como: Integridad = [(1-amenaza) x (1-seguridad)]

Facilidad de uso Mide la amigabilidad del software con el usuario final. Se mide en funcin de: Habilidad intelectual o fsica para aprender el sistema. El tiempo requerido para hacer uso eficiente del sistema. Aumento de la productividad. Valoracin subjetiva de la disposicin de los usuarios hacia el sistema.

54

Ingeniera de Software2.5.2 Eficacia de la eliminacin de defectos La eficacia de la eliminacin de defectos (EED), es una mtrica que permite medir la habilidad de filtrar las actividades de la garanta de calidad y de control, ya que es aplicable a todas las actividades del marco de trabajo del proceso. Se define de la siguiente forma: EED = E / (E + D) E D Nmero de errores encontrados antes de la entrega del software Nmero de defectos encontrados despus de la entrega

El valor ideal de EED es 1.

No se han encontrado defectos en el software.

2.5.3 Integracin de las mtricas dentro del proceso de Ingeniera del Software

Estableciendo una lnea base de mtricas se obtienen beneficios a nivel de: Proceso Proyecto Producto

Esta lnea base, comprende los siguientes pasos:

55

Ingeniera de Software1 Recopilacin de datos Requiere una investigacin histrica de los proyectos para reconstruir los datos requeridos 2 Clculo de mtricas Se hace el clculo de mtricas una vez se han determinado las medidas. Pueden abarcar una gran cantidad de mtricas: LDC y PF De calidad Del proyecto 3 Evaluacin de mtricas Se deben evaluar las mtricas y aplicar durante: la estimacin, el control de proyectos y la mejora del proceso. Los indicadores guan el proyecto o el proceso. Indicadores Mtricas Medidas

56

Ingeniera de Software

ACTIVIDADES COMPLEMENTARIAS

1. Describa, con sus propias palabras, la diferencia entre mtricas del proceso y del proyecto. 2. Elabore un ensayo argumentativo, que de respuesta a la pregunta Por qu renecesita medir? Por qu son importantes las mtricas dentro de la ingeniera de Software? 3. Sugiera tres medidas, tres mtricas y los indicadores que se podran utilizar para evaluar un automvil. 4. Indague con algn desarrollador de software o un equipo de desarrollo de software qu medidas, mtricas e indicadores utilizan o tienen implementadas. Elabore un cuadro sinptico.

INVESTIGACIN 1. El Instituto de Ingeniera de Software (The Carnegie Mellon Software Engineering Institute -SEI) ha desarrollado una gua para establecer un programa de medicin de software dirigido hacia objetivos. Investigue y elabore un documento sobre esta gua.

EJERCICIOS 1. Calcule el Punto de Funcin de un proyecto con las siguientes caractersticas del dominio de informacin:

Nmero de entrada de usuario Nmero de salida de usuario Nmero de peticiones de usuario Nmero de archivos Nmero de interfaces externos

32 60 24 8 2

Asuma que todos los valores de ajuste de complejidad estn en la media.

57

Ingeniera de Software3. PLANIFICACIN DE PROYECTOS DE SOFTWARE

La Planificacin del proyecto es el conjunto de actividades con las cuales comienza la gestin de proyectos software.

Planificacinimplica determina El costo El esfuerzo Los recursos El tiempo

Estimacin

Su resultado Es una tabla con: Las tareas a desarrollar Las funciones a implementar El costo, esfuerzo y tiempo necesario Para la realizacin de cada tarea. Y, Una lista de recursos necesarios

Para construir y desarrollar un producto software

La estimacin se inicia con una descripcin del mbito del producto. El problema se descompone en un conjunto de problemas de menor tamao y cada uno de stos se estima guindose con datos histricos y con la experiencia.

El objetivo primordial es hacer estimaciones razonables de recursos, costos y una planificacin temporal. Las estimaciones involucran un periodo de tiempo y deben ser actualizadas a medida que avanza el proyecto. Planificacininvolucra mbito del software Recursos Estimacin del proyecto Tcnicas de descomposicin Modelos de estimacin

3.1 mbito del Software y Recursos

58

Ingeniera de Software3.1.1. mbito del Software Describe el control y los datos a procesar, la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad. Se evalan las funciones descritas en la declaracin del mbito, y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. mbito del softwarecomprende

Recoleccin de la informacin Su objetivo es acercar al desarrollador y al cliente para establecer una comunicacin, para lograr esto, se utiliza una tcnica muy comn que es una reunin o una entrevista preliminar. Esta reunin o entrevista debe involucrar los siguientes tipos de preguntas: 1. Preguntas de contexto libre: se centran en el cliente, en los objetivos globales y en los beneficios. Estas preguntas deben llevar a un entendimiento bsico del problema, las personas interesadas en la solucin y la solucin que se desea. 2. Metacuestiones: estas preguntas se centran en la efectividad de la reunin, involucra preguntas para determinar si la persona es la apropiada para responder a las preguntas, si son relevantes las preguntas para el problema en estudio, si las respuestas son oficiales, si existe algo que se debera preguntar. Tambin existe otra tcnica que permite la creacin de un equipo compuesto por los clientes y los desarrolladores para identificar el problema, proponer elementos de solucin, establecer enfoques y especificar un conjunto preliminar de requisitos denominada TFEA (Facilitated application specification techniques) Tcnica para facilitar las especificaciones de la aplicacin. Viabilidad Se centra en preguntarse: Se puede construir el software de acuerdo al mbito definido? Es factible el proyecto?

La factibilidad del software tiene 4 dimensiones: Tecnologa, financiacin, Tiempo y Recursos. Tanto el equipo de desarrollo y las dems personas involucradas en el software deben determinar si puede ser construido dentro de las dimensiones especificadas. 3.1.2 Recursos

59

Ingeniera de SoftwareComprende la estimacin de los recursos necesarios para emprender el desarrollo del software. Los recursos de desarrollo son:Humanos Componentes reutilizables de software De entorno (Hardware / software)

Recurso humano Se debe establecer el perfil y las habilidades que se necesitan del personal que se necesita para llevar a cabo el desarrollo del proyecto. Hay que especificar tanto la posicin dentro de la organizacin como la especialidad. Gestor Ingeniero de software Analista de sistemas

El nmero de personas requerido para un proyecto de software se determina despus de hacer una estimacin del esfuerzo de desarrollo.

Recursos de software reutilizable Se destaca la reutilizacin, esto es, la creacin y la reutilizacin de bloques de construccin de software. Se establecen 4 categoras de recursos de software que se deben tener en cuenta a medida que se avanza con la planificacin:

Componentes ya desarrollados: componentes que ya han sido validados totalmente se pueden utilizar e implementar en el desarrollo del proyecto actual.

60

Ingeniera de Software Componentes ya experimentados: se puede utilizar Especificaciones, diseos, cdigo o datos de prueba existentes que ya han sido desarrollados para proyectos anteriores. Componentes con experiencia parcial: se puede utilizar Especificaciones, diseos, cdigo o datos de prueba existentes que ya han sido desarrollados para proyectos anteriores y que requieren una modificacin sustancial. Componentes nuevos: componentes que el equipo de software requiere construir especficamente para el proyecto.

Recursos de entorno El entorno es donde se apoya el proyecto de software. Comprende Hardware y Software

Comprende el conjunto de herramientas requeridas para producir o desarrollar el producto software y se debe verificar que estos recursos estn disponibles. Software 3.2 Estimacin del proyecto de software y tcnicas de descomposicin Para realizar estimaciones seguras de costos y esfuerzos, se pueden tener las siguientes opciones: 1. Dejar la estimacin para cuando el proyecto este ms adelantado. 2. Basar las estimaciones en proyectos similares ya terminados. 3. Usar tcnicas de descomposicin que permita generar las estimaciones de costos y de esfuerzo del proyecto. 4. Utilizar modelos empricos para la estimacin del costo y esfuerzo del software.

61

Ingeniera de SoftwareLa utilizacin de tcnicas de descomposicin y de modelos empricos, permiten descomponer el proyecto en funciones principales y en tareas lo que implica que se pueda realizar una estimacin del costo y del esfuerzo del proyecto de forma escalonada.

Antes de de realizar la estimacin del proyecto se debe generar una estimacin del tamao del software a construir. 3.2.1 Tamao del software Dentro de la planificacin de proyectos, el tamao se refiere a una produccin cuantificable del proyecto de software. El tamao se mide en LDC, si se utiliza un enfoque directo El tamao se representa como PF, si se utiliza un enfoque indirecto.

Se tienen 4 enfoques referentes al tamao:1

Tamao en lgica difusa Utiliza las tcnicas aproximadas de razonamiento. Para aplicar este enfoque se debe: Identificar el tipo de aplicacin Establecer su magnitud en una escala cuantitativa Refinar la magnitud dentro del rango originalQu es Lgica Difusa? Un tipo de lgica que reconoce ms que simples valores verdaderos y falsos. Con lgica difusa, las proposiciones pueden ser representadas con grados de veracidad o falsedad. Por ejemplo, la sentencia "hoy es un da soleado", puede ser 100% verdad si no hay nubes, 80% verdad si hay pocas nubes, 50% verdad si existe neblina y 0% si llueve todo el da.

62

Ingeniera de Software2

Tamao de componentes estndar El software esta compuesto por un nmero de componentes estndar (subsistemas, mdulos, pantallas, informes, etc.) que son genricos para un rea en particular Se debe: Estimar el nmero de incidencias de cada uno de los componentes Utilizar los datos de proyectos histricos para determinar el tamao de entrega por componente. Por ejemplo: Para un sistema de informacin se estima que se requiere generar 15 informes. Los datos histricos indican que por informe se requieren 827 lneas de programacin. Esto permite que se estime que se requieren 12405 LDC para el componente de informes.3

Tamao del cambio Este enfoque se utiliza cuando en un proyecto se utiliza software existente y que se debe modificar de alguna manera como parte del proyecto. Se debe estimar el nmero y tipo de modificaciones que se deben llevar a cabo. Para estimar el tamao del cambio, se utiliza una proporcin de esfuerzo para cada tipo de cambio.

3.2.2 Estimacin basada en el problema

Puede usarse LOC o PF para hacer estimaciones. Si se utiliza LOC, la descomposicin es esencial y a menudo debe ser a detalle. Si se utiliza PF, en vez de centrar la descomposicin en la funcin, se calcula el PF, estimando de alguna forma, cada uno de los valores. En ambos casos, mediante datos histricos o la intuicin, se estiman valores optimista (O), medio (M) y pesimista (P) para cada funcin o contador, y se calcula el valor esperado (E) con la siguiente frmula:

E = (O + 4 * M + P) / 6

63

Ingeniera de Software3.2.3 Estimacin basada en el proceso Esta tcnica permite, descomponer el proceso en un conjunto relativamente pequeo de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de cada tarea. Esta estimacin comprende: 1. Delineacin de las funciones del software obtenidas a partir del mbito del proyecto. 2. Se mezclan las funciones del problema y las actividades del proceso. 3. Se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de software.

3.3 Modelos empricos de estimacin

Utilizan frmulas derivadas empricamente de una muestra limitada de proyectos para predecir el esfuerzo en funcin de LOC o PF. La estimacin de los valores de LOC y PF se realizan utilizando las tcnicas de descomposicin. Los valores resultantes se aplican a la frmula del modelo que se haya escogido para obtener el esfuerzo en hombres-mes. Precisamente por venir de una muestra limitada, no son adecuados para toda clase de software ni para todo medio ambiente de desarrollo.

Modelo COCOMO Creado por Barry Boehm en 1981. Su nombre significa COnstructive COst MOdel (Modelo constructivo de costo) y se puede dividir en tres modelos.

64

Ingeniera de SoftwareCOCOMO bsico. Calcula el esfuerzo y el costo del desarrollo en funcin del tamao del programa estimado en LOC. COCOMO intermedio. Calcula el esfuerzo del desarrollo en funcin del tamao del programa y un conjunto de conductores de costo que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto. COCOMO detallado. Incorpora las caractersticas de la versin intermedia y lleva a cabo una evaluacin del impacto de los conductores de costo en cada fase (anlisis, desarrollo, etc.) del proceso. Los modelos COCOMO estn definidos para tres tipos de proyectos de software:

Modelos

Orgnicos. o Proyectos pequeos y sencillos. o Equipos pequeos con experiencia en la aplicacin. o Requisitos poco rgidos. Semiacoplados. o Proyectos de tamao y complejidad intermedia. o Equipos con variado niveles de experiencia. o Requisitos poco o medio rgidos. Empotrados. o Proyectos que deben ser desarrollados con un conjunto de requisitos (hardware y software) muy restringidos.

COCOMO bsico Las ecuaciones del modelo COCOMO bsico son de la forma: E = a * KLOCb D = c * Ed

Donde:

65

Ingeniera de SoftwareE D KLOC es el esfuerzo aplicado en hombre-mes es el tiempo de desarrollo en meses es el nmero de miles de lneas de cdigo estimado para el proyecto

Los coeficientes a y c y los exponentes b y d se obtienen de la siguiente tabla: Tipo de proyecto Orgnico Semiacoplado Empotrado a 2.4 3.0 3.6 b 1.05 1.12 1.20 C 2.5 2.5 2.5 d 0.38 0.35 0.32

Aplicando el modelo COCOMO bsico al ejemplo anterior y usando un tipo de proyecto orgnico obtenemos una estimacin para el esfuerzo:

E = 2.4 * KLOC1.05

= 2.4 * 7.41.05 = 20 hombre-mes

Para calcular la duracin del proyecto usamos la estimacin de esfuerzo: D = 2.5 * E0.38 = 2.5 * 200.38 = 8 meses El valor de la duracin del proyecto permite al planificador recomendar un nmero de personas N para el proyecto. N=E/D = 20 / 8 = 3 personas El planificador puede decidir emplear slo una o dos personas y ampliar por tanto la duracin del proyecto.

66

Ingeniera de SoftwareCOCOMO intermedio En el COCOMO intermedio, la ecuacin para calcular el tiempo de desarrollo es la misma que la del COCOMO bsico. La ecuacin para calcular el esfuerzo es: E = a * KLOCb * EAF Donde, E KLOC es el esfuerzo en hombre-mes es el nmero estimado de miles de lneas de cdigo

El coeficiente a y el exponente b estn dados por la tabla: Tipo de proyecto Orgnico Semiacoplado Empotrado Y EAF Es un factor de ajuste del esfuerzo que se calcula valorando en una escala de muy bajo, bajo, nominal, alto y muy alto cada uno de los siguientes 15 atributos, agrupados en 4 categoras. As: Atributos del producto. Son restricciones y requerimientos del proyecto que va a ser desarrollado. Confiabilidad requerida* Tamao de la base de datos Complejidad del producto Atributos de computadora. Son limitaciones puestas por el hardware y el sistema operativo donde el proyecto va a ejecutarse. o Restricciones de tiempo de ejecucin* o Restricciones de memoria principal* o Volatilidad de la mquina virtual. o Tiempo de respuesta de la computadora. a 3.2 3.0 2.8 b 1.05 1.12 1.20

67

Ingeniera de SoftwareEAF Atributos de personal. Nivel de habilidades que tiene el personal. Son habilidades profesionales generales, habilidad de programacin, experiencia con el medio ambiente de desarrollo y familiaridad con el dominio del proyecto. o Capacidad del analista. o Experiencia en aplicaciones* o Capacidad del programador. o Experiencia con la mquina virtual. o Experiencia con el lenguaje de programacin. Atributos del proyecto. Restricciones y condiciones bajo las cuales el proyecto se desarrolla. o Prcticas modernas de programacin o Uso de herramientas de software* o Calendario de desarrollo requerido.

A cada atributo se le asigna un nmero real de acuerdo a la tabla siguiente: Escala Muy bajo Bajo Nominal Alto Muy alto Nmero 0.75 0.88 1 1.15 1.40

El nmero indica el grado con el que cada factor puede influenciar la productividad. Un valor menor que 1 indica que el factor puede decrementar el calendario y el esfuerzo. Un valor mayor que 1 denota un factor que extiende el calendario y el esfuerzo. Finalmente, un valor igual a 1 no extiende ni decrementa el calendario y el esfuerzo (esta clase de factor se llama nominal). Para obtener el EAF se multiplican cada uno de los 15 factores. Se puede simplificar el clculo del EAF porque hay una tendencia a considerar los atributos marcados en (*), como los ms relevantes y que deberan ser tomados en cuenta. La ecuacin del software 68

Ingeniera de Software

Propuesta por Putnam y Myers en 1992. Asume una distribucin especfica del esfuerzo a lo largo de la vida de un proyecto. Se obtuvo a partir de datos de productividad de unos 4,000 proyectos.

Es de la forma: E = (LOC * B0.333 / P)3 * (1 / t4) Donde, E t B Esfuerzo en hombres-ao. Duracin del proyecto en aos. Factor especial de destrezas. Para programas pequeos B vale 0.16, para programas intermedios vale 0.28, para programas mayores vale 0.39. Parmetro de productividad, para un software de tiempo real, P vale 2,000, para comunicaciones vale 10,000, para software cientfico vale 12,000 y para aplicaciones comerciales de sistemas vale 28,000.

P

Para simplificar el proceso de estimacin se sugiere un conjunto de ecuaciones obtenidas de la ecuacin del software. Un tiempo mnimo de desarrollo de software se define como: tmin = 8.14 * (LOC / P)0.43 para tmin > 6 meses. E = 180 * B * t3 en hombres-mes para E >= 20 hombres-mes y t representado en aos

69

Ingeniera de SoftwareAplicando las ecuaciones al ejemplo anterior, obtenemos:

tmin = 8.14 * (7,400 / 12,000)0.43 = 7 meses E = 180 * 0.28 * 0.753 = 21 hombres-mes

3.4 Riesgo del software El anlisis y la gestin del riesgo son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre. Un riesgo es un problema potencial puede ocurrir o no -.

Por tal razn es importante: Identificarlo Evaluar su probabilidad de aparicin, Estimar su impacto, y , Establecer un plan de contingencia por si ocurre el problema.

Los pasos que se deben seguir son:1 2

Identificar el riesgo. Reconocimiento de que algo puede ir mal. Cada riesgo se analiza para determinar la probabilidad de que pueda ocurrir y el dao que puede causar si ocurre.

3 3

Se priorizan los riesgos, en funcin de la probabilidad y del impacto.Se desarrolla un plan para gestionar aquellos riesgos con gran probabilidad e impacto.

3.4.1. Estrategias de riesgo 70

Ingeniera de SoftwareSe tienen dos estrategias: Reactiva Supervisa el proyecto en previsin de posibles riesgos. Evaluar las consecuencias del riesgo cuando este ya se ha producido (ya no es un riesgo) Actuar en consecuencia

Proactiva Identifica los riesgos potenciales. Evaluacin previa y sistemtica de riesgos Evaluacin de consecuencias Se establece un plan de contingencia para controlar el riesgo.

Riesgoimplica

Incertidumbre el acontecimiento que caracteriza al riesgo puede o no puede ocurrir.

Prdida Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas.

71

Ingeniera de Software3.4.2 Categoras de riesgos Riesgos del proyecto Pueden amenazar al plan del proyecto, porque puede retrazar el proyecto y aumentar los costos. Identifican problemas de: Presupuesto Personal Recursos Cliente Requisitos Riesgos tcnicos Amenazan la calidad del software y la planificacin temporal del proyecto. La implementacin puede llegar a ser difcil o imposible. Identifican problemas de: Diseo Implementacin De interfaz Verificacin Mantenimiento Riesgos del negocio Amenazan la viabilidad del software a construir. Se pone en riesgo el proyecto y el producto. Identifican problemas de: De mercado De estrategia De ventas De gestin De presupuesto

72

Ingeniera de Software3.4.3 Identificacin del riesgo Existen dos tipos de riesgo: Riesgos genricos Riesgos especficos Representan una amenaza potencial para Implican un conocimiento profundo del todos los proyectos de software. proyecto (Entorno, Tecnologa, Personal)

Lista de comprobacin de elementos de riesgo Es un mtodo que permite identificar riesgos, por medio de las siguientes categoras: Relacionados con tamao del producto el Se asocian los riesgos con el tamao del software a construir o desarrollar. Tamao estimado del proyecto (LOC/PF) Confianza en la estimacin Numero de programas, archivos y transacciones Tamao relativo al resto de proyectos Tamao de la base de datos Nmero de usuarios Nmero de cambios de requerimientos previstos antes y despus de la entrega Cantidad de software reutilizado Con el impacto en la Asociados con las limitaciones impuestas por la gestin. organizacin Efecto del producto en la cifra de ventas Visibilidad desde la direccin de la organizacin Fecha lmite de entrega razonable Nmero de clientes que usarn el producto Numero de productos con los que deber interaccionar Sofisticacin del usuario final Cantidad y calidad de la documentacin a entregar al cliente Lmites legales y gubernamentales Costos asociados al retraso en la entrega Costos asociados a errores en el producto

73

Ingeniera de SoftwareCon el tipo de cliente Asociados con la comunicacin del cliente. Hay experiencias anteriores con dicho cliente Tiene una idea clara de lo que precisa Est dispuesto a dedicar tiempo en la especificacin formal de requerimientos Est dispuesto a relacionarse de forma gil con el equipo de desarrollo Est dispuesto a participar en la revisiones Es un usuario experto Dejar trabajar al equipo de desarrollo sin dar consejos de experto informtico Entiende el ciclo de vida de una aplicacin Con la definicin del Asociados al proceso y seguimiento del software. proceso de produccin Hay una poltica clara de normalizacin y seguimiento de una metodologa Existe una metodologa escrita para el proyecto Se ha utilizado en otros proyectos Estn los gestores y desarrolladores formados Conoce todo el mundo los estndares Existen plantillas y modelos para todos los documentos resultado del proceso Se aplican revisiones tcnicas de la especificacin de requerimientos diseo y codificacin Se aplican revisiones tcnicas de los procedimientos de revisin y prueba Se documentan los resultados de las revisiones tcnicas Hay algn mecanismos para asegurar que un proceso de desarrollo sigue los estndares Se realiza gestin de la configuracin Hay mecanismos para controlar los cambios en los requerimientos que tienen impacto en el software Se documenta suficientemente cada subcontrato Se ha habilitado y se siguen mecanismos de seguimiento y evaluacin tcnica de cada subcontrato. Se dispone de tcnicas de especificacin de aplicaciones para facilitar la comunicacin con el cliente. Se usan mtodos especficos para anlisis de software Se utiliza un mtodo especfico para el diseo arquitectnico y de datos Est el 90% del cdigo en lenguajes de alto nivel 74

Ingeniera de Software Hay estndares de documentacin de cdigo Se usan mtodos especficos para el diseo de pruebas Se utilizan herramientas para llevar a cabo la planificacin y control

Con el entorno desarrollo

Con la tecnologa

de Asociados a las herramientas que se van a utilizar en el desarrollo del software Hay herramientas de gestin de proyectos Hay herramientas de gestin del proceso de desarrollo Hay herramientas de anlisis y diseo Hay generadores de cdigo apropiados para la aplicacin Hay herramientas de prueba apropiadas Hay herramientas de gestin de configuracin apropiadas Se hace uso de una base de datos o repositorio centralizado Estn todas las herramientas de desarrollo integradas Se ha proporcionado formacin a todos los miembros del equipo de desarrollo Hay expertos a los cuales solicitar ayuda acerca de las herramientas Hay ayuda en lnea y documentacin disponible Asociados con la tecnologa a utilizar y la complejidad del sistema Se trata de una tecnologa nueva en la organizacin Se requieren nuevos algoritmos o tecnologa de I/O Se debe interactuar con hardware nuevo Se debe interactuar con software que no ha sido probado Se debe interactuar con un B.D. cuya funcionalidad y rendimiento no ha sido probada Es requerido un interface de usuario especializado Se necesitan componentes de programa radicalmente diferentes a los hasta ahora desarrollados Se deben utilizar mtodos nuevos de anlisis, diseo o pruebas Se deben utilizar mtodos de desarrollo no habituales, tales como mtodos formales, Inteligencia Artificial o redes neuronales Se aplican requisitos de rendimiento especialmente estrictos 75

Ingeniera de SoftwareCon la tcnica Existen dudas de que el proyecto sea realizable experiencia Asociados a la experiencia de los ingenieros de desarrollo de software. Es el mejor personal disponible Tienen los miembros las tcnicas apropiadas Hay suficiente gente disponible Est el personal comprometido en toda la duracin del proyecto Habr parte del personal dedicado solamente en parte al proyecto Tiene el personal las expectativas correctas del trabajo Tiene el personal la necesaria formacin Puede la rotacin del personal perjudicar el proceso de desarrollo

3.4.4 Proyeccin del riesgo La estimacin del riesgo mide el riesgo de dos maneras: La probabilidad de que el riesgo sea real Las consecuencias de los problemas asociados con el riesgo, si ocurriera Se realizan cuatro actividades de proyeccin del riesgo: 1. 2. 3. 4. Establecer una escala que refleje la probabilidad percibida del riesgo Definir las consecuencias del riesgo Estimar el impacto del riesgo en el proyecto y en el producto Apuntar la exactitud general de la proyeccin del riesgo de manera que no haya confusiones.

Uso de Tablas de Riesgo Por medio del uso de la siguiente tabla se facilita una proyeccin del riesgo.

Riesgos Mayor nmero de usuarios previstos

Categora TP

Probabilidad Impacto 30% 3

1. En la columna Riesgo, se registran todos los riesgos 2. En la columna Categora, cada riesgo se categoriza as: 76

Ingeniera de Software Tamao del producto (TP) Impacto en la organizacin (IO) Tipo de cliente (TC) Proceso de produccin (PP) Entorno de desarrollo (ED) Tecnologa (T) Experiencia tcnica (ET) Se pueden utilizar las iniciales que se encuentran entre parntesis o puede asignar unas especficas. 3. En la columna Probabilidad, se registra la probabilidad de aparicin de cada riesgo. 4. En la columna Impacto, Se valora y se registra el impacto de cada riesgo as:

77

Ingeniera de Software1 2 3 4 Catastrfico Crtico Marginal Despreciable

Por ltimo la tabla es ordenada por probabilidad y por impacto. Aquellos riesgos que presentan alta probabilidad y alto impacto pasan al inicio de la tabla y los que presentan baja probabilidad e impacto pasan al final de la tabla. Una vez la tabla ha sido ordenada, el encargado del proyecto debe trazar una lnea de corte donde los riesgos que se encuentren por encima de sta lnea se les prestara una mayor atencin.

Evaluacin del impacto del riesgo La exposicin al riesgo est dada por la ecuacin: ER = P x C

Donde: P C Es la probabilidad de que ocurra un riesgo Costo del proyecto si el riesgo ocurre

Esta ecuacin se aplica para calcular la exposicin al riesgo de cada riesgo descrito en la tabla de riesgos. Estos clculos permiten ajustar los costos finales del proyecto.

Evaluacin del riesgo Se establece un punto en el que se decide cundo desistir y finalizar el proyecto. Para esto se debe: Definir un punto de referencia Marcar la relacin entre cada factor de riesgo enumerado y el punto de referencia Definir el rea de incertidumbre, donde ser tan vlido continuar como interrumpir el trabajo Predecir cmo la combinacin de riesgos afectar a los niveles de referencia 78

Ingeniera de Software3.4.5 Reduccin, supervisin y gestin del riesgo El objetivo que debe tener un equipo de software es evitar y tratar un riesgo. Para esto, es importante que se desarrolle un plan de reduccin del riesgo. Este plan de reduccin del riesgo involucra para cada riesgo una serie de pasos y acciones que debe tomar e implementar el equipo de desarrollo del software. El plan RSGR Se puede incluir una estrategia de gestin de riesgo en el plan del proyecto de software o se podran organizar los pasos de gestin del riesgo en un plan diferente de reduccin, supervisin y gestin del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del anlisis de riesgo y son empleados por el jefe del proyecto como parte del Plan del Proyecto general. A continuacin se expone un esquema del Plan RSGR:I. Introduccin 1. Alcance y propsito del documento 2. Visin general de los riesgos principales 3. Responsabilidades a. Gestin b. Personal tcnico II. Tabla de riesgo del proyecto. 1. Descripcin de todos los riesgos por encima 2. Factores que influyen en la probabilidad e impacto III. Reduccin, supervisin y gestin del riesgo n. Riesgo # n a. Reduccin i.Estrategia general. ii. Pasos especficos. b. Supervisin i. Factores a supervisar ii. Enfoque de supervisin c. Gestin i. Plan de contingencia ii. Consideraciones especiales. IV. Planificacin temporal de revisin del Plan RSGR V. Resumen

de

la

lnea

de

corte

79

Ingeniera de SoftwareUna vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los procedimientos de reduccin y supervisin del riesgo. La reduccin del riesgo es una actividad para evitar problemas. La supervisin del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales:

1. Valorar cuando un riesgo previsto ocurre de hecho. 2. Asegurarse de que los procedimientos para evitar el riesgo definidos para el riesgo en cuestin se estn aplicando apropiadamente. 3. Recoger informacin que pueda emplearse en el futuro para analizar riesgos.

La supervisin de riesgos tambin intentar determinar el "origen" (qu riesgos ocasionaron tal problema) a lo largo de todo el proyecto.

80

Ingeniera de Software3.5 Planificacin temporal La planificacin temporal de un proyecto es una actividad que evoluciona con el tiempo y que permite identificar, definir y programar las actividades especficas que se requieren para realizar una actividad. La planificacin temporal permite: Definir todas las tareas Definir las tareas crticas Identificar el camino crtico Realizar seguimiento a tareas -> Detect