_IngenieriadeSoftware

8/4/2019 _IngenieriadeSoftware

1/143

Ingeniera de Software

1

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BASICAS, TECNOLOGA E

INGENIERIAPROGRAMA INGENIERIA DE SISTEMAS

MODULO


Autor: Ing. Alexandra AparicioRevisado y Editado: Ing. Jairo Martnez


2/143


2

TABLA DE CONTENIDOPg.

INTRODUCCIN 4

PRIMERA UNIDAD. INTRODUCCIN A LA INGENIERA DESOFTWARE 6

INTRODUCCIN 61. EL PRODUCTO 7

Leccin 1. El Producto 7Leccin 2. Evolucin del Software 8Leccin 3. El Software 9Leccin 4. Aplicaciones del Software 9Leccin 5. Mitos del Software 11

2. EL PROCESO 13Leccin 6. Definicin de Ingeniera de Software 13

Leccin 7. Esquema de la Ingeniera de Software 15Leccin 8. Esencia de la Ingeniera de Software 16Leccin 9. Procesos, Mtodos y Herramientas 17Leccin 10. El Proceso del Software 19

3. MODELOS DE PROCESO DE SOFTWARE 20Leccin 11. Modelo Lineal Secuencial 20Leccin 12. Modelo de Construccin de Prototipos 22Leccin 13. Modelo DRA 25Leccin 14. Modelos de Procesos Evolutivos de Software 27Leccin 15. Modelo de Mtodos Formales y Tcnicas de Cuarta

Generacin

31

SEGUNDA UNIDAD. GESTIN Y PLANIFICACIN DE PROYECTOSSOFTWARE

34

INTRODUCCIN 344. CONCEPTOS SOBRE GESTIN DE PROYECTOS 35

Leccin 16. Gestin de Proyectos 35Leccin 17. Personal 36Leccin 18. El Producto 38Leccin 19. El Proceso 39Leccin 20. El Proyecto 40

5. EL PROCESO DE SOFTWARE Y MTRICAS DEL PROYECTO 42

Leccin 21. Mtricas en el Proceso y Dominios del Proyecto 43Leccin 22. Mejora Estadstica del Proceso del Software 45Leccin 23. Mtricas del Proyecto 48Leccin 24. Mediciones del Software 49Leccin 25. Mtricas para la Calidad del Software 53

6. PLANIFICACION DE PROYECTOS DE SOFTWARE 58Leccin 26. mbito del Software y Recursos 59


3/143


3

Pg.Leccin 27. Estimacin del Proyecto de Software y Tcnicas deDescomposicin

61

Leccin 28. Modelos Empricos de Estimacin 64

Leccin 29. Riesgo del Software 70Leccin 30. Planificacin Temporal del Proyecto 80TERCERA UNIDAD. CONTROL DE CALIDAD DEL SOFTWARE 89INTRODUCCIN 897. GARANTIA DE CALIDAD DEL SOFTWARE 90

Leccin 31. Conceptos de Calidad 91Leccin 32. Tendencia de la Calidad 94Leccin 33. Garanta y Aseguramiento de la Calidad del Software 96Leccin 34. Revisiones del Software 97Leccin 35. Garanta de Calidad Estadstica, Fiabilidad y EstndarISO 9001

101

8. TECNICAS DE PRUEBA DEL SOFTWARE 108Leccin 36. Fundamentos de la Prueba del Software 108Leccin 37. Diseo de Casos de Prueba, Pruebas de la CajaBlanca y del Camino Bsico

110

Leccin 38. Prueba de la Estructura de Control 112Leccin 39. Prueba de la Caja Negra 114Leccin 40. Prueba de Entornos Especializados, Arquitecturas yAplicaciones

114

9. ESTRATEGIAS DE PRUEBA DEL SOFTWARE 117Leccin 41. Enfoque Estratgico de la Prueba del Software 117Leccin 42. Prueba de Unidad 122Leccin 43. Pruebas de Integracin del Sistema 123Leccin 44. Mtricas Tcnicas del Software 129Leccin 45. Mtricas del Modelo del Software 136


4/143


4

INTRODUCCIN

El curso Ingeniera de Software tiene como objetivo desarrollar habilidades y adquirir

capacidades en la utilizacin de mtodos y tcnicas para desarrollar y mantenersoftware de calidad.

El curso tiene 3 crditos acadmicos los cuales comprenden el estudio independiente yel acompaamiento tutorial, con el propsito de:

Comprender los aspectos tcnicos y de gestin de la disciplina de ingeniera desoftware.

Capacitar a los estudiantes en las tcnicas de gestin necesarias para planificar,

organizar, supervisar y controlar proyectos de software.

Fomentar en el estudiante tcnicas de gestin de calidad del software.

Obtener un conjunto de tcnicas de prueba de software con el propsito deencontrar y corregir errores antes de entregar el software al cliente.

Este curso est compuesto por tres unidades didcticas a saber:

Unidad 1. Introduccin a la ingeniera de software: se presenta una vista general

sobre la definicin de: ingeniera de software, producto de software, procesos desoftware, se determina las caractersticas del software, los mitos del software. Sepresenta tambin los diferentes tipos de proceso y los modelos evolutivos del software.

Unidad 2. Gestin y planificacin de proyectos de software : se trata de determinarcomo se debe gestionar el personal, el proceso y el problema durante un proyecto desoftware. Se identifican las mtricas de software y cmo pueden emplearse paragestionar 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 relacionadoscon 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 lagaranta de calidad del software as como se definen las estrategias para los planes degaranta de calidad del software.


5/143


5

La ingeniera de software es el proceso de construir aplicaciones de tamao o alcanceprcticos, en las que predomina el esfuerzo del software y que satisfacen losrequerimientos de funcionalidad y desempeo. La ingeniera de software, ofrecemtodos y tcnicas para desarrollar, mantener, producir y asegurar software de

calidad.Por tal razn, este curso terico pretende describir los aspectos tcnicos y de gestinde la Ingeniera de Software, as como de establecer la importancia de la garanta decalidad del software.


6/143


6

INTRODUCCIN

La ingeniera de software es una disciplina que integra procesos, mtodos yherramientas para el desarrollo de software. Varios son los modelos de procesos que sehan propuesto para la ingeniera de software, cada uno presenta ventajas ydesventajas, pero todos tienen en comn fases genricas que permiten llevar a cabo el

proceso de la ingeniera de software.

OBJETIVOS

GENERAL

Comprender los aspectos tcnicos y de gestin de la disciplina de Ingenieradel Software

ESPECIFICOS

Definicin de Ingeniera de software, producto de software, procesosde 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

UNIDAD 1.

INTRODUCCIN A LA INGENIERA DE SOFTWARE


7/143


7

ESTRUCTURA TEMTICA

Captulo 1. EL PRODUCTO

Leccin 1. Definicin del Producto Software.

El software es el producto que disean y construyen los ingenieros del software decualquier tamao y arquitectura.

ElSoftware

esimportante

Afecta cualquier aspecto de nuestras vidas

Afecta las actividades cotidianas

Est muy extendido en el comercio

Porque

Desde

El producto obtenido(software)

El punto de vistadel Ingeniero del

Software

El punto de vistadel Usuario

El conjunto de programas,documentos y los datos queconfiguran el software decomputadora

La informacin resultanteque hace el mundo mejor.

es es


8/143


8

Leccin 2. La Evolucin del Software

1Primeros Aos Segunda era 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 lamisma persona u organizacin (entornopersonalizado)

El diseo de software era realizado en la mentede alguien y no exista documentacin

Aparece la multiprogramacin y los sistemasmultiusuario

Establecimiento del software como producto y lallegada de las casas de software

El software se desarrollaba para sercomercializado

Se empez a distribuir software para grandescomputadoras y minicomputadores

Comenz a extenderse las bibliotecas desoftware

El mantenimiento de software comenz aabsorber recursos en una gran medida.

Comenz una crisis del software porque lanaturaleza personalizada de los programas hizoimposible su mantenimiento.

Tercera era Cuarta 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

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

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

1950 1960 1970 1980 1990 2003

Primeros Aos Segunda Era Tercera Era Cuarta Era


9/143


9

Leccin 3. El Software

El software se ha convertido en el elemento clave de la evolucin de los sistemas yproductos informticos, y por tal razn no se puede tomar como slo el conjunto de

programas, instrucciones y estructuras de datos. A continuacin se presentan algunascaractersticas que permiten visualizar lo que en realidad es el software.

Caractersticas del Software

Leccin 4. Aplicaciones del SoftwareEl software tiene una gran amplitud de aplicaciones. A continuacin se relacionan:

Software de Sistemas

Se desarrolla, no se fabrica: se utiliza un modelo de proceso dedesarrollo que comprende anlisis, diseo, desarrollo,implementacin y evaluacin para obtener un producto de calidad.

No se estropea, pero se deteriora: El software durante su vidasufre cambios por lo que es probable que surjan fallos y defectosque si no se corrigen permiten que el software se vayadeteriorando.

Se construye a medida: a medida que el software evoluciona secrean estndares de diseo. El software debe disearse eimplementarse para que pueda ser reutilizable.

Conjunto de programas creados como herramienta paraotros programas. Por ejemplo: compiladores, Sistemasoperativos

Software de GestinGestin de grandes cantidades de informacinalmacenadas, para facilitar la toma de decisiones. Porejemplo Bases de datos y aplicaciones de gestin deempresa

ElSoftware


10/143


10

Software de ingenieray cientfico

Utiliza algoritmos de manejo de nmeros, simulacin de

sistemas, utiliza software en tiempo real. Por ejemplo:aplicaciones de astronoma, vulcanologa, fabricacinautomtica.

Software de tiemporeal

El software que coordina / analiza/ controla sucesos delmundo real conforme ocurren, se denomina de tiemporeal.

Software empotrado Reside en memoria de slo lectura y se utiliza paracontrolar productos y sistemas de los mercadosindustriales. Por ejemplo, el control de las teclas de unhorno de microondas, funciones digitales en un automvil.

Software para PCAplicaciones orientadas a usuarios individuales omultiusuarios. Por ejemplo: procesadores de texto, hojasde clculo, juegos, aplicaciones financieras, gestores debases de datos.

Software deInteligencia Artificial

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


11/143


11

Leccin 5. Mitos del software

Los mitos de software propagaron informacin errnea y confusin, lo que conllevo a lacrisis del software durante los primeros aos del desarrollo del software.

Mitos de Gestin

Tenemos ya un libro que est lleno de estndares y procedimientos paraconstruir software, no le proporciona ya a mi gente todo lo que necesita saber?

Mi gente dispone de las herramientas de desarrollo de software msavanzadas, despus de todo, les compramos las computadoras ms modernas.

Si fallamos en la planificacin, podemos aadir ms programadores y adelantarel tiempo perdido.

Mitos del Cliente

Una declaracin general de los objetivos es suficiente para comenzar a escribirlos programas.

Los requisitos del proyecto cambian continuamente, pero los cambios puedenacomodarse fcilmente, ya que el software es flexible.

Mitos de los Desarrolladores

Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo

ha terminado. Hasta que no tengo el programa ejecutndose, realmente no tengo forma decomprobar su calidad.

Lo nico que se entrega al terminar el proyecto es el programa funcionando.


12/143


12

ACTIVIDADES COMPLEMENTARIAS

1. Muchos autores han tratado el impacto de la era de la informacin. D variosejemplos (positivos y negativos) que indiquen el impacto del software en nuestra

sociedad.2. Escriba un informe que resuma las ventajas recientes en una de las reas de

aplicaciones de software principales. Entre las selecciones potenciales seincluyen: aplicaciones avanzadas basadas en Web, realidad virtual, redesneuronales artificiales, interfaces humanas avanzadas y agentes inteligentes.

3. Analice y describa la Realidad para cada uno de los mitos descritos en elnumeral 1.5.

CONSULTAS WEB

http://www.rspa.com/spi/glossary.html, Glosario de trminos de software.

http://books.google.com.co/books?id=ytdKQGJ8f_AC&lpg=PA4&ots=hSqsOPw078&dq=Software%20Myths&pg=PA5 , encuentra un libro con informacin sobre losmitos del software.
http://www.rspa.com/spi/glossary.htmlhttp://books.google.com.co/books?id=ytdKQGJ8f_AC&lpg=PA4&ots=hSqsOPw078&dq=Software%20Myths&pg=PA5http://books.google.com.co/books?id=ytdKQGJ8f_AC&lpg=PA4&ots=hSqsOPw078&dq=Software%20Myths&pg=PA5http://books.google.com.co/books?id=ytdKQGJ8f_AC&lpg=PA4&ots=hSqsOPw078&dq=Software%20Myths&pg=PA5http://books.google.com.co/books?id=ytdKQGJ8f_AC&lpg=PA4&ots=hSqsOPw078&dq=Software%20Myths&pg=PA5http://www.rspa.com/spi/glossary.html


13/143


13

Captulo 2. EL PROCESO

Es una serie de pasos a seguir para construir un producto o un sistema. El proceso delsoftware es importante porque proporciona estabilidad, control y organizacin a una

actividad que puede, si no se controla, volverse catica.Leccin 6. Definicin de Ingeniera de Software

de

para

de

es

Ingeniera de software

el conjunto

Principios Mtodos Tcnicas

Desarrollar Mantener

Software

Calidad


14/143


14

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

1 Zelkovitz. Principles of Software Engineering and Design.Ingeniera de Software es el estudio de los principios y metodologas paradesarrollo y mantenimiento de sistemas de software.

Boehm. Software Engineering.Ingeniera de Software es la aplicacin prctica del conocimiento cientficoen el diseo y construccin de programas de computadora y ladocumentacin asociada requerida para desarrollar, operar y mantenerlos.

Bauer. Software Engineering.Ingeniera del software trata del establecimiento de los principios ymtodos de la ingeniera a fin de obtener software de modo rentable quesea fiable y trabaje en mquinas reales.

Pressman. Ingeniera de SoftwareLa Ingeniera de/l software es una disciplina o rea de la informtica oCiencias de la Computacin, que ofrece mtodos y tcnicas paradesarrollar y mantener software de calidad que resuelven problemas detodo tipo.

2

3

4

Braude. Ingeniera de SoftwareLa ingeniera de software es el proceso de construir aplicaciones detamao o alcance prcticos, en las que predomina el esfuerzo del softwarey que satisfacen los requerimientos de funcionalidad y desempeo.

5

IEEELa aplicacin de un enfoque sistemtico, disciplinado y cuantificable haciael desarrollo, operacin y mantenimiento del software; es decir, laaplicacin de ingeniera al software.

6


15/143


15

Leccin 7. Esquema de la Ingeniera de Software

Imagen tomada de http://dis.um.es/~jnicolas/09BK_FIS.html

Es muy simple el esquema que consiste en desarrollar un programa sencillo queresuelve una tarea bien determinada. Lo normal es que se evolucione al desarrollo deun

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 quepueden trabajar en varios entornos.


16/143


16

Leccin 8. Esencia de la Ingeniera de Software

Imagen tomada de http://www.um.es/docencia/barzana/IAGP/IAGP2-Metodologias-de-desarrollo.html

Esta figura podra resumir buena parte de la esencia del curso: en el desarrollo desoftware (una entidad "compleja") se producen problemas de comunicacin a variosniveles: entre usuarios y desarrolladores y entre los componentes mismos del equipo dedesarrollo.

Se estudiarn las tcnicas, mtodos y herramientas de ingeniera que puedan hacerque estos problemas se minimicen, e incluso que desaparezcan.


17/143


17

Leccin 9. Proceso, Mtodos y Herramientas

La ingeniera del software es una tecnologa multicapa, y que se apoya sobre unenfoque de calidad.

Enfoque de calidad Gestin total de calidad. Cultura continua de mejorasde procesos.Proceso Define un nmero de actividades del marco de trabajo

aplicables a todos los proyectos del software.Mtodos Indican cmo construir tcnicamente el software.

Abarcan una gran gama de tareas que incluyenanlisis de requisitos, diseo, construccin deprogramas, pruebas y mantenimiento.

Herramientas Soporte automtico o semi-automtico para el procesoy los mtodos

La ingeniera es el anlisis, diseo, construccin, verificacin y gestin de entidadestcnicas.

El trabajo que se asocia a la ingeniera del software se puede dividir en tres fases, conindependencia del rea de aplicacin, tamao o complejidad del proyecto.

Enfoque de calidad

Herramientas

Proceso

Mtodos


18/143


18

1 Fase de definicinSe centra sobre el qu. Identificar qu informacin ha de ser procesada,que funcin y rendimiento se desea, qu comportamiento del sistema, qu

interfaces van a ser establecidas, qu restricciones de diseo existen, yqu criterios de validacin se necesitan para definir un sistema correcto.Identificar los requisitos del sistema y del software.Las tareas especficas de esta fase son:

ooo Ingeniera de Sistemas o de informacinooo Planificacin del proyecto softwareooo Anlisis de requerimientos

2 Fase de desarrolloSe centra en el cmo. Definir cmo han de disearse las estructuras de

datos, cmo ha de implementarse la funcin dentro de una arquitectura desoftware, cmo ha de implementarse los detalles procedimentales, cmohan de caracterizarse interfaces, cmo ha de traducirse el diseo en unlenguaje de programacin y cmo ha de realizarse la prueba.Las tareas especficas de esta fase son:

ooo Diseo del softwareooo Generacin de cdigoooo Prueba del software

3 Fase de mantenimientoSe centra en el cambio. Correccin de errores Adaptaciones requeridas a medida que evoluciona el entorno del software Cambios debidos a las mejoras producidas por los requisitos cambiantes

del cliente Se encuentran cuatro tipos de cambio:

ooo Correccinooo Adaptacinooo Mejoraooo Prevencin


19/143


19

Leccin 10. El Proceso del Software

Un proceso de software se puede caracterizar as:

Marco de trabajo comn del proceso

Actividades de Proteccin

Actividades del marco de trabajo

Conjuntos de tareas

TareasHitos, entregasPuntos SQA

Son independientes decualquier actividad del marcode trabajo y aparecen durantetodo el proceso.

Permiten que las actividades delmarco de trabajo se adapten alas caractersticas del proyectodel software y a los requisitos del

proyecto.

Aplicables a todos los proyectos desoftware, con independencia de sutamao o complejidad.


20/143


20

Captulo 3. MODELOS DE PROCESO DEL SOFTWARE

Es importante incorporar estrategias de desarrollo que acompae al proceso, mtodos ya las herramientas.

Una estrategia a menudo de llama modelo de proceso o paradigma de ingeniera delsoftware. Se selecciona un modelo de proceso para la ingeniera del software segn lanaturaleza del proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse, ylos controles y entregas que se requieren.

Leccin 11. Modelo Lineal Secuencial

Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo linealsecuencial sugiere un enfoque sistemtico, secuencial, para el desarrollo del software

que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin,pruebas y mantenimiento.

Es un ciclo de vida en sentido amplio, que incluye no slo las etapas de ingeniera sinotoda la vida del producto: las pruebas, el uso (la vida til del software) y elmantenimiento.

Ingenieradel Sistema

Anlisis

Diseo

Codificacin

Prueba

Utilizacin

Mantenimiento


21/143


21

Ingeniera delSistema

Anlisis de las caractersticas y el comportamiento del sistema delcual el software va a formar parte.Para un sistema nuevo: Se debe analizar cules son los requisitos

funciones del sistema, y luego asignar un subconjunto de estosrequisitos y funciones al software.Para un sistema ya existente: se debe analizar el funcionamientode la organizacin y sus operaciones y se asigna al softwareaquellas funciones que se van a automatizar.Est formado por diagramas y por descripciones en lenguajenatural.

Anlisis Se debe comprender cules son los datos que se van a manejar,cul va a ser la funcin que tiene que cumplir el software, culesson las interfaces requeridas y cul es el rendimiento y otrosrequisitos no funcionales que se esperan lograr.

Los requisitos, tanto del sistema como del software debendocumentarse y revisarse con el cliente. Como resultado del lafase de anlisis, se obtiene la especificacin de requisitos delsoftware.Tambin est formado por diagramas y descripciones en lenguajenatural.

Diseo El diseo se aplica a cuatro caractersticas distintas del software: laestructura de los datos, la arquitectura de las aplicaciones, laestructura interna de los programas y las interfaces.El diseo es el proceso que traduce los requisitos en unarepresentacin del software de forma que pueda conocerse la

arquitectura, funcionalidad e incluso la calidad del mismo antes decomenzar la codificacin.En el diseo, los requisitos del software se traducen a una serie dediagramas que representan la estructura del sistema software, desus datos, de sus programas y de sus interfaces.

Codificacin Consiste en la traduccin del diseo a un formato que seacomprensible para la mquina. Si el diseo es lo suficientementedetallado, la codificacin es relativamente sencilla, y puedehacerse de forma automtica, usando generadores de cdigo.Se traducen los diagramas de diseo a un lenguaje fuente, queluego se traduce - se compila - para obtener un programa

ejecutable.Prueba El objetivo es comprobar que no se hayan producido errores enalguna de las fases anteriores, especialmente en la codificacin.Se deben probar todas las sentencias, y todos los mdulos queforman parte del sistema.

Utilizacin El software se entrega al cliente y comienza la vida til del mismo.Mantenimiento El software sufrir cambios a lo largo de su vida til. Estos cambios


22/143


22

pueden ser debidos a tres causas:Que, durante la utilizacin, el cliente detecte errores en elsoftware: los errores latentes.Que se produzcan cambios en alguno de los componentes del

sistema.Que el cliente requiera modificaciones funcionales nocontempladas en el proyecto.

Leccin 12. Modelo de Construccin de Prototipos

No

S

Identificar los

requerimientosconocidos

Desarrollarmodelo que

funcione

Utilizar elprototipo

Revisar elprototipo

PrototipoTerminado?

Abandonar laaplicacin

Implantar la aplicacin Volver a desarrollar la

aplicacin Comenzar un nuevo


23/143


23

Paso DescripcinIdentificar losrequerimientos

conocidos

Los analistas y los usuarios trabajan juntos para identificar losrequerimientos conocidos que tienen que satisfacerse.

Se debe: determinar los fines del sistema y el alcance de sucapacidad.Paso Descripcin

Desarrollarmodelo quefuncione

Los desarrolladores explican a los usuarios: El mtodo Las actividades a realizar La secuencia en que se llevar a cabo La responsabilidad de cada participanteEl proceso de construccin del prototipo se debe iniciar con eldesarrollo de un plan general que permita conocer el procesode desarrollo.

Es importante definir un cronograma para el inicio y fin de laprimera iteracin.

El desarrollador estima los costos asociados con el desarrollo

del prototipo.En el desarrollo del prototipo se preparan los siguientescomponentes: 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 lasespecificaciones de salida o de diseo del software.

Utilizar elprototipo

La responsabilidad de trabajar con el prototipo y evaluar suscaractersticas y operacin es del usuario.La experiencia con el sistema bajo condiciones reales permitedeterminar los cambios o mejoras o eliminar caractersticasinnecesarias.

Debe

describir

PrimeraIteracin

Los reportes y documentos que elsistema debe proporcionar

El formato de cada uno de ellos.


24/143


24

Paso DescripcinRevisar elprototipo

Se realiza la evaluacin y con la informacin obtenida se levantanlas caractersticas que debe llevar la siguiente versin del

prototipo.La evaluacin permite profundizar los rasgos de los usuarios y losde la organizacin que tienen influencia sobre la aplicacin y en suimplementacin.Los cambios en el prototipo son planificados con los usuarios antesde llevarlos a cabo por el analista.

Prototipoterminado?

Los pasos anteriores se repiten varias veces (4 o 6 iteraciones)cuando los usuarios y desarrolladores estn de acuerdo en que elsistema ha evolucionado lo suficiente e incluye todas lascaractersticas necesarias.

Cuando el prototipo est terminado, el paso que sigue acontinuacin es tomar la decisin sobre cmo proceder, para locual existen cuatro opciones:

Abandonar la aplicacinSe descartan el prototipo y la aplicacin. El desarrollo del prototipoproporcion informacin a partir de la cual se determin que laaplicacin o el enfoque seleccionado son inapropiados para

justificar un desarrollo adicional.

Implantar el prototipoLas caractersticas y funcionamiento del prototipo satisfacen las

necesidades de los usuarios ya sea en forma permanente o paraun futuro.

Volver a desarrollar la aplicacinEl desarrollo del prototipo proporcion suficiente informacin paradeterminar las caractersticas necesarias de toda la aplicacin. Lainformacin se utiliza como punto de partida para el desarrollo dela aplicacin en forma tal haga el mejor uso posible de losrecursos.

Comenzar un nuevo prototipoLa informacin ganada con el desarrollo del prototipo inicial

sugiere otras opciones o circunstancia. Se construye un prototipodiferente para aadir informacin relacionada con losrequerimientos de aplicacin.


25/143


25

Un prototipo puede tener alguna de las tres formas siguientes:

Leccin 13. Modelo DRA (Desarrollo Rpido de Aplicaciones)

1 Un prototipo, en papel o ejecutable en computador, que describa lainteraccin hombre-mquina y los listados del sistema.

2 Un prototipo que implemente algn(os) subconjunto(s) de la funcinrequerida, y que sirva para evaluar el rendimiento de un algoritmo o lasnecesidades de capacidad de almacenamiento y velocidad de clculo delsistema final.

3 Un programa que realice en todo o en parte la funcin deseada pero quetenga caractersticas que deban ser mejoradas durante el desarrollo delproyecto.

en un

que

de

es un

DRA

modelo de proceso

desarrollo de software

Enfatiza

Ciclo dedesarrollo

corto


26/143


26

El proceso DRA permite al equipo de desarrollo crear un sistema completamentefuncional dentro de periodos cortos de tiempo (de 60 a 90 das). El enfoque DRAcomprende las siguientes fases:

Equipo N. 1

Equipo N. 2

Modelado

de gestin

Modeladode datos

Modeladodeprocesos

Pruebas yentrega

Generacindeaplicaciones

60-90 das

Modeladode gestin

Modeladode datos

Modeladode

procesos

Pruebas yentrega

Generacinde

aplicaciones

Modelado

de gestin

Modelado

de datos

Modeladodeprocesos

Pruebas y

entrega

Generacindeaplicaciones

Equipo N. 3


27/143


27

Modelado degestin

El flujo de informacin entre las funciones de gestin se modela deforma que responda a las siguientes preguntas: Qu informacinconduce al proceso de gestin? Qu informacin se genera?

Quin la genera? A dnde va la informacin? Quin laprocesa?Modelado dedatos

Conjunto de objetos de datos necesarios para apoyar la empresa.Se definen las caractersticas (atributos) de cada uno de losobjetos y las relaciones entre estos objetos.

Modelado delproceso

Los objetos de datos definidos en la fase de modelado de datosquedan transformados para lograr el flujo de informacin necesariopara implementar una funcin de gestin. Las descripciones delproceso se crean para aadir, modificar, suprimir o recuperar unobjeto de datos.

Generacin de

aplicaciones

El DRA asume la utilizacin de tcnicas de cuarta generacin. En

lugar de crear software con lenguajes de programacin de tercerageneracin, el proceso DRA trabaja para volver a utilizarcomponentes de programas ya existentes o crear componentesreutilizables.

Pruebas yEntrega

Como el proceso DRA enfatiza la reutilizacin, ya se hancomprobado muchos de los componentes de los programas. Estoreduce tiempo de pruebas. Sin embargo, se deben probar todoslos componentes nuevos y se deben ejercitar todas las interfaces afondo.

Leccin 14. Modelos de Procesos Evolutivos de Software

cada vezpor

se

sonLos

modelosevolutivos

iterativos

caracterizan desarrollarversiones

ms completasdel software


28/143


28

3.14.1 El Modelo Incremental

El modelo incremental se centra en la entrega de un producto operacional con cadaincremento.

Los primeros incrementos son versiones incompletas del producto final, peroproporcionan al usuario la funcionalidad necesaria para su evaluacin.

lael

combina

El modelo incremental

Modelo lineal secuencial Construccin de prototipos

ara

Entregar el software

en

Partes pequeas

llamadas

Incrementos


29/143


29

Anlisis Diseo Cdigo Prueba

Ingeniera de

Sistemas / Informacin incremento 1

Entrega

1er. Incremento

Anlisis Diseo Cdigo PruebaEntrega

2do. Incrementoincremento 2


3er. Incrementoincremento 3


4to. Incrementoincremento 4

Tiempo

3.14.2 El Modelo Espiral

En las primeras iteraciones, la versin incremental podra ser un modelo en papel o unprototipo.

Durante las ltimas iteraciones, se producen versiones cada vez ms completas delsistema diseado.

proporciona

conjugaes unproceso de

softwareevolutivo

ModeloEspiral

construccin de prototipos

modelo lineal secuencial

Un desarrollo rpido deversiones incremntales delsoftware


30/143


30

Actividadesdel modeloen espiral

Comunicacin con el cliente: Se establece comunicacinentre el desarrollador y el cliente.

Planificacin: Se definen los recursos, el tiempo y otrainformacin relacionados con el proyecto.

Anlisis de riesgos: Se evalan riesgos tcnicos y de gestin

Ingeniera: Se construyen una o ms representaciones de laaplicacin.

Construccin y accin: Construir, probar, instalar yproporcionar soporte al usuario.

Evaluacin del cliente: Se obtiene la reaccin del cliente. Serealiza la evaluacin de las representaciones del softwarecreadas durante la etapa de ingeniera e implementada durantela etapa de instalacin.


31/143


31

El equipo de ingeniera del software gira alrededor de la espiral en la direccin de lasagujas del reloj, comenzando por el centro.

El primer circuito de la espiral puede producir el desarrollo de una especificacin de

productos; los pasos siguientes en la espiral se podran utilizar para desarrollar unprototipo y progresivamente versiones mas sofisticadas del software. Cada paso por laregin de planificacin produce ajustes en el plan del proyecto. El costo y laplanificacin se ajustan con la realimentacin ante la evaluacin del cliente. Adems, elgestor del proyecto ajusta el nmero planificado de iteraciones requeridas paracompletar el software.

Leccin 15. Modelo de Mtodos Formales y Tcnicas de Cuarta Generacin

El modelo de mtodos formales comprende un conjunto de actividades que conducen ala especificacin matemtica del software de computadora. Los mtodos formales

permiten que un ingeniero de software especifique, desarrolle y verifique un sistemabasado en computadora aplicando una notacin rigurosa y matemtica.Este enfoque es llamado ingeniera del software de sala limpia. Cuando se utilizanmtodos formales se descubren y corrigen ambigedades, inconsistencias y errores.

Las tcnicas de cuarta generacin, abarcan un conjunto de herramientas que facilitan alingeniero del software la especificacin de las caractersticas del software a alto nivel.La herramienta genera automticamente el cdigo fuente basndose en laespecificacin del tcnico. Cuanto mayor sea el nivel en el que se especifique elsoftware, ms rpido se puede construir el programa.El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad de

especificar el software usando formas de lenguaje especializado o notaciones grficasque describa el problema que hay que resolver en trminos que los entienda el cliente.

las etapas

incluyeEl paradigmaT4G

Lenguajes no procedimentales de consulta a bases dedatos

Generacin de informesManejo de datosInteraccin y definicin de pantallasGeneracin de cdigosCapacidades grficasGeneracin automatizada de HTML

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


32/143


32


1. Las capas de la Ingeniera del Software sita las tres capas encima de la capatitulada enfoque de calidad. Esto implica un programa de calidad tal como

Gestin de Calidad Total. Investigue y desarrolle un esquema de los principiosclave de un programa de Gestin de Calidad Total.

2. Elabore y proporcione una tabla donde se especifiquen las ventajas ydesventajas de los diferentes paradigmas de ingeniera de software.

3. Qu paradigmas de ingeniera del software de los presentados piensa que serael ms eficaz? Por que?

4. Qu es ms importante, el producto o el proceso?


33/143


33

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 Addisonwesley. 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.comhttp://www.wiley.com/college/braudehttp://www.minerva.uevora.pt/simposio/comunicacoes/rigomezmarino.htmlhttp://apuntes.rincondelvago.com/trabajos_global/informatica/9/http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdf

http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.phphttp://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.htmlhttp://www.monografias.com/trabajos5/inso/inso.shtmlhttp://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.html


34/143


34

INTRODUCCIN

La gestin y planificacin de proyectos es una actividad que empieza antes de iniciarcualquier actividad tcnica y contina a lo largo de la definicin, del desarrollo y delmantenimiento del software.

La actividad de gestin del proyecto comprende medicin y mtricas, estimacin,anlisis de riesgos, planificacin, seguimiento y control.

OBJETIVOS

GENERALES

Estudiar las tcnicas de gestin necesarias para planificar, organizar,supervisar y controlar proyectos de software.

Estudiar las tcnicas de anlisis y gestin del riesgo.

Estudiar las tcnicas de gestin necesarias para planificar proyectos desoftware.

ESPECIFICOS

Determinar como se debe gestionar el personal, el proceso y elproblema durante un proyecto de software.

Identificar las mtricas de software y cmo pueden emplearse paragestionar el proceso de software y el proyecto llevado a cabo comoparte 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.

UNIDAD 2.

GESTIN Y PLANIFICACIN DE PROYECTOS SOFTWARE


35/143


35

ESTRUCTURA TEMTICA

Captulo 4. CONCEPTOS SOBRE GESTION DE PROYECTOS

Leccin 16. Gestin de Proyectos

La gestin de un proyecto de software se centra en:

mientras

de

implica

Gestin de proyectos

Planificacin Supervisin Control

Personal Procesos Eventos

Evoluciona el Software

4 Ps

Personal Producto Proceso Proyecto

Necesidad depersonal para el

desarrollo desoftware

Objetivos ymbito del

software

Estructura queestablece un

plan detalladopara eldesarrollo del

software

Proyectos desoftware

planificados ycontrolados.


36/143


36

Participantes Se clasifican en:

Jefes deequipo

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 delproyecto.

Hace saber a todos los miembros del equipo que la calidad esimportante.

Equipo desoftware

Mantei, propone 3 niveles de organizacin de equipos.

Leccin 17. PersonalRecurso humano que participa y colabora en el proceso del software y su organizacinpara el desarrollo de los proyectos software de manera eficaz.

1. Gestores Superiores: se encargan de definir los aspectosdel negocio.

2. Gestores tcnicos del proyecto: se encargan deplanificar, motivar, organizar y controlar a los profesionalesque realizan el trabajo de desarrollo del software.

3. Profesionales: se encargan de proporcionan lascapacidades tcnicas necesarias para la ingeniera de un

producto o aplicacin.4. Clientes: especifican los requisitos para la ingeniera delsoftware.

5. Usuarios finales: Se encargan de interactuar con elsoftware.

Descentralizado democrticoEste equipo no tiene un jefe permanente y se nombrancoordinadores a corto plazo. Las decisiones se hacen porconsenso del grupo. La comunicacin entre los miembros del

equipo es horizontal.


37/143


37

CoordinacinyComunicacin

Se establecen mecanismos de comunicacin para coordinar al equipode trabajo. Se deben tener:

Descentralizado controladoEste equipo tiene un jefe definido que coordina tareasespecficas y jefes secundarios que tienen responsabilidades

sobre subtareas. La resolucin de problemas sigue siendo unaactividad del grupo, pero la implementacin de soluciones sereparte entre subgrupos por el jefe de equipo. La comunicacinentre subgrupos e individuos es horizontal. Tambin haycomunicacin vertical a lo largo de la jerarqua de control.

Centralizado controladoEl jefe del equipo se encarga de la resolucin de problemas aalto nivel y la coordinacin interna del equipo. La comunicacinentre jefe y los miembros del equipo es vertical.

Comunicacin formal: se lleva a cabo por escrito, conreuniones organizadas y otros canales de comunicacin.Incluye documentos de ingeniera de software, memorandostcnicos, documentacin, informes de seguimiento.

Comunicacin informal: es ms personal. Incluye reunionesde grupo para la divulgacin de informacin y para la

resolucin de problemas.Comunicacin electrnica: se lleva a cabo por correoselectrnicos, boletines, audioconferencias, videoconferencias.


38/143


38

mbito Se define:

Contexto: Cmo encaja el software a construir en un sistema,producto o contexto de negocios mayor y qu limitaciones seimponen como resultado del contexto?

Objetivos de informacin: Qu objetos de datos visibles alcliente se obtienen del software? Qu objetos de datos son

requeridos de entrada? Funcin y rendimiento: Qu funcin realiza el software paratransformar la informacin de entrada en una salida? Haycaractersticas de rendimiento especiales que abordar?

Descomposicindel problema

Comprende el anlisis de requisitos del software.

La descomposicin se aplica en dos reas principales:

(1) la funcionalidad que debe entregarse y(2) el proceso que se emplear para entregarlo.

Un problema complejo se parte en problemas ms pequeos queresultan ms manejables.

Leccin 18. ProductoAl 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 productodelimitarlo.


39/143


39

Maduracin delproblema y elproceso

Los miembros del equipo de software deben estructurar unconjunto de actividades que le permitan trabajar en cada funcindel problema.Se pueden considerar las siguientes actividades:

El trabajo del gestor del proyecto es estimar los requisitos derecursos, poner fechas de inicio y finalizacin de las tareas y losproductos a fabricar.

Descomposicindel proceso

Las actividades de: comunicacin, planificacin, anlisis de riesgo,ingeniera, construccin, entrega y evaluacin se adaptan almodelo o paradigma de desarrollo de software seleccionado.

Leccin 19. Proceso

El gestor del proyecto decide qu modelo de proceso es el ms adecuado para:

1. Los clientes que han solicitado el producto y la gente que realizar el trabajo.2. Las caractersticas del producto.3. El entorno del proyecto.

ComunicacinSe establece comunicacin entre el desarrollador y el cliente,con el propsito de obtener los requisitos del sistema.PlanificacinConjunto de tareas con el propsito de definir los recursos y laplanificacin temporal del proyecto.Anlisis del riesgoTareas requeridas para valorar los riesgos tcnicos y degestin.Ingeniera

Tareas requeridas para construir una o ms representacionesde la aplicacin.Construccin y entregaTareas requeridas para construir, probar, instalar yproporcionar asistencia al usuario.Evaluacin del clienteTareas requeridas para que el cliente evale lasrepresentaciones de software creadas durante la fase dein eniera.


40/143


40

Se debe:

Leccin 20. Proyecto

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

Comprender el problema asolucionar y establecer losobjetivos.

1

Mantener el equipo dedesarrollo y proporcionarincentivos.

2

Realizar seguimiento a las

actividades desarrolladasdurante el proceso comoparte de la calidad delmismo.

3

Tomar decisiones junto con

el gestor del proyecto y elequipo de desarrollo desoftware.

4

Evaluar la planificacin realy la prevista, reunir yanalizar mtricas delproyecto de software yrealimentar cada uno de los

procesos.

5


41/143


41


1. Se le ha nombrado gestor de proyecto dentro de una organizacin de sistemasde informacin. Su trabajo es construir una aplicacin que es bastante similar a

otras que ha construido su equipo, aunque sta es mayor y ms compleja. Losrequisitos han sido detalladamente documentados por el cliente. Qu estructurade equipo elegira y porqu? Qu modelo(s) de proceso de software elegira ypor qu?

2. Se le ha nombrado gestor de proyecto de una pequea compaa de productossoftware. Su trabajo consiste en construir un producto innovador que combinehardware de realidad virtual con software innovador. Puesto que la competenciapor el mercado de entretenimiento casero es intensa, hay cierta presin paraterminar el trabajo rpidamente. Qu estructura de equipo elegira y porqu?Qu modelo(s) de proceso de software elegira y por qu?


42/143


42

Captulo 5. EL PROCESO DE SOFTWARE Y MTRICAS DEL PROYECTO

Las razones para medir los procesos del software, los productos y los recursos, son:

para

alse

de

comprende

Mtricas del

software

Mediciones

Software

aplican Proceso del software Proyecto de software

Una gama

para el

Ayudar en la estimacin, elcontrol de calidad, laevaluacin de productividad yel control de proyectos

Caracterizar: para comprender mejor los procesos, los productos, losrecursos 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.


43/143


43

Leccin 21 Mtricas en el Proceso y Dominios del Proyecto

Dentro de la Ingeniera del software se manejan los siguientes conceptos:

El objetivo principal de los indicadores de proceso es evaluar las condiciones defuncionamiento de un proceso y poder tener una visin de la eficacia de un procesoexistente.

Durante un tiempo considerable se recopilan las mtricas de todos los proyectos y seproporcionan los indicadores para obtener mejoras e el software.

Medida: Proporciona unaindicacin cuantitativa de laextensin, cantidad,dimensiones, capacidad otamao de algunos atributosde un proceso o producto.

Medicin: es el acto de determinar unamedida.

Mtrica: Una medida cuantitativa delgrado en que el sistema, componente oproceso posee un atributo dado.

Indicador: es una mtrica o una combinacin de mtricas queproporcionan una visin profunda del proceso del software, del proyecto desoftware o del producto en s. Un indicador proporciona una visin profunda

que permite al gestor de proyectos o a los ingenieros de software ajustar elproducto, el proyecto o el proceso.

permiten

Los indicadoresde proyecto

1

Evaluar elestado delproyecto

2

Hacerseguimientoa los riesgos

potenciales

3

Detectar lasreas problemasantes de que se

conviertan encrticas

4

Ajustar elflujo y lastareas del

trabajo

5

Evaluar la habilidaddel equipo paracontrolar la calidad

de los productossoftware.


44/143


44

Para mejorar cualquier proceso se debe:

De acuerdo a la figura:

El producto, la tecnologa y las personas tienen una fuerte influencia en el desarrollo yla calidad del software. El proceso se encuentra dentro de unas condiciones de entornoque incluyen: entornos de desarrollo, condiciones del negocio, y caractersticas del

cliente. Estas condiciones, son de gran importancia puesto que permiten definir lasreglas 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 segnlos resultados que provienen del proceso.

Dentro de stos resultados se debe incluir:

Medir atributos del proceso

Definir y desarrollar un juego de mtricas para esos atributos

Utilizar las mtricas para encontrar indicadores para la estrategia de mejora

Producto

TecnologaPersonas

Proceso

Condicionesdel negocio

Caractersticasdel cliente

Entorno dedesarrollo

Figura tomada de Roger Presuman. Ingeniera de Software

Medida de errores detectados antes de la entrega del software

Defectos detectados

Productos de trabajo entregados

Esfuerzo humano y tiempo consumido

Ajuste con la planificacin


45/143


45

Tambin se debe incluir mtricas para medir las caractersticas de tareas especficas dela ingeniera del software.

Leccin 22. Mejora Estadstica del Proceso del Software (MEPS)

Para una organizacin es importante estar a gusto con la recopilacin y la utilizacin demtricas de proceso, de stas se deriva la identificacin de indicadores llevando a un

enfoque ms riguroso denominado Mejora estadstica de proceso del software(MEPS).

y

para

del

utiliza

MEPS

Anlisis de fallos

Software

Recopilar informacin

de

Errores Defectos

Medida del tiempo y del esfuerzo para llevar a cabo actividadesde proteccin

Actividades genricas de ingeniera del software


46/143


46

Para realizar un anlisis de fallos se deben seguir los siguientes pasos:

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

Error Es alguna fisura descubierta por los ingenieros del softwareantes de que el software sea entregado al usuario final

Defecto Es alguna fisura descubierta despus de la entrega delsoftware al usuario final

1 Categorizar por origen, todos los errores y defectos.

2 Registrar el costo de corregir cada error y el del defecto

3 Contar el nmero de errores y de defectos de cada categora y se ordenar por ordendescendente

4 Computar el costo global de errores y defectos de cada categora.

5 Los datos resultantes se analizan para detectar las categoras que producen uncosto alto para la organizacin

6 Desarrollar planes para eliminar los errores y defectos ms costosos.


47/143


47

En un diagrama de espina:

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

problema de calidad.

Esta misma notacin se aplica para cada una de las lneas diagonales conectadas a lalnea central.

Por ejemplo:Se han encontrado y determinado las siguientes causas y su origen en un proyecto desoftware:

Origen de errores / defectos Causa %Especificacin / requisitos Lgica 20

Manejo de datos 10.9estndares 6.9

Diseo Especificaciones 25.5Cdigo Interfaz software 6.0

Interfaz hardware 7.7Comprobacin de errores 10.9Interfaz de usuario 11.7

ProblemaPrincipal

R%

Causapotencial No. 1

Q1%

Causapotencial no. 2

Q2%

Causapotencial n

Qi%

Causapotencial n+1

Qi%

Ci, j

Ci, j

Ci, j : Causa asociada a cada subproblema

Qi %: Porcentaje de relevancia del subproblema

R% : Porcentaje de relevancia del problema principal


48/143


48

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

Leccin 23. Mtricas del Proyecto

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

Se utilizan

Defectos deespecificacin

25.5%

Incorrecto Cambios

Perdido Ambiguo

El cliente dioinformacin equivocada

Informacin desactualizada

Cliente consultadono adecuado

Insuficienteinformacin solicitada

Mtricas de proyecto

Para minimizar la planificacinde desarrollo, ya que serealizan ajuste y se reduce losretrasos

Para evaluar la calidad de losproductos. A medida quemejora la calidad se minimizanlos defectos.

Entradas: la dimensin de los recursos que se requieren para realizar el trabajo

2 Salidas: medidas de las entradas o productos creados durante el proceso deingeniera del software

3 Resultados: medidas que indican la efectividad de las entregas.

1


49/143


49

Leccin 24. Mediciones del Software

Las mtricas del software se pueden categorizar en:

El domino de las mtricas del software se dividen en mtricas de proceso, proyecto yproducto.

5.24.1 Mtricas orientadas al tamao

Provienen de la normalizacin de las medidas de calidad y/o productividadconsiderando el tamao del software que se haya producido.Los datos que se deben tener en cuenta, se pueden llevar en la siguiente tabla:

Proyecto LDC Esfuerzo Costo $ Pginas dedocumentacin

Errores Defectos Personas

IRIS 18.200 24 200.000 945 134 86 4

Teniendo en cuenta los datos de la tabla, se pueden derivar otras mtricas paracomparar 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

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


50/143


50

5.24.2 Mtricas orientadas a la funcin

Los puntos de funcin se obtienen utilizando una funcin emprica basado en medidascuantitativas del dominio de informacin del software y valoraciones subjetivas de lacomplejidad del software.

Los puntos de funcin se calculan utilizando la siguiente tabla:

Parmetros demedicin

Cuenta Factor de ponderacinSimple Medio Complejo

Nmero deentradas deusuario

X3 4 6

=

Nmero desalidas de usuario X

4 5 7 =

Nmero depeticiones deusuario

X3 4 6

=

Nmero dearchivos X

7 10 15 =

Nmero deinterfacesexternas

X5 7 10

=

Cuenta_total

permiten

Mtricas del software orientadas a la funcin

La medida de lafuncionalidad dela aplicacin.

Propuestas

Allan Albrecht de IBM, comenz a analizar sistemas, apedido del grupo de usuarios de IBM, buscandoidentificar los factores crticos que determinan el tamaodel software y por consiguiente, estimar el esfuerzo y elcosto de desarrollarlo. Luego de analizar cientos desistemas, naci la tcnica de Anlisis de Puntos porfuncin. La tcnica mide una aplicacin con base en lasfunciones que ste realiza para/por solicitud del usuariofinal.


51/143


51

Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen enla posicin apropiada de la tabla. Los valores del mbito de informacin estn definidosde la siguiente manera:

Cuando han sido recogidos los datos anteriores, se asocia el valor de complejidad a

cada cuenta. Las organizaciones que utilizan mtodos de puntos de funcin desarrollancriterios para determinar si una entrada es denominada simple, media o compleja. Noobstante la determinacin de la complejidad es algo subjetivo.

Para calcular los puntos de funcin se utiliza la siguiente relacin:

PF Punto de funcin

Cuenta_total Es la suma de todas las entradas obtenidasfi Donde i=1 hasta 14. Son valores de ajuste de lacomplejidad basados en las respuestas a las cuestionessealadas de la siguiente tabla:

Evaluar cada factor en escala 0 a 5

1. Nmero de entradas de usuario: se cuenta cada entrada de usuario queproporcione al software diferentes datos orientados a la aplicacin.

2. Nmero de salidas de usuario:se cuenta cada salida que proporciona al usuarioinformacin orientada a la aplicacin. En este contexto las salidas se refieren ainformes, pantallas, mensajes de error.

3. Nmero de peticiones de usuario:una peticin esta definida como una entradainteractiva que resulta de la generacin de algn tipo de respuesta en forma desalida interactiva. Se cuenta cada peticin por separado.

4. Nmero de archivos:se cuenta cada archivo maestro lgico.

5. Nmero de interfaces externas:se cuentan todas las interfaces legibles por lamaquina por ejemplo: archivos de datos, en cinta o discos que son utilizados paratransmitir informacin a otro sistema.

PF = Cuenta_total * [0.65 + 0.01 * (fi)]


52/143


52

0 1 2 3 4 5Noinfluencia

Incidental Moderado Medio Significativo Esencial

Fi :1 Requiere el sistema copias de seguridad y de

recuperacin fiables?2 Se requiere comunicacin de datos?3 Existen funciones de procesamiento distribuido?4 Es crtico el rendimiento?5 Se ejecutar el sistema en un entorno operativo

existente y fuertemente utilizado?6 Requiere el sistema entrada de datos interactiva?7 Requiere la entrada de datos interactiva que las

transacciones de entrada se lleven a cabo sobremltiples pantallas u operaciones?

8 Se actualizan los archivos maestros de formainteractiva?9 Son complejas las entradas, las salidas, los archivos

o las peticiones?10 Es complejo el procesamiento interno?11 Se ha diseado el cdigo para ser reutilizable?12 Estn incluidas en el diseo la conversin y la

instalacin?13 Se ha diseado el sistema para soportar mltiples

instalaciones en diferentes organizaciones?14 Se ha diseado la aplicacin para facilitar los

cambios y para ser fcilmente utilizada por el

usuario?

Una vez calculado los puntos de funcin se usan como medida de la productividad,calidad y otros productos del software.

Productividad = PF / persona-mesCalidad = Errores / PFCosto = Dlares / PFDocumentacin = Paginas Documentadas / PF


53/143


53

Leccin 25. Mtricas para la Calidad del Software

El objetivo de la ingeniera del software es desarrollar y producir software de altacalidad. Para lograr este objetivo, es fundamental aplicar mtodos y herramientas

efectivos dentro del contexto de un proceso maduro de desarrollo de software.

5.25.1 Medidas de la Calidad

Dentro de las medidas de calidad del software tenemos:

Correccin

Es el grado en que el software cumple su funcin.La medida ms comn es:

Defectos por KDLC (miles de lneas de cdigo)

Facilidad de mantenimiento

Es la facilidad con la que se puede corregir un programa si se encuentra unerrorSe utilizan medidas indirectas como:

Tiempo Medio de cambio (TMC)Es decir, el tiempo que se tarda en:

Analizar una peticin Disear un modificacin Implementar el cambio Probar y realizar el cambio.


54/143


54

Integridad

Mide la capacidad del software para resistir ataques.

Se debe tener en cuenta los siguientes atributos:

Amenaza

Seguridad

Se define como:

Integridad = [(1-amenaza) x (1-seguridad)]

Es la probabilidad de que un ataque ocurra en un tiempodeterminado.

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

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.


55/143


55

5.25.2 Eficacia de la eliminacin de defectos

La eficacia de la eliminacin de defectos (EED), es una mtrica que permite medir lahabilidad de filtrar las actividades de la garanta de calidad y de control, ya que es

aplicable a todas las actividades del marco de trabajo del proceso.Se define de la siguiente forma:

E Nmero de errores encontrados antes de la entrega del softwareD Nmero de defectos encontrados despus de la entrega

5.25.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:

EED = E / (E + D)

No se han encontradodefectos en el software.

El valor ideal de EED es 1.


56/143


56

MedidasRecopilacin de datosRequiere una investigacin histrica de los

proyectos para reconstruir los datos requeridos

1

MtricasClculo de mtricasSe hace el clculo de mtricas una vez se handeterminado las medidas. Pueden abarcar unagran cantidad de mtricas:

LDC y PF De calidad Del proyecto

2

IndicadoresEvaluacin de mtricasSe deben evaluar las mtricas y aplicardurante: la estimacin, el control deproyectos y la mejora del proceso.Los indicadores guan el proyecto o elproceso.

3


57/143


57


1. Describa, con sus propias palabras, la diferencia entre mtricas del proceso y del

proyecto.2. Elabore un ensayo argumentativo, que de respuesta a la pregunta Por qu

renecesita medir? Por qu son importantes las mtricas dentro de la ingenierade Software?

3. Sugiera tres medidas, tres mtricas y los indicadores que se podran utilizar paraevaluar un automvil.

4. Indague con algn desarrollador de software o un equipo de desarrollo desoftware qu medidas, mtricas e indicadores utilizan o tienen implementadas.

Elabore un cuadro sinptico.

INVESTIGACIN

1. El Instituto de Ingeniera de Software (The Carnegie Mellon Software EngineeringInstitute -SEI) ha desarrollado una gua para establecer un programa de medicinde software dirigido hacia objetivos. Investigue y elabore un documento sobreesta gua.

EJERCICIOS1. Calcule el Punto de Funcin de un proyecto con las siguientes caractersticas del

dominio de informacin:

Nmero de entrada de usuario 32Nmero de salida de usuario 60Nmero de peticiones de usuario 24Nmero de archivos 8Nmero de interfaces externos 2

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


58/143


58

Captulo 6. PLANIFICACIN DE PROYECTOS DE SOFTWARE

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

La estimacin se inicia con una descripcin del mbito del producto. El problema sedescompone en un conjunto de problemas de menor tamao y cada uno de stos seestima 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 medidaque avanza el proyecto.

determina

implica

Planificacin

Estimacin

El costo El esfuerzo Los recursos El tiempo

Para construir y desarrollar unproducto software

Su resultado

Es una tabla con: Las tareas a desarrollar Las funciones a implementar El costo, esfuerzo y tiempo

necesarioPara la realizacin de cadatarea.Y, Una lista de recursos

involucra

Planificacin

mbito delsoftware

Recursos Estimacin delproyecto

Tcnicas dedescomposicin

Modelos deestimacin


59/143


59

Leccin 26. mbito del Software y Recursos

6.26.1. mbito del SoftwareDescribe el control y los datos a procesar, la funcin, el rendimiento, las restricciones,

las interfaces y la fiabilidad. Se evalan las funciones descritas en la declaracin delmbito, y en algunos casos se refinan para dar mas detalles antes del comienzo de laestimacin.

comprende

mbito del software

Recoleccin de la informacinSu 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 unaentrevista preliminar.

Esta reunin o entrevista debe involucrar los siguientes tipos de preguntas:1. Preguntas de contexto libre: se centran en el cliente, en los objetivos globales

y en los beneficios. Estas preguntas deben llevar a un entendimiento bsicodel problema, las personas interesadas en la solucin y la solucin que sedesea.

2. Metacuestiones: estas preguntas se centran en la efectividad de la reunin,involucra preguntas para determinar si la persona es la apropiada pararesponder a las preguntas, si sin relevantes las preguntas para el problemaen estudio, si las respuestas son oficiales, si existe algo que se deberapreguntar.

Tambin existe otra tcnica que permite la creacin de un equipo compuesto por losclientes y los desarrolladores para identificar el problema, proponer elementos desolucin, establecer enfoques y especificar un conjunto preliminar de requisitosdenominada TFEA (Facilitated application specification techniques) Tcnica parafacilitar las especificaciones de la aplicacin.

ViabilidadSe 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 yRecursos. Tanto el equipo de desarrollo y las dems personas involucradas en elsoftware deben determinar si puede ser construido dentro de las dimensionesespecificadas.


60/143


60

6.26.2 Recursos

Comprende la estimacin de los recursos necesarios para emprender el desarrollo delsoftware.

Los recursos de desarrollo son:

Recurso humanoSe debe establecer el perfil y las habilidades que se necesitan del personal que senecesita para llevar a cabo el desarrollo del proyecto. Hay que especificar tanto laposicin dentro de la organizacin como la especialidad.

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

Recursos de software reutilizable

Se destaca la reutilizacin, esto es, la creacin y la reutilizacin de bloques deconstruccin de software.

Se establecen 4 categoras de recursos de software que se deben tener en cuenta amedida que se avanza con la planificacin:

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

Humanos

Componentes reutilizablesde software

De entorno(Hardware / software)

Gestor Ingeniero de software Analista de sistemas


61/143


61

Componentes ya experimentados: se puede utilizar Especificaciones, diseos,cdigo o datos de prueba existentes que ya han sido desarrollados para proyectosanteriores.

Componentes con experiencia parcial: se puede utilizar Especificaciones, diseos,cdigo o datos de prueba existentes que ya han sido desarrollados para proyectosanteriores y que requieren una modificacin sustancial.

Componentes nuevos: componentes que el equipo de software requiere construirespecficamente para el proyecto.

Recursos de entorno

El entorno es donde se apoya el proyecto de software.

Comprende

Comprende el conjunto de herramientas requeridas para producir o desarrollar elproducto software y se debe verificar que estos recursos estn disponibles.

Leccin 27. Estimacin del Proyecto de Software y Tcnicas de Descomposicin

Para realizar estimaciones seguras de costos y esfuerzos, se pueden tener lassiguientes opciones:

Hardware y Software

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.


62/143


62

La utilizacin de tcnicas de descomposicin y de modelos empricos, permitendescomponer el proyecto en funciones principales y en tareas lo que implica que sepueda realizar una estimacin del costo y del esfuerzo del proyecto de forma

escalonada.

Antes de de realizar la estimacin del proyecto se debe generar una estimacin deltamao del software a construir.

6.27.1 Tamao del software

Dentro de la planificacin de proyectos, el tamao se refiere a una produccincuantificable del proyecto de software.

Se tienen 4 enfoques referentes al tamao:

El tamao se mide en LDC, si se utiliza un enfoque directo

El tamao se representa como PF, si se utiliza un enfoque indirecto.

Tamao en lgica difusa

Utiliza las tcnicas aproximadas de razonamiento. Para aplicar este enfoque sedebe: 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, lasproposiciones 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.

1


63/143


63

6.27.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 secalcula el valor esperado (E) con la siguiente frmula:

Tamao de componentes estndarEl software esta compuesto por un nmero de componentes estndar(subsistemas, mdulos, pantallas, informes, etc.) que son genricos para un reaen particularSe 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 deprogramacin.Esto permite que se estime que se requieren 12405 LDC para el componente deinformes.

2

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

3

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


64/143


64

6.27.3 Estimacin basada en el proceso

Esta tcnica permite, descomponer el proceso en un conjunto relativamente pequeode actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de

cada tarea.Esta estimacin comprende:

Leccin 28. Modelos Empricos de Estimacin

Utilizan frmulas derivadas empricamente de una muestra limitada de proyectospara predecir el esfuerzo en funcin de LOC o PF.

La estimacin de los valores de LOC y PF se realizan utilizando las tcnicas dedescomposicin.

Los valores resultantes se aplican a la frmula del modelo que se haya escogidopara 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.

1. Delineacin de las funciones del software obtenidas a partir del mbito delproyecto.

2. Se mezclan las funciones del problema y las actividades del proceso.

3. Se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de

software.


65/143


65

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:

COCOMO bsico. Calcula el esfuerzo y el costo del desarrollo enfuncin del tamao del programa estimado en LOC.

COCOMO intermedio. Calcula el esfuerzo del desarrollo enfuncin del tamao del programa y un conjunto de conductores decosto que incluyen la evaluacin subjetiva del producto, delhardware, del personal y de los atributos del proyecto.

COCOMO detallado. Incorpora las caractersticas de la versinintermedia y lleva a cabo una evaluacin del impacto de losconductores de costo en cada fase (anlisis, desarrollo, etc.) delproceso.

Modelos

E = a * KLOCbD = c * Ed


66/143


66

Donde:

E es el esfuerzo aplicado en hombre-mesD es el tiempo de desarrollo en meses

KLOC es el nmero de miles de lneas de cdigo estimado para el proyecto

Los coeficientes ay cy los exponentes by dse obtienen de la siguiente tabla:

Tipo de proyecto a b C dOrgnico 2.4 1.05 2.5 0.38Semiacoplado 3.0 1.12 2.5 0.35Empotrado 3.6 1.20 2.5 0.32

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

Para calcular la duracin del proyecto usamos la estimacin de esfuerzo:

El valor de la duracin del proyecto permite al planificador recomendar un nmero depersonas N para el proyecto.

El planificador puede decidir emplear slo una o dos personas y ampliar por tanto laduracin del proyecto.

E= 2.4 * KLOC1.05= 2.4 * 7.41.05= 20 hombre-mes

D = 2.5 * E0.38= 2.5 * 200.38= 8 meses

N = E / D= 20 / 8= 3 personas


67/143


67

COCOMO intermedio

En el COCOMO intermedio, la ecuacin para calcular el tiempo de desarrollo es lamisma que la del COCOMO bsico. La ecuacin para calcular el esfuerzo es:

Donde,

E es el esfuerzo en hombre-mesKLOC es el nmero estimado de miles de lneas de cdigo

El coeficiente ay el exponente bestn dados por la tabla:

Tipo de proyecto a b

Orgnico 3.2 1.05Semiacoplado 3.0 1.12Empotrado 2.8 1.20

Y

EAF Es un factor de ajuste del esfuerzo que se calcula valorando en unaescala de muy bajo, bajo, nominal, altoy muy altocada uno de lossiguientes 15 atributos, agrupados en 4 categoras. As:

Atributos del producto.

Son restricciones y requerimientos del proyecto que va a serdesarrollado. Confiabilidad requerida* Tamao de la base de datos Complejidad del producto

Atributos de computadora.Son limitaciones puestas por el hardware y el sistema operativodonde 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.

E = a* KLOCb* EAF


68/143


68

EAFAtributos de personal.Nivel de habilidades que tiene el personal. Son habilidadesprofesionales generales, habilidad de programacin, experiencia

con el medio ambiente de desarrollo y familiaridad con el dominiodel 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 sedesarrolla.

o Prcticas modernas de programacino Uso de herramientas de software*o Calendario de desarrollo requerido.

A cada atributo se le asigna un nmero real de acuerdo a la tabla siguiente:

Escala NmeroMuy bajo 0.75

Bajo 0.88Nominal 1Alto 1.15Muy alto 1.40

El nmero indica el grado con el que cada factor puede influenciar la productividad. Unvalor 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 losatributos marcados en (*), como los ms relevantes y que deberan ser tomados encuenta.


69/143


69

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:

Donde,

E Esfuerzo en hombres-ao.

t Duracin del proyecto en aos.B Factor especial de destrezas. Para programas pequeos Bvale 0.16,para programas intermedios vale 0.28, para programas mayores vale0.39.

P Parmetro de productividad, para un software de tiempo real, P vale2,000, para comunicaciones vale 10,000, para software cientfico vale12,000 y para aplicaciones comerciales de sistemas vale 28,000.

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:

E = (LOC * B0.333 / P)3 * (1 / t4)

tmin = 8.14 * (LOC / P)0.43 para tmin > 6 meses.

E = 180 * B * t3 en hombres-mes para E >= 20 hombres-mes y trepresentado en aos


70/143


70

Aplicando las ecuaciones al ejemplo anterior, obtenemos:

Leccin 29. Riesgo del Software

El anlisis y la gestin del riesgo son una serie de pasos que ayudan al equipo delsoftware a comprender y a gestionar la incertidumbre.

Por tal razn es importante:

Los pasos que se deben seguir son:

tmin = 8.14 * (7,400 / 12,000)0.43= 7 meses

E = 180 * 0.28 * 0.753= 21 hombres-mes

Un riesgo es un problema potencial puede ocurrir o no -.

Identificarlo Evaluar su probabilidad de aparicin, Estimar su impacto, y , Establecer un plan de contingencia por si ocurre el problema.

1 Identificar el riesgo. Reconocimiento de que algo puede ir mal.

2 Cada riesgo se analiza para determinar la probabilidad de que pueda ocurrir y eldao que puede causar si ocurre.

3 Se priorizan los riesgos, en funcin de la probabilidad y del impacto.

3 Se desarrolla un plan para gestionar aquellos riesgos con gran probabilidad eimpacto.


71/143


71

6.29.1. Estrategias de riesgo

Se tienen dos estrategias:

ReactivaSupervisa el proyecto en previsin de posibles riesgos. Evaluar las consecuencias del riesgo cuando este ya se ha producido (ya no es

un riesgo) Actuar en consecuencia

ProactivaIdentifica los riesgos potenciales. Evaluacin previa y sistemtica de riesgos

Evaluacin de consecuenciasSe establece un plan de contingencia para controlar el riesgo.

implica

Riesgo

Incertidumbreel acontecimiento quecaracteriza al riesgopuede o no puedeocurrir.

PrdidaSi el riesgo se convierte en unarealidad, ocurrirn consecuenciasno deseadas o prdidas.


72/143


72

6.29.2 Categoras de riesgos

Riesgos del proyectoPueden amenazar al plan del proyecto, porque puede retrazar el proyecto y aumentar

los costos.Identifican problemas de: Presupuesto Personal Recursos Cliente Requisitos

Riesgos tcnicosAmenazan la calidad del software y la planificacin temporal del proyecto. La

implementacin puede llegar a ser difcil o imposible.Identifican problemas de: Diseo Implementacin De interfaz Verificacin Mantenimiento

Riesgos del negocioAmenazan la viabilidad del software a construir. Se pone en riesgo el proyecto y elproducto.

Identifican problemas de: De mercado De estrategia De ventas De gestin De presupuesto


73/143


73

6.29.3 Identificacin del riesgo

Existen dos tipos de riesgo:

Riesgos genricosRepresentan una amenaza potencial paratodos los proyectos de software.

Riesgos especficosImplican un conocimiento profundo delproyecto (Entorno, Tecnologa, Personal)

Lista de comprobacin de elementos de riesgo

Es un mtodo que permite identificar riesgos, por medio de las siguientes categoras:

Relacionados con el

tamao del producto

Se asocian los riesgos con el tamao del software a construir o

desarrollar. Tamao estimado del proyecto (LOC/PF) Confianza en la estimacin Numero de programas, archivos y transacciones Tamao relativo al resto de proyectos Tamao de la base de datos Nmero de usuarios Nmero de cambios de requerimientos previstos antes y

despus de la entrega Cantidad de software reutilizado

Con el impacto en laorganizacin

Asociados con las limitaciones impuestas por la gestin. Efecto del producto en la cifra de ventas

Visibilidad desde la direccin de la organizacin Fecha lmite de entrega razonable Nmero de clientes que usarn el producto Numero de productos con los que deber interaccionar Sofisticacin del usuario final Cantidad y calidad de la documentacin a entregar al cliente Lmites legales y gubernamentales Costos asociados al retraso en la entrega Costos asociados a errores en el producto


74/143


74

Con el tipo de cliente Asociados con la comunicacin del cliente. Hay experiencias anteriores con dicho cliente Tiene una idea clara de lo que precisa

Est dispuesto a dedicar tiempo en la especificacin formalde requerimientos Est dispuesto a relacionarse de forma gil con el equipo de

desarrollo Est dispuesto a participar en la revisiones Es un usuario experto Dejar trabajar al equipo de desarrollo sin dar consejos de

experto informtico Entiende el ciclo de vida de una aplicacin

Con la definicin delproceso de produccin

Asociados al proceso y seguimiento del software. Hay una poltica clara de normalizacin y seguimiento de

una metodologa

Existe una metodologa escrita para el proyecto Se ha utilizado en otros proyectos Estn los gestores y desarrolladores formados Conoce t

_IngenieriadeSoftware

Documents