Documente Academic
Documente Profesional
Documente Cultură
MODULO
Unidad 1. 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.
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. 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. 2
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
ESTRUCTURA 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.
Afecta las actividades cotidianas Afecta cualquier aspecto de nuestras vidas Est muy extendido en el comercio
Primeros Aos
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.
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
Tercera era
Complejidad alta en los sistemas informticos Sistemas distribuidos Incorporacin de inteligencia Ejecucin de funciones concurrentes Desarrollo de software para redes y comunicaciones Planificacin en el proceso del desarrollo de software
Cuarta era
Impacto colectivo del software Sistemas operativos operativos sofisticados , en redes globales y locales Aplicaciones de software avanzadas Entorno cliente/cliente servidor Superautopista de informacin y una conexin del ciberespacio La industria del software es la cuna de la economa Tecnologas orientadas a objetos Tcnicas de cuarta generacin para el desarrollo de software Software de redes neuronales Sistemas expertos e inteligencia artificial Programacin de realidad virtual y sistemas multimedia Algoritmos genticos Adopcin de prcticas de Ingeniera del software
1.3 El Software
1
El Elsoftware softwareque quecoordina coordina/ /analiza/ analiza/controla controlasucesos sucesos del delmundo mundoreal realconforme conformeocurren, ocurren,se sedenomina denominade de tiempo real. tiempo real.
Software empotrado Reside Resideen enmemoria memoriade deslo slolectura lecturayyse seutiliza utilizapara para controlar productos y sistemas de los mercados controlar productos y sistemas de los mercados industriales. industriales.Por Porejemplo, ejemplo,el elcontrol controlde delas lasteclas teclasde de un horno de microondas, funciones digitales en un un horno de microondas, funciones digitales en un automvil. automvil. Aplicaciones Aplicaciones orientadas orientadas aa usuarios usuarios individuales individuales oo multiusuarios. Por ejemplo: procesadores multiusuarios. Por ejemplo: procesadoresde detexto, texto, hojas hojas de de clculo, clculo, juegos, juegos, aplicaciones aplicaciones financieras, financieras, gestores gestoresde debases basesde dedatos. datos. Software de inteligencia artificial Hace Haceuso usode dealgoritmos algoritmosno nonumricos numricospara pararesolver resolver problemas problemas complejos. complejos. Por Por ejemplo: ejemplo: sistemas sistemas expertos, expertos, redes redes neuronales, neuronales, robtica, robtica, prueba prueba de de teoremas teoremasyyjuegos. juegos.
Software para PC
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.
10
el el conjunto conjunto
de
Principios Principios
Mtodos Mtodos
Tcnicas Tcnicas
para
Desarrollar Desarrollar
Mantener Mantener
Software Software
de
Calidad 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:
Zelkovitz. Principles of Software Engineering and Design. Ingeniera del software es el estudio de los principios y 11 metodologas para desarrollo y mantenimiento de sistemas de software.
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.
12
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.
13
Esta figura podra resumir buena parte de la esencia de la asignatura: 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.
14
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.
15
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.
17
Ingeniera Ingeniera del delSistema Sistema Anlisis Anlisis Diseo Diseo Codificaci Codificaci n n Prueba Prueba Utilizacin Utilizacin Mantenimien Mantenimien to to
Anlisis
Diseo
Codificacin
Utilizacin Mantenimient o
Utilizar el prototipo
No
Revisar el prototipo
Descripcin Los analistas y los usuarios trabajan juntos para identificar los requerimientos conocidos que tienen que satisfacerse. Se debe: determinar los fines del sistema y el alcance de su capacidad. Paso 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.
Primer a Iteraci n
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 el La responsabilidad de trabajar con el prototipo y 21
22
23
DRA DRA
es un
modelo de proceso
del
24
Equipo N. 1
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?
25
son
iterativos
caracterizan
por
desarrollar versiones
cada vez
26
Construccin de prototipos
Entregar el software
en
Partes pequeas
llamadas
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.
27
Anlisis
Diseo
Cdigo
Prueba
incremento 2
Anlisis
Diseo
Cdigo
Prueba
incremento 3
Anlisis
Diseo
Cdigo
Prueba
incremento 4
Anlisis
Diseo
Cdigo
Prueba
Tiempo
Model o Espiral
es un
proporciona
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.
28
29
las etapas
Recoleccin de requisitos: descritos por los clientes Diseo de prototipo 30 Desarrollo de prototipo operativo Implementacin Documentacin Mantenimiento
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?
31
BIBLIOGRAFIA
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.info-ab.uclm.es/asignaturas/42551/enlaces.htm http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdf http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.php http://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppt http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html http://www.monografias.com/trabajos5/inso/inso.shtml http://www.sistemas.unam.mx/software.html http://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.html 32
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.
33
ESTRUCTURA TEMTICA
1. CONCEPTOS SOBRE GESTION DE PROYECTOS 1.1 Gestin de proyectos Gestin de proyectos
implic a
Planificaci n
Supervisi n
de
Control
Personal
Procesos
mientra s
eventos
Personal
Necesidad de personal para el desarrollo de software
Producto
Objetivos y mbito del software
Proceso
Estructura que establece un plan detallado para el desarrollo del software
Proyecto
Proyectos de software planificados y controlados.
34
Participante Se clasifican en: s Gestores Superiores: se encargan de definir los aspectos del negocio. Gestores tcnicos del proyecto: se encargan de planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de desarrollo del software. Profesionales: se encargan de proporcionan las capacidades tcnicas necesarias para la ingeniera de un producto o aplicacin. Clientes: especifican los requisitos para la ingeniera del software. Usuarios finales: Se encargan de interactuar con el software. Jefes equipo 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.
Equipo software
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.
35
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 36 producto delimitarlo.
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?
Descomposici Comprende el anlisis de requisitos del software. n 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 pequeos que resultan ms manejables. problemas ms
37
38
Realizar seguimiento a las actividades desarrolladas durante el proceso como parte de la calidad del mismo.
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.
39
40
Una gama
de
Mediciones
para el
se
aplican
al
Software
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.
41
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 Los indicadores indicadores de de proyecto proyecto
permite n
Evaluar la habilidad del equipo para controlar la calidad de los productos software.
De acuerdo a la figura:
Producto
Caracterstic as del cliente Condiciones del negocio
Proceso
Persona s
Entorno de desarrollo
Tecnologa
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 43
Tambin se debe incluir mtricas para medir las caractersticas de tareas especficas de la ingeniera del software. Medida Medida del del tiempo tiempo y y del del esfuerzo esfuerzo para para llevar llevar a a cabo cabo actividades de proteccin actividades de proteccin Actividades Actividades genricas genricas de de ingeniera ingeniera del del software 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).
MEP S
utiliza
Anlisis de fallos
del
Software
para
Recopilar informacin
1 2 3
Registrar el costo de corregir cada error y el del defecto s Contar el nmero de errores y de defectos de cada categora y se ordenar por orden descendente Computar el costo global de errores y defectos de cada categora. Los datos resultantes se analizan para detectar las categoras que producen un costo alto para la organizacin Desarrollar planes para eliminar los errores y defectos ms costosos.
Errores
Defecto
4 5
44
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
Defect o
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.
Ci, j
Problema Principal R%
Ci, j
Ci, j : Causa asociada a cada subproblema Qi %: Porcentaje de relevancia del subproblema 45 R% : Porcentaje de relevancia del problema principal
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 Diseo Cdigo Causa Lgica Manejo de datos estndares Especificaciones Interfaz software Interfaz hardware Comprobacin de errores Interfaz de usuario % 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:
Incorrecto
Cliente consultado no adecuado El cliente dio informacin equivocada Insuficiente informacin solicitada Informacin desactualizada
Cambios
Perdido
Ambiguo
46
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.
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
47
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 funcin
Mtricas del software orientadas a la funcin
permiten Propuestas por
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.
48
= = = = =
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:
2. Nmero de salidas de usuario: se cuenta cada salida que proporciona al usuario infor
3. Nmero de peticiones de usuario: una peticin esta definida como una entrada interactiva qu
4. Nmero de archivos:
5. Nmero de interfaces externas: se cuentan todas las interfaces legibles por la maqu
49
Fi :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 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 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?
50
51
52
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.
53
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:
54
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
55
56
Planificacin
implica determina
Estimaci n
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.
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. Planificacin
involucra mbito del software Recurso s Estimacin del proyecto Tcnicas de descomposici n Modelos de estimacin
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: 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. 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 sin 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 58
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. 59
Recursos de entorno El entorno es donde se apoya el proyecto de software. Comprende Hardware Software y
Comprende el conjunto de herramientas requeridas para producir o desarrollar el producto software y se debe verificar que estos recursos estn disponibles. 3.2 Estimacin descomposicin del proyecto de software y tcnicas de
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.
60
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 original
Qu 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.
61
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
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 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
62
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.
63
Modelo Modelo s s
COCOMO 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:
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
64
Los coeficientes a y c y los exponentes b y d se obtienen de la siguiente tabla: Tipo de proyecto Orgnico Semiacoplado Empotrado a b 2.4 1.0 5 3.0 1.1 2 3.6 1.2 0 C 2. 5 2. 5 2. 5 d 0.3 8 0.3 5 0.3 2
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.
65
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. 66 a b 3.2 1.0 5 3.0 1.1 2 2.8 1.2 0
EAF 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.
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
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 P 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. 68
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 hombresmes y t representado en aos
69
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.
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
Proactiva Identifica los riesgos potenciales. Evaluacin previa y sistemtica de riesgos Evaluacin de consecuencias Se establece un plan de contingencia para controlar el riesgo.
Riesgo
implica
71
72
Lista de comprobacin de elementos de riesgo Es un mtodo que permite identificar riesgos, por medio de las siguientes categoras: Relacionados con el Se asocian los riesgos con el tamao del software a construir o desarrollar. tamao del producto
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. Efecto del producto en la cifra de ventas organizacin 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
74
Con el entorno de Asociados a las herramientas que se van a utilizar en el desarrollo del software desarrollo
Con la tecnologa
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 Existen dudas de que el proyecto sea realizable
75
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. Establecer una escala que refleje la probabilidad percibida del riesgo 2. Definir las consecuencias del riesgo 3. Estimar el impacto del riesgo en el proyecto y en el producto 4. 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 Probabilid ad 30% Impact o 3
1. En la columna Riesgo, se registran todos los riesgos 2. En la columna Categora, cada riesgo se categoriza as: Tamao del producto (TP) 76
77
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 78
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
3.5.1 Principios bsicos de la planificacin temporal Compartimentar Interdependencia Tareas y actividades manejables Las actividades pueden ser: Secuenciales Paralelas Independientes Orden de ejecucin A cada tarea se debe asignar: N unidades de tiempo Fecha inicio y fecha fin Asignar: Esfuerzo N personas actual Asignar: Tarea Miembro equipo Cada tarea debe tener un resultado o producto definido. Cada tarea Hito
81
El diagrama PERT es una representacin grfica de las relaciones entre las tareas del proyecto que permite calcular los tiempos del proyecto de forma sencilla. Caractersticas Es un grafo, o sea, un conjunto de puntos (nodos) unidos por flechas. Representa las relaciones entre las tareas del proyecto, no su distribucin temporal. Las flechas del grafo corresponden a las tareas del proyecto. Los nodos del grafo, representado por crculos o rectngulos, corresponden a instantes del proyecto. Cada nodo puede representar hasta dos instantes distintos, el inicio mnimo de las tareas que parten del nodo y el final mximo de las tareas que llegan al mismo. Es una herramienta de clculo, y una representacin visual de las dependencias entre las tareas del proyecto. Tarea A B C D E F G H Predec Duraci . n A C DII+1 BFI-1 D, E, F GFF 2 3 2 3 2 3 3 2
82
Para construir un diagrama PERT se deben tener en cuenta las siguientes reglas Los nodos representan instantes del proyecto. Cada nodo representa el inicio mnimo (im) de las tareas que tienen origen en dicho nodo y el final mximo (FM) de las tareas que llegan al mismo.
Slo puede haber un nodo inicial y un nodo final. O sea, slo puede haber un nodo al que no llegue ninguna flecha (nodo inicial) y slo puede haber un nodo del que no salga ninguna flecha (nodo final). La numeracin de los nodos es arbitraria, si bien se reservan el nmero menor (generalmente el 0 o el 1) para el nodo inicial y el mayor para el nodo final. Las flechas representan tareas y se dibujan de manera que representen las relaciones de dependencia entre las tareas. Los recorridos posibles a travs del diagrama desde el nodo inicial al nodo final, siguiendo el sentido de las flechas, deben corresponder con las secuencias en que deben realizarse las distintas tareas, o sea, los caminos del proyecto.
No
puede
haber
dos
nodos
unidos
por
ms
de
una
flecha.
Se pueden introducir tareas ficticias, de duracin 0, para evitar construcciones ilegales o representar dependencias entre tareas.
83
Con un diagrama PERT se obtiene un conocimiento preciso de la secuencia necesaria, o planificada para la ejecucin de cada actividad y utilizacin de diagramas de red. Se trata de un mtodo muy orientado al plazo de ejecucin, con poca consideracin hacia al costo. Se suponen tres duraciones para cada suceso: la optimista a, la pesimista b y la normal m; Suponiendo una distribucin beta, la duracin ms probable: t = (a + 4m + b) / 6. Aplicacin de las tcnicas PERT: Determinar las actividades necesarias y cuando lo son. Buscar el plazo mnimo de ejecucin del proyecto. Buscar las ligaduras temporales entre actividades del proyecto. Identificar las actividades crticas, es decir, aquellas cuyo retraso en la ejecucin supone un retraso del proyecto completo. Identificar el camino crtico, que es aquel formado por la secuencia de actividades crticas del proyecto. Detectar y cuantificar las holguras de las actividades no crticas, es decir, el tiempo que pueden retrasarse (en su comienzo o finalizacin) sin que el proyecto se vea retrasado por ello. Si se est fuera de tiempo durante la ejecucin del proyecto, seala las actividades que hay que forzar. Nos da un proyecto de coste mnimo.
84
El camino crtico en un proyecto es la sucesin de actividades que dan lugar al mximo tiempo acumulativo. Determina el tiempo ms corto que podemos tardar en hacer el proyecto si se dispone de todos los recursos necesarios. Es necesario conocer la duracin de las actividades. Este concepto es utilizado por dos mtodos: Mtodo del tiempo estimado (CPM) La duracin de una actividad es la ms probable de duracin. Tiempo que se empleara en condiciones normales (m). Situacin determinista. Mtodo del tiempo esperado (PERT) Determinacin probabilstica de los tiempos esperados (Te), en funcin de los siguientes tiempos: o Duracin ms corta (a) o Duracin ms larga (b) o Duracin ms probable (m) (el mismo que en CPM) o Duracin esperada: Te = (a + 4m + b) / 6 Clculo del camino crtico
1. Calcular Te m segn el mtodo empleado para cada actividad. Se coloca en el grafo encima o debajo de cada flecha. 2. Calcular las fechas early -fecha mnima de comienzo de la actividad, MIC del suceso anterior- y last -fecha mnima de comienzo de la actividad, MAC del suceso posterior- de las distintas actividades que configuran el proyecto. (Calcular el MIC y el MAC de todos los sucesos del proyecto). 3. Clculo de las holguras. 4. Identificacin del camino crtico.
Holguras La holgura de una actividad es el margen suplementario de tiempo que tenemos para determinar esa actividad. Las actividades crticas no tienen holgura.
Holgura de un suceso Hs: Hs = MAC del suceso MIC del suceso
Holgura total de una actividad Ht = MAC del s.p. MIC del s.a. duracin tarea Ht: Margen suplementario de tiempo de esa actividad sin que se altere el MIC de ninguna actividad crtica. Holgura libre de unaHi: HI = MIC del s.p. MIC del s.a. duracin tarea Margen suplementario de tiempo para esa actividad sin que se altere el MIC de cualquier actividad. Holgura independiente Hi: Hi = MIC del s.p. MAC del s.a. duracin tarea Margen suplementario de tiempo que existe en una actividad si las actividades precedentes
85
Actividades crticas Una actividad es crtica cuando no se puede cambiar sus instantes de comienzo y finalizacin sin modificar la duracin total del proyecto. La concatenacin de actividades crticas es el camino crtico. En una actividad crtica la fecha early coincide con la ms tarda de comienzo, y la fecha ms temprana de finalizacin coincide con la fecha last de la actividad. La holgura total es 0.
3. DIAGRAMA DE GANTT
Los cronogramas de barras o grficos de Gantt fueron concebidos por el ingeniero norteamericano Henry L. Gantt. Gantt resolvi el problema de la programacin de actividades, es decir, su distribucin conforme a un calendario, donde se poda visualizar el periodo de duracin de cada actividad, sus fechas de iniciacin y terminacin e igualmente el tiempo total requerido para la ejecucin de un trabajo. El instrumento que desarroll permite tambin que se siga el curso de cada actividad, al proporcionar informacin del porcentaje ejecutado de cada una de ellas, as como el grado de adelanto o atraso con respecto al plazo previsto. Este grfico consiste en un sistema de coordenadas en que se indica:
En el eje Vertical: Las actividades que constituyen el trabajo a ejecutar. A cada actividad se hace corresponder una lnea horizontal cuya longitud es proporcional a su duracin en la cual la medicin efecta con relacin a la escala definida en el eje horizontal.
En el eje Horizontal: un calendario, o escala de tiempo definido en trminos de la unidad ms adecuada al trabajo que se va a ejecutar: hora, da, semana, mes, etc.
86
Oct 2005
Nov 2005
Dec 2005
ID 1 2 3 4 5
Duracion
10/2 10/9 10/16 10/23 10/30 11/6 11/13 11/20 11/27 12/4 12/11 12/18
5w 5w 8w 12.40w 2.40w
Smbolos Convencionales: Los smbolos bsicos son los siguientes: Iniciacin de una actividad. Trmino de una actividad Lnea fina que conecta las dos L invertidas. Indica la duracin prevista de la actividad. Lnea gruesa. Indica la fraccin ya realizada de la actividad, en trminos de porcentaje. Debe trazarse debajo de la lnea fina que representa el plazo previsto. Plazo durante el cual no puede realizarse la actividad. Corresponde al tiempo improductivo puede anotarse encima del smbolo utilizando una abreviatura. Indica la fecha en que se procedi a la ltima actualizacin del grfico, es decir, en que se hizo la comparacin entre las actividades previstas y las efectivamente realizadas. En el proceso de dibujar un diagrama de Gantt se tendrn en cuenta las siguientes consideraciones siguientes: Las dependencias fin-inicio se representan alineando el final del bloque de la tarea predecesora con el inicio del bloque de la tarea dependiente. Las dependencias final-final se representan alineando los finales de los bloques de las tareas predecesora y dependiente. Las dependencias inicio-inicio se representan alineando los inicios de los bloques de las tareas predecesora y dependiente. Los retardos se representan desplazando la tarea dependiente hacia la derecha en el caso de retardos positivos y hacia la izquierda en el caso de retardos negativos.
87
ACTIVIDADES COMPLEMENTARIAS 1. Investigue sobre TFEA (Facilitated application specification techniques). Puede consultar en: http://www.rspa.com/checklists/risk.html 2. Investigue y profundice sobre el tema: Estimacin del proyecto software. Elabore un ensayo. 3. Un tema de gran importancia en el cual se puede profundizar es: Lgica difusa (http://delta.cs.cinvestav.mx/~gmorales/ldifll/ldifll.html) Constructive Cost Model (http://www1.jsc.nasa.gov/bu2/COCOMO.html) 4. Describa la diferencia entre riesgos conocidos y riesgos predecibles 5. Usted es el jefe de proyectos de una compaa de software. Se le ha pedido que dirija a un equipo que est desarrollando un software de un procesador de textos. Construya una tabla de riesgo para el proyecto. 6. Asuma que ha sido contratado por una Universidad para desarrollar un sistema de inscripcin a cursos para un determinado programa. Defina un listado de tareas. Utilice las diferentes tcnicas descritas en el numeral 4.6.2 para establecer una planificacin temporal del proyecto.
88
BIBLIOGRAFIA
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, Jose 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.cis.ohio-state.edu/hypertext/faq/usenet/proj-planfaq/faq.html http://www.rspa.com http://www.pmi.org http://www.4pm.com http://www.projectmanagement.com www.minas.unalmed.edu.co/facultad/publicaciones/dyna/143/ALINEACI%D3N%20ENTRE %20METAS.pdf http://www.calidad.org/s/causa.pdf http://www.salud.gob.mx/unidades/dgces/gestion/page/05.html
http://www.minas.unalmed.edu.co/facultad/publicaciones/dyna/143/ALINEACI%D3N%20ENTRE %20METAS.pdf
89
UNIDAD 3.
CONTROL DE CALIDAD DEL SOFTWARE
INTRODUCCIN
La garanta de calidad del software es una actividad de proteccin que se aplica a cada paso del proceso de software y que comprende: procedimientos, mtodos y herramientas, revisiones tcnicas formales, tcnicas y estrategias de prueba, procedimientos de garanta de ajustes y mecanismos de medida e informacin.
OBJETIVOS
GENERALES Estudiar las tcnicas de gestin de calidad del software. Determinar las tcnicas de prueba de software con el propsito de encontrar y corregir errores antes de entregar el programa al cliente. Definir las estrategias de prueba del software Determinar y analizar las mtricas tcnicas del software Determinar y aprender los beneficios de la reutilizacin del software. ESPECIFICOS Determinar qu es la calidad del software Identificar los aspectos de gestin y las actividades especficas del proceso de calidad del software. Establecer la importancia de la garant de calidad del software as como definir las estrategias para los planes de garanta de calidad del software. Definir los fundamentos de las pruebas del software. Determinar que son las pruebas de caja negra, blanca, de camino bsico y de estructura de control. Identificar las pruebas de unidad, integracin, validacin y del sistema. Identificar las mtricas del modelo de anlisis, del modelo de diseo, del cdigo fuente, para pruebas y del mantenimiento. Definir los fundamentos de la reutilizacin del software. Determinar las dificultades para la reutilizacin 90
1. GARANTIA DE CALIDAD DEL SOFTWARE La garanta de calidad del software (SQA, Software Quality Assurance GCS, Gestin de calidad del software) es una actividad de proteccin que se aplica a lo largo de todo el proceso del software. Antes del siglo veinte, la garanta de calidad era responsabilidad nica de la persona que construa el producto. La primera funcin de control y de garanta de calidad formal fue introducida por los laboratorios Bell en 1916 y se extendi rpidamente por todo el mundo de las manufacturas. Hoy en da, cada compaa tiene un mecanismo que asegura la calidad de sus productos de hecho, durante la pasada dcada, se han usado ampliamente como tcticas de mercado la declaracin explcita de mensajes que ponan de manifiesto la calidad ofrecida por las compaas.
2
La historia de la garanta de calidad en el desarrollo de software ha sido paralela a la historia en la fabricacin de hardware. Durante los primeros aos de informacin (los 50 y los 60), la calidad era responsabilidad nicamente del programador. Durante los aos 70 se introdujeron estndares de garanta de calidad para el software en los contratos militares de desarrollo de software y sean extendido rpidamente en los desarrollos de software del mundo comercial. La SQA forma parte de una funcin ms amplia de garanta de calidad y engloba las siguientes actividades: 1. Un enfoque de gestin de calidad. 2. Mtodos y herramientas 3. Revisiones tcnicas formales 4. Documentacin La calidad del software es importante porque:
http://www.pcm.gob.pe/portal_ongei/publicaciones/cultura/Lib5042/cap20.htm
91
De Diseo Son las caractersticas que se especifican para un elemento. Comprende: Requisitos Especificaciones Diseo del sistema
92
De Concordancia Es el grado de cumplimiento de las especificaciones de diseo. Centrado en: La implementacin Debe ser: Alta
93
94
Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfar los requerimientos dados sobre calidad. En Ingeniera de Software, Segn Roger S. Pressman: Consiste en la auditoria y las funciones de informacin de la gestin. El objetivo es proporcionar la gestin para 4. Coste de informar de Calidad los datos necesarios sobre la calidad del producto, por lo Son todos costos acarreados laprofunda bsqueda de la calidad o en las que se va los adquiriendo una visin en ms y segura de que la actividades con la obtencin la calidad. calidad delrelacionadas producto est cumpliendo susde objetivos. Se dividen en: Costes de prevencin: Costes de evaluacin: Planificacin de la calidad Inspeccin en el proceso y entre procesos Revisiones tcnicas Calibrado y mantenimiento del formales equipo Equipo de pruebas Pruebas Formacin Costes de fallos internos Costes de fallos externos Retrabajo (revisin) Resolucin de quejas Reparacin Devolucin y sustitucin productos Anlisis de la modalidades Soporte de lnea de ayuda de fallos Trabajo de garanta
de
95
Kaizen Se refiere a un sistema de mejora continua en el proceso. El objetivo es desarrollar un proceso que sea visible, repetible y mensurable.
El objetivo de la actitud Kaizen es el mejoramiento continuo en base a pequeos y constantes cambios, mediante la eliminacin, reduccin o cambio de las cosas, sistemas, medidas, etc.; que impiden un adecuado desempeo de las actividades. En el marco empresarial, se traduce a que todos los miembros de una organizacin estn comprometidos con la revisin constante de los procesos y la mejora permanente. KAISEN est basado en las cinco S SEIRE Organizacin: Cada cosa en su lugar y un lugar para cada cosa. SEITON Reducir bsquedas: Facilitar el movimiento de las cosas, servicios y personas SEISO Limpieza: Cuando todo est limpio, todo est ordenado y se simplifican los procedimientos. SEIKETSU Estandarizacin y simplificacin de procesos: Mantener el orden, organizacin y Atarimae (Calidad Funcional) limpieza en hinshitsu el ambiente y las personas.
Examina lo intangible que afecta al proceso y trabaja para optimizar SHITSUKE Kansei su impacto en el proceso. Disciplina buenos hbitosdel de trabajo: Basados en el respeto a las reglas y a el las Se centrayen el usuario producto. Examinando la forma en que personas (compaeros de trabajo y clientes) usuario aplica el producto, conduce a la o mejora Calidad Funcional: es la calidad quekansei ya se le asigna al producto servicio en el mismo, si son autos... depende de la marca del auto para producto mismo y potencialmente al proceso queasignarle lo creo.
inconscientemente una calidad. Kansei es un trmino japons donde la slaba kan significa sensitividad y sei significa sensibilidad. Se usa para expresar la cualidad de un objeto de despertar placer en su uso. As, hay objetos con mucho kansei y otros con absolutamente ninguno. Cada vez ms, se est expresando la necesidad de tener en cuenta los aspectos subjetivos (emocin, afecto, percepciones, sensaciones...) en la experiencia de uso, yendo ms all del puro diseo visual. Las necesidades bsicas que permitirn definir la estructura general del planteamiento Kansei son como sigue (Nagamachi, 1995): 3 Obtener y cuantificar la respuesta del usuario en trminos kansei (valoracin psicosociolgica). Identificar las caractersticas de diseo de un producto desde la percepcin del usuario. 96 Implementar la herramienta a partir de los datos anteriores. Ajustar el diseo del producto a los cambios sociales y a los que se producen en las preferencias de los usuarios con el paso del tiempo.
Miryoku Teki hinshitsu Orientado a la gestin que busca la oportunidad en reas relacionadas que se pueden identificar observando la utilizacin del producto en el mercado.
Calidad Emocional: es lo que te hace sentir el usar tal o cual producto o servicio.... no te sientes igual al conducir un Toyota que un mercedes Benz o que un auto volvo....
97
La garanta de calidad del software (SQA), comprende un conjunto de tareas y acciones sistemticas y planificadas que permiten asegurar la calidad del software. A este conjunto de tareas y acciones se le denomina Actividades de SQA y comprende: Actividad Plan SQA para proyecto Caractersticas el El plan debe involucrar: Evaluaciones, Auditorias, revisiones, estndares que se pueden aplicar al proyecto. Procedimientos para informacin, seguimiento de errores y realimentacin. El grupo SQA debe adems documentar la informacin necesaria.
Actividad Caractersticas Proceso de software del Se determina el proceso y se realiza la revisin de proyecto la descripcin del proceso para poder establecer los ajustes de acuerdo a las polticas de la organizacin. Ajustes al proceso del El grupo SQA se encarga de revisar, documentar y software verificar que se han hecho los ajustes al proceso. Auditoria de los El grupo SQA esta en constante revisin del productos de software proceso software e informa peridicamente los resultados al gestor del proyecto. 98
Las revisiones de software se usan como modelo para la amplificacin de defectos y para ilustrar la generacin y deteccin de errores durante los pasos de diseo preliminar, diseo detallado y codificacin del proceso de ingeniera del software.
Paso de desarrollo Defectos Errores de pasos anteriores Errores que pasan inadvertidos Errores amplificados 1:x Nuevos errores Deteccin Errores pasados al Porcentaje de eficiencia de siguiente la deteccin de errores paso
99
Descubrir errores en la funcin, la lgica o la implementacin de cualquier representacin del software Verificar que el software bajo revisin alcanza sus requisitos Garantizar que el software ha sido representado de acuerdo con ciertos estndares predefinidos Conseguir un software desarrollado de forma uniforme Hacer que los proyectos sean manejables
La RTF incluye: Recorridos Inspecciones Revisiones cclicas Evaluaciones tcnicas del software
Cada RTF debe estar debidamente planificada, controlada y atendida por el grupo encargado de cada RTF. Cada reunin debe tener las siguientes caractersticas: Deben convocarse para la revisin entre tres y cinco personas Se debe preparar por adelantado, La duracin de la reunin de revisin, debe ser menor de dos horas 100
Registro e informe de la revisin Como se menciono anteriormente, uno de los revisores es el encargado de registrar todos los acontecimientos y conclusiones que van surgiendo durante la RTF. Al final de la reunin, hace un resumen de las conclusiones y genera una lista de sucesos de revisin. Adems, prepara un informe sumario de la revisin tcnica formal que responda a las siguientes preguntas: Que fue revisado? Quin lo revis? Qu se descubri conclusiones?
cules
son
las
La lista de sucesos de revisin que se genera permite: Identificar reas problemticas dentro del producto Servir como lista de comprobacin para hacer las correcciones.
101
102
4. Una vez que se han identificado los defectos vitales, se acta para corregir los problemas que han producido los defectos.
El siguiente es un ejemplo de aplicacin: Los siguientes son los defectos mas frecuentes que se han encontrado en procesos de desarrollo de software:
Especificacin incompleta o errnea Mala interpretacin de la comunicacin del cliente Desviacin deliberada de la especificacin Incumplimiento de los estndares de programacin Error en la representacin de los datos Interfaz de mdulo inconsistente Error en la lgica de diseo Prueba incompleta o errnea Documentacin imprecisa o incompleta Error en la traduccin del diseo al lenguaje de programacin Interfaz hombre-maquina ambigua o inconsistente Varios
103
Error
Especificacin incompleta o errnea Mala interpretacin de la comunicacin del cliente Desviacin deliberada de la especificacin Incumplimiento de los estndares de programacin Error en la representacin de los datos Interfaz de mdulo inconsistente Error en la lgica de diseo Prueba incompleta o errnea Documentacin imprecisa o incompleta Error en la traduccin del diseo al lenguaje de programacin Interfaz hombre-maquina ambigua o inconsistente Varios Total
Frecuencia (No.)
205 156 48 25 130 58 45 95 36 60 28 56 942
El siguiente paso es utilizar la frecuencia porcentual es decir, el porcentaje de errores en cada tipo de defecto: Error Especificacin incompleta o errnea Mala interpretacin de la comunicacin del cliente Desviacin deliberada de la especificacin Incumplimiento de los estndares de programacin Error en la representacin de los datos Interfaz de mdulo inconsistente Error en la lgica de diseo Prueba incompleta o errnea Documentacin imprecisa o incompleta Error en la traduccin del diseo al lenguaje de programacin Interfaz hombre-maquina ambigua o inconsistente Varios Total Frecuencia (No.) 205 156 48 25 130 58 45 95 36 60 28 56 942 Frec. % 22% 17% 5% 3% 14% 6% 5% 10% 4% 6% 3% 6% 100%
El objetivo es determinar cules son los defectos que aparecen con mayor frecuencia. Para esto se ordenan los datos de la tabla en orden decreciente de frecuencia:
104
105
De esta forma, resulta evidente cuales son los tipos de defectos ms frecuentes. Podemos observar que los 4 primeros tipos de defectos representan ms del 60%. Por el Principio de Pareto, se puede concluir que: La mayor parte de los defectos encontrados pertenece slo a 4 tipos de defectos, de manera que si se eliminan las causas que los provocan desaparecera la mayor parte de los defectos.
Fiabilidad del software La fiabilidad del software es la probabilidad de que en un tiempo y entorno determinado el software en operacin este libre de fallos. Los fallos del software, se producen por problemas de diseo o de implementacin. La medida de fiabilidad del software est dada por: El tiempo medio entre fallos (TMEF), TMEF = TMDF + TMDR
Donde: 106
La disponibilidad del software Es la probabilidad de que un programa funcione de acuerdo con los requisitos en un momento dado. Se define como: Disponibilidad = TMDF (100%) TMDF+TMDR
Estos datos pueden ser medidos o estimados mediante datos histricos o de desarrollo. El estndar de calidad ISO 9001 La Organizacin Internacional para la Estandarizacin (ISO) es una federacin mundial de cuerpos de normas nacionales de aproximadamente 140 pases. ISO es una organizacin establecida en 1947, cuya misin es promover el desarrollo de la estandarizacin y de las actividades relacionadas en el mundo, con la idea de que facilita el cambio internacional de bienes y servicios, y la cooperacin que se desarrolla en las esferas de la actividad intelectual, la actividad cientfica, tecnolgica y econmica. La serie ISO 9000 es un conjunto de normas orientadas a ordenar la gestin de la empresa que han ganado reconocimiento y aceptacin internacional debido al mayor poder que tienen los consumidores y a la alta competencia internacional acentuada por los procesos integracionistas. Algunas de estas normas especifican requisitos para sistemas de calidad (ISO 9001, 9002, 9003) y otras dan una gua para ayudar en la interpretacin e implementacin del sistema de calidad (ISO 9000-2, ISO 9004-1)
107
3.
4. 5. 6. 7. 8.
108
109
111
La lgica interna del programa. Utilizando pruebas de "caja blanca" Los requisitos del software. Utilizando pruebas de caja negra
2.1 Fundamentos de la prueba del software Las pruebas de software tienen los siguientes objetivos:
Las tienen
Descubrir un error Mostrar un error no descubierto hasta ese momento Descubrir un error no detectado hasta ese momento
112
Un software debe ser fcil de probar, para lo cual se puede tener en cuenta las siguientes caractersticas que propone Pressman:
Caracterstica Operatividad Observacin Cunto mejor funcione, ms eficientemente se puede probar El sistema tiene pocos errores Ningn error bloquea la ejecucin de las pruebas El producto evoluciona en fases funcionales Observabilida Lo que se ve es lo que se prueba d Se genera una salida distinta para cada entrada Todos los factores que afectan a los resultados estn visibles Un resultado incorrecto se identifica fcilmente Los errores internos se detectan automticamente Se informa automticamente de los errores internos El cdigo fuente es accesible. Controlabilida Cunto mejor se pueda controlar el software, ms se puede d automatizar y optimizar Todo el cdigo es ejecutable a travs de alguna combinacin de entrada El ingeniero de pruebas puede controlar los estados y las variables del hardware y software Los formatos de las entradas y los resultados son consistentes y estructurados Capacidad de Controlando el mbito de las pruebas, podemos aislar ms descomposici rpidamente los problemas y llevar a cabo pruebas de n regresin El software esta construido con mdulos independientes Los mdulos de software se pueden probar independientemente. Simplicidad Cunto menos haya que probar, ms rpidamente se puede probar Simplicidad funcional Simplicidad estructural
113
Caracterstica Estabilidad
Observacin Cuanto menos cambios, menos interrupciones a las pruebas Los cambios del software son infrecuentes Los cambios del software estn controlados Los cambios del software no invalidan las pruebas existentes El software se recupera bien de los fallos Facilidad de Cuanta ms informacin se tenga, ms inteligentes eran las comprensin pruebas El diseo se ha entendido perfectamente Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente Se han comunicado los cambios del diseo La documentacin tcnica es accesible
2.2 Diseo de casos de prueba El diseo de casos de prueba, tiene un nico objetivo: tener la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo posible. Cualquier producto software puede aprobarse de una las siguientes formas: 1. Conociendo la funcin para la que fue diseado el producto. Se pueden utilizar pruebas para: comprobar su funcin operativa y buscar errores de cada funcin. 2. Conociendo el funcionamiento del producto. Se pueden utilizar pruebas para: comprobar que las operaciones esta de acuerdo con las especificaciones y para comprobar que los componentes internos funcionan de forma adecuada.
Pruebas
114
Caja blanca Camino Bsico De estructuras de control Caja Negra De entornos especializados
115
Entrada
Salida
Mediante est prueba, el ingeniero del software puede: 1. Garantizar que se recorre por lo menos una vez todos los caminos independientes de cada mdulo. 2. Recorrer todas las decisiones lgicas en sus condiciones verdadera y falsa. 3. Recorrer todos los bucles en sus lmites y con sus lmites operacionales. 4. Recorrer las estructuras internas de datos para asegurar su validez Prueba del camino bsico Esta prueba permite obtener una medida de la complejidad de la lgica de un diseo procedimental y usar sa medida como gua para la definicin de un conjunto bsico de camino de ejecucin. Esta prueba permite que se ejecute por lo menos una vez cada sentencia del programa. Complejidad ciclomtica Es una mtrica que proporciona una medicin cuantitativa de la complejidad lgica de un programa. La complejidad ciclomtica est basada en la teora de grafos por lo que es importante recordar:
116
Nodos
Region
R3 9
1 0 1 1
La complejidad ciclomtica se calcula de las siguientes formas: 1. El nmero de regiones del grafo de flujo coincide con la complejidad ciclomtica 2. La complejidad ciclomtica, V(G) de un grafo de flujo G se define como: V(G) = A N + 2 Donde: A N Es el nmero de aristas del grafo de flujo Es el nmero de nodos del grafo de flujo
3. La complejidad ciclomtica, V(G), de un grafo de flujo G tambin se define: V(G) = P + 1 Donde: P Es el nmero de nodos predicado contenidos en el grafo de flujo G
117
118
2.4 Prueba de caja negra Consiste en estudiar la especificacin de las funciones, la entrada y la salida para derivar los casos. Aqu, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del programa. La prueba de caja negra, tambin encuentra errores de: Funciones incorrectas o ausentes Errores de interfaz Errores en estructuras de datos o en accesos a bases de datos externas Errores de rendimiento Errores de inicializacin y de terminacin
Entrada
Funciones funciones
Salida
Se abren las ventanas mediante rdenes basadas en el teclado o en un men? Se puede ajustar el tamao, mover y desplegar la ventana? Se regenera adecuadamente cuando se escribe y se vuelve a abrir? Se muestra la barra de men apropiada en el contexto apropiado? Es correcto el tipo, tamao y formato del texto? Si el ratn tiene varios botones, estn apropiadamente reconocidos en el contexto? Se repiten y son introducidos adecuadamente los datos alfanumricos? Funcionan adecuadamente los modos grficos de entrada de datos? (p.e. barra deslizante) Se reconocen adecuadamente los datos no vlidos? Son inteligibles los mensajes de entrada de datos?
Entrada de datos:
o o o o
Prueba de arquitectura cliente / servidor Debido a la complejidad del sistema, sern necesarias varias fases: o Pruebas de funcionalidad de la aplicacin. Se puede llevar a cabo sobre mquinas de desarrollo y estaciones de trabajo de forma paralela o Pruebas de carga del servidor o Pruebas de integridad de datos: Son especialmente importantes en el caso de bases de datos distribuidas o Pruebas transaccionales o Pruebas de red Prueba de la documentacin y facilidades de ayudas Se puede dar en dos sentidos: Revisin e inspeccin: examina la documentacin para comprobar la claridad de la misma. Prueba en vivo: se utiliza la documentacin junto al uso del software.
120
121
2. Investigue y ample la informacin relacionada con: o Prueba de condicin o Prueba del flujo de datos o Prueba de bucles
122
3.1 Enfoque estratgico para las pruebas del software Segn Roger S. Pressman, las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemticamente. Por esta razn, se define una plantilla para las pruebas del software. Una estrategia de prueba del software tiene las siguientes caractersticas generales: Las pruebas comienzan a nivel de mdulo (en los sistemas orientados a objetos, las pruebas empiezan a nivel de clase o de objeto) y trabajan hacia fuera, hacia la integracin de todo el sistema. Segn el momento, son apropiadas diferentes tcnicas de prueba La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas. La prueba y la depuracin son actividades diferentes, pero la depuracin se debe incluir en cualquier estrategia de prueba
Una estrategia de prueba de software proporciona una gua al profesional y proporciona un conjunto de hitos para el jefe de proyecto.
123
124
Estrategia de prueba
Si se considera el proceso desde el punto de vista procedimental, la prueba, en el contexto de la ingeniera del software, realmente es una serie de cuatro pasos que se llevan a cabo secuencialmente.
125
Requisito s Diseo
Prueba De unidad
1. La prueba se centra en cada mdulo individualmente, asegurando que funcionan adecuadamente como una unidad. La prueba de unidad hace uso de las tcnicas de prueba de caja blanca, ejercitando caminos especficos de la estructura de control del mdulo para asegurar un alcance completo y una deteccin mxima de errores. 2. Se ensamblan o integran los mdulos para formar el paquete de software completo. La prueba de integracin se dirige a todos los aspectos asociados con el doble problema de verificacin y de construccin del programa. Durante la integracin, las tcnicas que ms prevalecen son las de diseo de casos de prueba de caja negra, aunque se pueden llevar a cabo algunas pruebas de caja blanca con el fin de asegurar que se cubren los principales caminos de control. 3. Despus de que el software se ha integrado (construido), se dirigen un conjunto de pruebas de alto nivel. Se deben comprobar los criterios de validacin. La prueba de validacin proporciona una seguridad final de que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. Durante la validacin se usan exclusivamente tcnicas de prueba de caja negra. 4. La prueba del sistema verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total.
126
Objetivos especficos de la prueba Cobertura de la prueba Tiempo medio de fallo El coste para encontrar y arreglar errores Densidad de fallos remanente o frecuencia de ocurrencia Horas de trabajo por prueba
Comprender qu usuarios van a manejar el software y desarrollar un perfil para cada categora de usuario
Se debe:
Describir el escenario de interaccin para cada clase de usuario Desarrollar un plan de prueba que haga hincapi en la prueba de ciclo rpido El equipo de ingeniera de software, debe aprender a probar en ciclos rpidos y que se pueda probar sobre el terreno. Construir un software robusto diseado para probarse a s mismo. El software debe ser capaz de diagnosticar ciertas clases de errores. Adems, el diseo debe incluir pruebas automatizadas y pruebas de regresin. Usar revisiones tcnicas formales efectivas como filtro antes de la prueba
Las revisiones tcnicas formales ayudan a reducir el esfuerzo de prueba necesaria para la produccin del software.
Llevar a cabo revisiones tcnicas formales para evaluar la estrategia de prueba y los propios casos de prueba. Permiten descubrir inconsistencias, omisiones y errores claros en el enfoque 127
3.2 Prueba de unidad El proceso de verificacin, se centra en la menor unidad del diseo del software: el mdulo. Est orientada a caja blanca y este paso se puede llevar a cabo en paralelo para mltiples mdulos. Las pruebas que se dan como parte de la prueba de unidad son:
Interfaz Estructuras de datos locales Condiciones lmite Caminos independientes Caminos de manejo de errores
Prueba de interfaz del Asegura que la informacin fluye de forma adecuada mdulo hacia y desde la unidad de programa que est siendo probada. Prueba de estructuras Asegura que los datos que se mantienen de datos locales temporalmente conservan su integridad durante todos los pasos de ejecucin del algoritmo. Prueba de Asegurar que el mdulo funciona correctamente en condiciones de lmite los lmites establecidos como restricciones de procesamiento. Prueba de caminos Se recorren los caminos independientes de la 128
Controlador Controlador
Interfaz Estructuras de datos locales Condiciones lmite Caminos independientes Caminos de manejo de errores
Resguardo
Resguardo
Para cada mdulo que se va a probar, se crea un controlador (un programa principal) que permite aceptar los datos del caso de prueba, los pasa al mdulo y luego imprime los resultados.
129
M5
M6
M7
M8
Integracin descendente
Integracin primero en profundidad: integra todos los mdulos de un camino de control principal de la estructura. Por ejemplo, si se elige el camino de la izquierda se integrarn primero los mdulos M1, M2 y M5. A continuacin, se integrar M8 o M6. A continuacin se construyen los caminos de control central y derecho. Integracin primero en anchura: incorpora todos los mdulos directamente subordinados a cada nivel, movindose por la estructura de forma horizontal. Por ejemplo: Los primeros mdulos que se integran son M2, M3 y M4. A continuacin, sigue el siguiente nivel de control, M5, M6, M7 y por ltimo M8. 130
Mb D3
Grupo 1
Grupo 2
Integracin ascendente
Se combinan los mdulos para formar los grupos 1,2 y 3. Cada uno de los grupos se somete a prueba mediante un controlador (mostrado como un bloque punteado). Los mdulos de los grupos 1 y 2 son subordinados M a. Los controladores D1 y D2 se eliminan y los grupos interaccionan directamente con Ma. De forma similar, se elimina el controlador D 3 del grupo 3 antes de la integracin con el mdulo Mb. Tanto Ma como Mb se integraran finalmente con el mdulo Mc y as sucesivamente. 3.3.3 Prueba de regresin La prueba de regresin consiste en volver a ejecutar un subconjunto pruebas que se han llevado a cabo anteriormente para asegurarse de que cambios no han propagado efectos colaterales no deseados. La prueba regresin es la actividad que ayuda a asegurar que los cambios introducen un comportamiento no deseado o errores adicionales. de los de no
El conjunto de pruebas de regresin contiene tres clases diferentes de casos de prueba: o Una muestra representativa de pruebas que ejercite todas las funciones del software; o Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio; o Pruebas que se centran en los componentes del software que han cambiado.
132
3.3.5 Prueba de validacin La validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. La validacin del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Se llevan a cabo dos pruebas: Prueba Alfa Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los Prueba Beta Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. El desarrollador no est presente en esta prueba. La prueba beta es una
133
Casos de prueb a
Pruebas adicionales Pruebas de Regresin Correccion es
Ejecucin de casos
Resultado s
Causas sospechad as Causas identificad as
Depuracin Depuracin
El proceso de depuracin
El proceso de depuracin comienza con la ejecucin de un caso de prueba. Se evalan los resultados y aparece una falta de correspondencia entre los esperados y los encontrados realmente. El proceso de depuracin intenta hacer corresponder el sistema con una causa, llevando as a la correccin del error. El proceso de depuracin siempre tiene uno de los dos resultados siguientes: Se encuentra la causa, se corrige y se elimina. 135 No se encuentra la causa.
En este ltimo caso, la persona que realiza la depuracin debe sospechar la causa, disear un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrs a la correccin del error de una forma interactiva. Durante la depuracin se encuentran errores que van desde lo ligeramente inesperado hasta lo catastrfico. La depuracin tiene el objetivo primordial de encontrar y corregir la causa de un error en el software.
3.4 MTRICAS TCNICAS DEL SOFTWARE Las mtricas tcnicas para el software proporcionan una manera sistemtica de valorar la calidad basndose en un conjunto de reglas. Tambin proporcionan al ingeniero del software descubrir y corregir problemas potenciales antes de que se conviertan en defectos catastrficos. 3.4.1 Factores de calidad Factores de calidad de McCall McCall y Cavano definieron un juego de factores de calidad como los primeros pasos hacia el desarrollo de mtricas de la calidad del software. Estos factores evalan el software desde tres puntos de vista distintos: 1 . 2 . 3 . Operacin del producto Revisin del producto Transicin del producto
136
137
Correccin Eficiencia
Fiabilidad
Usabilidad
Integridad
Las mtricas pueden ir en forma de lista de comprobacin para evaluar y puntuar atributos especficos del software. McCall, propuso un esquema de puntuacin en una escala del 0 (bajo) al 10 (alto). Se emplean las siguientes mtricas en el esquema de puntuacin:
Facilidad de auditora Exactitud Estandarizacin de comunicaciones Complexin La facilidad con la que se puede comprobar el cumplimiento de los estndares. La exactitud de los clculos y del control. El grado de empleo de estndares de interfaces, protocolos y anchos de banda.
El grado con que se ha logrado la implementacin total de una funcin. Concisin Lo compacto que es el programa en trminos de lneas de cdigo. Consistencia El empleo de un diseo uniforme y de tcnicas de documentacin a lo largo del proyecto de desarrollo del software Estandarizacin El empleo de estructuras y tipos de datos estndares a lo de datos largo del programa. Tolerancia al El dao causado cuando un programa encuentra un error. error Eficiencia de El rendimiento del funcionamiento de un programa. ejecucin Capacidad de El grado con que se pueden ampliar el diseo arquitectnico,
138
A continuacin, se presenta la relacin entre los factores de calidad del software y las mtricas de la lista anterior.
Fiabilidad Reusabilidad Flexibilidad Portabilidad Interoperatividad Mantenimiento Correccin Usabilidad Eficiencia Integridad
Factor de calidad
Facilidad de auditoria Exactitud Estandarizacin de comunicaciones Complexin Complejidad Concisin Consistencia Estandarizacin de datos Tolerancia a errores Eficiencia de ejecucin
X X X X X X X X X 139 X X X X X
X X X X
pruebasCapacidad de
X X X X X X X X X X X X X X X X X X X
X X X X X
X X X X X
X X X
3.4.2 FURPS El modelo de McCall ha servido de base para modelos de calidad posteriores, y este es el caso del modelo FURPS, producto del desarrollo de HewlettPackard. En este modelo se desarrollan un conjunto de factores de calidad de software, bajo el acrnimo de FURPS. F U R P S Functionality - funcionalidad Usability usabilidad facilidad de uso Reliability - confiabilidad Performance - desempeo Supportability - capacidad de soporte
La siguiente tabla, presenta la clasificacin de los atributos de calidad que se incluyen en el modelo, junto con las caractersticas asociadas a cada uno (Pressman, 2002). Factor de Calidad Funcionalidad Atributos Caractersticas y capacidades del programa Generalidad de las funciones Seguridad del sistema Factores humanos Factores estticos Consistencia de la interfaz Documentacin Frecuencia y severidad de las fallas Exactitud de las salidas Tiempo medio de fallos 140
Facilidad de uso
Confiabilidad
Rendimiento
Capacidad de Soporte
El modelo FURPS incluye, adems de los factores de calidad y los atributos, restricciones de diseo y requerimientos de implementacin, fsicos y de interfaz. Las restricciones de diseo especifican o restringen el diseo del sistema. Los requerimientos de implementacin especifican o restringen la codificacin o construccin de un sistema (por ejemplo, estndares requeridos, lenguajes, polticas). Por su parte, los requerimientos de interfaz especifican el comportamiento de los elementos externos con los que el sistema debe interactuar. Por ltimo, los requerimientos fsicos especifican ciertas propiedades que el sistema debe poseer, en trminos de materiales, forma, peso, tamao (por ejemplo, requisitos de hardware, configuracin de red). Factores de calidad ISO 9126 El estndar ISO/IEC 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para un producto de software (Pressman, 2002). Este estndar es una simplificacin del Modelo de McCall, e identifica seis caractersticas bsicas de calidad que pueden estar presentes en cualquier producto de software. El estndar provee una descomposicin de las caractersticas en subcaractersticas, que se muestran en la siguiente tabla: Caracterstica Funcionalidad Subcaracterstica Adecuacin Exactitud Interoperabilidad Seguridad 141
Usabilidad
Eficiencia Mantenibilidad
Portabilidad
ISO/IEC 9126 no son necesariamente usados para mediciones directas (Pressman, 2002), pero proveen una valiosa base para medidas indirectas, y una excelente lista para determinar la calidad de un sistema. Es importante establecer una estructura fundamental y un conjunto de principios bsicos para la medicin de mtricas tcnicas para el software. Los principios bsicos de la medicin, sugeridos por Roche, pueden caracterizarse mediante cinco actividades: Formulacin Coleccin Anlisis Interpretaci n Realimentaci n Obtencin de medidas y mtricas del software apropiadas para la representacin del software. Mecanismo empleado para acumular datos necesarios para obtener las mtricas formuladas. Clculo de las mtricas y aplicacin de herramientas matemticas. Evaluacin de los resultados de las mtricas en un esfuerzo por conseguir una visin interna de la calidad de la representacin. Recomendaciones obtenidas de la interpretacin de mtricas tcnicas transmitidas al equipo software.
142
3.5 Mtricas del modelo del software 3.5.1 Mtricas del modelo de anlisis En esta fase, las mtricas tcnicas proporcionan una visin interna a la calidad del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de predecir el "tamao" del sistema resultante; es probable que el tamao y la complejidad del diseo estn directamente relacionados. Dentro de las mtricas del modelo de anlisis tenemos: 143
144
Adems, se determinan medidas adicionales para: Primitivas modificadas de funcin manual (PMFu) Elementos de datos de entrada (EDE) Elementos de datos de salida (EDS) Elementos de datos retenidos (EDR) Muestras (tokens) de datos (TCi) Conexiones (Rei) de Funciones que caen fuera del lmite del sistema y que deben modificarse para acomodarse al nuevo sistema. Aquellos elementos de datos que se introducen en el sistema. Aquellos elementos de datos que se sacan en el sistema. Aquellos elementos de datos que son retenidos (almacenados) por el sistema. Las muestras de datos que existen en el lmite de la isima primitiva funcional (evaluada para cada primitiva). relacin Las relaciones que conectan el i-simo objeto en el modelo de datos con otros objetos.
145
La complejidad estructural, S(i), de un mdulo i se define de la siguiente 2 manera: S(i)=f out(i). Donde fout(i) es la expansin del mdulo i. La expansin indica el nmero de mdulos que son invocados directamente por el mdulo i. La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos : C(i)= S(i) + D(i) La complejidad de datos, D(i), proporciona una indicacin de la complejidad en la interfaz interna de un mdulo i y se define como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el nmero de variables de entrada y salida que entran y salen del mdulo i. Fenton sugiere varias mtricas de morfologa simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas.
146
n1 : nmero de operadores diferentes que aparecen en el programa. n2 : nmero de operandos diferentes que aparecen en el programa. N1 : nmero total de veces que aparece el operador. N2 : nmero total de veces que aparecen el operando. Halstead utiliza medidas primitivas para desarrollar expresiones par la longitud global del programa; volumen mnimo potencial para un algoritmo; el volumen real (nmero de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras caractersticas tales como el esfuerzo de desarrollo, tiempo de desarrollo e incluso el nmero esperado de fallos en el software. Halstead propone las siguientes mtricas: Longitud N se puede estimar como: N = n1 log2 n1 + n2 log2 n2. Volumen de programa se define como: V = N n1 log2(n1 + n2). 147
El porcentaje del esfuerzo global de pruebas a asignar a un mdulo k se puede estimar utilizando la siguiente relacin: Donde Porcentaje de esfuerzo de pruebas(k) = e(k)/e(i) (Ec. 3) e(k) se calcula para el mdulo k utilizando las ecuaciones (Ec. 1) y (Ec. 2), la suma en el denominador de la ecuacin (Ec. 3) es la suma del esfuerzo de la ciencia del software a lo largo de todos los mdulos del sistema.
148
Perfiles fallos
3.5.5 Mtricas del mantenimiento Todas las mtricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente. El estndar IEEE 982.1-1988 sugiere el ndice de madurez del software (IMS) que proporciona una indicacin de la estabilidad de un producto software basada en los cambios que ocurren con cada versin del producto. Con el IMS se determina la siguiente informacin: El MT= Nmero de mdulos en la versin actualFc = Nmero de mdulos en la versin actual que se han cambiado Fa= Nmero de mdulos en la versin actual que se han aadido Fe= Nmero de mdulos en la versin actual que se han eliminado
IMS= [MT - (Fc + Fa + Fe)]/MT A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar. El IMS puede emplearse tambin como mtrica para la planificacin de las actividades de mantenimiento del software. 149
2. Haga una lista de algunos problemas que puedan estar asociados con la creacin de un grupo independiente de prueba. Estn formados por las mismas personas el GIP y el grupo SQA? 3. Quin debe llevar a cabo la prueba de validacin -el desarrollador del software o el usuario-? Justifique su respuesta.
150
BIBLIOGRAFIA
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, Jose 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://comp.software-eng http://asqc.org http://www.qualitytree.com/links/links.htm http://www.gestiopolis.com/recursos/documentos/fulldocs/eco/diagramaparet o.htm http://campus.fortunecity.com/defiant/114/iso9000.htm http://www.iso.org http://www.iso.org/iso/en/iso9000-14000 http://www.well.com/user/vision/sqa.html http://www.processimprovement.com/resources/sqa.htm http://www.softwaretestinginstitute.com/Profession.html
151