8255409 Metodologias Para La Geston y Desarrollo de Software

8/4/2019 8255409 Metodologias Para La Geston y Desarrollo de Software

1/99


2/99

INTRODUCCIN

El desarrollo de software es un proceso tecnolgico de alta complejidad que

consume tiempo, requiere mucho esfuerzo humano y demanda costos,

generalmente, elevados. Un porcentaje muy alto de proyectos de software

fracasan debido, entre otros factores, a una gestin deficiente del proyecto.

El xito de un proyecto de software se mide en funcin de tres variables

fundamentales: costo, tiempo y calidad. Un proyecto exitoso es aquel que

se entrega a tiempo, bajo el presupuesto asignado y con la calidad

especificada. Para manejar estas tres variables, los ingenieros de software

emplean modelos, procesos y tcnicas gerenciales.


3/99

I. METODOLOGA DE GESTIN DE PROYECTO

1.1 GESTION DE PROYECTOS DE SOFTWARE

1.1.1 MISIN, COORDINACIN CON OTROS PROYECTOS,DIFERENCIAS Y DOCUMENTACIN (AD-HOC, DOCUMENTADO,NORMAS)

1.1.1.1 Misin :

Que el desarrollo del proyecto est dentro de los lmitesmarcados de tiempo y presupuesto.

Indirectamente garantiza una buena realizacin tcnica. Una buena gestin no garantiza el xito, pero sin gestin

hay fracaso

1.1.1.2 Coordinacin con otros proyectos:

Hablar de proyectos software puede resultar incorrecto porque lo normal no es que se desarrolle un software sino unsistema en el que el software va a tener una parte ms omenos protagonista.

Generalmente el proyecto software no se ejecuta de forma

aislada sino que tiene que integrarse con otros proyectosque se estn realizando en la organizacin. Cuando se integra con otros proyecto (en curso o en

futuro) software de la organizacin se suele hablar degestin integrada de la informacin en la empresa.

1.1.1.3 Diferencia de la gestin de software con otroscampos:

El producto es intangible No hay un proceso software estndar. No hay una relacin cerrada entre tipos de producto

software

Tipos de Software: [1]

Software de sistemas

Est formado por todos aquellos programas cuyafinalidad es servir al desarrollo o al funcionamiento deotros programas. Estos programas son muy variados:editores, compiladores, sistemas operativos, entornosgrficos, programas de telecomunicaciones, etc. pero

se caracterizan por estar muy prximos al hardware,por ser utilizados concurrentemente por numerososusuarios y por tratarse de programas de amplia


4/99

difusin, no estando diseados normalmente a medida.Esto permite un mayor esfuerzo en su diseo yoptimizacin, pero tambin les obliga a ser muy fiables,cumpliendo estrictamente las especificaciones para lasque fueron creados. Un ejemplo de este tipo desoftware son los sistemas operativos, como Windows y

Unix.Software de tiempo real

Esta formado por todos aquellos programas que miden,analizan y controlan los sucesos del mundo real amedida que ocurren, debiendo reaccionar de formacorrecta a los estmulos de entrada en un tiempomximo prefijado. Deben, por tanto, cumplir unosrequisitos temporales muy estrictos y, dado que losprocesos que controlan pueden ser potencialmentepeligrosos, tienen que ser fiables y tolerantes a fallos.

Por otro lado, no suelen ser muy complejos y precisande poca interaccin con el usuario. Un sistema detiempo real es aquel en el que para que las operacionescomputacionales estn correctas no depende solo deque la lgica e implementacin de los programascomputacionales sea correcto, sino tambin en eltiempo en el que dicha operacin entreg su resultado.Si las restricciones de tiempo no son respetadas elsistema se dice que ha fallado. Un Buen ejemplo es elde un robot que necesita tomar una pieza de una banda

sinfn. Si el Robot llega tarde, la pieza ya no estardonde deba recogerla. Por lo tanto el trabajo se llevacabo incorrectamente, aunque el robot haya llegado allugar adecuado. Si el robot llega antes de que la piezallegue, la pieza aun no estar ah y el robot puedebloquear su paso.

Software de gestin

El procesamiento de informacin de gestin constituye,casi desde los inicios de la informtica la mayor de lasreas de aplicacin de los ordenadores. Estos

programas utilizan grandes cantidades de informacinalmacenadas en bases de datos con objeto de facilitarlas transacciones comerciales o la toma de decisiones.Adems de las tareas convencionales de procesamientode datos, en las que el tiempo de procesamiento no escrtico y los errores pueden ser corregidos a posteriori,incluyen programas interactivos que sirven de soporte atransacciones comerciales.

Software cientfico y de ingeniera

Otro de los campos clsicos de aplicacin de la

informtica. Se encarga de realizar complejos clculossobre datos numricos de todo tipo. En este caso lacorreccin y exactitud de las operaciones que realizan


5/99

es uno de los requisitos bsicos que deben de cumplir.

El campo del software cientfico y de ingeniera se havisto ampliado ltimamente con el desarrollo de lossistemas de diseo, ingeniera y fabricacin asistida porordenador (CAD, CAE y CAM), los simuladores grficos yotras aplicaciones interactivas que lo acercan ms alsoftware de tiempo real e incluso al software desistemas.

Software de ordenadores personales

El uso de ordenadores personales y de uso domsticose ha generalizado a lo largo de la pasada dcada.Aplicaciones tpicas son los procesadores de textos, lashojas de clculo, bases de datos, aplicaciones grficas,

juegos, etc. Son productos de amplia difusinorientados a usuarios no profesionales, por lo que entre

sus requisitos se encuentran la facilidad de uso y elbajo coste. Un ejemplo de este tipo de software es elpaquete de Office.

Software empotrado

Software empotrado es aquel que va instalado en otrosproductos industriales, como por ejemplo la electrnicade consumo, dotando a estos productos de un grado deinteligencia cada vez mayor. Se aplica a todo tipo deproductos, desde un vdeo domstico hasta un misil concabeza atmica, pasando por algunos sistemas de

control de los automviles, y realiza funciones muydiversas, que pueden ir desde complicados clculos entiempo real a sencillas interacciones con el usuariofacilitando el manejo del aparato que los incorpora.Comparten caractersticas con el software de sistemas,el software de tiempo real, el software de ingeniera ycientfico y el software de ordenadores personales. Otroejemplo de los productos que utilizan este tipo desoftware son los telfonos celulares.

Software de inteligencia artificial

El software basado en lenguajes procedimentales es tilpara realizar de forma rpida y fiable operaciones quepara el ser humano son tediosas e incluso inabordables.Sin embargo, es difcilmente aplicable a problemas querequieran la aplicacin de funciones intelectuales mselevadas, por triviales que nos puedan parecer. Elsoftware de inteligencia artificial trata de dar respuestaa estas deficiencias, basndose en el uso de lenguajesdeclarativos, sistemas expertos y redes neuronales.

Un ejemplo de este software es Smart Airport

Operations Center, programa de logstica creado porAscent Technology, el cual es utilizado en losaeropuertos, que computacional-mente, son el mayor


6/99

reto mundial para resolver problemas. Un cambio(atraso, lluvia, falta de un empleado) genera el efectodomin. Con el susodicho software, este pulpo balanceatodos los detalles hasta que todo cuadre.

Son logsticas, pero el problema es ms sutil que unaecuacin gigante. No hay manera de solucionar unaeropuerto con sus miles de variables. A cambio, losalgoritmos genticos usan la seleccin natural, lamutacin, el cruce de escenarios subptimos,permitiendo que el programa encuentre la mejoropcin. La gente hace esto instintivamente en la vidadiaria.

Pero el software eleva la productividad en un 30% enlos aeropuertos que lo usan, eliminando diferentesengalletamientos.

Grandes proyectos software son con frecuencia proyectosnicos.

Empleo de nuevas tcnicas. Elevado nmero de interfases.

1.1.1.4 Documentacin

No se puede llamar gestin a lo que es un procesoAd-Hoc:

Sin planes escritos, registros etc.

Gestin es un proceso documentado :

Si no, no es posible el seguimiento [2]

Hoy en da las valoraciones que se hacen de lasempresas, consideran como aspecto no-financieroms importante la habilidad de ejecutar laestrategia de una empresa, y no tanto la calidad de

la estrategia en s misma.

De acuerdo con un informe de Ernst & Young, de losfactores no financieros ms importantes a la hora devalorar una empresa, el nmero uno es la habilidadpara ejecutar la estrategia de la empresa, mientrasque la calidad de esta estrategia se encuentra entercera posicin.

Para confirmar esta idea, podemos ir a un estudiopublicado en la revista Fortune, que dice que

alrededor del 70% de los fallos que cometen losdirectivos no estn causados por una estrategiapobre, sino por una ejecucin deficiente de la


7/99

misma siendo indecisivos y no cumpliendo con loscompromisos establecidos con los accionistas, losclientes o los profesionales que trabajan en laempresa.

El Cuadro de Mando Integral CMI (denominacin en castellano de BalancedScorecard, desarrollado por Kaplan y Norton aprincipios de los aos noventa) es una herramientade gestin estratgica que apoya la definicin,comunicacin y gestin de los objetivos y estrategiade la empresa. Segn el CMI la estrategia de unaempresa puede definirse en funcin de cuatroperspectivas como son la financiera, la de clientes,la de procesos y la de aprendizaje y crecimiento.

BITS (Balanced IT Scorecard)Los problemas presentados anteriormente seacentan en las compaas de Tecnologas de laInformacin (TI), donde las barreras decomunicacin causadas por el uso de idiomas muydistintos entre el departamento de TI y el resto delnegocio, provocan una reduccin en el potencialque las TI tienen para aadir valor a la empresaidentificando nuevas oportunidades de negocio.

Ante esta situacin se ve la necesidad de crear unlenguaje comn en la empresa que ofrezca unmarco comn de evaluacin haciendo uso de losmismos criterios en toda la empresa. Esto permitirque las inversiones en TI y las mejoras que se llevena cabo en la empresa estn orientadas a conseguirobjetivos de negocio y que puedan evaluarse enfuncin de esta aportacin al negocio.

Conociendo los principios del CMI debemosdesarrollar una metodologa para llevarlos a las

organizaciones de TI, considerando laspeculiaridades de estas empresas.

Podemos definir cinco perspectivas:

Financiera: Cmo aaden valor econmico a laempresa nuestros procesos de desarrollo desoftware y la mejora de dichos procesos?

Clientes: Cmo sabemos que nuestros clientes,internos y externos, estn satisfechos?

Procesos funcionan a un nivel suficiente quesatisfaga a los clientes? Cumplen nuestros


8/99

procesos con las expectativas de los clientes?

Personas : Aqu es donde introducimos una de lasdiferencias respecto del BSC. Hemos aadido unaperspectiva ms; la de personas. Tienen nuestrosempleados las capacidades suficientes para realizar

su trabajo?, Son felices con lo que estn haciendoy donde lo estn haciendo?

Infraestructura e innovacin: Aqu, para lasorganizaciones de TI, queremos gestionar aspectosrelacionados con la mejora de procesos de software,la tecnologa y la infraestructura organizativa, por loque deberemos preguntarnos, estamos trabajandopara implantar un programa de mejora sostenible?Por programa de mejora sostenible entendemos unprograma de mejora continuo en el tiempo queapoya a la empresa para alcanzar sus objetivos denegocio, por lo que podremos medir el impacto deestas mejoras en el negocio y por lo tanto su ROI.

La metodologa BITS la componen principalmentetres elementos

El primero es el Modelo Genrico: consiste en unconjunto de objetivos genricos que una empresade TI podra querer alcanzar y un conjunto de

conductores para alcanzar estos objetivos, paracada una de las cinco perspectivas que hemos visto.Asociados a estos objetivos y conductores (ofactores crticos de xito) existe un conjunto deindicadores cuantitativos para realizar elseguimiento de los mismos.

El segundo componente es el Mtodo, que ofreceuna forma para desarrollar un CMI para unaempresa de modo que en la empresa exista unaalineacin entre las iniciativas de mejora de

procesos de software y los objetivos de negocio.

El tercer componente es el Material de Aplicacindel mtodo. Aqu podemos encontrar material deapoyo a la hora de aplicar el mtodo, como porejemplo plantillas que las empresas pueden utilizar,y que facilitan y aceleran el proceso de desarrollarun CMI para una empresa.

Tampoco sera posible la realimentacin Y no se podra certificar el proceso de desarrollo.

Normas de la documentacin


9/99

La documentacin (que refleja el proyecto) ha de estarligada a una norma .

Esta norma puede estar fijada por la organizacin o porun estndar

Una de las primeras tareas de la gestin es adaptar(tailoring) las normas a la naturaleza y dimensiones del

proyecto.

1.1.2 TAREAS, PLANES Y ACTIVIDADES

1.1.2.1 Tareas:

1.1.2.1.2 Planificar el proyecto

Fija objetivos, tiempos, recursos, normas, tcnicas, etc.(VER TEMA 2.1)

1.1.2.1.3 Controlar el proyecto

Se realizan seguimientos, anlisis, pruebas de loselementos antes indicados .

Se toman las acciones correctivas. Todo ello reflejado en los planes anteriores.

1.1.2.2 Planes :

Plan de desarrollo software (ANEXO 01)

Plan de configuracin software (ANEXO 02) Plan de calidad de software Plan de verificacin y validacin Plan de mantenimiento Plan de desarrollo del personal Plan de despliegue.

1.1.2.3 Actividades de control del proyecto:

Gestin de requisitos Establecimiento de plan de trabajo y Monitorizacin

progreso Gestin de la garanta de calidad de producto y de

proceso Gestin de la configuracin Gestin del cambio Gestin del riesgo Seleccin y formacin del personal Gestin de suministradores Medida y anlisis Informe y presentaciones

1.1.3 ROLES, JEFE/GESTOR Y ORGANIZACIN DEL EQUIPO DEDESARROLLO:CERRADO, ALEATORIO, ABIERTO, SINCRONIZADO


10/99

1.1.3.1 Roles asociados a las tareas

1.1.3.1.1 Roles mnimos

Jefe o gestor de proyecto. Resp. de configuracin. Resp. de calidad. Resp. de desarrollo.

1.1.3.1.2 Roles dependiendo de la aplicacin

Resp. de despliegue. Resp. de mantenimiento. Resp. de libreras. Resp. de la base de datos. Resp. de safety/seguridad.

1.1.3.2 Jefe/Gestor del proyecto software

Responsable de la gestin del proyecto Supervisa la adherencia de los procesos a los

estndares y normas fijados en el proyecto.

Responsable de la planificacin y programacin deeventos.

Controla el proyecto para mantenerlo dentro delos mrgenes de tiempo y presupuesto

1.1.3.3 Organizacin del equipos de desarrollo

Paradigma cerrado

Estructura jerrquica tradicional de autoridad(proyectos de los que hay un gran conocimientoprevio ).

Aleatorio

El equipo se estructura libremente en funcin de lainiciativa del personal. Funcionan bien en entornostecnolgicos muy innovadores pero chocan cuando hayque conseguir un rendimiento ordenado. No facilita laasuncin de responsabilidades.

Abierto

Conjuga los dos anteriores.Se incluyen muchas vas de comunicacin y toma dedecisiones consensuadas. Adecuados para la resolucinde problemas complejos pero no tienen tantorendimiento como el cerrado.


11/99

Sincronizado

Se divide el problema en partes disjuntas de formanatural, con una organizacin clara pero con pocacomunicacin entre ellas.

1.1.4 NORMAS, ESTNDARES Y HERRAMIENTAS

1.1.4.1 Normas y estndares

1.1.4.1.1 Planificacin

PSS-05 - ECSS-E-40A

1.1.4.1.2 Calidad

Iso 9001- CMM y CMMI - Capability Maturity ModelIntegration

1.1.4.1.3 Ciclo de vida

RUP - Rational Unified Process: Modelo de desarrollobasado en su diagrama de ballenas.

Las normas IEEE 1074 e ISO 12207-1 enfocan eltrmino de forma muy similar considerando una

actividad como un conjunto de tareas y una tarea comouna accin que transforman entradas en salidas.

1.1.4.2 Herramientas

1.1.4.2.1 Planificacin

REVIC y SOFTEST del USAAF

1.1.4.2.2 Control de la configuracin

La Gestin de Configuracin del Software (GCS) es unconjunto de actividades desarrolladas para gestionar loscambios a lo largo del ciclo de vida del software. Es unaactividad de garanta de calidad que se aplica en todaslas fases del proceso de ingeniera del software.

CVS o ClearQuest

1.1.4.2.3 Control del versiones [3]

Un sistema de control de versiones debe proporcionar: Mecanismo de almacenaje de los elementos que

deba gestionar (ej. archivos de texto, imgenes,documentacin...)


12/99

Posibilidad de realizar cambios sobre loselementos almacenados (ej. modificacionesparciales, aadir, borrar, renombrar o moverelementos)

Registro histrico de las acciones realizadas concada elemento o conjunto de elementos

(normalmente pudiendo volver o extraer unestado anterior del producto)Aunque no es estrictamente necesario, suele ser muytil la generacin de informes con los cambiosintroducidos entre dos versiones, informes de estado,marcado con nombre identificativo de la versin de unconjunto de ficheros, etctera.

CVS, Subversion, SourceSafe, ClearCase, Darcs, PlasticSCM, Git, Mercurial, etc.

1.1.4.2.4 Ciclo de vida

Rational Enterprise Edition , Rational SoDA, RationalSuite

1.2. PLANIFICACION

1.2.1 PLANIFICACIN: (MARCO DESARROLLO, COSTO, PLAN,RIESGOS), RELACIN CON REQUISITOS, QUE DEFINE(MARCO, PLANES, ACTIVIDADES).

1.2.1.1 Planificacin:

Marco de desarrollo del proyectoDefinicin a alto nivel de normas, estndares,herramientas, etc.

Costo del proyectoConsistir en analizar los productos y el tiempo yrecursos que en abstracto tiene su desarrollo

Plan de trabajo

Se realizan las asignaciones de personal, tiemposy recursos.

RiesgosGestin de riesgos

1.2.1.2 Funcin de los requisitos

Tiene que tener en cuenta los requisitos en sentidoamplio:

Los que provienen de los stakeholders (losinteresados).

Los que provienen del entorno de la propiaorganizacin.


13/99

1.2.1.3 Definiciones Definir un marco de referencia

Definir un plan (ANEXO 03)

Reflejado en un documento de planificacin Este es un documento necesariamente vivo por lo

que se han de plantear los recursos para ellos.

Actividades

1.2.2 MARCO GENERAL: ALCANCE, NORMAS, EQUIPO,CONTROL Y HERRAMIENTAS

1.2.2.1 Alcance Definicin de los objetivos y prioridades Definicin de los productos finales en alto nivel Definicin de Entregables

Entregables hardware Entregables software Entregables de documentacin

Definicin de lmites e interfases con otras empresas.

1.2.2.2 Normas y referencias: customizacin

Normas o estndares a emplear Adaptacin de dichas normas al presenteproyecto

Eleccin del Modelo de proceso de desarrollo Metodologas utilizadas

1.2.2.3 Organizacin del equipo Definicin de la Estructura organizativa A nivel de asignacin de los roles definidos en el

SQAP

Software Quality Assurance Plan o SQAP (esdecir, Plan de Garanta de Calidad de Software)es un documento que organiza el desarrollo delsoftware con el fin de que el proceso de creacinde este siga unas pautas que aseguren la calidaddel resultado. Este plan de garanta forma partede la Ingeniera de software. En este documentose organiza el equipo de personas, se elige elciclo de vida a seguir, se especifican losdocumentos que harn falta, las revisiones quese harn, las pruebas e incluso cmo realizar elmantenimiento. (ANEXO 04)


14/99

1.2.2.4 Mecanismos de monitorizacin y control

Mecanismos de control y seguimiento en funcinde lo definido en el SQAP

Establecimiento de reuniones de seguimiento deproyecto

Reuniones internas de seguimiento del proyecto. Reuniones de hitos. Definicin de informes de progreso Definicin del registro de comunicaciones Control de suministradores

1.2.3 ANLISIS DEL COSTE: TAREAS DE DESARROLLO(CSCI/CSC, ETIMACIN, AJUSTE, HISTORICO), NODESARROLLO, AJUSTE PRESUPUESTARIO

1.2.3.1 Descomposicin de las tareas no directamentede desarrollo

Documentacin Control Test Plan ms all del desarrollo

No siempre se contemplan, a veces se posponen Definicin de plan de despliegue

Definicin de las actividades de Mantenimiento Adquisicin y recepcin de recursos materiales

1.2.3.2 Descomposicin de las tareas de desarrollo

1.2.3.2.1 Definicin de Paquetes de Trabajo enCSCI/CSC (Computer Software ConfigurationItem/Computer Software Component)

Fuente para su definicin:

Los requisitos Las normas (que fijan productos concretos) Los mecanismos de control La discusin entre ellos.

1.2.3.2.2 Estimacin de horas/hombre porpaquete de trabajo

Para ello es necesario utilizar herramientasbasadas en modelos como COCOMO, COCOMO 2o REVIC

Como funciona REVIC:


15/99

Se introduce el conjunto de CSCI/CSC delproyecto

Se realiza una estimacin del nmero delneas de cdigo de cada componente,

normalmente se introduce una distribucinestadstica.

A continuacin se fijan unos parmetrosglobales del proyecto como:

Experiencia, criticidad,aerotransportado, etc.

El programa proporcionar una distribucinen valor medio (incluso varianza) .

1.2.4 PLAN DE TRABAJO: RECURSOS HUMANOS YMATERIALES, HITOS, ANLISIS, CAMINOS CRTICOS YTCNICAS

1.2.4.1 Recursos humanos

Organizar el equipo de trabajo en funcin de lanorma y en funcin del volumen del proyecto.

Asignar las horas/hombre al equipo de trabajo. Asignacin de Responsabilidades a cada uno delos paquetes. de trabajo.

Formacin.

1.2.4.2 Recursos materiales

Reparto de los existentes

Planes de adquisicin

1.2.4.3 Estudiar caminos crticos

1.2.4.3.1 Tecnicas

GANTT [4]

En gestin de proyectos, el diagrama de Ganttmuestra el origen y el final de las diferentesunidades mnimas de trabajo y los grupos detareas (llamados summary elements en laimagen) o las dependencias entre unidadesmnimas de trabajo (no mostradas en la imagen).Desde su introduccin los diagramas de Gantt sehan convertido en una herramienta bsica en la


16/99

gestin de proyectos de todo tipo, con la finalidadde representar las diferentes fases, tareas yactividades programadas como parte de unproyecto o para mostrar una lnea de tiempo enlas diferentes actividades haciendo el mtodoms eficiente.

PERT [5]

Una malla PERT permite planificar y controlar eldesarrollo de un proyecto. A diferencia de lasredes CPM, las redes PERT trabajan con tiemposprobabilsticos. Normalmente para desarrollar unproyecto especfico lo primero que se hace esdeterminar, en una reunin multidisciplinaria,cules son las actividades que se deber ejecutar

para llevar a feliz trmino el proyecto, cul es laprecedencia entre ellas y cul ser la duracinesperada de cada una.

II. METODOLOGA DE DESARROLLO DE SOFTWARE

2.1 METODOLOGA Y PROCESO DE DESARROLLO DE SOFTWARE

Un proceso de desarrollo de software tiene como propsito la

produccin eficaz y eficiente de un producto software que rena losrequisitos del cliente. Dicho proceso, en trminos globales se muestraen la Figura 2 [3]. Este proceso es intensamente intelectual, afectado


17/99

por la creatividad y juicio de las personas involucradas [4]. Aunque unproyecto de desarrollo de software es equiparable en muchos aspectosa cualquier otro proyecto de ingeniera, en el desarrollo de software hayuna serie de desafos adicionales, relativos esencialmente a lanaturaleza del producto obtenido. A continuacin se explican algunasparticularidades asociadas al desarrollo de software y que influyen en

su proceso de construccin.Un producto software en s es complejo, es prcticamente inviableconseguir un 100% de confiabilidad de un programa por pequeo quesea. Existe una inmensa combinacin de factores que impiden unaverificacin exhaustiva de las todas posibles situaciones de ejecucinque se puedan presentar (entradas, valores de variables, datosalmacenados, software del sistema, otras aplicaciones que intervienen,el hardware sobre el cual se ejecuta, etc.).

Un producto software es intangible y por lo general muy abstracto, estodificulta la definicin del producto y sus requisitos, sobre todo cuando

no se tiene precedentes en productos software similares. Esto hace quelos requisitos sean difciles de consolidar tempranamente. As, loscambios en los requisitos son inevitables, no slo despus deentregado en producto sino tambin durante el proceso de desarrollo.

Adems, de las dos anteriores, siempre puede sealarse la inmadurezde la ingeniera del software como disciplina, justificada por su cortavida comparada con otras disciplinas de la ingeniera. Sin embargo,esto no es ms que un intil consuelo.

Requisitos nuevoso modificados

Sistema nuevoo modificado

Proceso de Desarrollode Software

Requisitos nuevoso modificados

Sistema nuevoo modificado

Proceso de Desarrollode Software

Figura 1: proceso de desarrollo de software.

El proceso de desarrollo de software no es nico. No existe un procesode software universal que sea efectivo para todos los contextos deproyectos de desarrollo. Debido a esta diversidad, es difcil automatizartodo un proceso de desarrollo de software.A pesar de la variedad de propuestas de proceso de software, existe unconjunto de actividades fundamentales que se encuentran presentesen todos ellos [4]:

1. Especificacin de software: Se debe definir la funcionalidad yrestricciones operacionales que debe cumplir el software.

2. Diseo e Implementacin: Se disea y construye el softwarede acuerdo a la especificacin.

3. Validacin: El software debe validarse, para asegurar quecumpla con lo que quiere el cliente.

4. Evolucin: El software debe evolucionar, para adaptarse a las


18/99

necesidades del cliente.

Adems de estas actividades fundamentales, Pressman [1] mencionaun conjunto de actividades protectoras, que se aplican a lo largo detodo el proceso del software. Ellas se sealan a continuacin:

Seguimiento y control de proyecto de software.

Revisiones tcnicas formales. Garanta de calidad del software.

Gestin de configuracin del software.

Preparacin y produccin de documentos.

Gestin de reutilizacin.

Mediciones.

Gestin de riesgos.

Pressman [1] caracteriza un proceso de desarrollo de software como semuestra en la Figura 3. Los elementos involucrados se describen acontinuacin:

Un marco comn del proceso, definiendo un pequeo nmero deactividades del marco de trabajo que son aplicables a todos losproyectos de software, con independencia del tamao o complejidad.

Un conjunto de tareas, cada uno es una coleccin de tareas deingeniera del software, hitos de proyectos, entregas y productos detrabajo del software, y puntos de garanta de calidad, que permitenque las actividades del marco de trabajo se adapten a las

caractersticas del proyecto de software y los requisitos del equipodel proyecto.

Las actividades de proteccin, tales como garanta de calidad delsoftware, gestin de configuracin del software y medicin, abarcanel modelo del proceso. Las actividades de proteccin sonindependientes de cualquier actividad del marco de trabajo yaparecen durante todo el proceso.

Figura 2: Elementos del proceso del software

Otra perspectiva utilizada para determinar los elementos del proceso


19/99

de desarrollo de software es establecer las relaciones entre elementosque permitan responder Quin debe hacer Qu, Cundo y Cmodebe hacerlo [5].

Figura 3: Relacin entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollode software y sus relaciones. As las interrogantes se responden de lasiguiente forma:

Quin: Las Personas participantes en el proyecto de desarrollodesempeando uno o ms Roles especficos.

Qu: Un Artefacto1 es producido por un Rol en una de susActividades. Los Artefactos se especifican utilizando Notacionesespecficas. Las Herramientas apoyan la elaboracin de Artefactossoportando ciertas Notaciones.

Cmo y Cundo: Las Actividades son una serie de pasos que lleva acabo un Rol durante el proceso de desarrollo. El avance del proyectoest controlado mediante hitos que establecen un determinadoestado de terminacin de ciertos Artefactos.

La composicin y sincrona de las actividades est basada en unconjunto de Principios y Prcticas. Las Prcticas y Principios enfatizanciertas actividades y/o la forma como deben realizarse, por ejemplo:desarrollar iterativamente, gestionar requisitos, desarrollo basado encomponentes, modelar visualmente, verificar continuamente la calidad,gestionar los cambios, etc.

2.1.1. Modelos de proceso software

Sommerville [4] define modelo de proceso de software como Unarepresentacin simplificada de un proceso de software,

representada desde una perspectiva especfica. Por su naturaleza1 Un artefacto es una pieza de informacin que (1) es producida, modificada o usada por el proceso, (2) define un

rea de responsabilidad para un rol y (3) est sujeta a control de versiones. Un artefacto puede ser un modelo, unelemento de modelo o un documento.


20/99

los modelos son simplificados, por lo tanto un modelo de procesosdel software es una abstraccin de un proceso real.

Los modelos genricos no son descripciones definitivas de procesosde software; sin embargo, son abstracciones tiles que pueden serutilizadas para explicar diferentes enfoques del desarrollo desoftware.

Modelos que se van a discutir a continuacin:

Codificar y corregir

Modelo en cascada

Desarrollo evolutivo

Desarrollo formal de sistemas

Desarrollo basado en reutilizacin

Desarrollo incremental

Desarrollo en espiral

2.1.1.1. Codificar y corregir (Code-and-Fix)

Este es el modelo bsico utilizado en los inicios del desarrollode software. Contiene dos pasos:

Escribir cdigo.

Corregir problemas en el cdigo.

Se trata de primero implementar algo de cdigo y luego

pensar acerca de requisitos, diseo, validacin, ymantenimiento.

Este modelo tiene tres problemas principales [7]:

Despus de un nmero de correcciones, el cdigo puedetener una muy mala estructura, hace que los arreglos seanmuy costosos.

Frecuentemente, an el software bien diseado, no seajusta a las necesidades del usuario, por lo que esrechazado o su reconstruccin es muy cara.

El cdigo es difcil de reparar por su pobre preparacin paraprobar y modificar.

2.1.1.2. Modelo en cascada

El primer modelo de desarrollo de software que se public sederiv de otros procesos de ingeniera [8]. ste toma lasactividades fundamentales del proceso de especificacin,desarrollo, validacin y evolucin y las representa como fasesseparadas del proceso.

El modelo en cascada consta de las siguientes fases:

Definicin de los requisitos: Los servicios, restriccionesy objetivos son establecidos con los usuarios del


21/99

sistema. Se busca hacer esta definicin en detalle.

Diseo de software: Se particiona el sistema ensistemas de software o hardware. Se establece laarquitectura total del sistema. Se identifican ydescriben las abstracciones y relaciones de loscomponentes del sistema.

Implementacin y pruebas unitarias: Construccin delos mdulos y unidades de software. Se realizanpruebas de cada unidad.

Integracin y pruebas del sistema: Se integran todaslas unidades. Se prueban en conjunto. Se entrega elconjunto probado al cliente.

Operacin y mantenimiento: Generalmente es la fasems larga. El sistema es puesto en marcha y se realizala correccin de errores descubiertos. Se realizanmejoras de implementacin. Se identifican nuevosrequisitos.

La interaccin entre fases puede observarse en la Figura 5.Cada fase tiene como resultado documentos que deben seraprobados por el usuario.

Una fase no comienza hasta que termine la fase anterior ygeneralmente se incluye la correccin de los problemasencontrados en fases previas.

Figura 4: Modelo de desarrollo en cascada.

En la prctica, este modelo no es lineal, e involucra variasiteraciones e interaccin entre las distintas fases dedesarrollo. Algunos problemas que se observan en el modelode cascada son:

Las iteraciones son costosas e implican rehacer trabajodebido a la produccin y aprobacin de documentos.

Aunque son pocas iteraciones, es normal congelar parte deldesarrollo y continuar con las siguientes fases.

Los problemas se dejan para su posterior resolucin, lo que


22/99

lleva a que estos sean ignorados o corregidos de una formapoco elegante.

Existe una alta probabilidad de que el software no cumplacon los requisitos del usuario por el largo tiempo deentrega del producto.

Es inflexible a la hora de evolucionar para incorporarnuevos requisitos. Es difcil responder a cambios en losrequisitos.

Este modelo slo debe usarse si se entienden a plenitud losrequisitos. An se utiliza como parte de proyectos grandes.

2.1.1.3. Desarrollo evolutivo

La idea detrs de este modelo es el desarrollo de unaimplantacin del sistema inicial, exponerla a los comentariosdel usuario, refinarla en N versiones hasta que se desarrolleel sistema adecuado. En la Figura 6 se observa cmo lasactividades concurrentes: especificacin, desarrollo yvalidacin, se realizan durante el desarrollo de las versioneshasta llegar al producto final.

Una ventaja de este modelo es que se obtiene una rpidarealimentacin del usuario, ya que las actividades deespecificacin, desarrollo y pruebas se ejecutan en cadaiteracin.

Figura 5: Modelo de desarrollo evolutivo.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque esexplorar con el usuario los requisitos hasta llegar a unsistema final. El desarrollo comienza con las partes que setiene ms claras. El sistema evoluciona conforme seaaden nuevas caractersticas propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender losrequisitos del usuario y trabajar para mejorar la calidad de

los requisitos. A diferencia del desarrollo exploratorio, secomienza por definir los requisitos que no estn claros parael usuario y se utiliza un prototipo para experimentar conellos. El prototipo ayuda a terminar de definir estos


23/99

requisitos.

Entre los puntos favorables de este modelo estn:

La especificacin puede desarrollarse de forma creciente.

Los usuarios y desarrolladores logran un mejorentendimiento del sistema. Esto se refleja en una mejora

de la calidad del software. Es ms efectivo que el modelo de cascada, ya que cumple

con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniera y administracin seidentifican los siguientes problemas:

Proceso no Visible: Los administradores necesitan entregaspara medir el progreso. Si el sistema se necesita desarrollarrpido, no es efectivo producir documentos que reflejencada versin del sistema.

Sistemas pobremente estructurados: Los cambioscontinuos pueden ser perjudiciales para la estructura delsoftware haciendo costoso el mantenimiento.

Se requieren tcnicas y herramientas: Para el rpidodesarrollo se necesitan herramientas que pueden serincompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeos (menos de100.000 lneas de cdigo) o medianos (hasta 500.000 lneasde cdigo) con poco tiempo para su desarrollo y sin generar

documentacin para cada versin.Para proyectos largos es mejor combinar lo mejor del modelode cascada y evolutivo: se puede hacer un prototipo globaldel sistema y posteriormente reimplementarlo con unacercamiento ms estructurado. Los subsistemas conrequisitos bien definidos y estables se pueden programarutilizando cascada y la interfaz de usuario se puedeespecificar utilizando un enfoque exploratorio.

2.1.1.4. Desarrollo formal de sistemas

Este modelo se basa en transformaciones formales de losrequisitos hasta llegar a un programa ejecutable.

Figura 6: Paradigma de programacin automtica.

La Figura 7 (obtenida desde [20]) ilustra un paradigma idealde programacin automtica. Se distinguen dos fasesglobales: especificacin (incluyendo validacin) ytransformacin. Las caractersticas principales de esteparadigma son: la especificacin es formal y ejecutable

constituye el primer prototipo del sistema), la especificacines validada mediante prototipacin. Posteriormente, a travsde transformaciones formales la especificacin se convierte


24/99

en la implementacin del sistema, en el ltimo paso detransformacin se obtiene una implementacin en unlenguaje de programacin determinado. , el mantenimientose realiza sobre la especificacin (no sobre el cdigo fuente),la documentacin es generada automticamente y elmantenimiento es realizado por repeticin del proceso (no

mediante parches sobre la implementacin).Observaciones sobre el desarrollo formal de sistemas:

Permite demostrar la correccin del sistema durante elproceso de transformacin. As, las pruebas que verifican lacorrespondencia con la especificacin no son necesarias.

Es atractivo sobre todo para sistemas donde hay requisitosde seguridad y confiabilidad importantes.

Requiere desarrolladores especializados y experimentadosen este proceso para llevarse a cabo.

2.1.1.5. Desarrollo basado en reutilizacin

Como su nombre lo indica, es un modelo fuertementeorientado a la reutilizacin. Este modelo consta de 4 fasesilustradas en la Figura 9. A continuacin se describe cadafase:

1. Anlisis de componentes: Se determina qu componentespueden ser utilizados para el sistema en cuestin. Casisiempre hay que hacer ajustes para adecuarlos.

2. Modificacin de requisitos: Se adaptan (en lo posible) losrequisitos para concordar con los componentes de la etapaanterior. Si no se puede realizar modificaciones en losrequisitos, hay que seguir buscando componentes msadecuados (fase 1).

3. Diseo del sistema con reutilizacin: Se disea o reutiliza elmarco de trabajo para el sistema. Se debe tener en cuentalos componentes localizados en la fase 2 para disear odeterminar este marco.

4. Desarrollo e integracin: El software que no puede

comprarse, se desarrolla. Se integran los componentes ysubsistemas. La integracin es parte del desarrollo en lugarde una actividad separada.

Las ventajas de este modelo son:

Disminuye el costo y esfuerzo de desarrollo.

Reduce el tiempo de entrega.

Disminuye los riesgos durante el desarrollo.


25/99

Figura 7: Desarrollo basado en reutilizacin decomponentes

Desventajas de este modelo:

Los compromisos en los requisitos son inevitables,por lo cual puede que el software no cumpla lasexpectativas del cliente.

Las actualizaciones de los componentes adquiridos

no estn en manos de los desarrolladores delsistema.

2.1.2. Procesos iterativos

A continuacin se expondrn dos enfoques hbridos, especialmentediseados para el soporte de las iteraciones:

Desarrollo Incremental.

Desarrollo en Espiral.

2.1.2.1 Desarrollo incrementalMills [9] sugiri el enfoque incremental de desarrollo comouna forma de reducir la repeticin del trabajo en el procesode desarrollo y dar oportunidad de retrasar la toma dedecisiones en los requisitos hasta adquirir experiencia con elsistema (ver Figura 10). Es una combinacin del Modelo deCascada y Modelo Evolutivo.

Reduce el rehacer trabajo durante el proceso de desarrollo yda oportunidad para retrasar las decisiones hasta tenerexperiencia en el sistema.

Durante el desarrollo de cada incremento se puede utilizar elmodelo de cascada o evolutivo, dependiendo delconocimiento que se tenga sobre los requisitos aimplementar. Si se tiene un buen conocimiento, se puedeoptar por cascada, si es dudoso, evolutivo.


26/99

Figura 8: Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental seencuentran:

Los clientes no esperan hasta el fin del desarrollo parautilizar el sistema. Pueden empezar a usarlo desde elprimer incremento.

Los clientes pueden aclarar los requisitos que no tenganclaros conforme ven las entregas del sistema.

Se disminuye el riesgo de fracaso de todo el proyecto, yaque se puede distribuir en cada incremento.

Las partes ms importantes del sistema son entregadasprimero, por lo cual se realizan ms pruebas en estosmdulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modeloson:

Cada incremento debe ser pequeo para limitar el riesgo(menos de 20.000 lneas).

Cada incremento debe aumentar la funcionalidad.

Es difcil establecer las correspondencias de los requisitoscontra los incrementos.

Es difcil detectar las unidades o servicios genricos paratodo el sistema.

2.1.2.2 Desarrollo en espiral

El modelo de desarrollo en espiral (ver Figura 11) esactualmente uno de los ms conocidos y fue propuesto porBoehm [7]. El ciclo de desarrollo se representa como unaespiral, en lugar de una serie de actividades sucesivas conretrospectiva de una actividad a otra.

Cada ciclo de desarrollo se divide en cuatro fases:

1. Definicin de objetivos: Se definen los objetivos. Se definenlas restricciones del proceso y del producto. Se realiza undiseo detallado del plan administrativo. Se identifican losriesgos y se elaboran estrategias alternativas dependiendode estos.

2. Evaluacin y reduccin de riesgos: Se realiza un anlisis


27/99

detallado de cada riesgo identificado. Pueden desarrollarseprototipos para disminuir el riesgo de requisitos dudosos.Se llevan a cabo los pasos para reducir los riesgos.

3. Desarrollo y validacin: Se escoge el modelo de desarrollodespus de la evaluacin del riesgo. El modelo que seutilizar (cascada, sistemas formales, evolutivo, etc.)depende del riesgo identificado para esa fase.

4. Planificacin: Se determina si continuar con otro ciclo. Seplanea la siguiente fase del proyecto.

Este modelo a diferencia de los otros toma en consideracinexplcitamente el riesgo, esta es una actividad importante enla administracin del proyecto.

El ciclo de vida inicia con la definicin de los objetivos. Deacuerdo a las restricciones se determinan distintas

alternativas. Se identifican los riesgos al sopesar los objetivoscontra las alternativas. Se evalan los riesgos con actividadescomo anlisis detallado, simulacin, prototipos, etc. Sedesarrolla un poco el sistema. Se planifica la siguiente fase.

Figura 9: Modelo de desarrollo en Espiral

2.2. Cul es el modelo de proceso ms adecuado?

Cada proyecto de software requiere de una forma de particular deabordar el problema. Las propuestas comerciales y acadmicasactuales promueven procesos iterativos, donde en cada iteracin puedeutilizarse uno u otro modelo de proceso, considerando un conjunto decriterios (Por ejemplo: grado de definicin de requisitos, tamao delproyecto, riesgos identificados, entre otros).

En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunoscriterios bsicos para la seleccin de un modelo de proceso [10], lamedida utilizada indica el nivel de efectividad del modelo de proceso deacuerdo al criterio (Por ejemplo: El modelo Cascada responde con unnivel de efectividad Bajo cuando los Requisitos y arquitectura no estn


28/99

predefinidos ):


29/99

Modelo deproceso

Funcionaconrequisitos yarquitecturanopredefinido

s

Producesoftwarealtamentefiable

Gestinderiesgos

Permitecorreccionessobrelamarcha

Visindel

progresoporelClienteyelJefe

delproyecto

Codificar ycorregir

Bajo Bajo Bajo AltoMedio

Cascada Bajo Alto Bajo Bajo Bajo

Evolutivoexploratorio

Medio oAlto

Medioo Alto

Medio

Medio oAlto

MediooAlto

Evolutivoproto

tipado

Alto MedioMedio Alto

Alto

Desarrolloformal desistemas

Bajo Alto

BajoaMedio

Bajo Bajo


30/99

Desarrolloorientadoareutilizaci

n

Medio

Bajo aAlto

BajoaMedio

AltoAlto

Incremental

Bajo AltoMedio

BajoBa

jo

Espiral

Alto Alto Alto MedioMedio

Tabla 1: Comparacin entre modelos de proceso de software.

2.3. Metodologas para desarrollo de software

Un proceso de software detallado y completo suele denominarseMetodologa. Las metodologas se basan en una combinacin de losmodelos de proceso genricos (cascada, evolutivo, incremental, etc.).Adicionalmente una metodologa debera definir con precisin losartefactos, roles y actividades involucrados, junto con prcticas ytcnicas recomendadas, guas de adaptacin de la metodologa alproyecto, guas para uso de herramientas de apoyo, etc. Habitualmentese utiliza el trmino mtodo para referirse a tcnicas, notaciones y

guas asociadas, que son aplicables a una (o algunas) actividades delproceso de desarrollo, por ejemplo, suele hablarse de mtodos deanlisis y/o diseo.

La comparacin y/o clasificacin de metodologas no es una tareasencilla debido a la diversidad de propuestas y diferencias en el gradode detalle, informacin disponible y alcance de cada una de ellas. Agrandes rasgos, si tomamos como criterio las notaciones utilizadas paraespecificar artefactos producidos en actividades de anlisis y diseo,podemos clasificar las metodologas en dos grupos: MetodologasEstructuradas y Metodologas Orientadas a Objetos. Por otra parte,considerando su filosofa de desarrollo, aquellas metodologas conmayor nfasis en la planificacin y control del proyecto, enespecificacin precisa de requisitos y modelado, reciben el apelativo deMetodologas Tradicionales (o peyorativamente denominadaMetodologas Pesadas, o Peso Pesado). Otras metodologas,denominadas Metodologas giles, estn ms orientadas a lageneracin de cdigo con ciclos muy cortos de desarrollo, se dirigen aequipos de desarrollo pequeos, hacen especial hincapi en aspectoshumanos asociados al trabajo en equipo e involucran activamente alcliente en el proceso. A continuacin se revisan brevemente cada unade estas categoras de metodologas.

2.3.1. Metodologas estructuradas

Los mtodos estructurados comenzaron a desarrollarse a


31/99

fines de los 70s con la Programacin Estructurada, luego amediados de los 70s aparecieron tcnicas para el Diseo (porejemplo: el diagrama de Estructura) primero y posteriormentepara el Anlisis (por ejemplo: Diagramas de Flujo de Datos).Estas metodologas son particularmente apropiadas enproyectos que utilizan para la implementacin lenguajes de

3ra y 4ta generacin.Ejemplos de metodologas estructuradas de mbitogubernamental: MERISE2 (Francia), MTRICA3 (Espaa),SSADM4 (Reino Unido). Ejemplos de propuestas de mtodosestructurados en el mbito acadmico: Gane & Sarson5, Ward& Mellor6, Yourdon & DeMarco7 e Information Engineering8.

2.3.2. Metodologas orientadas a objetos

Su historia va unida a la evolucin de los lenguajes deprogramacin orientada a objeto, los ms representativos: afines de los 60s SIMULA, a fines de los 70s Smalltalk-80, laprimera versin de C++ por Bjarne Stroustrup en 1981 yactualmente Java9 o C# de Microsoft. A fines de los 80scomenzaron a consolidarse algunos mtodos Orientadas aObjeto.

En 1995 Booch y Rumbaugh proponen el Mtodo Unificadocon la ambiciosa idea de conseguir una unificacin de susmtodos y notaciones, que posteriormente se reorienta a unobjetivo ms modesto, para dar lugar al Unified ModelingLanguage (UML)10, la notacin OO ms popular en laactualidad.Algunos mtodos OO con notaciones predecesoras de UMLson: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler& Mellor y OMT (Rumbaugh).

Algunas metodologas orientadas a objetos que utilizan lanotacin UML son: Rational Unified Process (RUP)11, OPEN12,MTRICA (que tambin soporta la notacin estructurada).

2.3.3. Metodologas tradicionales (no giles)

Las metodologas no giles son aquellas que estn guiadaspor una fuerte planificacin durante todo el proceso dedesarrollo; llamadas tambin metodologas tradicionales o

2 http://perso.club-internet.fr/brouardf/SGBDRmerise.htm(7.5.2002)3 http://www.map.es/csi/metrica3/(7.5.2003)4 http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003)5 http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc(29.8.2003)6 http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003)7 http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco(29.8.2003)8 http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html

(29.8.2003)9 http://java.sun.com/ (7.5.2003)10 http://www.uml.org/(7.5.2003)11 http://www.rational.com/products/rup/index.jsp (7.5.2003)12 http://www.open.org.au/ (17.9.2003)
http://perso.club-internet.fr/brouardf/SGBDRmerise.htmhttp://www.map.es/csi/metrica3/http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.htmlhttp://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.dochttp://www.yourdon.com/books/coolbooks/notes/wardmellor.htmlhttp://www.yourdon.com/books/coolbooks/notes/wardmellor.htmlhttp://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarcohttp://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarcohttp://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.htmlhttp://java.sun.com/http://www.uml.org/http://www.uml.org/http://www.rational.com/products/rup/index.jsphttp://www.open.org.au/http://perso.club-internet.fr/brouardf/SGBDRmerise.htmhttp://perso.club-internet.fr/brouardf/SGBDRmerise.htmhttp://www.map.es/csi/metrica3/http://www.map.es/csi/metrica3/http://www.map.es/csi/metrica3/http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.htmlhttp://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.htmlhttp://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.htmlhttp://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.dochttp://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.dochttp://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.dochttp://www.yourdon.com/books/coolbooks/notes/wardmellor.htmlhttp://www.yourdon.com/books/coolbooks/notes/wardmellor.htmlhttp://www.yourdon.com/books/coolbooks/notes/wardmellor.htmlhttp://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarcohttp://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarcohttp://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarcohttp://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.htmlhttp://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.htmlhttp://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.htmlhttp://java.sun.com/http://java.sun.com/http://java.sun.com/http://www.uml.org/http://www.uml.org/http://www.uml.org/http://www.rational.com/products/rup/index.jsphttp://www.rational.com/products/rup/index.jsphttp://www.rational.com/products/rup/index.jsphttp://www.open.org.au/http://www.open.org.au/http://www.open.org.au/http://perso.club-internet.fr/brouardf/SGBDRmerise.htm


32/99

clsicas, donde se realiza una intensa etapa de anlisis ydiseo antes de la construccin del sistema.

Todas las propuestas metodolgicas antes indicadas puedenconsiderarse como metodologas tradicionales. Aunque en elcaso particular de RUP, por el especial nfasis que presentaen cuanto a su adaptacin a las condiciones del proyecto(mediante su configuracin previa a aplicarse), realizandouna configuracin adecuada, podra considerarse gil.

2.3.4. Metodologas giles

Un proceso es gil cuando el desarrollo de software esincremental (entregas pequeas de software, con ciclosrpidos), cooperativo (cliente y desarrolladores trabajan

juntos constantemente con una cercana comunicacin),sencillo (el mtodo en s mismo es fcil de aprender ymodificar, bien documentado), y adaptable (permite realizarcambios de ltimo momento) [11].

Entre las metodologas giles identificadas en [11]:

Extreme Programming [6].

Scrum ([12], [13]).

Familia de Metodologas Crystal [14].

Feature Driven Development [15].

Proceso Unificado Rational, unaconfiguracin gil ([16]).

Dynamic Systems Development Method[17].

Adaptive Software Development [18].

Open Source Software Development [19].

2.3.4.1. Programacin extrema

La programacin extrema se diferencia de lasmetodologas tradicionales principalmente en que pone

ms nfasis en la adaptabilidad que en la previsibilidad.Los defensores de XP consideran que los cambios derequisitos sobre la marcha son un aspecto natural,inevitable e incluso deseable del desarrollo deproyectos. Creen que ser capaz de adaptarse a loscambios de requisitos en cualquier punto de la vida delproyecto es una aproximacin mejor y ms realista queintentar definir todos los requisitos al comienzo delproyecto e invertir esfuerzos despus en controlar loscambios en los requisitos.


33/99

Caractersticas13

Desarrollo iterativo e incremental

Pruebas unitarias continuas

Programacin en parejas

integracin del equipo de programacin con elcliente

Correccin de todos los errores

Refactorizacin del cdigo

Propiedad del cdigo compartida

Simplicidad en el cdigo

2.3.4.2. Scrum

Scrum es un proceso de desarrollo de software iterativoe incremental utilizado comnmente en entornosbasado en la metodologa Agile de desarrollo desoftware.

Scrum es un proceso marco que incluye un conjunto deprcticas y roles predefinidos. Los roles principales enScrum son el ScrumMaster, que mantiene los procesosy trabaja de forma similar al director de proyecto, elProductOwner, que representa a los stakeholders(clientes externos o internos), y el Team que incluye a

los desarrolladores.Durante cada sprint, un periodo entre 15 y 30 das (lalongitud es definida por el equipo), el equipo crea unincremento de software potencialmente entregable(utilizable). El conjunto de caractersticas que formaparte de cada sprint viene del product backlog, que esun conjunto de requisitos de alto nivel priorizados quedan forma al trabajo a realizar. Los elementos delbacklog que forman parte del sprint se determinandurante la reunin de sprint planning. Durante esta

reunin, el Product Owner informa al equipo de loselementos en el product backlog que quiere vercompletados. El equipo entonces determina la cantidadde ese trabajo que puede comprometerse a completardurante el siguiente sprint.[4] Durante el sprint, nadiepuede cambiar el sprint backlog, lo que significa que losrequisitos estn congelados durante el sprint.

Existen varias implementaciones de sistemas paragestionar el proceso de Scrum, que van desde notasamarillas "post-it" y pizarras hasta paquetes de

software. Una de las mayores ventajas de Scrum es quees muy fcil de aprender, y requiere muy poco esfuerzo

13 http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema
http://es.wikipedia.org/wiki/Programaci?n_Extremahttp://es.wikipedia.org/wiki/Programaci?n_Extremahttp://es.wikipedia.org/wiki/Programaci?n_Extremahttp://es.wikipedia.org/wiki/Programaci?n_Extrema


34/99

para comenzarse a utilizar.

2.3.4.3. Proceso Unificado de Rational

Es un proceso de desarrollo de software y junto con elLenguaje Unificado de Modelado UML, constituye la

metodologa estndar ms utilizada para el anlisis,implementacin y documentacin de sistemasorientados a objetos.

El RUP no es un sistema con pasos firmementeestablecidos, sino un conjunto de metodologasadaptables al contexto y necesidades de cadaorganizacin.

Tambin se conoce por este nombre al softwaredesarrollado por Rational, hoy propiedad de IBM, el cualincluye informacin entrelazada de diversos artefactos

y descripciones de las diversas actividades. Estincluido en el Rational Method Composer (RMC), quepermite la personalizacin de acuerdo a necesidades.

2.3.4.4. Mtrica V314

La metodologa MTRICA Versin 3 ofrece a lasOrganizaciones un instrumento til para lasistematizacin de las actividades que dan soporte alciclo de vida del software dentro del marco que permitealcanzar los siguientes objetivos:

Proporcionar o definir Sistemas de Informacinque ayuden a conseguir los fines de laOrganizacin mediante la definicin de un marcoestratgico para el desarrollo de los mismos.

Dotar a la Organizacin de productos softwareque satisfagan las necesidades de los usuariosdando una mayor importancia al anlisis derequisitos.

Mejorar la productividad de los departamentos de

Sistemas y Tecnologas de la Informacin y lasComunicaciones, permitiendo una mayorcapacidad de adaptacin a los cambios yteniendo en cuenta la reutilizacin en la medidade lo posible.

Facilitar la comunicacin y entendimiento entrelos distintos participantes en la produccin desoftware a lo largo del ciclo de vida del proyecto,teniendo en cuenta su papel y responsabilidad,as como las necesidades de todos y cada uno de

ellos.

14 http://www.csi.map.es/csi/metrica3/introduccion.pdf
http://www.csi.map.es/csi/metrica3/introduccion.pdfhttp://www.csi.map.es/csi/metrica3/introduccion.pdfhttp://www.csi.map.es/csi/metrica3/introduccion.pdfhttp://www.csi.map.es/csi/metrica3/introduccion.pdf


35/99

Facilitar la operacin, mantenimiento y uso de losproductos software obtenidos.

Los procesos de la estructura principal de MTRICAVersin 3 son los siguientes:

PLANIFICACIN DE SISTEMAS DE INFORMACIN.

DESARROLLO DE SISTEMAS DE INFORMACIN.

MANTENIMIENTO DE SISTEMAS DE INFORMACIN.

Y define el proceso de desarrollo de sistemas deinformacin en:

ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).

ANLISIS DEL SISTEMA DE INFORMACIN (ASI).

DISEO DEL SISTEMA DE INFORMACIN (DSI).

CONSTRUCCIN DEL SISTEMA DE INFORMACIN(CSI).

IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS).

2.3.4.5. Open Source Development Software15

Open Source es software desarrollado con la falta decoordinacin, donde los programadores que colaboranlibremente, utilizando libremente el cdigo fuentedistribuido y la infraestructura de comunicaciones de

Internet. El cdigo abierto se basa en la filosofa delsoftware libre. Sin embargo, el cdigo abierto extiendeesta ideologa ligeramente para presentar un enfoquems comercial que incluye tanto un modelo de negocioy metodologa de desarrollo.

La catedral y el bazar es la descripcin citada conmayor frecuencia al ser relacionada como una dedesarrollo, sin embargo, aunque el documento seidentifican muchos de los mecanismos de xito dedesarrollo de cdigo abierto, no exponer la dinmica.

Existen crticas sobre ciertos aspectos que siguensiendo ambiguas, lo que sugiere que el documento nodescribe el proceso de desarrollo de cdigo abierto.

15 http://chinese-school.netfirms.com/computer-article-open-source.html
http://chinese-school.netfirms.com/computer-article-open-source.htmlhttp://chinese-school.netfirms.com/computer-article-open-source.htmlhttp://chinese-school.netfirms.com/computer-article-open-source.htmlhttp://chinese-school.netfirms.com/computer-article-open-source.html


36/99

III. METODOLOGAS DE CONTROL DE CALIDAD DEL SOTWARE

La obtencin de un software con calidad implica la utilizacin de metodologas oprocedimientos estndares para el anlisis, diseo, programacin y prueba del software quepermitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad,mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de

desarrollo como para el control de la calidad del software.La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico,administrativo y ergonmico.

El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo delsoftware.

El principio administrativo contempla las funciones de planificacin y control deldesarrollo del software, as como la organizacin del ambiente o centro de ingeniera desoftware.

El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado.

La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software,

pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin.

3.1.Como controlar la calidad del software?

Para controlar la calidad del software es necesario, ante todo, definir los parmetros,indicadores o criterios de medicin, ya que, como bien plantea Tom De Marco, ustedno puede controlar lo que no se puede medir. Las cualidades para medir la calidad delsoftware son definidas por innumerables autores, los cuales las denominan y agrupande formas diferentes. Por ejemplo, John Wiley define mtricas de calidad y criterios,donde cada mtrica se obtiene a partir de combinaciones de los diferentes criterios. LaMetodologa para la evaluacin de la calidad de los medios de programas de la CIC, deRusia, define indicadores de calidad estructurados en cuatro niveles jerrquicos: factor,criterio, mtrica, elemento de evaluacin, donde cada nivel inferior contiene losindicadores que conforman el nivel precedente. Otros autores identifican la calidad conel nivel de complejidad del software y definen dos categoras de mtricas: decomplejidad de programa o cdigo, y de complejidad de sistema o estructura.

Todos los autores coinciden en que el software posee determinados ndices mediblesque son las bases para la calidad, el control y el perfeccionamiento de la productividad.

Una vez seleccionados los ndices de calidad, se debe establecer el proceso de control,que requiere los siguientes pasos:

Definir el software que va a ser controlado: clasificacin por tipo, esfera deaplicacin, complejidad, etc., de acuerdo con los estndares establecidos parael desarrollo del software.

Seleccionar una medida que pueda ser aplicada al objeto de control. Para cadaclase de software es necesario definir los indicadores y sus magnitudes.


37/99

Crear o determinar los mtodos de valoracin de los indicadores: mtodosmanuales como cuestionarios o encuestas estndares para la medicin decriterios periciales y herramientas automatizadas para medir los criterios declculo.

Definir las regulaciones organizativas para realizar el control: quines participanen el control de la calidad, cundo se realiza, qu documentos deben serrevisados y elaborados, etc.

3.2.La gestin de la calidad

Gestin de la calidad: "Aspectos de la funcin de gestin que determinan y aplican lapoltica de la calidad, los objetivos y las responsabilidades y que lo realiza con mediostales como la planificacin de la calidad, el control de la calidad, la garanta de calidad yla mejora de la calidad".

Dentro de la gestin de la calidad se observa:

Gestin de la calidad de software (ISO 9000): Conjunto de actividades de lafuncin general de la direccin que determina la calidad, los objetivos y lasresponsabilidades y se implanta por medios tales como la planificacin de lacalidad, el control de la calidad, el aseguramiento (garanta) de la calidad y lamejora de la calidad, en el marco del sistema de calidad

Poltica de calidad (ISO 9000): Directrices y objetivos generales de una

organizacin, relativos a la calidad, tal como se expresan formalmente por laalta direccin.

La gestin de la calidad se aplica normalmente a nivel de empresa. Tambin puedehaber una gestin de calidad dentro de la gestin de cada proyecto.

3.3.El aseguramiento de la calidad

Ante todo se debe conocer:

Aseguramiento de la calidad: "Conjunto de acciones planificadas ysistemticas necesarias para proporcionar la confianza adecuada de que unproducto o servicio satisfar los requerimientos dados sobre calidad".

Aseguramiento de la calidad de software: Conjunto de actividadesplanificadas y sistemticas necesarias para aportar la confianza en que elproducto (software) satisfar los requisitos dados de calidad.


38/99

El aseguramiento de calidad del software se disea para cada aplicacin antes decomenzar a desarrollarla. Hay quienes prefieren decir garanta de calidad en vez deaseguramiento.

La garanta, puede confundir con garanta de productos, mientras que el aseguramientopretende dar confianza en que el producto tiene calidad.

El aseguramiento de calidad del software est presente en:

Mtodos y herramientas de anlisis, diseo, programacin y prueba.

Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo delsoftware.

Estrategias de prueba multiescala. Control de la documentacin del software y de los cambios realizados.

Procedimientos para ajustarse a los estndares (y dejar claro cuando se estfuera de ellos).

Mecanismos de medida (mtricas). Registro de auditorias y realizacin de informes.

Las actividades para el aseguramiento de calidad del software se detallan en:

Mtricas de software para el control del proyecto. Verificacin y validacin del software a lo largo del ciclo de vida (Incluye las

pruebas y los procesos de revisin e inspeccin).

La gestin de la configuracin del software.

Algunos mtodos del aseguramiento:

Revisiones tcnicas y de gestin (su objetivo es la evaluacin).

Inspeccin (su objetivo es la verificacin).Estamos construyendo el productocorrecto?.

Pruebas (su objetivo es la validacin). Estamos construyendo el productocorrectamente?.

Auditorias (su objetivo es la confirmacin del cumplimiento).

3.4.El control de la calidad

Se debe conocer:

Control de calidad: "Conjunto de tcnicas y actividades de carcter operativo,utilizadas para verificar los requerimientos relativos a la calidad del producto oservicio".

Control de la calidad del software: Tcnicas y actividades de carcteroperativo, utilizadas para verificar los requisitos relativos a la calidad, centradasen mantener bajo control el proceso de desarrollo y eliminar las causas de los

defectos en las diferentes fases del ciclo de vida.El control de la calidad del software est centrado en dos objetivos fundamentales:

Mantener bajo control un proceso. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

En general, se puede decir que el control de de la calidad del software son lasactividades para evaluar la calidad de los productos desarrollados.

Las estrategias de trabajo se representan como sigue:


39/99

3.5.Modelos de calidad de software

1. CMM

El Modelo de Madurez de Capacidades (CMM) es un modelo de referenciapara la aplicacin de conceptos de gestin de procesos y de mejora de calidaden el desarrollo y mantenimiento de software, que deben ser implementadaspor toda organizacin interesada en desarrollar y mejorar la calidad de susproductos y su productividad.

Este modelo est basado en conceptos de calidad total y de mejoramientocontinuo y ha sido desarrollado en el SEI (Software Engineering Institute)relacionado con Carnegie Mellon University, en Pittsburgh.El CMM se desarroll como reaccin a la crisis del software a principios de losochenta y financiado por el Departamento de Defensa de los Estados Unidos.

Se entiende por proceso el saber como utilizar el conocimiento del personal y latecnologa de forma eficiente para lograr productos que alta calidad quesatisfagan las necesidades de los clientes, producidos dentro de costos y plazosaceptables.

Un proceso puede considerarse maduro si cumple con los siguientes criterios:

Est definido: El proceso es claro, sistemtico y suficientementedetallado. Adems existe acuerdo entre el personal, la gerencia y losproyectos respecto al proceso que se va a utilizar.

Esta documentado: Esta escrito en un procedimiento publicado,aprobado y fcilmente accesible.

El personal ha sido entrenado en el proceso: Los ingenieros de softwarey la gerencia han recibido cursos y entrenamiento en cada proceso queaplica a su trabajo

Es practicado: El proceso definido debe ser usado en las tareashabituales llevadas a cabo por los proyectos. El entrenamiento y laadaptacin del proceso a la realidad de la empresa debieran garantizarsu aplicacin en la vida real.

Es mantenido: El proceso es revisado regularmente, para asegurarseque est adaptado para satisfacer las necesidades reales de losproyectos.


40/99

Est controlado: Los cambios y puestas al da del proceso sonrevisados, aprobados y comunicados oportunamente a todos losusuarios.

Se verifica: La gerencia mantiene mecanismos para asegurarse de quetodos los proyectos siguen el proceso vigente.

Se valida: Se asegura que el proceso mantiene concordancia con losrequerimientos y estndares aplicables.

Se mide: La utilizacin, los beneficios y el rendimiento resultante delproceso se miden regularmente.

Puede mejorarse: Existen mecanismos y apoyo de la gerencia pararevisar e introducir cambios en el proceso, de manera que se puedamejorar su eficacia e incorporar nuevas metodologas.

El CMM se basa principalmente es dos conceptos importantes, el concepto deproceso maduro, definido anteriormente y el concepto de nivel de madurezque

es definido como la capacidad de los procesos de ingeniera de software y deadministracin de proyectos usados en una organizacin de desarrollo desoftware y entendindose por maduro el definido anteriormente como proceso.

1. Niveles de Madurez de CMM

El CMM identifica los niveles de madurez de los procesos siguientes:

As es como el modelo CMM mide el progreso conforme avanza, enniveles de madurez. Cada nivel tiene un cierto nmero de reas deproceso importantes que deben lograrse. Su logro se detecta mediantela satisfaccin (o no) de varios metas claras y cuantificables.

Con excepcin del Nivel 1, cada uno de estos Niveles de Madurez estcompuesto por un cierto nmero de reas Claves de Proceso,

conocidas a travs de la documentacin del CMM por su sigla inglesa:KPA. Cada KPA identifica una agrupacin de actividades y prcticasrelacionadas, las cuales cuando son realizadas en forma colectivapermiten lograr alcanzar las metas fundamentales del proceso. Las


41/99

KPAs pueden clasificarse en 3 tipos de proceso: Gestin,Organizacional e Ingeniera.

Las prcticas que deben ser realizadas por cada Area Clave de Procesoestn organizadas en 5 Caractersticas Comunes, las cualesconstituyen propiedades que indican si la implementatcin y lainstitucionalizacin de un proceso clave es efectivo, repetible y duradero.

Estas 5 caractersticas son:

Compromiso de la realizacin. La capacidad de realizacin. Las actividades realizadas Las mediciones y el anlisis La verificacin de la implementacin.

El modelo CMM se formula de una manera genrica. Es independientede cualquier mtodo (o metodologa) y de cualquier ambiente detecnologa (software o hardware).

Los mtodos especficos usados por una compaa o agencia noimpone restricciones especficas en la utilizacin del SW-CMM, debido aque sus prcticas se formulan de forma general para que puedafcilmente adaptarse de manera de satisfacer las necesidades deambientes particulares.

Este modelo debe interpretarse de acuerdo al tamao de las compaaso agencias, pero es aplicable en el contexto global. Cualquier entidadque desarrolla o mantiene software, independientemente de su tamaose beneficiar mejorando su proceso de software aplicando el CMM.

Uno de los mtodos de evaluacin basados en el modelo CMM para el

mejoramiento interno de procesos, generalmente conocido como CBA-IPI ("CMM -Based Appraisal for Internal Process Improvement"): suprincipal objetivo es permitir a la empresa la determinacin de suspuntos fuertes y necesidades de mejoramiento, tambin permite revisarlas prcticas de los proveedores externos, a objeto de que puedanderivar un plan de mejoramiento adecuado a su organizacin.

1. Nivel 1: Nivel Inicial

Nivel de Inmadurez

Es el estado inicial de las empresas que desarrollan software. En estenivel se encuentran todas las empresas que no han logrado implementarlas prcticas bsicas de gestin de proyectos e ingeniera de softwaredefinidas a partir del nivel 2 o superiores. Una empresa est en el nivelcatico cuando sus gerentes y personal afirmen que los proyectos no sepueden planear, que los requerimientos no se pueden tener bajo control,que no est siempre en condiciones de controlar las versiones deproducto, donde la calidad sea percibida como una burocraciainnecesaria, cuando se acepte que los procesos son una cosa personal,cuando no se pueda verificar ni validar el producto, y sobre todo, cuandosus gerentes y personal vivan bajo condiciones de stress y frustracin

permanentes.La gerencia ocupa una parte significativa de su tiempo en paliarproblemas y enfrentar clientes insatisfechos. Ante una situacin de crisispermanente, se les hace difcil destinar recursos para definir o


42/99

documentar procesos, lo que lleva a un crculo sin salida.

Cuando el proyecto se termina, la inversin hecha en desarrollar elproceso es raramente reutilizada en nuevos proyectos. Losdesarrolladores de software generalmente tienen que trabajar largashoras y paliar problemas en forma cotidiana, lo cual les disminuye sucreatividad y productividad netas.

2. Nivel 2: Nivel Repetible

El proyecto planificado

El nivel 2 o Repetible hace posible la implementacin de prcticasmnimas de administracin de proyecto, de control de requerimientos,versiones de producto y de proyectos realizados por subcontratistas. Elgrupo o equipo humano que realiz el proyecto puede aprovechar suexperiencia e inversin en procesos para aplicarla en un nuevo

proyecto.Este nivel no garantiza que todos los proyectos dentro de la empresaestn necesariamente al mismo nivel de madurez. Algunos pueden estartodava en el nivel inicial. Luciano Guerrero [1], en cuya pgina hemosbasado gran parte del trabajo ha visto algunos casos en la prctica y entodos ellos estos proyectos fueron ineficientes con respecto a los demayor madurez, malgastando el xito de estos ltimos. Eventualmentealgunos invertieron los esfuerzos necesarios para ponerse a tono, otrossimplemente fueron cerrados con un elevado costo de frustracin ydescalabro de carreras profesionales.

Beneficios de implantar el Nivel 2

El mayor beneficio obtenido de la implementacin del nivel 2 por laempresa en la cual se encuentra actualmente [1], es la planificacinrealista de los proyectos. Antes los cronogramas de proyectoexpresaban ms los deseos de la gerencia que la realidad. Esteprincipio (el mismo en la cual se basa la magia) conduca una situacinde buscar culpables y generar excusas, produciendo al mismo tiempofrustracin y desconfianza entre clientes y empleados actualmente en laempresa, los cronogramas son cada da ms confiables, y mejora amedida que se acumula ms informacin en las bases de datos de losproyectos pasados. El uso generalizado de mtodos de estimacinpermite al personal del proyecto de justificar plazos y recursos. An el"olfato profesional" y la experiencia personal juegan un papel importanteen la generacin de planes de proyecto, pero ahora son decisionesinformadas en vez de simples adivinanzas como en el pasado.

Los pasos siguientes

Este nivel todava permite la proliferacin y definicin insuficiente de losprocesos de ingeniera de software. Los proyectos compartenprincipalmente sus experiencias en materia de administracin deproyectos, pero sus mtodos tcnicos pueden diferir. An existeincomunicacin entre proyectos, grupos y entre personal y gerencia.

Este nivel identifica prcticas de sentido comn que son aplicables en

todo tipo de organizaciones de desarrollo de software,independientemente de su rubro, tamao o ambiente de desarrollo. Laausencia de cualquiera de sus prcticas simplemente pone en peligro elxito de la empresa.


43/99

KPAs del Nivel 2

Gestin de Requisitos Planificacin del proyecto de software Seguimiento y Supervisin del proyecto Gestin de subcontratos de software

Garanta de calidad de software Gestin de configuracin del software

3. Nivel 3: El proceso definido

El proceso generalizado en todos los proyectos

La empresa ha definido un conjunto de procesos, metodologas yLa empresa ha definido un conjunto de procesos, metodologas yherramientas comunes a todos los proyectos iniciados por laherramientas comunes a todos los proyectos iniciados por la corporacin.corporacin.

El proceso comn est suficientemente documentado en una bibliotecaaccesible a todo los desarrolladores. Todo el personal ha recibido elentrenamiento necesario para entender el proceso estndar. Existenpautas y criterios definidos para adaptar dicho proceso a lasnecesidades y caractersticas propias de cada proyecto. El nivel dedefinicin es detallado y completo. La dependencia (o el riesgo dedepender) en individuos irreemplazables es baja.

Beneficios de implantar el Nivel 3 del CMM

La base de datos que rene estadsticas de los proyectos pasados encurso, permite planificar y comparar el rendimiento. Existen mecanismosde comunicacin entre proyectos y departamentos, lo que garantiza unavisin comn del producto y una rpida accin para enfrentar losproblemas. Segn el autor [1], ha conocido unas pocas empresas a estenivel y la cosa que ms le llamo la atencin, fue la satisfaccin delpersonal. En empresas de nivel 1 habitualmente se escuchan quejas yacusaciones.

A nivel 3 los empleados tienen una alta valoracin de los procesos yentienden claramente la manera en que afecta su desempeo habitual.Los gerentes pueden realizar su verdadera funcin, administrar.

El hecho de realizar revisiones tempranas en forma regular mejoravisiblemente la calidad de los productos y minimiza las reiteracionesinnecesarias. Curiosamente muchas organizaciones de nivel 1 realizanrevisiones de pares, pero lo hacen de manera inconsistente y al primersigno de pnico las suspenden.


El nivel 3 ya es un estado avanzado y es percibido por algunos gerentescomo un lujo. Si no todas, al menos unas cuantas de sus reas clavesde procesos deben ser implementadas.

KPAs del Nivel 3

Enfoque en el proceso de la organizacin


44/99

Definicin del proceso de la organizacin Programa de entrenamiento Gestin integrada del software Ingeniera de software del producto Coordinacin entre grupos Revisin de pares

4. Nivel 4: El proceso gestionado

La calidad planificada y confiable

En este nivel la corporacin mide la calidad del producto y del procesode software. Ambos, producto y proceso, son seguidos en formacuantitativa y se controlan mediante mtricas detalladas. La capacidadde rendimiento del proceso es previsible. Las mediciones permitendetectar cuando las variaciones del rendimiento se salen de los rangosaceptables, de manera que se puedan tomar medidas correctivas paraasegurar la calidad.


La empresa es capaz de proponerse metas cuantitativas para la calidadde los productos y de los procesos de software. Es posible medir laproductividad y calidad de los procesos de software a travs de todo elproyecto.

Los proyectos pueden controlar la variacin del rendimiento de susproductos y procesos para mantenerla dentro de fronteras cuantitativasaceptables. Es posible discriminar las variaciones significativas en elrendimiento del proceso de la variacin (ruido) al azar, particularmentedentro de lneas de productos establecidas.

Es necesario aclarar que el hecho de contar con un sistema de mtricasde software no significa que se est en el nivel 4. Es una virtual seal dealarma que les dice lo graves que son sus problemas, pero la inmadurezde sus procesos no les permite hacer nada efectivo, excepto tal vezabortar el producto para evitar un dao mayor que puede resultar dedistribuirlo a los clientes.

Los pasos siguientesLos pasos siguientes

Son muy raras las empresas que han decidido implementar este nivel.Son muy raras las empresas que han decidido implementar este nivel. No son muchos los especialistas de procesos que realmente tenganNo son muchos los especialistas de procesos que realmente tenganexperiencia prctica, o incluso que entiendan bien las reas claves deexperiencia prctica, o incluso que entiendan bien las reas claves de proceso del nivel 4. Son solamente 2 prcticas, pero imposibles deproceso del nivel 4. Son solamente 2 prcticas, pero imposibles de alcanzar si no se ha implementado firmemente los 2 niveles dealcanzar si no se ha implementado firmemente los 2 niveles demadurez anteriores.madurez anteriores.

KPAs del Nivel 4

Gestin cuantitativa del proceso Gestin de la calidad del software

5. Nivel 5: El mejoramiento permanente


45/99

La calidad planificada y confiable

En el Nivel Optimizado, la caracterstica principal es el mejoramientocontinuo del proceso, en base a la realimentacin cuantitativa y alensayo de ideas y tecnologas innovadoras.


La organizacin entera se aboca al mejoramiento continuo del proceso.La corporacin cuenta con los medios para identificar las debilidades yreforzar el proceso, con objeto de prevenir la ocurrencia de defectos.

Los datos relativos a la eficacia del proceso de software se usan paraanalizar el coste y el beneficio de usar nuevas tecnologas y deimplementar cambios al proceso de software.

Los proyectos de software analizan los defectos para determinar suscausas. Los proceso de software se evalan para prevenir que losdefectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidasson difundidas a otros proyectos.


No existen ms de 10 empresas en el mundo que estn a este nivel (nohay ninguna en pases hispano-hablantes). Y las pocas que lo hanlogrado no divulgan sus secretos para mantener su ventaja competitiva.Este nivel es un estado ideal, que probablemente nunca ser alcanzadopor la mayora de las empresas productoras de software. LucianoGuerrero [1] opina que es una hermosa utopa, pero inalcanzable en elmundo normal.

KPAs del Nivel 5

Prevencin de defectos Gestin del cambio de tecnologa Gestin del cambio del proceso

2. La familia CMM

Hay toda una familia de modelos de madurez (CMMs), aplicables aotros dominios relacionados con el software.

SW-CMM: El modelo CMM lo aplicamos especficamente al mbito del

software .SE- CMM: que significa Systems Engineering, el cual cubre el mbito dela Ingeniera de Sistemas.P-CMMP-CMM:: que significa Personal CMM, el cual cubre la administracin deque significa Personal CMM, el cual cubre la administracin depersonal.personal.SA-CMM: que significa Software Acquisition, el cual cubre las prcticasde la adquisicin de productos de software.IPD-CMM: que significa Integrated Product Development, el cual cubreel desarrollo de la integracin del producto.

A continuacin pasamos a detallar los cinco niveles de madurez de que

consta CMM.

2. ISO / IEC TR 15504


46/99

Modelo para la mejora y evaluacin de los procesos de desarrollo ymantenimiento de sistemas y productos de software.

Origen

En enero de 1993 la comisin ISO/IEC JTC1 aprob un programa de trabajo

para el desarrollo de un modelo que fuera la base de un futuro estndarinternacional para la evaluacin de los procesos del ciclo de vida del software.Este trabajo recibi el nombre de proyecto SPICE (Software ProcessImprovement and Capability dEtermination), y en junio de 1995, con lapublicacin de su primer borrador, desde ISO fueron invitadas diferentesorganizaciones para aplicarlo y valorar sus resultados.

En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, eltrabajo pas a la fase de informe tcnico con la denominacin ISO/IEC TR15504. La instruccin tcnica consta de 9 apartados, recogidos en volmenesindependientes que se han ido publicando como redaccin definitiva delestndar internacional ISO/IEC 15504 durante el periodo 2003 - 2005.

Caractersticas

Establece un marco para mtodos de evaluacin, no es un mtodo omodelo en s.

Comprende: evaluacin de procesos, mejora de procesos,determinacin de capacidad.

Est alineado con el estndar ISO/IEC 12207 que define losprocesos del ciclo de vida del desarrollo, mantenimiento y operacin delos sistemas de software.

Equivalencia y compatibilidad con CMMI. ISO forma parte del panel

elaborador del modelo CMMI y SEI mantiene la compatibilidad yequivalencia de sta ltima con 15504.


47/99

Dimensiones

Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad

de proceso.

Desde la dimensin de proceso a

8255409 Metodologias Para La Geston y Desarrollo de Software

Documents

Transcript of 8255409 Metodologias Para La Geston y Desarrollo de Software