16755657 301404 modulo ingenieria del software

7/31/2019 16755657 301404 Modulo Ingenieria Del Software

1/162

Ingeniera del Software

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

FACULTAD DE CIENCIAS BASICAS E INGENIERIA

PROGRAMA INGENIERIA DE SISTEMAS

MODULO

Ingeniera delsoftware


2/162


Tabla de ContenidoPg.

INTRODUCCIN 4

PRIMERA UNIDAD. INTRODUCCIN A LA INGENIERA DELSOFTWARE

6

INTRODUCCIN 61. EL PRODUCTO 7

1.1 El producto 71.2 Evolucin del Software 81.3 El software 91.4 Aplicaciones del Software 91.5 Mitos del Software 11

2. EL PROCESO 13

2.1 Definicin de Ingeniera del software 132.2 Esquema de la Ingeniera del Software 152.3 Esencia de la Ingeniera del Software 162.4 Procesos, mtodos y herramientas 172.5 El proceso del software 19

3. MODELOS DE PROCESO DE SOFTWARE 203.1 Modelo lineal secuencial 203.2 Modelo de construccin de prototipos 223.3 Modelo DRA 253.4 Modelos de procesos evolutivos de software 273.5 Modelo de mtodos formales y Tcnicas de cuarta

generacin

31

SEGUNDA UNIDAD. GESTIN Y PLANIFICACIN DEPROYECTOS SOFTWARE

34

INTRODUCCIN 341. CONCEPTOS SOBRE GESTIN DE PROYECTOS 35

1.1 Gestin de proyectos 351.2 Personal 361.3 El producto 381.4 El proceso 391.5 El proyecto 40

2. EL PROCESO DE SOFTWARE Y MTRICAS DEL PROYECTO 422.1 Mtricas en el proceso y dominios del proyecto 432.2 Mejora estadstica del proceso del software 452.3 Mtricas del proyecto 482.4 Mediciones del software 492.5 Mtricas para la calidad del software 53

3. PLANIFICACION DE PROYECTOS DE SOFTWARE 58


3/162

Ingeniera del Software3.1 mbito del software y Recursos 593.2 Estimacin del proyecto de software y Tcnicas deDescomposicin

61

Pg.

3.3 Modelos empricos de Estimacin 643.4 Riesgo del Software 703.5 Planificacin temporal del proyecto 80

TERCERA UNIDAD. CONTROL DE CALIDAD DEL SOFTWARE 89INTRODUCCIN 891. GARANTIA DE CALIDAD DEL SOFTWARE 90

1.1 Conceptos de calidad 911.2 Tendencia de la calidad 941.3 Garanta y aseguramiento de la calidad del software 961.4 Revisiones del software 971.5 Garanta de calidad estadstica, Fiabilidad y Estndar

ISO 9001

101

2. TECNICAS DE PRUEBA DEL SOFTWARE 1092.1 Fundamentos de la prueba del software 1092.2 Diseo de casos de prueba, pruebas de la caja blanca ydel camino bsico

111

2.3 Prueba de la estructura de control 1142.4 Prueba de caja negra 1152.5 Prueba de entornos especializados, arquitecturas yaplicaciones

116

3. ESTRATEGIAS DE PRUEBA DEL SOFTWARE 119

3.1 Enfoque estratgico la prueba del software 1193.2 Prueba de unidad 1243.3 Pruebas de integracin del sistema 1263.4 Mtricas tcnicas del software 1323.5 Mtricas del modelo del software 139


4/162


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 de

software.

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

organizar, supervisar y controlar proyectos de software.

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

Obtener un conjunto de tcnicas de prueba de software con el propsito de

encontrar y corregir errores antes de entregar el software al cliente.

Este curso esta compuesto por tres unidades didcticas a saber:

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

la definicin de: ingeniera de software, producto de software, procesos de software, sedetermina las caractersticas del software, los mitos del software. Se presenta tambinlos diferentes tipos de proceso y los modelos evolutivos del software.

Unidad 2. Gestin y planificacin de proyectos de software: se trata de determinar comose 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 relacionados conla 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/162

Ingeniera del SoftwareLa 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/162


INTRODUCCIN

La ingeniera de software es una disciplina que integra procesos, mtodos yherramientas para el desarrollo de software. Varios son los modelos deprocesos que se han propuesto para la ingeniera de software, cada unopresenta ventajas y desventajas, pero todos tienen en comn fases genricas

que permiten llevar a cabo el proceso de la ingeniera de software.

OBJETIVOS

GENERAL

Comprender los aspectos tcnicos y de gestin de la disciplina deIngeniera 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

UNIDAD 1.

INTRODUCCIN A LA INGENIERADEL SOFTWARE


7/162


ESTRUCTURA TEMTICA

1. EL PRODUCTO

1.1 Definicin del Producto Software.El software es el producto que disean y construyen los ingenieros delsoftware de cualquier tamao y arquitectura.

1.2 La evolucin del Software

ElSoftware

esimporta

Afecta cualquier aspecto de nuestras

Afecta las actividades cotidianas

Est muy extendido en el comercio

Porque

Desde

El productoobtenido

El punto devista del

Ingeniero delSoftware

El punto devista delUsuario

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

La informacin resultanteque hace el mundomejor.

eses


8/162


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 porla misma persona u organizacin (entornopersonalizado)

El diseo de software era realizado en lamente de alguien y no existadocumentacin

Aparece la multiprogramacin y lossistemas multiusuario

Establecimiento del software comoproducto y la llegada de las casas desoftware

El software se desarrollaba para sercomercializado

Se empez a distribuir software paragrandes computadoras yminicomputadores

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 programashizo imposible 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

economaTecnologas orientadas a objetosTcnicas 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 Roger 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/162

Ingeniera del SoftwareEl software se ha convertido en el elemento clave de la evolucin de lossistemas y productos informticos, y por tal razn no se puede tomar comoslo el conjunto de programas, instrucciones y estructuras de datos. Acontinuacin se presentan algunas caractersticas que permiten visualizar lo

que en realidad es el software.

Caractersticas del Software

1.4 Aplicaciones del software

El software tiene una gran amplitud de aplicaciones. A continuacin serelacionan:

Software de sistemas

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

No se estropea, pero se deteriora: El softwaredurante su vida sufre cambios por lo que es probable quesurjan fallos y defectos que si no se corrigen permiten queel software se vaya deteriorando.

Se construye a medida: a medida que el softwareevoluciona se crean estndares de diseo. El software

Conjunto de programas creados como herramientapara otros programas. Por ejemplo: compiladores,Sistemas operativos

Software de gestin

Gestin de grandes cantidades de informacinalmacenadas, para facilitar la toma de decisiones.Por ejemplo Bases de datos y aplicaciones degestin de empresa

Software de ingenieray cientfico

Elsoftwar


10/162


Utiliza algoritmos de manejo de nmeros,simulacin de sistemas, utiliza software en tiemporeal. Por ejemplo: aplicaciones de astronoma,

vulcanologa, fabricacin automtica.

Software de tiemporeal

El software que coordina / analiza/ controla sucesosdel mundo real conforme ocurren, se denomina detiempo real.

Software empotradoReside en memoria de slo lectura y se utiliza para

controlar productos y sistemas de los mercadosindustriales. Por ejemplo, el control de las teclas deun horno de microondas, funciones digitales en un

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

Software deinteligencia artificial

Hace uso de algoritmos no numricos para resolverproblemas complejos. Por ejemplo: sistemasexpertos, redes neuronales, robtica, prueba de


11/162

Ingeniera del Software1.5 Mitos del software

Los mitos de software propagaron informacin errnea y confusin, lo queconllevo a la crisis del software durante los primeros aos del desarrollo del

software.

Mitos de gestin

Tenemos ya un libro que est lleno de estndares y procedimientos paraconstruir software, no le proporciona ya a mi gente todo lo que necesita saber?Mi gente dispone de las herramientas de desarrollo de software ms avanzadas,despus de todo, les compramos las computadoras ms modernas.Si fallamos en la planificacin, podemos aadir ms programadores y 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 losdesarrolladores

Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo haterminado.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/162

Ingeniera del SoftwareACTIVIDADES COMPLEMENTARIAS

1. Muchos autores han tratado el impacto de la era de la informacin.D varios ejemplos (positivos y negativos) que indiquen el impacto del

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

reas de aplicaciones de software principales. Entre las seleccionespotenciales se incluyen: aplicaciones avanzadas basadas en Web,realidad virtual, redes neuronales artificiales, interfaces humanasavanzadas y agentes inteligentes.

3. Analice y describa la Realidad para cada uno de los mitos descritosen el numeral 1.5.

CONSULTAS WEB

Glosario de trminos de software, en:http://dxsting.cern.ch/sting/glossary.html

En www.spmn.com, informacin sobre los mitos del software.


13/162


2. EL PROCESO

Es una serie de pasos a seguir para construir un producto o un sistema. El

proceso del software es importante porque proporciona estabilidad, control yorganizacin a una actividad que puede, si no se controla, volverse catica.

2.1 Ingeniera del Software

A nivel internacional, la Ingeniera de Software empieza a tomar un papelfundamental y como un rea de la Ingeniera. A continuacin se relacionanalgunas definiciones de Ingeniera del Software:

de

para

de

es

Ingeniera de

el conjunto

Principios Mtodos Tcnicas

DesarrollarMantener

Software

Calidad

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


14/162


Boehm. Software Engineering.Ingeniera del software es la aplicacin prctica del conocimientocientfico en el diseo y construccin de programas decomputadora y la documentacin asociada requerida para

Bauer. Software Engineering.Ingeniera del software trata del establecimiento de los principiosy mtodos de la ingeniera a fin de obtener software de modorentable que sea fiable y trabaje en mquinas reales.

Pressman. Ingeniera del Software

La Ingeniera de/l software es una disciplina o rea de lainformtica o Ciencias de la Computacin, que ofrece mtodos ytcnicas para desarrollar y mantener software de calidad queresuelven problemas de todo tipo.

2

3

4

Braude. Ingeniera de SoftwareLa ingeniera de software es el proceso de construir aplicacionesde tamao o alcance prcticos, en las que predomina el esfuerzodel software y que satisfacen los requerimientos de funcionalidad

desem eo..

5

IEEELa aplicacin de un enfoque sistemtico, disciplinado ycuantificable hacia el desarrollo, operacin y mantenimiento delsoftware; es decir, la aplicacin de ingeniera al software.

6


15/162

Ingeniera del Software2.2 Esquema de la Ingeniera del Software

Es muy simple el esquema que consiste en desarrollar un programa sencilloque resuelve una tarea bien determinada. Lo normal es que se evolucione aldesarrollo 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": Programasintegrados que pueden trabajar en varios entornos.


16/162

Ingeniera del Software2.3 Esencia de la Ingeniera del Software

Esta figura podra resumir buena parte de la esencia de la asignatura: en eldesarrollo de software (una entidad "compleja") se producen problemas decomunicacin a varios niveles: entre usuarios y desarrolladores y entre loscomponentes mismos del equipo de desarrollo.

Estudiaremos las tcnicas, mtodos y herramientas de ingeniera que puedanhacer que estos problemas se minimicen, e incluso que desaparezcan.


17/162

Ingeniera del Software2.4 Proceso, mtodos y herramientas

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

Enfoque de calidad Gestin total de calidad. Cultura continua de

mejoras de procesos.Proceso Define un nmero de actividades del marco detrabajo aplicables a todos los proyectos delsoftware.

Mtodos Indican cmo construir tcnicamente elsoftware. Abarcan una gran gama de tareas queincluyen anlisis de requisitos, diseo,construccin de programas, pruebas ymantenimiento.

Herramientas Soporte automtico o semi-automtico para elproceso y los mtodos

La ingeniera es el anlisis, diseo, construccin, verificacin y gestin deentidades tcnicas.

El trabajo que se asocia a la ingeniera del software se puede dividir en tresfases, con independencia del rea de aplicacin, tamao o complejidad delproyecto.

Enfoque de calidad

Herramientas

Proceso

Mtodos


18/162


2.5 El Proceso del Software

1 Fase de definicinSe centra sobre el qu. Identificar qu informacin ha de serprocesada, que funcin y rendimiento se desea, qu

comportamiento del sistema, qu interfaces van a serestablecidas, qu restricciones de diseo existen, y qu criteriosde validacin se necesitan para definir un sistema correcto.Identificar los requisitos del sistema y del software.Las tareas especficas de esta fase son:Ingeniera de Sistemas o de informacinPlanificacin del proyecto software

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

estructuras de datos, cmo ha de implementarse la funcin dentrode una arquitectura de software, cmo ha de implementarse losdetalles procedimentales, cmo han de caracterizarse interfaces,cmo ha de traducirse el diseo en un lenguaje de programacin ycmo ha de realizarse la prueba.Las tareas especficas de esta fase son:Diseo del softwareGeneracin de cdigo

3 Fase de mantenimientoSe centra en el cambio.Correccin de erroresAdaptaciones requeridas a medida que evoluciona el entorno delsoftwareCambios debidos a las mejoras producidas por los requisitoscambiantes del clienteSe encuentran cuatro tipos de cambio:CorreccinAdaptacinMejora


19/162


Un proceso de software se puede caracterizar as:

Marco de trabajo comn delproceso

Actividades de Proteccin

Actividades del marco detrabajo

Conjuntos de tareas

TareasHitos, entregasPuntos SQA

Son independientes decualquier actividad delmarco de trabajo yaparecen durante todo el

roceso.

Permiten que las actividadesdel marco de trabajo seadapten a las caractersticasdel proyecto del software y alos requisitos del proyecto.

Aplicables a todos los proyectosde software, con independenciade su tamao o complejidad.


20/162

Ingeniera del Software3. MODELOS DE PROCESO DEL SOFTWARE

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

Una estrategia a menudo de llama modelo de proceso o paradigma deingeniera del software. Se selecciona un modelo de proceso para laingeniera del software segn la naturaleza del proyecto y de la aplicacin,los mtodos y las herramientas a utilizarse, y los controles y entregas que serequieren.

3.1 El modelo lineal secuencial

Llamado algunas veces ciclo de vida bsico o modelo en cascada, el

modelo lineal secuencial sugiere un enfoque sistemtico, secuencial, para eldesarrollo del software que comienza en un nivel de sistemas y progresa conel anlisis, diseo, codificacin, pruebas y mantenimiento.

Es un ciclo de vida en sentido amplio, que incluye no slo las etapas deingeniera sino toda la vida del producto: las pruebas, el uso (la vida til delsoftware) y el mantenimiento.

Ingeniera del Anlisis de las caractersticas y el comportamiento del

Ingeniera

del SistemaAnlisis

Diseo

Codificacin

Prueba

Utilizacin

Mantenimiento


21/162

Ingeniera del SoftwareSistema sistema del cual el software va a formar parte.

Para un sistema nuevo: Se debe analizar cules son losrequisitos funciones del sistema, y luego asignar unsubconjunto de estos requisitos y funciones al software.

Para un sistema ya existente: se debe analizar elfuncionamiento de la organizacin y sus operaciones y seasigna al software aquellas funciones que se van aautomatizar.Est formado por diagramas y por descripciones enlenguaje natural.

Anlisis Se debe comprender cules son los datos que se van amanejar, cul va a ser la funcin que tiene que cumplir elsoftware, cules son las interfaces requeridas y cul es el

rendimiento y otros requisitos no funcionales que seesperan lograr.Los requisitos, tanto del sistema como del software debendocumentarse y revisarse con el cliente. Como resultadodel la fase de anlisis, se obtiene la especificacin derequisitos del software.Tambin est formado por diagramas y descripciones enlenguaje natural.

Diseo El diseo se aplica a cuatro caractersticas distintas delsoftware: la estructura de los datos, la arquitectura de lasaplicaciones, la estructura interna de los programas y las

interfaces.El diseo es el proceso que traduce los requisitos en unarepresentacin del software de forma que pueda conocersela arquitectura, funcionalidad e incluso la calidad delmismo antes de comenzar la codificacin.En el diseo, los requisitos del software se traducen a unaserie de diagramas que representan la estructura delsistema software, de sus datos, de sus programas y de susinterfaces.

Codificacin Consiste en la traduccin del diseo a un formato que seacomprensible para la mquina. Si el diseo es lo

suficientemente detallado, la codificacin es relativamentesencilla, y puede hacerse de forma automtica, usandogeneradores de cdigo.Se traducen los diagramas de diseo a un lenguaje fuente,que luego se traduce - se compila - para obtener unprograma ejecutable.

Prueba El objetivo es comprobar que no se hayan producido


22/162

Ingeniera del Softwareerrores en alguna de las fases anteriores, especialmenteen la codificacin. Se deben probar todas las sentencias, ytodos los mdulos que forman 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. Estoscambios 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 componentesdel sistema.Que el cliente requiera modificaciones funcionales nocontempladas en el proyecto.

3.2 El modelo de construccin de prototipos

No

S

Identificar losrequerimientos conocidos

Desarrollarmodelo que

funcione

Utilizar elprototipo

Revisar elprototipo

Prototipo

Abandonar laaplicacin

Implantar laaplicacin

Volver a desarrollarla a licacin


23/162


Paso DescripcinIdentificar

losrequerimientos conocidos

Los analistas y los usuarios trabajan juntos para

identificar los requerimientos conocidos que tienen quesatisfacerse.Se debe: determinar los fines del sistema y el alcancede su capacidad.

Paso DescripcinDesarrollarmodelo 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 iniciarcon el desarrollo de un plan general que permitaconocer el proceso de desarrollo.Es importante definir un cronograma para el inicio y finde la primera iteracin.

El desarrollador estima los costos asociados con eldesarrollo 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 evaluarsus caractersticas y operacin es del usuario.La experiencia con el sistema bajo condiciones reales

Debe

describir

Primera

Los reportes y documentosque el sistema debeproporcionar

El formato de cada uno de


24/162

Ingeniera del Softwarepermite determinar los cambios o mejoras o eliminarcaractersticas innecesarias.


25/162


Paso DescripcinRevisar elprototipo

Se realiza la evaluacin y con la informacin obtenida selevantan las caractersticas que debe llevar la siguiente

versin del prototipo.La evaluacin permite profundizar los rasgos de losusuarios y los de la organizacin que tienen influenciasobre la aplicacin y en su implementacin.Los cambios en el prototipo son planificados con losusuarios antes de llevarlos a cabo por el analista.

Prototipoterminado?

Los pasos anteriores se repiten varias veces (4 o 6iteraciones) cuando los usuarios y desarrolladores estn deacuerdo en que el sistema ha evolucionado lo suficiente eincluye todas las caractersticas necesarias.

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

Abandonar la aplicacinSe descartan el prototipo y la aplicacin. El desarrollo delprototipo proporcion informacin a partir de la cual sedetermin que la aplicacin o el enfoque seleccionado soninapropiados para justificar un desarrollo adicional.

Implantar el prototipo

Las caractersticas y funcionamiento del prototiposatisfacen las necesidades de los usuarios ya sea en formapermanente o para un futuro.

Volver a desarrollar la aplicacinEl desarrollo del prototipo proporcion suficienteinformacin para determinar las caractersticas necesariasde toda la aplicacin. La informacin se utiliza como puntode partida para el desarrollo de la aplicacin en forma talhaga el mejor uso posible de los recursos.

Comenzar un nuevo prototipoLa informacin ganada con el desarrollo del prototipoinicial sugiere otras opciones o circunstancia. Se construyeun prototipo diferente para aadir informacin relacionadacon los requerimientos de aplicacin.


26/162

Ingeniera del SoftwareUn prototipo puede tener alguna de las tres formas siguientes:

3.3 El modelo DRA (Desarrollo Rpido de Aplicaciones)

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

2 Un prototipo que implemente algn(os) subconjunto(s) de lafuncin requerida, y que sirva para evaluar el rendimiento de unalgoritmo o las necesidades de capacidad de almacenamiento yvelocidad de clculo del sistema final.

3 Un programa que realice en todo o en parte la funcin deseadapero que tenga caractersticas que deban ser mejoradas duranteel desarrollo del proyecto.

un

que

del

es

DRA

modelo de proceso

Desarrollo del software

Enfatiza

Ciclo dedesarrollo

corto


27/162


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

Modelado degestin

El flujo de informacin entre las funciones de gestin semodela 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 lainformacin? Quin la procesa?

Equipo

Equipo N.

Modela

do degestin

Modelado dedatos

Modelado deproceso

Pruebasyentrega

Generacin deaplicacio

60-90 das

Modelado de

Modelado de

Modelado deproceso

Pruebasy


Modelado de

Modelado de

Modelado deproceso

Pruebasy


Equipo N.


28/162


Modelado dedatos

Conjunto de objetos de datos necesarios para apoyar laempresa. Se definen las caractersticas (atributos) de cadauno de los objetos y las relaciones entre estos objetos.

Modelado delproceso Los objetos de datos definidos en la fase de modelado dedatos quedan transformados para lograr el flujo deinformacin necesario para implementar una funcin degestin. Las descripciones del proceso se crean paraaadir, modificar, suprimir o recuperar un objeto de datos.

Generacindeaplicaciones

El DRA asume la utilizacin de tcnicas de cuartageneracin. En lugar de crear software con lenguajes deprogramacin de tercera generacin, el proceso DRAtrabaja para volver a utilizar componentes de programasya existentes o crear componentes reutilizables.

Pruebas y

Entrega

Como el proceso DRA enfatiza la reutilizacin, ya se han

comprobado muchos de los componentes de losprogramas. Esto reduce tiempo de pruebas. Sin embargo,se deben probar todos los componentes nuevos y se debenejercitar todas las interfaces a fondo.

3.4 Modelos de procesos evolutivos de software

cada vezpor

se

Los

modelosevolutiv

os

iterativos

caracterizan desarrollarversiones

mscompletas

del software


29/162


3.4.1 El modelo incremental

El modelo incremental se centra en la entrega de un producto operacionalcon cada incremento.

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

y lael

combinaEl modelo

Modelo lineal Construccin de

para

Entregar el software

en

Partes pequeas

llamadas

Incrementos


30/162


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.4.2 El modelo espiral

En las primeras iteraciones, la versin incremental podra ser un modelo enpapel o un prototipo.Durante las ltimas iteraciones, se producen versiones cada vez ms

completas del sistema diseado.

proporciona

conjugaes un procesode

software

evolutivo

Modelo

construccin de

modelo lineal

Un desarrollo rpido deversiones incremntalesdel software


31/162


Actividadesdel modeloen espiral

Comunicacin con el cliente: Se establececomunicacin entre 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 degestin

Ingeniera: Se construyen una o ms representacionesde la aplicacin.

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

Evaluacin del cliente: Se obtiene la reaccin delcliente. Se realiza la evaluacin de las representacionesdel software creadas durante la etapa de ingeniera eimplementada durante la etapa de instalacin.


32/162

Ingeniera del SoftwareEl equipo de ingeniera del software gira alrededor de la espiral en ladireccin de las agujas del reloj, comenzando por el centro.

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

especificacin de productos; los pasos siguientes en la espiral se podranutilizar para desarrollar un prototipo y progresivamente versiones massofisticadas del software. Cada paso por la regin de planificacin produceajustes en el plan del proyecto. El costo y la planificacin se ajustan con larealimentacin ante la evaluacin del cliente. Adems, el gestor del proyectoajusta el nmero planificado de iteraciones requeridas para completar elsoftware.

3.5 Modelo de mtodos formales y Tcnicas de cuarta generacinEl modelo de mtodos formales comprende un conjunto de actividades queconducen a la especificacin matemtica del software de computadora. Los

mtodos formales permiten que un ingeniero de software especifique,desarrolle y verifique un sistema basado en computadora aplicando unanotacin rigurosa y matemtica.Este enfoque es llamado ingeniera del software de sala limpia. Cuando seutilizan mtodos formales se descubren y corrigen ambigedades,inconsistencias y errores.

Las tcnicas de cuarta generacin, abarcan un conjunto de herramientas quefacilitan al ingeniero del software la especificacin de las caractersticas delsoftware a alto nivel.La herramienta genera automticamente el cdigo fuente basndose en la

especificacin del tcnico. Cuanto mayor sea el nivel en el que se especifiqueel software, ms rpido se puede construir el programa.El paradigma T4G para la ingeniera del software se orienta hacia laposibilidad de especificar el software usando formas de lenguajeespecializado o notaciones grficas que describa el problema que hay queresolver en trminos que los entienda el cliente.

las etapas

incluyeEl paradigmaT4G

Lenguajes no procedimentales de consulta a bases dedatosGeneracin de informesManejo de datos

Interaccin y definicin de pantallasGeneracin de cdigosCapacidades grficasGeneracin automatizada de HTML

Recoleccin de requisitos: descritos por losclientesDiseo de prototipoDesarrollo de prototipo operativoImplementacin

Documentacin


33/162


ACTIVIDADES COMPLEMENTARIAS

1. Las capas de la Ingeniera del Software sita las tres capas encima dela capa titulada enfoque de calidad. Esto implica un programa decalidad tal como Gestin de Calidad Total. Investigue y desarrolle unesquema de los principios clave de un programa de Gestin de CalidadTotal.

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 sera el ms eficaz? Por que?4. Qu es ms importante, el producto o el proceso?


34/162


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.info-ab.uclm.es/asignaturas/42551/enlaces.htm

http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6/PDF/SEGlossary.pdfhttp://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.phphttp://www.itver.edu.mx/comunidad/material/ing-software/unidad5.ppthttp://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.htmlhttp://www.monografias.com/trabajos5/inso/inso.shtmlhttp://www.sistemas.unam.mx/software.htmlhttp://www.ii.uam.es/~jlara/docencia/is1.2003/recursos.html


35/162


INTRODUCCIN

La gestin y planificacin de proyectos es una actividad que empieza antesde iniciar cualquier actividad tcnica y contina a lo largo de la definicin, deldesarrollo y del mantenimiento del software.

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

OBJETIVOS

GENERALES

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

Estudiar las tcnicas de anlisis y gestin del riesgo. Estudiar las tcnicas de gestin necesarias para planificar proyectos

de software.

ESPECIFICOS

Determinar como se debe gestionar el personal, el proceso yel problema durante un proyecto de software.

Identificar las mtricas de software y cmo pueden emplearsepara gestionar el proceso de software y el proyecto llevado acabo como parte del proceso.

Determinar como se crea la planificacin temporal de unproyecto.

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 DEPROYECTOS SOFTWARE


36/162


ESTRUCTURA TEMTICA

1. CONCEPTOS SOBRE GESTION DE PROYECTOS

1.1 Gestin de proyectos

La gestin de un proyecto de software se centra en:

mientra

de

implic

Gestin de

Planificaci Supervisi Control

Personal Procesos eventos

Evoluciona el Software

4 Ps

Personal Producto Proceso Proyecto

Necesidad depersonal parael desarrollode software

Objetivos ymbito delsoftware

Estructuraque

establece unplan

detalladopara el

Proyectos de

softwareplanificadosy

controlados.


37/162


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 del

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

es importante.Equipo desoftware

Mantei, propone 3 niveles de organizacin de equipos.

1.2 PersonalRecurso humano que participa y colabora en el proceso del software y suorganizacin para el desarrollo de los proyectos software de manera eficaz.

Gestores Superiores: se encargan de definir losaspectos del negocio.Gestores tcnicos del proyecto: se encargan deplanificar, motivar, organizar y controlar a losprofesionales que realizan el trabajo de desarrollo delsoftware.Profesionales: se encargan de proporcionan las

capacidades tcnicas necesarias para la ingeniera deun producto o aplicacin.Clientes: especifican los requisitos para la ingenieradel software.Usuarios finales: Se encargan de interactuar con el

Descentralizado democrticoEste equipo no tiene un jefe permanente y se nombrancoordinadores a corto plazo. Las decisiones se hacen por

consenso del grupo. La comunicacin entre los miembrosdel equipo es horizontal.


38/162


Coordinacin yComunicacin

Se establecen mecanismos de comunicacin para coordinaral equipo de trabajo. Se deben tener:

Descentralizado controladoEste equipo tiene un jefe definido que coordina tareas

especficas y jefes secundarios que tienenresponsabilidades sobre subtareas. La resolucin deproblemas sigue siendo una actividad del grupo, pero laimplementacin de soluciones se reparte entresubgrupos por el jefe de equipo. La comunicacin entresubgrupos e individuos es horizontal. Tambin hay

Centralizado controladoEl jefe del equipo se encarga de la resolucin deproblemas a alto nivel y la coordinacin interna del

equipo. La comunicacin entre jefe y los miembros del

Comunicacin formal: se lleva a cabo por escrito,con reuniones organizadas y otros canales decomunicacin. Incluye documentos de ingeniera desoftware, memorandos tcnicos, documentacin,informes de seguimiento.

Comunicacin informal: es ms personal. Incluyereuniones de grupo para la divulgacin de informaciny para la resolucin de problemas.

Comunicacin electrnica: se leva a cabo por

1.3 ProductoAl inicio de un proyecto, el gestor del proyecto debe examinar el productoy el problema a resolver. Por lo que se debe establecer el mbito delproducto delimitarlo.


39/162


mbito Se define:

Contexto: Cmo encaja el software a construir en unsistema, producto o contexto de negocios mayor y qulimitaciones se imponen como resultado del contexto?

Objetivos de informacin: Qu objetos de datosvisibles al cliente se obtienen del software? Qu objetosde datos son requeridos de entrada?

Funcin y rendimiento: Qu funcin realiza elsoftware para transformar la informacin de entrada en

una salida? Hay caractersticas de rendimientoespeciales que abordar?

Descomposicin delproblema

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 que resultan ms manejables.


40/162


Maduracindel problema yel proceso

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

El trabajo del gestor del proyecto es estimar los requisitos

de recursos, poner fechas de inicio y finalizacin de lastareas y los productos a fabricar.Descomposicin del proceso

Las actividades de: comunicacin, planificacin, anlisis deriesgo, ingeniera, construccin, entrega y evaluacin seadaptan al modelo o paradigma de desarrollo de softwareseleccionado.

1.4 Proceso

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

para:1. Los clientes que han solicitado el producto y la gente que realizar el

trabajo.2. Las caractersticas del producto.3. El entorno del ro ecto.

ComunicacinSe establece comunicacin entre el desarrollador y elcliente, con el propsito de obtener los requisitos delsistema.PlanificacinConjunto de tareas con el propsito de definir losrecursos y la planificacin temporal del proyecto.Anlisis del riesgoTareas requeridas para valorar los riesgos tcnicos y degestin.

IngenieraTareas requeridas para construir una o msrepresentaciones de 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 fasede ingeniera.


41/162


Se debe:

1.5 Proyecto

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

Comprender el problemaa solucionar y establecerlos objetivos.

1

Mantener el equipo dedesarrollo y proporcionarincentivos.

2

Realizar seguimiento alas actividades

desarrolladas durante elproceso como parte de lacalidad del mismo.

3

Tomar decisiones juntocon el gestor del

proyecto y el equipo dedesarrollo de software.

4

Evaluar la planificacinreal y la prevista, reunir yanalizar mtricas delproyecto de software yrealimentar cada uno de

5


42/162

Ingeniera del SoftwareACTIVIDADES COMPLEMENTARIAS

1. Se le ha nombrado gestor de proyecto dentro de una organizacin desistemas de informacin. Su trabajo es construir una aplicacin que es

bastante similar a otras que ha construido su equipo, aunque sta esmayor y ms compleja. Los requisitos han sido detalladamentedocumentados por el cliente. Qu estructura de equipo elegira yporqu? Qu modelo(s) de proceso de software elegira y por qu?

2. Se le ha nombrado gestor de proyecto de una pequea compaa deproductos software. Su trabajo consiste en construir un productoinnovador que combine hardware de realidad virtual con softwareinnovador. Puesto que la competencia por el mercado deentretenimiento casero es intensa, hay cierta presin para terminar eltrabajo rpidamente. Qu estructura de equipo elegira y porqu?

Qu modelo(s) de proceso de software elegira y por qu?


43/162

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

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

para

alse

de

comprend

Mtricas del

software

Mediciones

Software

aplican Proceso del softwareProyecto de software

Una gama

para

Ayudar en la estimacin,el control de calidad, laevaluacin deproductividad y el controlde ro ectos

Caracterizar: para comprender mejor los procesos, los productos,

los recursos y los entornosEvaluar: para determinar el estado con respecto al diseo

Predecir: para poder planificar

Mejorar: la calidad del producto y el rendimiento del proceso.


44/162

Ingeniera del Software2.1 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 condicionesde funcionamiento de un proceso y poder tener una visin de la eficacia deun proceso existente.

Durante un tiempo considerable se recopilan las mtricas de todos losproyectos y se proporcionan los indicadores para obtener mejoras e elsoftware.

Para mejorar cualquier proceso se debe:

Medida: Proporciona unaindicacin cuantitativa dela extensin, cantidad,dimensiones, capacidad otamao de algunosatributos de un proceso o

Medicin: es el acto de determinaruna medida.

Mtrica: Una medida cuantitativadel grado en que el sistema,componente o proceso posee unatributo dado.

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

proporciona una visin profunda que permite al gestor deproyectos o a los ingenieros de software ajustar el producto, elproyecto o el proceso.

permite

Los indicadoresde proyecto

Evaluar elestado delproyecto

2

Hacer

seguimiento a losriesgospotenciales

3

Detectar lasreas

problemasantes de quese conviertanen crticas

4

Ajustarel flujo y

lastareasdeltraba o

5

Evaluar lahabilidad del

equipo paracontrolar lacalidad de losroductos


45/162


De acuerdo a la figura:

El producto, la tecnologa y las personas tienen una fuerte influencia en eldesarrollo y la calidad del software. El proceso se encuentra dentro de unascondiciones de entorno que incluyen: entornos de desarrollo, condiciones del

negocio, y caractersticas del cliente. Estas condiciones, son de granimportancia puesto que permiten definir las reglas del proceso y podercontribuir a la calidad del software.

La eficacia de un proceso de software se mide a travs de un juego demtricas segn los 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

Producto

TecnologaPersona

Proceso

Condicionesdel negocio

Caractersticas delcli nt

Entorno dedesarrollo

Figura tomada de Roger Presuman. Ingeniera de

Medida de errores detectados antes de la entrega del

Defectos detectados

Productos de trabajo entregados

Esfuerzo humano y tiempo consumido


46/162


Tambin se debe incluir mtricas para medir las caractersticas de tareasespecficas de la ingeniera del software.

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

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

y

para

del

utiliza

M

Anlisis de

Software

Recopilarinformacin

de

Errores Defecto

Ajuste con la planificacin

Medida del tiempo y del esfuerzo para llevar a caboactividades de proteccin

Actividades genricas de ingeniera del software

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 ordenarpor orden descendente

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

5 Los datos resultantes se analizan para detectar las categoras queproducen un costo alto para la organizacin

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


47/162


Para determinar las principales causas que pueden ocasionar defectos en elsoftware y con base en ello extraer los indicadores que permitan a unaorganizacin de software modificar su proceso para reducir la frecuencia de

errores y defectos se utiliza el diagrama de espina.

Problema

Principal

R%

Causapotencial No. 1

Q1%

Causapotencial no. 2

Q2%

Causa

potencial n

Qi%

Causa

potencial 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

ErrorEs alguna fisura descubierta por los ingenieros del

software antes de que el software sea entregado al

Defecto

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


48/162

Ingeniera del SoftwareEn un diagrama de espina:

La lnea central, representa el factor de calidad o el problema enconsideracin.

Las lneas diagonales conectadas a la lnea central indican una causapotencial del problema de calidad.

Esta misma notacin se aplica para cada una de las lneas diagonalesconectadas a la lnea central.

Por ejemplo:

Se han encontrado y determinado las siguientes causas y su origen en unproyecto de software:

Origen de errores /defectos

Causa %

Especificacin / requisitos Lgica 20Manejo 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

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

Defectos deespecificacin

25.5%

Incorrecto Cambios

Perdido Ambiguo

El cliente dio

informacin equivocada

Informacin desactualizada

Cliente consultadono adecuado

Insuficienteinformacin solicitada


49/162


2.3 Mtricas del Proyecto

Las mtricas del proyecto de software sugieren que los proyectos debenmedir:

2.4 Mediciones del Software

Las mtricas del software se pueden categorizar en:

Se utilizan

Mtricas de

Para minimizar laplanificacin de desarrollo,ya que se realizan ajuste yse reduce los retrasos

Para evaluar la calidad delos productos. A medidaque mejora la calidad seminimizan los defectos.

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

2 Salidas: medidas de las entradas o productos creados durante el procesode ingeniera del software

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

1

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 defectosinformados durante un eriodo de tiem o establecido

Medidas Indirectas:Incluyen: La funcionalidad, calidad, complejidad, eficiencia fiabilidad, facilidad, facilidad de mantenimiento


50/162


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

2.4.1 Mtricas orientadas al tamao

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

Proyecto LDC Esfuerzo Costo $ Pginas dedocumentaci

n

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 mtricaspara 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

permiten

Mtricas del software orientadas a la

La medida delafuncionalidad

Propuestas

Allan Albrecht de IBM, comenz a analizar

sistemas, a pedido del grupo de usuarios de IBM,buscando identificar los factores crticos quedeterminan el tamao del software y porconsiguiente, estimar el esfuerzo y el costo dedesarrollarlo. Luego de analizar cientos desistemas, naci la tcnica de Anlisis de Puntospor funcin. La tcnica mide una aplicacin conbase en las funciones que ste realiza para/por


51/162


Los puntos de funcin se obtienen utilizando una funcin emprica basado enmedidas cuantitativas del dominio de informacin del software y valoraciones

subjetivas de la complejidad del software.Los puntos de funcin se calculan utilizando la siguiente tabla:

Parmetrosde medicin

Cuenta

Factor deponderacin

Simple

Medio

Complejo

Nmero deentradas deusuario

X3 4 6

=

Nmero desalidas deusuario

X4 5 7

=

Nmero depeticiones deusuario

X3 4 6

=

Nmero dearchivos X

7 10 15=

Nmero deinterfacesexternas

X5 7 10

=

Cuenta_total

Se determinan 5 caractersticas del mbito de la informacin y los clculosaparecen en la posicin apropiada de la tabla. Los valores del mbito de

informacin estn definidos de la siguiente manera:

1. Nmero de entradas de usuario:se cuenta cada

2. Nmero de salidas de usuario:se cuenta cada salida que proporciona al usuari

Nmero de peticiones de usuario:una peticin esta definida como una entrada interact

4. Nmero de arch

5. Nmero de interfaces externas:se cuentan todas las interfaces legibles por la


52/162


Cuando han sido recogidos los datos anteriores, se asocia el valor decomplejidad a cada cuenta. Las organizaciones que utilizan mtodos depuntos de funcin desarrollan criterios para determinar si una entrada esdenominada simple, media o compleja. No obstante la determinacin de lacomplejidad es algo subjetivo.

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

PF Punto de funcinCuenta_total

Es la suma de todas las entradas obtenidas

fi Donde i=1 hasta 14. Son valores de ajuste de lacomplejidad basados en las respuestas a lascuestiones sealadas de la siguiente tabla:

Evaluar cada factor en escala 0 a 5

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


53/162

Ingeniera del Software01234

5

NoinfluenciaIncidentalModeradoMedioSignificativoEsencia

l


54/162

Ingeniera del Softwareserreutilizable?

12Estnincluidaseneldise

olaconversinylainstalacin?

13Sehadiseadoelsistem

aparasoportarmltiples


55/162


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

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


56/162

Ingeniera del Software2.5 Mtricas para la calidad del software

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

herramientas efectivos dentro del contexto de un proceso maduro dedesarrollo de software.

2.5.1 Medidas de la Calidad

Dentro de las medidas de calidad del software tenemos:

Correccin

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

Defectos por KDLC (miles de lneas de cdigo)

Facilidad de mantenimiento

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

Tiempo Medio de cambio (TMC)

Es decir, el tiempo que se tarda en:Analizar una peticinDisear un modificacinImplementar el cambioProbar y realizar el cambio.


57/162


Integridad

Mide la capacidad del software para resistir ataques.

Se debe tener en cuanta los siguientes atributos:

Amenaza

Seguridad

Se define como:

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

Es la probabilidad de que un ataque ocurra en untiempo determinado.

Es la probabilidad de que se pueda repeler el ataquede un tipo 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 elsistema.


58/162

Ingeniera del Software2.5.2 Eficacia de la eliminacin de defectos

La eficacia de la eliminacin de defectos (EED), es una mtrica que permitemedir la habilidad de filtrar las actividades de la garanta de calidad y de

control, ya que es aplicable a todas las actividades del marco de trabajo delproceso.

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

2.5.3 Integracin de las mtricas dentro del proceso de Ingenieradel 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.


59/162


MedidasRecopilacin de datosRequiere una investigacin histrica de los

proyectos para reconstruir los datos

MtricasClculo de mtricasSe hace el clculo de mtricas una vez sehan determinado las medidas. Puedenabarcar una gran cantidad de mtricas:LDC y PFDe calidadDel proyecto

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.


60/162


ACTIVIDADES COMPLEMENTARIAS

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

2. Elabore un ensayo argumentativo, que de respuesta a la pregunta Porqu renecesita medir? Por qu son importantes las mtricas dentro dela ingeniera de Software?

3. Sugiera tres medidas, tres mtricas y los indicadores que se podranutilizar para evaluar un automvil.

4. Indague con algn desarrollador de software o un equipo de desarrollode software qu medidas, mtricas e indicadores utilizan o tienenimplementadas. Elabore un cuadro sinptico.

INVESTIGACIN

1. El Instituto de Ingeniera de Software (The Carnegie Mellon SoftwareEngineering Institute -SEI) ha desarrollado una gua para establecer unprograma de medicin de software dirigido hacia objetivos. Investiguey elabore un documento sobre esta gua.

EJERCICIOS

1. Calcule el Punto de Funcin de un proyecto con las siguientescaractersticas del dominio de informacin:

Nmero de entrada de usuario 32Nmero de salida de usuario 60Nmero de peticiones de

usuario

24

Nmero de archivos 8Nmero de interfaces externos 2

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


61/162


3. PLANIFICACIN DE PROYECTOS DE SOFTWARE

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

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

experiencia.

El objetivo primordial es hacer estimaciones razonables de recursos, costos yuna planificacin temporal.

Las estimaciones involucran un periodo de tiempo y deben ser actualizadas amedida que avanza el proyecto.

3.1 mbito del Software y Recursos

determina

implica

Planificacin

Estimaci

El costo

El esfuerzo Los recursos El tiempo

Para construir ydesarrollar un producto

Su resultado

Es una tabla con:

Las tareas a desarrollar Las funciones a

implementar El costo, esfuerzo y

tiempo necesarioPara la realizacin de cada

involucra

Planificacin

mbito delsoftware

Recursos

Estimacindel proyecto

Tcnicas dedescomposici

Modelos deestimacin


62/162


3.1.1. mbito del SoftwareDescribe el control y los datos a procesar, la funcin, el rendimiento, lasrestricciones, las interfaces y la fiabilidad. Se evalan las funciones descritas

en la declaracin del mbito, y en algunos casos se refinan para dar masdetalles antes del comienzo de la estimacin.

3.1.2 Recursos

comprend

mbito del

Recoleccin de la informacinSu objetivo es acercar al desarrollador y al cliente para establecer unacomunicacin, para lograr esto, se utiliza una tcnica muy comn que esuna reunin o una entrevista preliminar.

Esta reunin o entrevista debe involucrar los siguientes tipos depreguntas:Preguntas de contexto libre: se centran en el cliente, en los objetivosglobales y en los beneficios. Estas preguntas deben llevar a unentendimiento bsico del problema, las personas interesadas en lasolucin y la solucin que se desea.

Metacuestiones: estas preguntas se centran en la efectividad de lareunin, involucra preguntas para determinar si la persona es la apropiadapara responder a las preguntas, si sin relevantes las preguntas para elproblema en estudio, si las respuestas son oficiales, si existe algo que sedebera preguntar.

Tambin existe otra tcnica que permite la creacin de un equipocompuesto por los clientes y los desarrolladores para identificar elproblema, proponer elementos de solucin, establecer enfoques yespecificar un conjunto preliminar de requisitos denominada TFEA(Facilitated application specification techniques) Tcnica para facilitar las

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 y Recursos. Tanto el equipo de desarrollo y lasdems personas involucradas en el software deben determinar sipuede ser construido dentro de las dimensiones especificadas.


63/162


Comprende la estimacin de los recursos necesarios para emprender eldesarrollo del software.

Los recursos de desarrollo son:

Recurso humano

Se debe establecer el perfil y las habilidades que se necesitan del personalque se necesita para llevar a cabo el desarrollo del proyecto. Hay queespecificar tanto la posicin dentro de la organizacin como la especialidad.

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 bloquesde construccin de software.

Se establecen 4 categoras de recursos de software que se deben tener encuenta a medida que se avanza con la planificacin:

Componentes ya desarrollados: componentes que ya han sido validadostotalmente se pueden utilizar e implementar en el desarrollo del proyectoactual.

Humanos

Componentesreutilizables de software

De entorno(Hardware / software)

Gestor Ingeniero de software Analista de sistemas


64/162


Componentes ya experimentados: se puede utilizar Especificaciones,diseos, cdigo o datos de prueba existentes que ya han sidodesarrollados para proyectos anteriores.

Componentes con experiencia parcial: se puede utilizar Especificaciones,diseos, cdigo o datos de prueba existentes que ya han sidodesarrollados para proyectos anteriores y que requieren una modificacinsustancial.

Componentes nuevos: componentes que el equipo de software requiereconstruir especficamente 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 odesarrollar el producto software y se debe verificar que estos recursos estndisponibles.

3.2 Estimacin del proyecto de software y tcnicas de

descomposicin

Para realizar estimaciones seguras de costos y esfuerzos, se pueden tenerlas siguientes opciones:

Hardware y

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.


65/162


La utilizacin de tcnicas de descomposicin y de modelos empricos,permiten descomponer el proyecto en funciones principales y en tareas loque implica que se pueda realizar una estimacin del costo y del esfuerzo del

proyecto de forma escalonada.

Antes de de realizar la estimacin del proyecto se debe generar unaestimacin del tamao del software a construir.

3.2.1 Tamao del software

Dentro de la planificacin de proyectos, el tamao se refiere a unaproduccin cuantificable 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 enfoqueindirecto.

Tamao en lgica difusa

Utiliza las tcnicas aproximadas de razonamiento. Para aplicar esteenfoque se debe:Identificar el tipo de aplicacinEstablecer su magnitud en una escala cuantitativaRefinar 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, lasentencia "hoy es un da soleado", puede ser 100% verdad si no hay nubes, 80% verdad si haypocas nubes, 50% verdad si existe neblina y 0% si llueve todo el da.


66/162


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 ocontador, y se calcula 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 paraun rea en 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 15informes. Los datos histricos indican que por informe se requieren 827lneas de programacin.

2

Tamao del cambioEste enfoque se utiliza cuando en un proyecto se utiliza softwareexistente y que se debe modificar de alguna manera como parte delproyecto.Se debe estimar el nmero y tipo de modificaciones que se deben llevara cabo.

3

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


67/162


3.2.3 Estimacin basada en el proceso

Esta tcnica permite, descomponer el proceso en un conjunto relativamente pequeo

de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin decada tarea.

Esta estimacin comprende:

3.3 Modelos empricos de estimacin

Utilizan frmulas derivadas empricamente de una muestra limitada deproyectos 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 hayaescogido para obtener el esfuerzo en hombres-mes.

Precisamente por venir de una muestra limitada, no son adecuadospara toda clase de software ni para todo medio ambiente de desarrollo.

Modelo COCOMO

Creado por Barry Boehm en 1981. Su nombre significa COnstructive COstMOdel (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 desoftware.


68/162


Los modelos COCOMO estn definidos para tres tipos de proyectos desoftware:

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 deldesarrollo en funcin del tamao del programa estimado

COCOMO intermedio. Calcula el esfuerzo del desarrolloen funcin del tamao del programa y un conjunto deconductores de costo que incluyen la evaluacinsubjetiva del producto, del hardware, del personal y de

COCOMO detallado. Incorpora las caractersticas de laversin intermedia y lleva a cabo una evaluacin delimpacto de los conductores de costo en cada fase(anlisis, desarrollo, etc.) del proceso.

Modelo

E = a * KLOCb

D = c * Ed


69/162

Ingeniera del SoftwareDonde:

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 elproyecto

Los coeficientes a y c y los exponentes b y d se obtienen de la siguientetabla:

Tipo de proyecto a b C d Orgnico 2.4 1

.052.5

0.38

Semiacoplado 3.0 1.12

2.5

0.35

Empotrado 3.6 1.20

2.5

0.32

Aplicando el modelo COCOMO bsico al ejemplo anterior y usando un tipo deproyecto orgnico 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 unnmero de personas N para el proyecto.

El planificador puede decidir emplear slo una o dos personas y ampliar portanto la duracin 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


70/162

Ingeniera del SoftwareCOCOMO intermedio

En el COCOMO intermedio, la ecuacin para calcular el tiempo de desarrolloes la misma 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 a y el exponente b estn dados por la tabla:

Tipo de proyecto a bOrgnico 3.2 1.05

Semiacoplado 3.0 1.12

Empotrado 2.8 1.20

Y

EAF Es un factor de ajuste del esfuerzo que se calcula valorando

en una escala de muy bajo, bajo, nominal, alto y muy altocada uno de los siguientes 15 atributos, agrupados en 4categoras. As:

E = a * KLOCb * EAF


71/162

Ingeniera del SoftwareAtributos del producto.Son restricciones y requerimientos del proyecto que va aser desarrollado.

Confiabilidad requerida*

Tamao de la base de datos Complejidad del producto

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

EAF


72/162

Ingeniera del SoftwareAtributos 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 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 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.75Bajo 0.88Nominal 1Alto 1.15Muy alto 1.40

El nmero indica el grado con el que cada factor puede influenciar laproductividad. Un valor menor que 1 indica que el factor puede decrementarel calendario y el esfuerzo. Un valor mayor que 1 denota un factor queextiende el calendario y el esfuerzo. Finalmente, un valor igual a 1 noextiende ni decrementa el calendario y el esfuerzo (esta clase de factor sellama nominal).Para obtener el EAF se multiplican cada uno de los 15 factores.


73/162

Ingeniera del SoftwareSe puede simplificar el clculo del EAF porque hay una tendencia aconsiderar los atributos marcados en (*), como los ms relevantes y quedeberan 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:

Donde,

E Esfuerzo en hombres-ao.t Duracin del proyecto en aos.B Factor especial de destrezas. Para programas pequeos B vale

0.16, para programas intermedios vale 0.28, para programasmayores vale 0.39.

P Parmetro de productividad, para un software de tiempo real, Pvale 2,000, para comunicaciones vale 10,000, para softwarecientfico vale 12,000 y para aplicaciones comerciales de

sistemas vale 28,000.

Para simplificar el proceso de estimacin se sugiere un conjunto deecuaciones 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 t representado en aos


74/162


Aplicando las ecuaciones al ejemplo anterior, obtenemos:

3.4 Riesgo del software

El anlisis y la gestin del riesgo son una serie de pasos que ayudan alequipo del software a comprender y a gestionar la incertidumbre.

Por tal razn es importante:

Los pasos que se deben seguir son:

3.4.1. Estrategias de riesgo

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

= 7 mesesE = 180 * 0.28 * 0.753

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.

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

2 Cada riesgo se analiza para determinar la probabilidad de que puedaocurrir y el dao 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 e impacto.


75/162


Se tienen dos estrategias:

Reactiva

Supervisa el proyecto en previsin de posibles riesgos.Evaluar las consecuencias del riesgo cuando este ya se ha producido (yano es un riesgo)Actuar en consecuencia

ProactivaIdentifica los riesgos potenciales.Evaluacin previa y sistemtica de riesgosEvaluacin de consecuencias

Se establece un plan de contingencia para controlar el riesgo.

implica

Riesgo

Incertidumbreel acontecimientoque caracteriza alriesgo puede o nopuede ocurrir.

PrdidaSi el riesgo se convierte enuna realidad, ocurrirnconsecuencias no deseadas oprdidas.


76/162


3.4.2 Categoras de riesgos

Riesgos del proyecto

Pueden amenazar al plan del proyecto, porque puede retrazar el proyecto yaumentar los costos.Identifican problemas de:

Presupuesto Personal Recursos Cliente Requisitos

Riesgos tcnicos

Amenazan la calidad del software y la planificacin temporal del proyecto. Laimplementacin 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 elproyecto y el producto.Identifican problemas de:

De mercado De estrategia De ventas De gestin De presupuesto


77/162

Ingeniera del Software3.4.3 Identificacin del riesgo

Existen dos tipos de riesgo:

Riesgos genricosRepresentan una amenaza potencialpara todos los proyectos de software.

Riesgos especficosImplican un conocimiento profundodel proyecto (Entorno, Tecnologa,Personal)

Lista de comprobacin de elementos de riesgo

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

Relacionados con eltamao del producto

Se asocian los riesgos con el tamao del software aconstruir 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 reutilizadoCon 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


78/162


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 especificacinformal de requerimientos Est dispuesto a relacionarse de forma gil con el

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

consejos de experto informtico Entiende el ciclo de vida de una aplicacin

Con la definicin 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 todo el mundo los estndares Existen plantillas y modelos para todos los

documentos resultado del proceso Se aplican revisiones tcnicas de la especificacin de

requerimientos diseo y codificacin Se aplican revisiones tcnicas de los procedimientos

de revisin y prueba

Se documentan los resultados de las revisionestcnicas Hay algn mecanismos para asegurar que un

proceso de desarrollo sigue los estndares Se realiza gestin de la configuracin Hay mecanismos para controlar los cambios en los

requerimientos que tienen impacto en el software Se documenta suficientemente cada subcontrato Se ha habilitado y se siguen mecanismos de

seguimiento y evaluacin tcnica de cadasubcontrato.

Se dispone de tcnicas de especificacin deaplicaciones para facilitar la comunicacin con elcliente.

Se usan mtodos especficos para anlisis desoftware

Se utiliza un mtodo especfico para el diseoarquitectnico y de datos

Est el 90% del cdigo en lenguajes de alto nivel


79/162

Ingeniera del Software Hay estndares de documentacin de cdigo Se usan mtodos especficos para el diseo de

pruebas Se utilizan herramientas para llevar a cabo la

planificacin y control

Con el entorno dedesarrollo

Asociados a las herramientas que se van a utilizar en eldesarrollo del software

Hay herramientas de gestin de proyectos Hay herramientas de gestin del proceso de desarrollo Hay herramientas de anlisis y diseo Hay generadores de cdigo apropiados para la

aplicacin Hay herramientas de prueba apropiadas

Hay herramientas de gestin de configuracinapropiadas Se hace uso de una base de datos o repositorio

centralizado E

16755657 301404 modulo ingenieria del software

Documents