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.

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 lmites marcados 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 por que lo normal no es que se desarrolle un software sino un sistema en el que el software va a tener una parte ms o menos protagonista. Generalmente el proyecto software no se ejecuta de forma aislada sino que tiene que integrarse con otros proyectos que se estn realizando en la organizacin. Cuando se integra con otros proyecto (en curso o en futuro) software de la organizacin se suele hablar de gestin integrada de la informacin en la empresa.

1.1.1.3 Diferencia de la gestin de software con otros campos:

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 cuya finalidad es servir al desarrollo o al funcionamiento de otros programas. Estos programas son muy variados: editores, compiladores, sistemas operativos, entornos grficos, programas de telecomunicaciones, etc. pero se caracterizan por estar muy prximos al hardware, por ser utilizados concurrentemente por numerosos usuarios y por tratarse de programas de amplia

difusin, no estando diseados normalmente a medida. Esto permite un mayor esfuerzo en su diseo y optimizacin, pero tambin les obliga a ser muy fiables, cumpliendo estrictamente las especificaciones para las que fueron creados. Un ejemplo de este tipo de software 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 a medida que ocurren, debiendo reaccionar de forma correcta a los estmulos de entrada en un tiempo mximo prefijado. Deben, por tanto, cumplir unos requisitos temporales muy estrictos y, dado que los procesos que controlan pueden ser potencialmente peligrosos, tienen que ser fiables y tolerantes a fallos. Por otro lado, no suelen ser muy complejos y precisan de poca interaccin con el usuario. Un sistema de tiempo real es aquel en el que para que las operaciones computacionales estn correctas no depende solo de que la lgica e implementacin de los programas computacionales sea correcto, sino tambin en el tiempo en el que dicha operacin entreg su resultado. Si las restricciones de tiempo no son respetadas el sistema se dice que ha fallado. Un Buen ejemplo es el de un robot que necesita tomar una pieza de una banda sinfn. Si el Robot llega tarde, la pieza ya no estar donde deba recogerla. Por lo tanto el trabajo se llev acabo incorrectamente, aunque el robot haya llegado al lugar adecuado. Si el robot llega antes de que la pieza llegue, la pieza aun no estar ah y el robot puede bloquear su paso. Software de gestin El procesamiento de informacin de gestin constituye, casi desde los inicios de la informtica la mayor de las reas de aplicacin de los ordenadores. Estos programas utilizan grandes cantidades de informacin almacenadas en bases de datos con objeto de facilitar las transacciones comerciales o la toma de decisiones. Adems de las tareas convencionales de procesamiento de datos, en las que el tiempo de procesamiento no es crtico y los errores pueden ser corregidos a posteriori, incluyen programas interactivos que sirven de soporte a transacciones comerciales. Software cientfico y de ingeniera Otro de los campos clsicos de aplicacin de la informtica. Se encarga de realizar complejos clculos sobre datos numricos de todo tipo. En este caso la correccin y exactitud de las operaciones que realizan

es uno de los requisitos bsicos que deben de cumplir. El campo del software cientfico y de ingeniera se ha visto ampliado ltimamente con el desarrollo de los sistemas de diseo, ingeniera y fabricacin asistida por ordenador (CAD, CAE y CAM), los simuladores grficos y otras aplicaciones interactivas que lo acercan ms al software de tiempo real e incluso al software de sistemas. Software de ordenadores personales El uso de ordenadores personales y de uso domstico se ha generalizado a lo largo de la pasada dcada. Aplicaciones tpicas son los procesadores de textos, las hojas de clculo, bases de datos, aplicaciones grficas, juegos, etc. Son productos de amplia difusin orientados a usuarios no profesionales, por lo que entre sus requisitos se encuentran la facilidad de uso y el bajo coste. Un ejemplo de este tipo de software es el paquete de Office. Software empotrado Software empotrado es aquel que va instalado en otros productos industriales, como por ejemplo la electrnica de consumo, dotando a estos productos de un grado de inteligencia cada vez mayor. Se aplica a todo tipo de productos, desde un vdeo domstico hasta un misil con cabeza atmica, pasando por algunos sistemas de control de los automviles, y realiza funciones muy diversas, que pueden ir desde complicados clculos en tiempo real a sencillas interacciones con el usuario facilitando el manejo del aparato que los incorpora. Comparten caractersticas con el software de sistemas, el software de tiempo real, el software de ingeniera y cientfico y el software de ordenadores personales. Otro ejemplo de los productos que utilizan este tipo de software son los telfonos celulares. Software de inteligencia artificial El software basado en lenguajes procedimentales es til para realizar de forma rpida y fiable operaciones que para el ser humano son tediosas e incluso inabordables. Sin embargo, es difcilmente aplicable a problemas que requieran la aplicacin de funciones intelectuales ms elevadas, por triviales que nos puedan parecer. El software de inteligencia artificial trata de dar respuesta a estas deficiencias, basndose en el uso de lenguajes declarativos, sistemas expertos y redes neuronales. Un ejemplo de este software es Smart Airport Operations Center, programa de logstica creado por Ascent Technology, el cual es utilizado en los aeropuertos, que computacional-mente, son el mayor

reto mundial para resolver problemas. Un cambio (atraso, lluvia, falta de un empleado) genera el efecto domin. Con el susodicho software, este pulpo balancea todos los detalles hasta que todo cuadre. Son logsticas, pero el problema es ms sutil que una ecuacin gigante. No hay manera de solucionar un aeropuerto con sus miles de variables. A cambio, los algoritmos genticos usan la seleccin natural, la mutacin, el cruce de escenarios subptimos, permitiendo que el programa encuentre la mejor opcin. La gente hace esto instintivamente en la vida diaria. Pero el software eleva la productividad en un 30% en los aeropuertos que lo usan, eliminando diferentes engalletamientos.

Grandes proyectos software son con frecuencia proyectos nicos. Empleo de nuevas tcnicas. Elevado nmero de interfases.

1.1.1.4 Documentacin

No se puede llamar gestin a lo que es un proceso Ad-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 las empresas, consideran como aspecto no-financiero ms importante la habilidad de ejecutar la estrategia de una empresa, y no tanto la calidad de la estrategia en s misma. De acuerdo con un informe de Ernst & Young, de los factores no financieros ms importantes a la hora de valorar una empresa, el nmero uno es la habilidad para ejecutar la estrategia de la empresa, mientras que la calidad de esta estrategia se encuentra en tercera posicin. Para confirmar esta idea, podemos ir a un estudio publicado en la revista Fortune, que dice que alrededor del 70% de los fallos que cometen los directivos no estn causados por una estrategia pobre, sino por una ejecucin deficiente de la

misma siendo indecisivos y no cumpliendo con los compromisos establecidos con los accionistas, los clientes o los profesionales que trabajan en la empresa. El Cuadro de Mando Integral CMI (denominacin en castellano de Balanced Scorecard, desarrollado por Kaplan y Norton a principios de los aos noventa) es una herramienta de gestin estratgica que apoya la definicin, comunicacin y gestin de los objetivos y estrategia de la empresa. Segn el CMI la estrategia de una empresa puede definirse en funcin de cuatro perspectivas como son la financiera, la de clientes, la de procesos y la de aprendizaje y crecimiento. BITS (Balanced IT Scorecard) Los problemas presentados anteriormente se acentan en las compaas de Tecnologas de la Informacin (TI), donde las barreras de comunicacin causadas por el uso de idiomas muy distintos entre el departamento de TI y el resto del negocio, provocan una reduccin en el potencial que las TI tienen para aadir valor a la empresa identificando nuevas oportunidades de negocio. Ante esta situacin se ve la necesidad de crear un lenguaje comn en la empresa que ofrezca un marco comn de evaluacin haciendo uso de los mismos criterios en toda la empresa. Esto permitir que las inversiones en TI y las mejoras que se lleven a cabo en la empresa estn orientadas a conseguir objetivos de negocio y que puedan evaluarse en funcin de esta aportacin al negocio. Conociendo los principios del CMI debemos desarrollar una metodologa para llevarlos a las organizaciones de TI, considerando las peculiaridades de estas empresas. Podemos definir cinco perspectivas: Financiera: Cmo aaden valor econmico a la empresa nuestros procesos de desarrollo de software y la mejora de dichos procesos? Clientes: Cmo sabemos que nuestros clientes, internos y externos, estn satisfechos? Procesos funcionan a un nivel suficiente que satisfaga a los clientes? Cumplen nuestros

procesos con las expectativas de los clientes? Personas : Aqu es donde introducimos una de las diferencias respecto del BSC. Hemos aadido una perspectiva ms; la de personas. Tienen nuestros empleados las capacidades suficientes para realizar su trabajo?, Son felices con lo que estn haciendo y donde lo estn haciendo? Infraestructura e innovacin: Aqu, para las organizaciones de TI, queremos gestionar aspectos relacionados con la mejora de procesos de software, la tecnologa y la infraestructura organizativa, por lo que deberemos preguntarnos, estamos trabajando para implantar un programa de mejora sostenible? Por programa de mejora sostenible entendemos un programa de mejora continuo en el tiempo que apoya a la empresa para alcanzar sus objetivos de negocio, por lo que podremos medir el impacto de estas mejoras en el negocio y por lo tanto su ROI. La metodologa BITS la componen principalmente tres elementos El primero es el Modelo Genrico: consiste en un conjunto de objetivos genricos que una empresa de TI podra querer alcanzar y un conjunto de conductores para alcanzar estos objetivos, para cada una de las cinco perspectivas que hemos visto. Asociados a estos objetivos y conductores (o factores crticos de xito) existe un conjunto de indicadores cuantitativos para realizar el seguimiento de los mismos. El segundo componente es el Mtodo, que ofrece una forma para desarrollar un CMI para una empresa de modo que en la empresa exista una alineacin entre las iniciativas de mejora de procesos de software y los objetivos de negocio. El tercer componente es el Material de Aplicacin del mtodo. Aqu podemos encontrar material de apoyo a la hora de aplicar el mtodo, como por ejemplo plantillas que las empresas pueden utilizar, y que facilitan y aceleran el proceso de desarrollar un CMI para una empresa.

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

Normas de la documentacin

La documentacin (que refleja el proyecto) ha de estar ligada a una norma . Esta norma puede estar fijada por la organizacin o por un 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 los elementos antes indicados . Se toman las acciones correctivas. Todo ello reflejado en los planes anteriores.

1.1.2.2 Planes :

Plan Plan Plan Plan Plan Plan Plan

de de de de de de de

desarrollo software (ANEXO 01) configuracin software (ANEXO 02) calidad de software verificacin y validacin mantenimiento desarrollo del personal 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 DE DESARROLLO:CERRADO, ALEATORIO, ABIERTO, SINCRONIZADO

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

de de de de de

despliegue. mantenimiento. libreras. la base de datos. 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 de eventos. Controla el proyecto para mantenerlo dentro de los 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 conocimiento previo ). Aleatorio El equipo se estructura libremente en funcin de la iniciativa del personal. Funcionan bien en entornos tecnolgicos muy innovadores pero chocan cuando hay que conseguir un rendimiento ordenado. No facilita la asuncin de responsabilidades. Abierto Conjuga los dos anteriores. Se incluyen muchas vas de comunicacin y toma de decisiones consensuadas. Adecuados para la resolucin de problemas complejos pero no tienen tanto rendimiento como el cerrado.

Sincronizado Se divide el problema en partes disjuntas de forma natural, con una organizacin clara pero con poca comunicacin 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 Model Integration

1.1.4.1.3 Ciclo de vida

RUP - Rational Unified Process: Modelo de desarrollo basado en su diagrama de ballenas. Las normas IEEE 1074 e ISO 12207-1 enfocan el trmino de forma muy similar considerando una actividad como un conjunto de tareas y una tarea como una 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 un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software. Es una actividad de garanta de calidad que se aplica en todas las 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...)

Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones parciales, aadir, borrar, renombrar o mover elementos) Registro histrico de las acciones realizadas con cada elemento o conjunto de elementos (normalmente pudiendo volver o extraer un estado anterior del producto) Aunque no es estrictamente necesario, suele ser muy til la generacin de informes con los cambios introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la versin de un conjunto de ficheros, etctera.

CVS, Subversion, SourceSafe, ClearCase, Darcs, Plastic SCM, Git, Mercurial, etc.

1.1.4.2.4 Ciclo de vida

Rational Enterprise Edition , Rational SoDA, Rational Suite

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 proyecto Definicin a alto nivel de normas, estndares, herramientas, etc. Costo del proyecto Consistir en analizar los productos y el tiempo y recursos que en abstracto tiene su desarrollo Plan de trabajo Se realizan las asignaciones de personal, tiempos y recursos. Riesgos Gestin de riesgos 1.2.1.2 Funcin de los requisitos Tiene que tener en cuenta los requisitos en sentido amplio: Los que provienen de los stakeholders (los interesados). Los que provienen del entorno de la propia organizacin.

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 NORMAS, EQUIPO,

1.2.2 MARCO GENERAL: ALCANCE, 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 presente proyecto 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 (es decir, Plan de Garanta de Calidad de Software) es un documento que organiza el desarrollo del software con el fin de que el proceso de creacin de este siga unas pautas que aseguren la calidad del resultado. Este plan de garanta forma parte de la Ingeniera de software. En este documento se organiza el equipo de personas, se elige el ciclo de vida a seguir, se especifican los documentos que harn falta, las revisiones que se harn, las pruebas e incluso cmo realizar el mantenimiento. (ANEXO 04)

1.2.2.4 Mecanismos de monitorizacin y control

Mecanismos de control y seguimiento en funcin de lo definido en el SQAP Establecimiento de reuniones de seguimiento de proyecto 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), NO DESARROLLO, AJUSTE PRESUPUESTARIO 1.2.3.1 Descomposicin de las tareas no directamente de 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 en CSCI/CSC (Computer Software Configuration Item/Computer Software Component)

Fuente para su definicin:

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

1.2.3.2.2 Estimacin de paquete de trabajo

Para ello es necesario utilizar herramientas basadas en modelos como COCOMO, COCOMO 2 o REVIC Como funciona REVIC:

Se introduce el conjunto de CSCI/CSC del proyecto Se realiza una estimacin del nmero de lneas de cdigo de cada componente, normalmente se introduce una distribucin estadstica. A continuacin se fijan unos parmetros globales del proyecto como:

Experiencia, aerotransportado, etc.

criticidad,

El programa proporcionar una distribucin en valor medio (incluso varianza) . Y Y

1.2.4 PLAN MATERIALES, TCNICAS

DE TRABAJO: RECURSOS HUMANOS HITOS, ANLISIS, CAMINOS CRTICOS

1.2.4.1 Recursos humanos

Organizar el equipo de trabajo en funcin de la norma y en funcin del volumen del proyecto. Asignar las horas/hombre al equipo de trabajo. Asignacin de Responsabilidades a cada uno de los 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 Gantt muestra el origen y el final de las diferentes unidades mnimas de trabajo y los grupos de tareas (llamados summary elements en la imagen) o las dependencias entre unidades mnimas de trabajo (no mostradas en la imagen). Desde su introduccin los diagramas de Gantt se han convertido en una herramienta bsica en la

gestin de proyectos de todo tipo, con la finalidad de representar las diferentes fases, tareas y actividades programadas como parte de un proyecto o para mostrar una lnea de tiempo en las diferentes actividades haciendo el mtodo ms eficiente. PERT [5] Una malla PERT permite planificar y controlar el desarrollo de un proyecto. A diferencia de las redes CPM, las redes PERT trabajan con tiempos probabilsticos. Normalmente para desarrollar un proyecto especfico lo primero que se hace es determinar, en una reunin multidisciplinaria, cules son las actividades que se deber ejecutar para llevar a feliz trmino el proyecto, cul es la precedencia entre ellas y cul ser la duracin esperada 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 los requisitos del cliente. Dicho proceso, en trminos globales se muestra en la Figura 2 [3]. Este proceso es intensamente intelectual, afectado

por la creatividad y juicio de las personas involucradas [4]. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuacin se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construccin. Un producto software en s es complejo, es prcticamente inviable conseguir un 100% de confiabilidad de un programa por pequeo que sea. Existe una inmensa combinacin de factores que impiden una verificacin exhaustiva de las todas posibles situaciones de ejecucin que se puedan presentar (entradas, valores de variables, datos almacenados, 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, esto dificulta la definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difciles de consolidar tempranamente. As, los cambios en los requisitos son inevitables, no slo despus de entregado en producto sino tambin durante el proceso de desarrollo. Adems, de las dos anteriores, siempre puede sealarse la inmadurez de la ingeniera del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniera. Sin embargo, esto no es ms que un intil consuelo.
Requisitos nuevos om odificados Sistem nuevo a om odificado

Proceso de Desarrollo de Softw are

Figura 1: proceso de desarrollo de software. El proceso de desarrollo de software no es nico. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difcil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos [4]: 1. Especificacin de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseo e Implementacin: Se disea y construye el software de acuerdo a la especificacin. 3. Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolucin: El software debe evolucionar, para adaptarse a las

necesidades del cliente. Adems de estas actividades fundamentales, Pressman [1] menciona un conjunto de actividades protectoras, que se aplican a lo largo de todo 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 se muestra en la Figura 3. Los elementos involucrados se describen a continuacin:

Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamao o complejidad. Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garanta de calidad, que permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto de software y los requisitos del equipo del proyecto. Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software y medicin, abarcan el modelo del proceso. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 2: Elementos del proceso del software Otra perspectiva utilizada para determinar los elementos del proceso

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

Figura 3: Relacin entre elementos del proceso del software En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. As las interrogantes se responden de la siguiente forma:

Quin: Las Personas participantes en el proyecto de desarrollo desempeando uno o ms Roles especficos. Qu: Un Artefacto1 es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones especficas. Las Herramientas apoyan la elaboracin de Artefactos soportando ciertas Notaciones. Cmo y Cundo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto est controlado mediante hitos que establecen un determinado estado de terminacin de ciertos Artefactos.

La composicin y sincrona de las actividades est basada en un conjunto de Principios y Prcticas. Las Prcticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, 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 Una representacin simplificada de un proceso de software, representada desde una perspectiva especfica. Por su naturaleza
1

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, un elemento de modelo o un documento.

los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstraccin de un proceso real. Los modelos genricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones tiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. 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 desarrollo de 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, y mantenimiento. Este modelo tiene tres problemas principales [7]:

Despus de un nmero de correcciones, el cdigo puede tener una muy mala estructura, hace que los arreglos sean muy costosos. Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es muy cara. El cdigo es difcil de reparar por su pobre preparacin para probar y modificar.

2.1.1.2. Modelo en cascada El primer modelo de desarrollo de software que se public se deriv de otros procesos de ingeniera [8]. ste toma las actividades fundamentales del proceso de especificacin, desarrollo, validacin y evolucin y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases:

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

sistema. Se busca hacer esta definicin en detalle.

Diseo de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. Implementacin y pruebas unitarias: Construccin de los mdulos y unidades de software. Se realizan pruebas de cada unidad. Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es puesto en marcha y se realiza la correccin de errores descubiertos. Se realizan mejoras de implementacin. Se identifican nuevos requisitos.

La interaccin entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la correccin de los problemas encontrados en fases previas.

Figura 4: Modelo de desarrollo en cascada. En la prctica, este modelo no es lineal, e involucra varias iteraciones e interaccin entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son:

Las iteraciones son costosas e implican rehacer trabajo debido a la produccin y aprobacin de documentos. Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases. Los problemas se dejan para su posterior resolucin, lo que

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

Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto. Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difcil responder a cambios en los requisitos.

Este modelo slo debe usarse si se entienden a plenitud los requisitos. An se utiliza como parte de proyectos grandes. 2.1.1.3. Desarrollo evolutivo La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cmo las actividades concurrentes: especificacin, desarrollo y validacin, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.

Figura 5: Modelo de desarrollo evolutivo. Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario. Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos

requisitos. Entre los puntos favorables de este modelo estn:

La especificacin puede desarrollarse de forma creciente. Los usuarios y desarrolladores logran un mejor entendimiento 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 se identifican los siguientes problemas:

Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del sistema. Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento. Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeos (menos de 100.000 lneas de cdigo) o medianos (hasta 500.000 lneas de cdigo) con poco tiempo para su desarrollo y sin generar documentacin para cada versin. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento ms estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio. 2.1.1.4. Desarrollo formal de sistemas Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.

Figura 6: Paradigma de programacin automtica. La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programacin automtica. Se distinguen dos fases globales: especificacin (incluyendo validacin) y transformacin. Las caractersticas principales de este paradigma son: la especificacin es formal y ejecutable constituye el primer prototipo del sistema), la especificacin es validada mediante prototipacin. Posteriormente, a travs de transformaciones formales la especificacin se convierte

en la implementacin del sistema, en el ltimo paso de transformacin se obtiene una implementacin en un lenguaje de programacin determinado. , el mantenimiento se realiza sobre la especificacin (no sobre el cdigo fuente), la documentacin es generada automticamente y el mantenimiento 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 el proceso de transformacin. As, las pruebas que verifican la correspondencia con la especificacin no son necesarias. Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes. Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

2.1.1.5. Desarrollo basado en reutilizacin Como su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuacin se describe cada fase: 1. Anlisis de componentes: Se determina qu componentes pueden ser utilizados para el sistema en cuestin. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes ms adecuados (fase 1). 3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para disear o determinar este marco. 4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integracin es parte del desarrollo en lugar de 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.

Figura componentes

7:

Desarrollo

basado

en

reutilizacin

de

Desventajas de este modelo:

Los compromisos en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente. Las actualizaciones de los componentes adquiridos no estn en manos de los desarrolladores del sistema.

2.1.2. Procesos iterativos A continuacin se expondrn dos enfoques hbridos, especialmente diseados para el soporte de las iteraciones:

Desarrollo Incremental. Desarrollo en Espiral. 2.1.2.1 Desarrollo incremental Mills [9] sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinacin del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Figura 8: Modelo de desarrollo iterativo incremental. Entre las ventajas encuentran:

del

modelo

incremental

se

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento. Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema. Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento. Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

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 requisitos contra los incrementos. Es difcil detectar las unidades o servicios genricos para todo el sistema.

2.1.2.2 Desarrollo en espiral El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los ms conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: 1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseo detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluacin y reduccin de riesgos: Se realiza un anlisis

detallado de cada riesgo identificado. Pueden desarrollarse prototipos 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 desarrollo despus de la evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo, esta es una actividad importante en la administracin del proyecto. El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalan los riesgos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla 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 de abordar el problema. Las propuestas comerciales y acadmicas actuales promueven procesos iterativos, donde en cada iteracin puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definicin de requisitos, tamao del proyecto, riesgos identificados, entre otros). En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios bsicos para la seleccin de un modelo de proceso [10], la medida utilizada indica el nivel de efectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y arquitectura no estn

predefinidos ):

Mode lo de proce so

F unci ona con requ isito s y arqu itect ura no pre defi nido s

Produ ce softw are altam ente fiable

Gesti n de riesg os

Permit e correc ciones sobre la march a

Vi si n de l pr og re so po r el Cli en te y el Jef e de l pr oy ec to

Codifi car y corre gir Casca da Evolu tivo explo ratori o Evolu tivo proto tipad o Desar rollo forma l de siste mas

Bajo

Bajo

Bajo

Alto

Me di o

Bajo

Alto

Bajo

Bajo

Ba jo Me di o o Alt o

Medi o o Alto

Medio o Alto

Medi o

Medio o Alto

Alto

Medio

Medi o

Alto

A lto

Bajo

Alto

Bajo a Medi o

Bajo

Ba jo

Desar rollo orien tado a reutil izaci n Incre ment al Espir al

Medi o

Bajo a Alto

Bajo a Medi o

Alto

A lto

Bajo

Alto

Medi o

Bajo

Ba jo Me di o

Alto

Alto

Alto

Medio

Tabla 1: Comparacin entre modelos de proceso de software. 2.3. Metodologas para desarrollo de software Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo. La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuacin se revisan brevemente cada una de estas categoras de metodologas. 2.3.1. Metodologas estructuradas Los mtodos estructurados comenzaron a desarrollarse a

fines de los 70s con la Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas para el Diseo (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan para la implementacin lenguajes de 3ra y 4ta generacin. Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE2 (Francia), MTRICA3 (Espaa), SSADM4 (Reino Unido). Ejemplos de propuestas de mtodos estructurados 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 de programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y actualmente Java9 o C# de Microsoft. A fines de los 80s comenzaron a consolidarse algunos mtodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms modesto, para dar lugar al Unified Modeling Language (UML)10, la notacin OO ms popular en la actualidad. Algunos mtodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Algunas metodologas orientadas a objetos que utilizan la notacin 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 guiadas por una fuerte planificacin durante todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o
2 3 4 5 6 7 8

9 10 11 12

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

clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema. Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas tradicionales. Aunque en el caso particular de RUP, por el especial nfasis que presenta en cuanto a su adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse), realizando una configuracin adecuada, podra considerarse gil. 2.3.4. Metodologas giles Un proceso es gil cuando el desarrollo de software es incremental (entregas pequeas de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios 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, configuracin gil ([16]). una

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 las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.

Caractersticas13

Desarrollo iterativo e incremental Pruebas unitarias continuas Programacin en parejas integracin del equipo de programacin con el cliente 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 iterativo e incremental utilizado comnmente en entornos basado en la metodologa Agile de desarrollo de software. Scrum es un proceso marco que incluye un conjunto de prcticas y roles predefinidos. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, 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 (la longitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de caractersticas que forma parte de cada sprint viene del product backlog, que es un conjunto de requisitos de alto nivel priorizados que dan forma al trabajo a realizar. Los elementos del backlog que forman parte del sprint se determinan durante la reunin de sprint planning. Durante esta reunin, el Product Owner informa al equipo de los elementos en el product backlog que quiere ver completados. El equipo entonces determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.[4] Durante el sprint, nadie puede cambiar el sprint backlog, lo que significa que los requisitos estn congelados durante el sprint. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco esfuerzo
13

http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema

para comenzarse a utilizar. 2.3.4.3. Proceso Unificado de Rational Es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo a necesidades. 2.3.4.4. Mtrica V314 La metodologa MTRICA Versin 3 ofrece a las Organizaciones un instrumento til para la sistematizacin de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos: Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin mediante la definicin de un marco estratgico para el desarrollo de los mismos. Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al anlisis de requisitos. Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la reutilizacin en la medida de lo posible. Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software 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

Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.

Los procesos de la estructura principal de MTRICA Versin 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 de informacin 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 de coordinacin, donde los programadores que colaboran libremente, utilizando libremente el cdigo fuente distribuido y la infraestructura de comunicaciones de Internet. El cdigo abierto se basa en la filosofa del software libre. Sin embargo, el cdigo abierto extiende esta ideologa ligeramente para presentar un enfoque ms comercial que incluye tanto un modelo de negocio y metodologa de desarrollo. La catedral y el bazar es la descripcin citada con mayor frecuencia al ser relacionada como una de desarrollo, sin embargo, aunque el documento se identifican muchos de los mecanismos de xito de desarrollo de cdigo abierto, no exponer la dinmica. Existen crticas sobre ciertos aspectos que siguen siendo ambiguas, lo que sugiere que el documento no describe el proceso de desarrollo de cdigo abierto.

15

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

III. METODOLOGAS DE CONTROL DE CALIDAD DEL SOTWARE

La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para el anlisis, diseo, programacin y prueba del software que permitan 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 del software. El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. 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, usted no puede controlar lo que no se puede medir. Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de 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. La Metodologa para la evaluacin de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerrquicos: factor, criterio, mtrica, elemento de evaluacin, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categoras de mtricas: de complejidad de programa o cdigo, y de complejidad de sistema o estructura. Todos los autores coinciden en que el software posee determinados ndices medibles que 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 de aplicacin, complejidad, etc., de acuerdo con los estndares establecidos para el desarrollo del software. Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de software es necesario definir los indicadores y sus magnitudes.

Crear o determinar los mtodos de valoracin de los indicadores: mtodos manuales como cuestionarios o encuestas estndares para la medicin de criterios periciales y herramientas automatizadas para medir los criterios de clculo. Definir las regulaciones organizativas para realizar el control: quines participan en el control de la calidad, cundo se realiza, qu documentos deben ser revisados y elaborados, etc.

3.2.La gestin de la calidad

Gestin de la calidad: "Aspectos de la funcin de gestin que determinan y aplican la poltica de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificacin de la calidad, el control de la calidad, la garanta de calidad y la 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 la funcin general de la direccin que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificacin de la calidad, el control de la calidad, el aseguramiento (garanta) de la calidad y la mejora 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 la alta direccin.

La gestin de la calidad se aplica normalmente a nivel de empresa. Tambin puede haber 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 y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfar los requerimientos dados sobre calidad". Aseguramiento de la calidad de software: Conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad.

El aseguramiento de calidad del software se disea para cada aplicacin antes de comenzar a desarrollarla. Hay quienes prefieren decir garanta de calidad en vez de aseguramiento. La garanta, puede confundir con garanta de productos, mientras que el aseguramiento pretende 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 del software. 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 est fuera de ellos). Mecanismos de medida (mtricas). Registro de auditorias y realizacin de informes. 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. Revisiones tcnicas y de gestin (su objetivo es la evaluacin). Inspeccin (su objetivo es la verificacin). Estamos construyendo el producto correcto?. Pruebas (su objetivo es la validacin). Estamos construyendo el producto correctamente?. Auditorias (su objetivo es la confirmacin del cumplimiento).

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

Algunos mtodos del aseguramiento:

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 o servicio". Control de la calidad del software: Tcnicas y actividades de carcter operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida. Mantener bajo control un proceso. 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:

En general, se puede decir que el control de de la calidad del software son las actividades para evaluar la calidad de los productos desarrollados. Las estrategias de trabajo se representan como sigue:

3.5.Modelos de calidad de software

1. CMM

El Modelo de Madurez de Capacidades (CMM) es un modelo de referencia para la aplicacin de conceptos de gestin de procesos y de mejora de calidad en el desarrollo y mantenimiento de software, que deben ser implementadas por toda organizacin interesada en desarrollar y mejorar la calidad de sus productos y su productividad. Este modelo est basado en conceptos de calidad total y de mejoramiento continuo 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 los ochenta y financiado por el Departamento de Defensa de los Estados Unidos. Se entiende por proceso el saber como utilizar el conocimiento del personal y la tecnologa de forma eficiente para lograr productos que alta calidad que satisfagan las necesidades de los clientes, producidos dentro de costos y plazos aceptables. Un proceso puede considerarse maduro si cumple con los siguientes criterios:

Est definido: El proceso es claro, sistemtico y suficientemente detallado. Adems existe acuerdo entre el personal, la gerencia y los proyectos 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 software y la gerencia han recibido cursos y entrenamiento en cada proceso que aplica a su trabajo Es practicado: El proceso definido debe ser usado en las tareas habituales llevadas a cabo por los proyectos. El entrenamiento y la adaptacin del proceso a la realidad de la empresa debieran garantizar su aplicacin en la vida real. Es mantenido: El proceso es revisado regularmente, para asegurarse que est adaptado para satisfacer las necesidades reales de los proyectos.

Est controlado: Los cambios y puestas al da del proceso son revisados, aprobados y comunicados oportunamente a todos los usuarios. Se verifica: La gerencia mantiene mecanismos para asegurarse de que todos los proyectos siguen el proceso vigente. Se valida: Se asegura que el proceso mantiene concordancia con los requerimientos y estndares aplicables. Se mide: La utilizacin, los beneficios y el rendimiento resultante del proceso se miden regularmente. Puede mejorarse: Existen mecanismos y apoyo de la gerencia para revisar e introducir cambios en el proceso, de manera que se pueda mejorar su eficacia e incorporar nuevas metodologas.

El CMM se basa principalmente es dos conceptos importantes, el concepto de proceso maduro, definido anteriormente y el concepto de nivel de madurez que es definido como la capacidad de los procesos de ingeniera de software y de administracin de proyectos usados en una organizacin de desarrollo de software 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, en niveles de madurez. Cada nivel tiene un cierto nmero de reas de proceso importantes que deben lograrse. Su logro se detecta mediante la satisfaccin (o no) de varios metas claras y cuantificables. Con excepcin del Nivel 1, cada uno de estos Niveles de Madurez est compuesto 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 prcticas relacionadas, las cuales cuando son realizadas en forma colectiva permiten lograr alcanzar las metas fundamentales del proceso. Las

KPAs pueden clasificarse Organizacional e Ingeniera.

en

tipos

de

proceso:

Gestin,

Las prcticas que deben ser realizadas por cada Area Clave de Proceso estn organizadas en 5 Caractersticas Comunes, las cuales constituyen propiedades que indican si la implementatcin y la institucionalizacin 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 independiente de cualquier mtodo (o metodologa) y de cualquier ambiente de tecnologa (software o hardware). Los mtodos especficos usados por una compaa o agencia no impone restricciones especficas en la utilizacin del SW-CMM, debido a que sus prcticas se formulan de forma general para que pueda fcilmente adaptarse de manera de satisfacer las necesidades de ambientes particulares. Este modelo debe interpretarse de acuerdo al tamao de las compaas o agencias, pero es aplicable en el contexto global. Cualquier entidad que desarrolla o mantiene software, independientemente de su tamao se 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 CBAIPI ("CMM -Based Appraisal for Internal Process Improvement"): su principal objetivo es permitir a la empresa la determinacin de sus puntos fuertes y necesidades de mejoramiento, tambin permite revisar las prcticas de los proveedores externos, a objeto de que puedan derivar 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 este nivel se encuentran todas las empresas que no han logrado implementar las prcticas bsicas de gestin de proyectos e ingeniera de software definidas a partir del nivel 2 o superiores. Una empresa est en el nivel catico cuando sus gerentes y personal afirmen que los proyectos no se pueden planear, que los requerimientos no se pueden tener bajo control, que no est siempre en condiciones de controlar las versiones de producto, donde la calidad sea percibida como una burocracia innecesaria, cuando se acepte que los procesos son una cosa personal, cuando no se pueda verificar ni validar el producto, y sobre todo, cuando sus gerentes y personal vivan bajo condiciones de stress y frustracin permanentes. La gerencia ocupa una parte significativa de su tiempo en paliar problemas y enfrentar clientes insatisfechos. Ante una situacin de crisis permanente, se les hace difcil destinar recursos para definir o

documentar procesos, lo que lleva a un crculo sin salida. Cuando el proyecto se termina, la inversin hecha en desarrollar el proceso es raramente reutilizada en nuevos proyectos. Los desarrolladores de software generalmente tienen que trabajar largas horas y paliar problemas en forma cotidiana, lo cual les disminuye su creatividad y productividad netas. 2. Nivel 2: Nivel Repetible El proyecto planificado El nivel 2 o Repetible hace posible la implementacin de prcticas mnimas de administracin de proyecto, de control de requerimientos, versiones de producto y de proyectos realizados por subcontratistas. El grupo o equipo humano que realiz el proyecto puede aprovechar su experiencia e inversin en procesos para aplicarla en un nuevo proyecto. Este nivel no garantiza que todos los proyectos dentro de la empresa estn necesariamente al mismo nivel de madurez. Algunos pueden estar todava en el nivel inicial. Luciano Guerrero [1], en cuya pgina hemos basado gran parte del trabajo ha visto algunos casos en la prctica y en todos ellos estos proyectos fueron ineficientes con respecto a los de mayor madurez, malgastando el xito de estos ltimos. Eventualmente algunos invertieron los esfuerzos necesarios para ponerse a tono, otros simplemente fueron cerrados con un elevado costo de frustracin y descalabro de carreras profesionales. Beneficios de implantar el Nivel 2 El mayor beneficio obtenido de la implementacin del nivel 2 por la empresa en la cual se encuentra actualmente [1], es la planificacin realista de los proyectos. Antes los cronogramas de proyecto expresaban ms los deseos de la gerencia que la realidad. Este principio (el mismo en la cual se basa la magia) conduca una situacin de buscar culpables y generar excusas, produciendo al mismo tiempo frustracin y desconfianza entre clientes y empleados actualmente en la empresa, los cronogramas son cada da ms confiables, y mejora a medida que se acumula ms informacin en las bases de datos de los proyectos pasados. El uso generalizado de mtodos de estimacin permite al personal del proyecto de justificar plazos y recursos. An el "olfato profesional" y la experiencia personal juegan un papel importante en la generacin de planes de proyecto, pero ahora son decisiones informadas en vez de simples adivinanzas como en el pasado. Los pasos siguientes Este nivel todava permite la proliferacin y definicin insuficiente de los procesos de ingeniera de software. Los proyectos comparten principalmente sus experiencias en materia de administracin de proyectos, pero sus mtodos tcnicos pueden diferir. An existe incomunicacin 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. La ausencia de cualquiera de sus prcticas simplemente pone en peligro el xito de la empresa.

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 y herramientas comunes a todos los proyectos iniciados por la corporacin. El proceso comn est suficientemente documentado en una biblioteca accesible a todo los desarrolladores. Todo el personal ha recibido el entrenamiento necesario para entender el proceso estndar. Existen pautas y criterios definidos para adaptar dicho proceso a las necesidades y caractersticas propias de cada proyecto. El nivel de definicin es detallado y completo. La dependencia (o el riesgo de depender) en individuos irreemplazables es baja. Beneficios de implantar el Nivel 3 del CMM La base de datos que rene estadsticas de los proyectos pasados en curso, permite planificar y comparar el rendimiento. Existen mecanismos de comunicacin entre proyectos y departamentos, lo que garantiza una visin comn del producto y una rpida accin para enfrentar los problemas. Segn el autor [1], ha conocido unas pocas empresas a este nivel y la cosa que ms le llamo la atencin, fue la satisfaccin del personal. En empresas de nivel 1 habitualmente se escuchan quejas y acusaciones. A nivel 3 los empleados tienen una alta valoracin de los procesos y entienden 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 mejora visiblemente la calidad de los productos y minimiza las reiteraciones innecesarias. Curiosamente muchas organizaciones de nivel 1 realizan revisiones de pares, pero lo hacen de manera inconsistente y al primer signo de pnico las suspenden. Los pasos siguientes El nivel 3 ya es un estado avanzado y es percibido por algunos gerentes como un lujo. Si no todas, al menos unas cuantas de sus reas claves de procesos deben ser implementadas. KPAs del Nivel 3 Enfoque en el proceso de la organizacin

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 proceso de software. Ambos, producto y proceso, son seguidos en forma cuantitativa y se controlan mediante mtricas detalladas. La capacidad de rendimiento del proceso es previsible. Las mediciones permiten detectar cuando las variaciones del rendimiento se salen de los rangos aceptables, de manera que se puedan tomar medidas correctivas para asegurar la calidad. Beneficios de implantar el Nivel 4 del CMM La empresa es capaz de proponerse metas cuantitativas para la calidad de los productos y de los procesos de software. Es posible medir la productividad y calidad de los procesos de software a travs de todo el proyecto. Los proyectos pueden controlar la variacin del rendimiento de sus productos y procesos para mantenerla dentro de fronteras cuantitativas aceptables. Es posible discriminar las variaciones significativas en el rendimiento del proceso de la variacin (ruido) al azar, particularmente dentro de lneas de productos establecidas. Es necesario aclarar que el hecho de contar con un sistema de mtricas de software no significa que se est en el nivel 4. Es una virtual seal de alarma que les dice lo graves que son sus problemas, pero la inmadurez de sus procesos no les permite hacer nada efectivo, excepto tal vez abortar el producto para evitar un dao mayor que puede resultar de distribuirlo a los clientes. Los pasos siguientes Son muy raras las empresas que han decidido implementar este nivel. No son muchos los especialistas de procesos que realmente tengan experiencia prctica, o incluso que entiendan bien las reas claves de proceso del nivel 4. Son solamente 2 prcticas, pero imposibles de alcanzar si no se ha implementado firmemente los 2 niveles de madurez anteriores. KPAs del Nivel 4 Gestin cuantitativa del proceso Gestin de la calidad del software

5. Nivel 5: El mejoramiento permanente

La calidad planificada y confiable En el Nivel Optimizado, la caracterstica principal es el mejoramiento continuo del proceso, en base a la realimentacin cuantitativa y al ensayo de ideas y tecnologas innovadoras. Beneficios de implantar el Nivel 5 del CMM La organizacin entera se aboca al mejoramiento continuo del proceso. La corporacin cuenta con los medios para identificar las debilidades y reforzar el proceso, con objeto de prevenir la ocurrencia de defectos. Los datos relativos a la eficacia del proceso de software se usan para analizar el coste y el beneficio de usar nuevas tecnologas y de implementar cambios al proceso de software. Los proyectos de software analizan los defectos para determinar sus causas. Los proceso de software se evalan para prevenir que los defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros proyectos. Los pasos siguientes No existen ms de 10 empresas en el mundo que estn a este nivel (no hay ninguna en pases hispano-hablantes). Y las pocas que lo han logrado no divulgan sus secretos para mantener su ventaja competitiva. Este nivel es un estado ideal, que probablemente nunca ser alcanzado por la mayora de las empresas productoras de software. Luciano Guerrero [1] opina que es una hermosa utopa, pero inalcanzable en el mundo normal. KPAs del Nivel 5 2. La familia CMM Hay toda una familia de modelos de madurez (CMMs), aplicables a otros 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 de la Ingeniera de Sistemas. P-CMM: que significa Personal CMM, el cual cubre la administracin de P-CMM: personal. SA-CMM: que significa Software Acquisition, el cual cubre las prcticas de la adquisicin de productos de software. IPD-CMM: que significa Integrated Product Development, el cual cubre el 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 Prevencin de defectos Gestin del cambio de tecnologa Gestin del cambio del proceso

Modelo para la mejora y evaluacin de los procesos de desarrollo y mantenimiento 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 estndar internacional para la evaluacin de los procesos del ciclo de vida del software. Este trabajo recibi el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination), y en junio de 1995, con la publicacin de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para aplicarlo y valorar sus resultados. En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pas a la fase de informe tcnico con la denominacin ISO/IEC TR 15504. La instruccin tcnica consta de 9 apartados, recogidos en volmenes independientes que se han ido publicando como redaccin definitiva del estndar internacional ISO/IEC 15504 durante el periodo 2003 - 2005. Caractersticas

Establece un marco para mtodos de evaluacin, no es un mtodo o modelo en s. Comprende: evaluacin de procesos, mejora de procesos, determinacin de capacidad. Est alineado con el estndar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operacin de los sistemas de software. Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de sta ltima con 15504.

Dimensiones Tiene una arquitectura basada en dos dimensiones: de proceso y de capacidad de proceso. Desde la dimensin de proceso agrupa a los procesos en tres grupos que contienen cinco categoras de acuerdo al tipo de actividad: Procesos primarios

CUS: Cliente - Proveedor ENG: Ingeniera

Procesos de soporte

SUP: Soporte

Procesos organizacionales

MAN: Gestin ORG: Organizacin

Para todos los procesos se definen los componentes: Identificador, Nombre, Tipo, Propsito, Salidas y Notas. Desde la dimensin de capacidad el modelo define una escala de 6 niveles para determinar la capacidad de cualquier proceso:

Nivel 0: Incompleto Nivel 1: Realizado Nivel 2: Gestionado Nivel 3: Establecido

Nivel 4: Predecible Nivel 5: En optimizacin

3.5.3 METRICA3 La metodologa MTRICA Versin 3 ofrece a las Organizaciones un instrumento til para la sistematizacin de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos:

Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin mediante la definicin de un marco estratgico para el desarrollo de los mismos. Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al anlisis de requisitos. Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la reutilizacin en la medida de lo posible. Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software 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. Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.

En una nica estructura la metodologa MTRICA Versin 3 cubre distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a travs de interfaces la realizacin de los procesos de apoyo u organizativos: Gestin de Proyectos, Gestin de Configuracin, Aseguramiento de Calidad y Seguridad. La automatizacin de las actividades propuestas en la estructura de MTRICA Versin 3 es posible ya que sus tcnicas estn soportadas por una amplia variedad de herramientas de ayuda al desarrollo. 3.5.3.1 PROCESOS PRINCIPALES DE MTRICA MTRICA Versin 3 tiene un enfoque orientado al proceso, ya que la tendencia general en los estndares se encamina en este sentido y por ello, como ya se ha dicho, se ha enmarcado dentro de la norma ISO 12.207, que se centra en la clasificacin y definicin de los procesos del ciclo de vida del software. Como punto de partida y atendiendo a dicha norma, MTRICA Versin 3 cubre el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Informacin. MTRICA Versin 3 ha sido concebida para abarcar el desarrollo completo de Sistemas de Informacin sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos mximos y deber adaptarse y dimensionarse en cada momento de acuerdo a las caractersticas particulares de cada proyecto. La metodologa descompone cada uno de los procesos en actividades, y stas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, tcnicas, prcticas y participantes. El orden asignado a las actividades no debe interpretarse como secuencia en su realizacin, ya que stas pueden realizare en orden diferente a su numeracin o bien en paralelo, como se muestra en los grficos de cada proceso. Sin embargo, no se dar por acabado un proceso hasta no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto. As los procesos de la estructura principal de MTRICA Versin 3 son los

siguientes:

PLANIFICACIN DE SISTEMAS DE INFORMACIN. DESARROLLO DE SISTEMAS DE INFORMACIN. MANTENIMIENTO DE SISTEMAS DE INFORMACIN.

El enfoque del Proceso de Planificacin de Sistemas de Informacin, al no estar dentro del mbito de la norma ISO 12.207 de Procesos del Ciclo de Vida de Software, se ha determinado a partir del estudio de los ltimos avances en este campo, la alta competitividad y el cambio a que estn sometidas las organizaciones. El entorno de alta competitividad y cambio en el que actualmente se encuentran las organizaciones, hace cada vez ms crtico el requerimiento de disponer de los sistemas y las tecnologas de la informacin con flexibilidad para adaptarse a las nuevas exigencias, con la velocidad que demanda dicho entorno. La existencia de tecnologa de reciente aparicin, permite disponer de sistemas que apoyan la toma de decisiones a partir de grandes volmenes de informacin procedentes de los sistemas de gestin e integrados en una plataforma corporativa. MTRICA Versin 3 ayuda en la planificacin de sistemas de informacin facilitando una visin general necesaria para posibilitar dicha integracin y un modelo de informacin global de la organizacin. En cuanto al Proceso de Desarrollo de Sistemas de Informacin, para facilitar la comprensin y dada su amplitud y complejidad se ha subdividido en cinco procesos:

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

La necesidad de acortar el ciclo de desarrollo de los sistemas de informacin ha orientado a muchas organizaciones a la eleccin de productos software del mercado cuya adaptacin a sus requerimientos supona un esfuerzo bastante inferior al de un desarrollo a medida, por no hablar de los costes de mantenimiento. Esta decisin, que es estratgica en muchas ocasiones para una organizacin, debe tomarse con las debidas precauciones, y es una realidad que est cambiando el escenario del desarrollo del software. Otra consecuencia de lo anterior es la prctica, cada vez ms habitual en las organizaciones, de la contratacin de servicios externos en relacin con los sistemas y tecnologas de la informacin y las comunicaciones, llevando a la necesidad de una buena gestin y control de dichos servicios externos y del riesgo implcito en todo ello, para que sus resultados supongan un beneficio para la organizacin. MTRICA Versin 3 facilita la toma de decisin y la realizacin de todas las tareas que comprende el desarrollo de un sistema de informacin. Desde el enfoque de la norma ISO 12.207, el Proceso de Mantenimiento de Sistemas de Informacin comprende actividades y tareas de modificacin o retirada de todos los componentes de un sistema de informacin (hardware, software, software de base, operaciones manuales, redes, etc.). Este marco de actuacin no es el objetivo de MTRICA Versin 3, ya que esta metodologa est dirigida principalmente al proceso de desarrollo del software. Por lo tanto, MTRICA Versin 3 refleja los aspectos del Mantenimiento, correctivo y evolutivo, que tienen relacin con el Proceso de Desarrollo. 3.5.3.2 Interfaz Aseguramiento de la Calidad El objetivo de la interfaz de Aseguramiento de la Calidad de MTRICA Versin 3 es proporcionar un marco comn de referencia para la definicin y puesta en marcha de planes especficos de aseguramiento de calidad aplicables a proyectos concretos. Si en la organizacin ya existe un sistema de calidad,

dichos planes debern ser coherentes con el mismo, completndolo en los aspectos no contemplados relativos a normas particulares del cliente, usuario o sistema concreto. La calidad se define como grado en que un conjunto de caractersticas inherentes cumple con unos requisitos [ISO 9000:2000]. El Aseguramiento de la Calidad pretende dar confianza en que el producto reune las caractersticas necesarias para satisfacer todos los requisitos del Sistema de Informacin. Por tanto, para asegurar la calidad de los productos resultantes el equipo de calidad deber realizar un conjunto de actividades que servirn para: Reducir, eliminar y lo ms importante, prevenir las deficiencias de calidad de los productos a obtener. Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario queden satisfechas. Para conseguir estos objetivos, es necesario desarrollar un plan de aseguramiento de calidad especfico que se aplicar durante la planificacin del proyecto de acuerdo a la estrategia de desarrollo adoptada en la gestin del proyecto. En el plan de aseguramiento de calidad se reflejan las actividades de calidad a realizar (normales o extraordinarias), los estndares a aplicar, los productos a revisar, los procedimientos a seguir en la obtencin de los distintos productos durante el desarrollo en MTRICA Versin 3 y la normativa para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su correccin. El grupo de aseguramiento de calidad participa en la revisin de los productos seleccionados para determinar si son conformes o no a los procedimientos, normas o criterios especificados, siendo totalmente independiente del equipo de desarrollo. Las actividades a realizar por el grupo de aseguramiento de calidad vienen gobernadas por el plan. Sus funciones estn dirigidas a: Identificar las posibles desviaciones en los estndares aplicados, as como en los requisitos y procedimientos especificados. Comprobar que se han llevado a cabo las medidas preventivas o correctoras necesarias. Las revisiones son una de las actividades ms importantes del aseguramiento de la calidad, debido a que permiten eliminar defectos lo ms pronto posible, cuando son menos costosos de corregir. Adems existen procedimientos extraordinarios, como las auditoras, aplicables en desarrollos singulares y en el transcurso de las cuales se revisarn tanto las actividades de desarrollo como las propias de aseguramiento de calidad. La deteccin anticipada de errores evita el que se propaguen a los restantes procesos de desarrollo, reduciendo substancialmente el esfuerzo invertido en los mismos. En este sentido es importante destacar que el establecimiento del plan de aseguramiento de calidad comienza en el Estudio de Viabilidad del Sistema y se aplica a lo largo de todo el desarrollo, en los procesos de Anlisis, Diseo, Construccin, Implantacin y Aceptacin del Sistema y en su posterior Mantenimiento. 3.5.3.2.1 ESTUDIO DE VIABILIDAD DEL SISTEMA En este proceso el grupo de aseguramiento de calidad inicia el estudio de los sistemas de informacin definidos en cada alternativa de solucin propuesta, con el fin de identificar las condiciones en que se van a desarrollar y/o a implantar, as como las caractersticas que deben reunir en cuanto a operacin, mantenibilidad y portabilidad, para satisfacer las necesidades del cliente y los requisitos especificados. La necesidad de establecer un plan especfico de aseguramiento de calidad y el grado de intensidad con el que se aplican las actuaciones de calidad, vendr determinada en funcin de este estudio y de los riesgos analizados por el equipo de desarrollo. Una vez tomada la decisin de llevar a cabo un plan de aseguramiento de calidad en las alternativas propuestas, se define el contenido de

dicho plan, de acuerdo a los estndares de calidad, si existen en la organizacin, sino se recomienda acudir a los estndares UNE-EN-ISO 9001:2000 Sistemas de Gestin de la Calidad Requisitos y UNE-ENISO 9000:2000 Sistemas de Gestin de la Calidad Fundamentos y vocabulario. El plan de aseguramiento de calidad debe cubrir todas las necesidades establecidas de modo que, aquellas normas impuestas por los usuarios o clientes que difieran de las existentes en el sistema de calidad, deben quedar tambin reflejadas en el plan. El siguiente esquema muestra la correspondencia entre las actividades del proceso EVS y las de la interfaz de Aseguramiento de la Calidad.

ACTIVIDAD EVS-CAL 1: IDENTIFICACIN DE LAS PROPIEDADES DE CALIDAD PARA EL SISTEMA

ACTIVIDAD EVSCAL 2: ESTABLECIMIENTO ASEGURAMIENTO DE CALIDAD

DEL

PLAN

DE

ACTIVIDAD EVSCAL 3: ADECUACIN DEL ASEGURAMIENTO DE CALIDAD A LA SOLUCIN

PLAN

DE

3.5.3.2.2 ANLISIS DEL SISTEMA DE INFORMACIN En este proceso se define de forma detallada el plan de aseguramiento de calidad para un sistema de informacin, a partir de la especificacin resultante del proceso Estudio de Viabilidad del Sistema (EVS). Tambin se detallan los estndares y normas a cumplir, las revisiones a llevar a cabo y sobre qu productos, as como los procedimientos y mecanismos necesarios para resolver los problemas que surjan, definiendo las acciones preventivas o correctoras para su posterior correccin e identificando quines son los responsables en cada caso. En el proceso Anlisis del Sistema de Informacin (ASI), el grupo de aseguramiento de calidad se implica directamente en la revisin de los siguientes productos: Catlogo de requisitos, comprobando hasta que punto se han definido de una forma que facilite su comprensin y seguimiento. Modelos resultantes del anlisis, asegurando que se han verificado y validado y que se ha realizado la trazabilidad de requisitos. Plan de pruebas, comprobando que se han tenido en cuenta en su definicin los criterios establecidos en el plan de aseguramiento de calidad, con el fin de facilitar en los procesos Diseo del Sistema de Informacin (DSI), Construccin del Sistema de Informacin (CSI) e Implantacin y Aceptacin del Sistema (IAS) la revisin de los distintos niveles de prueba.

ACTIVIDAD ASI-CAL 1: ESPECIFICACIN INICIAL DEL PLAN DE ASEGURAMIENTO DE CALIDAD

ACTIVIDAD ASICAL 2: ESPECIFICACIN DETALLADA DEL PLAN DE ASEGURAMIENTO DE CALIDAD

ACTIVIDAD ASI-CAL 3: REVISIN DEL ANLISIS DE CONSISTENCIA

ACTIVIDAD ASI-CAL 4: REVISIN DEL PLAN DE PRUEBAS

Actividad ASI-CAL 5: Registro de la Aprobacin del Anlisis del Sistema

3.5.3.2.3 DISEO DEL SISTEMA DE INFORMACIN Las revisiones del diseo se centran en confirmar que los requisitos especificados en el proceso Anlisis del Sistema de Informacin se han traducido en una arquitectura conforme al entorno tecnolgico seleccionado. Asimismo, se revisan los requisitos que deben cumplir los distintos niveles de pruebas (unitarias, de integracin, del sistema, de implantacin y aceptacin) especificados en el plan de pruebas, de acuerdo a los criterios de revisin establecidos en el plan de aseguramiento de calidad. Tambin se realiza una revisin de la identificacin de los requisitos no funcionales relacionados con la documentacin de usuario e implantacin. El siguiente esquema muestra la correspondencia entre las actividades del proceso DSI y las de la interfaz de Aseguramiento de la Calidad.

ACTIVIDAD DSICAL 1: REVISIN DE LA VERIFICACIN DE LA ARQUITECTURA DEL SISTEMA

ACTIVIDAD DSICAL 2: REVISIN DE LA ESPECIFICACIN TCNICA DEL PLAN DE PRUEBAS

ACTIVIDAD DSICAL 3: REVISIN DE LOS REQUISITOS DE IMPLANTACIN

ACTIVIDAD DSI-CAL 4: REGISTRO DE LA APROBACIN DEL DISEO DEL SISTEMA DE INFORMACIN

3.5.3.2.4 CONSTRUCCIN DEL SISTEMA DE INFORMACIN En este proceso el grupo de aseguramiento de calidad revisa los estndares de nomenclatura y normativa aplicada en la generacin del cdigo de componentes, en la evaluacin de los resultados de las pruebas, en los manuales de usuario y en el esquema de formacin. Con respecto a las pruebas, se revisa que se han llevado a cabo las pruebas unitarias, de integracin y del sistema segn los criterios de seleccin de verificaciones y casos de prueba asociados que se habrn fijado en el plan de aseguramiento de calidad. El siguiente esquema muestra la correspondencia entre las actividades del proceso CSI y las de la interfaz de Aseguramiento de la Calidad.

ACTIVIDAD CSICAL 1: REVISIN DEL CDIGO DE COMPONENTES Y PROCEDIMIENTOS

ACTIVIDAD CSICAL 2: REVISIN DE LAS PRUEBAS UNITARIAS, DE INTEGRACIN Y DEL SISTEMA

ACTIVIDAD CSICAL 3: REVISIN DE LOS MANUALES DE USUARIO

ACTIVIDAD CSICAL 4: REVISIN DE LA FORMACIN A USUARIOS FINALES

ACTIVIDAD CSI-CAL 5: REGISTRO DE LA APROBACIN DEL SISTEMA DE INFORMACIN

3.5.3.2.5 IMPLANTACIN Y ACEPTACIN DEL SISTEMA El grupo de aseguramiento de calidad en este proceso es responsable de revisar la existencia de un plan de implantacin que se habr elaborado conforme a la estrategia de implantacin determinada en el proceso Estudio de Viabilidad del Sistema (EVS) y teniendo en cuenta los requisitos de implantacin establecidos en el proceso Diseo del Sistema de Informacin (DSI).

Tambin deben comprobar que se han realizado las pruebas de implantacin y de aceptacin segn el plan de pruebas establecido en MTRICA Versin 3 y la normativa acordada en el plan de aseguramiento de calidad. Revisan la totalidad de las verificaciones y casos de prueba de implantacin y aceptacin que se hayan especificado para el sistema y las incidencias producidas, con el fin de determinar si puede verse afectada alguna propiedad de calidad. En cualquier caso, se registra la aprobacin de las pruebas de implantacin y de aceptacin por parte de operacin y del usuario respectivamente. En cuanto al mantenimiento, el grupo de aseguramiento de calidad debe asegurar que se le entrega el producto software al responsable de mantenimiento, con las propiedades adecuadas para que pueda asumir el servicio de mantenimiento, una vez que el sistema se encuentre en produccin. El siguiente esquema muestra la correspondencia entre las actividades del proceso IAS y las de la interfaz de Aseguramiento de la Calidad.

ACTIVIDAD IAS-CAL 1: REVISIN DEL PLAN DE IMPLANTACIN DEL SISTEMA

ACTIVIDAD IASCAL 2: REVISIN IMPLANTACIN DEL SISTEMA

DE

LAS

PRUEBAS

DE

ACTIVIDAD IASCAL 3: REVISIN ACEPTACIN DEL SISTEMA

DE

LAS

PRUEBAS

DE

ACTIVIDAD IASCAL 4: REVISIN DEL PLAN DE MANTENIMIENTO DEL SISTEMA

ACTIVIDAD IASCAL 5: REGISTRO DE LA APROBACIN DE LA IMPLANTACIN DEL SISTEMA

3.5.3.2.6 MANTENIMIENTO DEL SISTEMA DE INFORMACIN En el proceso Implantacin y Aceptacin del Sistema se habr determinado la necesidad de llevar a cabo un seguimiento y control de la

calidad en los sistemas de informacin, una vez se encuentren en el entorno de produccin. El grupo de aseguramiento de calidad intenvendr durante el mantenimiento, efectuando revisiones de seguimiento peridicas, ms o menos frecuentes segn los casos, que sirvan para constatar que el mantenimiento establecido para el sistema de informacin se realiza de forma correcta. En algn caso, segn las implicaciones del cambio, puede ser necesario revisar puntualmente: El contenido del plan de pruebas de regresin. La ejecucin de las pruebas de regresin segn la normativa acordada en el plan de aseguramiento de calidad. Las verificaciones y casos de prueba que se hayan incluido en el plan de pruebas para los cambios producidos por una peticin. Las incidencias detectadas con el fin de determinar si puede verse afectada alguna propiedad de calidad. En caso de revisar la ejecucin de las pruebas de regresin, se registrar la aprobacin de las pruebas por el responsable de mantenimiento. En el siguiente grfico se aprecian las actividades de Aseguramiento de la Calidad durante el Mantenimiento del Sistema de Informacin.

ACTIVIDAD MSI-CAL 1: REVISIN DEL MANTENIMIENTO DEL SISTEMA DE INFORMACIN

ACTIVIDAD MSICAL 2: REVISIN DEL PLAN DE PRUEBAS DE REGRESIN

ACTIVIDAD MSICAL3: REVISIN DE LA REALIZACIN DE LAS PRUEBAS DE REGRESIN

IV. METODOLOGA DE GESTIN DE PROYECTO 4.1. Aseguramiento de calidad del software (Software Quality Assurance) El aseguramiento de calidad del software es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad. El aseguramiento de calidad del software se disea para cada aplicacin antes de comenzar a desarrollarla y no despus. Algunos autores prefieren decir garanta de calidad en vez de aseguramiento. Garanta, puede confundir con garanta de productos Aseguramiento pretende dar confianza en que el producto tiene calidad El aseguramiento de calidad del software est presente en los siguientes casos: Mtodos y herramientas de anlisis, diseo, programacin y prueba Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo del software 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 est fuera de ellos) Mecanismos de medida (mtricas) Registro de auditorias y realizacin de informes Actividades para el aseguramiento- de calidad del software 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

4.2. Aseguramiento de la Calidad de software Se explican conceptos que los auditores deben evaluar y sobre los que deben informar al comprador pblico. Aparecern durante la realizacin de la auditora, pero su especificacin debe realizarse al principio. Se conoce como garanta de calidad de Software (SQA, Software Quality Assurance) al conjunto de actividades que se aplican a lo largo de todo el proceso de ingeniera del software. SQA engloba: Mtodos y herramientas de anlisis, diseo, codificacin y prueba. Revisiones tcnicas formales que se aplican durante cada paso de la ingeniera del software. Pruebas de software secuenciadas en mltiples pasos y con mtodos especficos de diseo de casos de prueba. Control de la documentacin del software y de los cambios

realizados. Procedimientos que aseguren un ajuste a los estndares de desarrollo de software. Mecanismos de medida y de informacin. Mtricas para medir la calidad del software. Todo este proceso se realiza de forma interna. La propia organizacin puede tener un grupo de SQA que se encargue de la realizacin de todas las tareas necesarias. Es posible tener un grupo de consultores externos dedicados a SQA pero, a poco que la organizacin tenga una mediana actividad de desarrollo, los costes econmicos de esta opcin pueden ser elevados. SQA es un proceso de control. La auditora que puede encargarse de SQA sin sufrir contradiccin con la idea de punto discontinuo de control es la auditora interna que, siendo la encargada de las tareas de control interno y estando realizada por personal propio, dispone de los medios y estructura de costes adecuados. Los factores que determinan la calidad del software se pueden clasificar en dos grandes grupos: Factores que pueden ser medidos directamente. Factores que slo pueden ser medidos indirectamente. En cualquiera de los dos casos debemos comparar el software con una referencia y llegar a una indicacin de la calidad. Se han propuesto los siguientes factores de calidad del software: Correccin: El grado en que un programa satisface sus especificaciones y consigue los objetivos encomendados. Fiabilidad: El grado en que se puede esperar que un programa lleve a cabo sus funciones con la precisin requerida. Eficiencia: La cantidad de recursos de ordenador y de cdigo requeridos por un programa para llevar a cabo sus funciones. Integridad: La informacin utilizada ser la ltima, exacta, autorizada y completa. Facilidad de uso: Esfuerzo requerido para trabajar con un programa. Facilidad de mantenimiento: Esfuerzo requerido para localizar y arreglar el error en un programa. Flexibilidad: Esfuerzo requerido para modificar un programa operativo. Facilidad de prueba: Esfuerzo requerido para probar un programa. Portabilidad: Esfuerzo requerido para transferir un programa desde un entorno operativo a otro. Reusabilidad: El grado en que un programa se puede reusar en otras aplicaciones. Facilidad de interoperacin: Esfuerzo requerido para acoplar un sistema a otro.

Es difcil para los auditores desarrollar medidas directas de los anteriores factores de calidad. Por tanto, para medir cuantitativamente cada uno de los factores cada oferta deber expresar claramente qu mtricas utiliza para la evaluacin del software. La garanta de calidad del software (SQA) es un planificado y sistemtico diseo de acciones para asegurar la calidad del software. El personal que lleva a cabo la SQA debe mirar el software desde el punto de vista del usuario. Se ha realizado el desarrollo de software de acuerdo con los estndares establecidos? Las disciplinas tcnicas han desempeado apropiadamente sus papeles? La calidad del software debe estar pensada para un producto o sistema o conjunto de sistemas; no es algo impuesto a posteriori. La SQA utiliza un conjunto de herramientas y mtodos tcnicos que ayudan al analista a conseguir una especificacin y un diseo de alta calidad. Una vez que se ha creado una especificacin, un diseo o un mdulo, debe ser garantizada de algn modo su calidad. La actividad central que permite garantizar la calidad es la revisin tcnica formal. El personal tcnico se rene con el nico propsito de descubrir problemas de calidad. Otro mtodo usado comnmente es la prueba de software. Este procedimiento combina mltiples pasos con una serie de mtodos de diseo de casos de prueba que ayudan a asegurar una efectiva deteccin de errores. Muchos grupos de desarrollo de software usan la prueba como una red de seguridad para la garanta de la calidad. Se asume que mediante la prueba se descubrir la mayora de los errores, mitigando as la necesidad de otras actividades de SQA. El grado de aplicacin de procedimientos y estndares en el proceso de ingeniera del software vara ampliamente dependiendo de la organizacin de la que se trate. Si existen estndares formales, escritos, se deben establecer actividades de SQA para garantizar que se siguen. Una de las principales amenazas para la calidad del software proviene de una actividad supuestamente beneficiosa: los cambios. El proceso de control de cambios debe venir especificado por la metodologa de desarrollo de sistemas que se use en esa organizacin. Enfoques formales a la SQA Todo lo que se ha comentado hasta ahora de SQA se concreta en la prctica en un conjunto de actividades que se deben realizar durante el desarrollo de sistemas. Debido a esto, previamente se seal que son actividades de control, no de auditora;

alternativamente, se les puede llamar actividades de auditora interna. Segmentos de la comunidad de ingenieros de software vienen sosteniendo que se deben implementar una serie de controles ms rigurosos, de tipo matemtico y estadstico. Estos controles pueden ser efectuados en cualquier momento, incluso en la fase de explotacin de sistemas. Se describirn dos tcnicas, que pueden ser el objetivo de un proyecto de auditora que abarque el rea de explotacin de SQA: Proceso limpio de creacin de software El proceso limpio de creacin del software se centra en la consecucin del objetivo de nmero de defectos nulo. La idea terica central es conseguir la verificacin matemtica de la correccin de elementos de un sistema de informacin. Sin embargo, por el momento no se ha conseguido llevar a la prctica esta idea para sistemas medianamente complejos, aunque no sea totalmente descartable que en el medio plazo se avance en esta direccin. En segundo lugar, se debe proporcionar una certificacin de calidad estadstica. Para ilustrar este proceso, supongamos que una organizacin de desarrollo de software recoge informacin sobre defectos durante un ao, tanto en explotacin como en construccin de sistemas (esto puede constituir por s mismo un proyecto de control). Aunque se descubran cientos de errores diferentes, todos ellos pueden encuadrarse dentro de una o varias causas. Los errores detectados debern ser clasificados en tres categoras: muy graves, graves, menores. Con estas dos clasificaciones (causa e importancia) se podrn establecer conclusiones estadsticas, que permitirn tomar medidas de correccin. Esta tcnica permite efectuar una eliminacin sistemtica de las causas de los defectos empezando por los ms serios y mejorando la utilizacin de los recursos. Medidas de fiabilidad La fiabilidad del software se define en trminos estadsticos como la probabilidad de operacin libre de fallos de un programa de ordenador en un entorno determinado y durante un tiempo especfico. Una sencilla medida de fiabilidad es el tiempo medio entre fallos (MTBF, Mean Time Between Failures- es el tiempo medio entre fallos de un sistema), y la duracin total de sus reparaciones, medida como el tiempo medio de la reparacin (MTTR, Mean Time To Repare es el tiempo medio de reparacin) desde la comunicacin del envo, contando desplazamientos del personal y la duracin

de la reparacin de la unidad averiada. Muchos investigadores argumentan que esta medida es ms eficiente que la medida que se usa generalmente para evaluar la cantidad de errores, que es el nmero de errores por cada mil lneas de cdigo. 4.3. Mtodos y herramientas de anlisis, diseo y codificacin La calidad del software debe estar diseada para el producto o sistema, no es algo impuesto a posteriori. Por esta razn, la garanta de calidad del software comienza realmente con un conjunto de herramientas y mtodos tcnicos que ayudan al analista a conseguir una especificacin y un diseo de alta calidad. En un proceso de desarrollo software, existen una serie de fases que vienen determinadas por las tareas bsicas que hay que realizar para obtener el producto software. Se definen distintos ciclos de vida de acuerdo a la evolucin del software a lo largo de dichas fases. Las fases ms tpicas son: Requisitos del Sistema: tambin llamada anlisis de requisitos, especificacin o diseo conceptual o diseo de alto nivel. Segn (Durn Toro, Bernrdez Jimnez, Corchuelo Gil, & Toro Bonilla, 2000) en (IEEE, 1990) se define: Requisitos: (a) una condicin o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. (b) una condicin o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, especificacin u otro documento formal. (c) una representacin en forma de documento de una condicin o capacidad como las expresadas en (a) o (b).

La ingeniera de requisitos se define como: Todas las actividades relacionadas con: (a) identificacin y documentacin de las necesidades del cliente y usuarios, (b) creacin de un documento que describe la conducta externa y las restricciones asociadas del sistema que satisfar dichas necesidades. (c) anlisis y validacin del documento de requisitos para asegurar su consistencia, viabilidad y que sea completo. (d) Evolucin de las necesidades. Existen varias propuestas en cuanto a las actividades que conlleva la ingeniera de requisitos. Por su claridad, se ha utilizado la presentada en (Durn Toro et al., 2000), que comprende tres actividades principales: obtencin, anlisis y validacin. La mayor parte de las normas y autores asumen que el proceso de obtencin de los requisitos, su anlisis y validacin es iterativo por naturaleza, ya que se reconoce que es prcticamente imposible obtener todos los requisitos y que stos sean correctos sin tener

que volver atrs en algn momento del proceso. Las actividades son:

Obtencin (Elicitation1) de Requisitos: los clientes, compradores o usuarios del sistema a desarrollar descubren, revelan, articulan y entienden sus propios requisitos. Los requisitos se obtienen con entrevistas, cuestionarios, reuniones de las distintas partes implicadas y diversas tcnicas cuyo resultado deben ser los requisitos orientados al cliente o tambin llamados requisitos-C.
(1 El trmino en ingls elicitatin se utiliza en la obtencin de requisitos para definir la actividad realizada por el analista con el fin de proteger la informacin que de las necesidades del sistema tienen los usuarios finales, los expertos y los clientes.)

Anlisis de requisitos: se debe razonar sobre los requisitos- C para comprender mejor el problema, detectar conflictos o inconsistencias, combinar requisitos relacionados e identificar nuevos requisitos, normalmente mediante la construccin de modelos, en la que podran participar aquellos clientes y usuarios con los conocimientos apropiados. El producto de esta actividad son los requisitos orientados al desarrollador o requisitos- D, y en algunas ocasiones, un prototipo. Adems, esta actividad debe ser capaz de mostrar el conocimiento tcito, aquello que los usuarios no comentan por olvidarlo o considerarlo obvio. En esta fase ya se estn tomando decisiones de cmo hacer el sistema ya que se realiza una descomposicin del sistema en subpartes siguiendo la tcnica de divide y vencers. Validacin de requisitos: los clientes y usuarios deben confirmar que los requisitos- C, una vez analizados, son vlidos, correctos y completos, mediante las inspecciones de los documentos generados y mediante la evaluacin del prototipo, proceso que por lo general conlleva la obtencin de nuevos requisitos. Adems ser necesario validar que los requisitos -D encajan con los requisitos -C. La nomenclatura de los requisitos (requisitos-C para los del cliente y requisitosD para los del desarrollador) fue presentada en (Brackett, 1990) y est siendo aceptada por algunos autores como (Durn Toro et al., 2000). La manera habitual de expresar los requisitos-C es el lenguaje natural, que puede acompaarse del uso de plantillas y patrones lingsticos para facilitar su uso. La forma de expresar los requisitos D suele ser mediante un modelo construido con tcnicas estructuradas (DFD, ERD, etc), tcnicas orientadas a objetos (OMT, UML, etc) o tcnicas formales. Dado que diversos estudios han revelado que el alto ndice de fracasos en los proyectos de desarrollo software tiene como principales causas actividades relacionadas con los requisitos (falta de participacin de los usuarios, requisitos incompletos y frecuentes cambios de los requisitos iniciales), es lgico que muchos estudios se basen

en esta etapa, por lo que las publicaciones relativas a la ingeniera de requisitos han sido abundantes en los ltimos aos (por ejemplo, los nmeros especiales de las revistas IEEE Software Marzo/Abril 1998 o el de Communications of the ACM Diciembre 1998 as como diversos libros). Adems, existen multitud de mtodos de modelado en general que se utilizan para el modelado de los requisitos-D. Otro ejemplo es el proyecto MENHIR: Metodologas, Entornos y Nuevas Herramientas para la Ingeniera de Requisitos (Proyecto de la CICYT TIC 97- 0593-C05-0).

Diseo: tambin llamado diseo arquitectural o diseo de bajo nivel. Partiendo del modelo de anlisis de requisitos obtenido en la fase anterior, se transforma ste en un conjunto de entes fsicos (hardware) y entes lgicos (software) inter-relacionados entre s que no tienen por qu conservar la misma estructura que en el modelo inicial. Cualquier cambio en dicha estructura con respecto a la del modelo inicial debe ir acompaado de las razones que lo han aconsejado, que suelen ser ciertas caractersticas que en su momento no se conoca, o no se tuvieron en cuenta por ser un aspecto de mayor nivel de detalle. Aunque en principio los requisitos -C afectan principalmente a la fase de anlisis de requisitos y se utilizan para la creacin de los requisitos -D (que evidentemente influyen directamente en la fase de diseo), puede darse el caso de que alguno de los requisitos del cliente tengan efecto directo sobre esta fase de diseo. Implantacin e Integracin: tambin llamada codificacin. Consiste en la codificacin del software utilizando un lenguaje de programacin siguiendo la estructura y comportamiento determinados en el diseo. Revisiones del software que se aplican durante cada paso del desarrollo del mismo Una vez que se ha creado una especificacin y un diseo de un software, debe garantizarse su calidad. Las revisiones del software son un filtro para el proceso de ingeniera del software y se aplican en varios momentos del desarrollo. Sirven para detectar fallos tanto en el anlisis como en el diseo y la codificacin, de manera que puedan ser eliminados cuanto antes. Es necesario partir de la idea de que todo el mundo comete errores, pero algunos de ellos se le pasan por alto ms fcilmente al que los origina que a otras personas. Los errores cometidos en pasos anteriores se amplifican en el paso siguiente. Segn las estadsticas, las actividades de diseo introducen entre el 50 y el 65 por 100 de todos los errores, por lo que cualquier tcnica que permita detectar los errores en las fases iniciales del desarrollo del software ser de gran utilidad. Existen muchos tipos diferentes de revisiones dependiendo de qu se revise y el tipo de profesional que lo revise. Una de ellas son las revisiones tcnicas formales o inspecciones, llevadas a cabo por ingenieros del software. Las revisiones tcnicas formales

son el filtro ms efectivo desde el punto de vista de la garanta del software, ya que detectan el 75% de los errores cometidos en el diseo. Los objetivos de la revisin tcnica formal son: (a) Descubrir errores en la funcin, la lgica o la implantacin de cualquier representacin del software. (b) Verificar que el software bajo revisin alcanza sus requisitos. (c) Garantizar que el software ha sido representado de acuerdo con ciertos estndares predefinidos. (d) Conseguir un software desarrollado de forma uniforme. (e) Hacer que los proyectos sean ms manejables. 4.4. Estrategia de prueba La prueba del software es un elemento crtico para la garanta de calidad del software y representa una revisin final de las especificaciones, del diseo y la codificacin. La prueba requiere que se descarten las ideas preconcebidas sobre la correccin del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezca cuando se detecten errores. En un libro clsico sobre la prueba del software (Myers, 1979) se establecen una serie de reglas que pueden entenderse como objetivos de la prueba: (a) La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. (b) Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. (c) Una prueba tiene xito si descubre un error no detectado hasta entonces. Debido a la importancia de las pruebas para la calidad y a su dificultad, existen mltiples tcnicas de prueba. En (Press m, 1995) se muestran algunas de estas tcnicas de prueba. Procedimiento que asegure un ajuste a los estndares de desarrollo del software. Gestin de configuraciones de software (control de la documentacin del software y de los cambios realizados) La gestin de configuraciones del software es una actividad protectora que se aplica a lo largo del proceso de ingeniera del software. Se trata de un conjunto de actividades de seguimiento y control que comienza al principio del proyecto de desarrollo del software y finaliza slo una vez que el software queda fuera de circulacin. Los elementos que componen toda la informacin producida se denominan configuracin del software (programas, documentos que describen los programas y estructuras de datos). La elaboracin de la documentacin

resulta muy costosa, por lo que es necesario intentar reducirla lo ms posible y realizarla cuando los beneficios que conlleve superen el coste de su realizacin. Una de las principales amenazas para la calidad del software viene de una fuente aparentemente benigna: los cambios. El proceso de control de cambios contribuye directamente a la calidad del software. El control de cambios se aplica durante el desarrollo del software y, posteriormente, durante su mantenimiento. Ya que un cambio se puede producir en cualquier momento, las actividades de la gestin de configuraciones del software sirven para: (1) identificar el cambio; (2) controlar el cambio; (3) garantizar que el cambio se implementa adecuadamente; (4) informar del cambio a todos aqullos a los que afecte. En (Belin, 1998) se muestran de manera resumida las ideas principales de la gestin de la configuracin. Mecanismos de medida. La medicin es una actividad fundamental para cualquier disciplina de ingeniera. Un objetivo importante de la garanta de calidad es seguir la pista a la calidad del software y evaluar el impacto de los cambios de metodologa y de procedimiento que intentan mejorar la calidad del software. Para conseguirlo, se deben recolectar mtricas del software, como se ver ms adelante. Registro y realizacin de informes. Son procedimientos para la recoleccin y divulgacin de informacin de la garanta de calidad del software. Los resultados de las revisiones, auditoras, control de cambios, prueba y otras actividades de la garanta de calidad deben convertirse en una parte del registro histrico de un proyecto. Adems, deben ser divulgados a la plantilla de desarrollo para que tenga conocimiento de ellos.

V. AUDITORIAS DE SEGURIDAD [5.1] 5.1 Auditoras Tcnicas Centrndonos ahora en las auditoras tcnicas, dependiendo de la profundidad de los trabajos, hablaremos de auditoras de vulnerabilidades, que tratan de localizar configuraciones errneas o relajadas en exceso y agujeros de seguridad en el software directamente explotables, habitualmente con el apoyo de herramientas que automatizan parte del trabajo, y proyectos de hacking controlado, pruebas de intrusin o auditoras a nivel de aplicacin, en la que los trabajos se expanden para dejar sitio al lado ms "creativo y artesano" de los auditores de seguridad, que tratan de explotar errores de programacin, la arquitectura de red y las relaciones de confianza, las debilidades de los protocolos de comunicacin y los controles de acceso para simular los ataques a una infraestructura de red bajo los perfiles que se consideren de inters (atacante externo con distinto nivel de calificacin, usuario interno, auditor, administrador, competencia...) bajo las mismas circunstancias y capacidades (informacin inicial, puntos de acceso, recursos disponibles...).

Por otro lado, dependiendo de la aproximacin que tomemos para realizar las auditoras tcnicas, hablaremos de pruebas de caja negra, que buscan las debilidades desde el exterior de los sistemas (habitualmente realizadas de forma remota, desde Internet), y pruebas de caja blanca, que realizan una revisin de seguridad analizando la configuracin del propio sistema, con acceso al mismo. Una auditora de seguridad de caja negra normalmente comienza con trabajos desde el exterior, para encontrar puntos dbiles y ganar algn tipo de acceso a los sistemas, y una vez conseguido este acceso, examinar el sistema para escalar privilegios y tomar control sobre l. Estas pruebas desde hace tiempo se vienen realizando basndose en el estndar OSSTMM (Open Source Testing Methodology Manual) o el documento SP 800-46 del NIST (instituto de estndares americano) que contemplan las pruebas a realizar para realizar una revisin de seguridad tcnica completa. En el caso de una auditora de caja blanca el objetivo no es lograr el acceso (la empresa lo proporciona para realizarla) sino revisar las medidas de seguridad implementadas en el sistema y su conformidad, o no, con estndares reconocidos y guas de "buenas prcticas", como por ejemplo, los trabajos del instituto de estndares norteamericanos, NIST, el CSI, Center of Internet Security, o del SANS Institute. 5.1.1. PRUEBA DE CAJA BLANCA Por el contrario, las pruebas de caja blanca, como se ha mencionado anteriormente, examinan el sistema desde su interior. Por lo tanto es necesario tener un acceso a los sistemas. Este acceso generalmente se obtiene porque directamente se le proporciona al auditor un acceso al equipo para que pueda realizar un anlisis en profundidad de la configuracin del sistema, aunque en algunos casos una prueba de caja negra se convierte en caja blanca por haber logrado un acceso al sistema a travs de alguna vulnerabilidad del mismo u obtener informacin que pueda analizarse de esta forma (por ejemplo, el cdigo fuente de las aplicaciones utilizadas). Es importante destacar que estas pruebas son complementarias de las anteriores, ya que el hecho de no haber encontrado vulnerabilidades en las pruebas de "caja negra", no significa que no las haya, si no que generalmente significar que no se han dedicado recursos suficientes a descubrirlas. Dicho de otra forma, el hecho de que un sistema sea o no vulnerable no radica en que se encuentre una vulnerabilidad, si no en que exista dicha vulnerabilidad. Siguiendo con esta filosofa, es necesario ampliar la informacin que se posee sobre los sistemas al mximo, incluyendo topologa, protocolos utilizados, reglas en los cortafuegos, software empleado,

etc. As, durante esta fase normalmente se realizan las siguientes tareas:

Anlisis de la configuracin de todos los sistemas operativos implantados: usuarios, ficheros, etc. Anlisis de la robustez de las contraseas utilizadas. Anlisis de la configuracin del software de base (Web, Mail, cortafuegos, etc.). Anlisis del cdigo fuente de las aplicaciones instaladas o desarrolladas a medida. Determinacin de las vulnerabilidades presentes en los sistemas debido a la desactualizacin en la aplicacin de parches de seguridad (obsolescencia de los sistemas).

En algunos casos estas tareas de anlisis pueden ser automatizadas con algunas herramientas pero en la mayora de los casos se realizarn de forma manual y requerirn de un conocimiento profundo de los sistemas auditados, recomendaciones del fabricante, etc. Generalmente estas inspecciones, aunque ms laboriosas hacen que la tarea analticacorrectora produzca un resultado cualitativamente superior. 5.1.2. PRUEBA DE CAJA NEGRA Las pruebas de caja negra, para que sean realmente efectivas, deben realizarse sin ningn conocimiento de la infraestructura, garantizando de esta forma que el anlisis no tratar de utilizar ningn tipo de informacin que facilite la tarea de anlisis. El propsito de estas pruebas es que el auditor se comporte como si realmente fuese un "atacante" de la infraestructura. Durante un anlisis de caja negra normalmente se llevarn a cabo pruebas de visibilidad (para conocer los servicios y versiones de stos activos y visibles desde el exterior en cada uno de los sistemas), pruebas de identificacin de servicios (para determinar qu programas ofrecen los servicios ofrecidos, a travs de las cabeceras obtenidas o respuestas programticas y no findose de la lista de puertos TCP/IP conocidos), obtencin de informacin (recuperacin de informacin o datos de configuracin del sistema final o sistemas adyacentes que desvelen detalles de la infraestructura auditada) y pruebas de vulnerabilidades en software estndar. Estas ltimas pruebas son las ms complejas y se realizarn una vez determinados los servicios que se estn corriendo, junto con la informacin disponible de versiones y sistemas operativos. Se basan en una parte que puede ser realizada por herramientas de diagnstico automticas y otra parte que debe ser realizada de forma manual por el auditor. Esta fase tiene que realizarse con ciertas precauciones puesto que son frecuentes los casos en que las pruebas de vulnerabilidades que puedan tener xito produzcan cortes de servicio o cadas en los sistemas auditados.

Una vez se ha conseguido penetrar con xito en un sistema, la auditora de caja negra puede continuar hacia otros sistemas adyacentes (generalmente ms expuestos una vez traspasado el permetro) y tambin derivar hacia anlisis de caja blanca. 5.2. Tipos de Pruebas [5.2] 5.2.1. Pruebas de unidad: La prueba de unidad se centra en el mdulo. Usando la descripcin del diseo detallado como gua, se prueban los caminos de control importantes con el fin de descubrir errores dentro del mbito del mdulo. La prueba de unidad hace uso intensivo de las tcnicas de prueba de caja blanca. 5.2.2. Prueba de integracin: El objetivo es coger los mdulos probados en la prueba de unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. Hay dos formas de integracin:

Integracin no incremental: Se combinan todos los mdulos por anticipado y se prueba todo el programa en conjunto. Integracin incremental: El programa se construye y se prueba en pequeos segmentos.

En la prueba de integracin el foco de atencin es el diseo y la construccin de la arquitectura del software. Las tcnicas que ms prevalecen son las de diseo de casos de prueba de caja negra, aunque se pueden llevar a cabo unas pocas pruebas de caja blanca. 5.2.3. Prueba del sistema: Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema est constituida por una serie de pruebas diferentes cuyo propsito primordial es ejercitar profundamente el sistema basado en computadora. Algunas de estas pruebas son:

Prueba de validacin: Proporciona una seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Adems, valida los requerimientos establecidos comparndolos con el sistema que ha sido construido. Durante la validacin se usan exclusivamente tcnicas de prueba de caja negra. Prueba de recuperacin: Fuerza un fallo del software y verifica que la recuperacin se lleva a cabo apropiadamente. Prueba de seguridad: Verificar los mecanismos de proteccin.

Prueba de resistencia: Enfrenta a los programas a situaciones anormales. Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecucin. Prueba de instalacin: Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o continuas interrupciones.

5.2.4. Pruebas de regresin: Las pruebas de regresin son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versin modificada, para asegurar la calidad despus de aadir la nueva funcionalidad. El propsito de estas pruebas es asegurar que:

Los defectos identificados en la ejecucin anterior de la prueba se ha corregido. Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores.

La prueba de regresin puede implicar la re-ejecucin de cualquier tipo de prueba. Normalmente, las pruebas de regresin se llevan a cabo durante cada iteracin, ejecutando otra vez las pruebas de la iteracin anterior. 5.3. Estrategias de pruebas del software: Una estrategia de prueba del software integra las tcnicas de diseo de casos de prueba en una serie de pasos bien planificados que llevan a la construccin correcta del software. Las caractersticas generales son:

La prueba comienza en el nivel de mdulo y trabaja hacia afuera. En diferentes puntos son adecuadas a la vez distintas tcnicas de prueba. La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente. La prueba y la depuracin son actividades diferentes.

Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, as como de pruebas de alto nivel. . Ms concretamente, los objetivos de la estrategia de prueba son:

Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de unidad, integracin y las pruebas de sistema. Las pruebas de unidad y de integracin son necesarias dentro de la

iteracin, mientras que las pruebas de sistema son necesarias slo al final de la iteracin. Disear e implementar las pruebas creando los casos de prueba que especifican qu probar, cmo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas. Realizar diferentes pruebas y manejar los resultados de cada prueba sistemticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseo o implementacin, de forma que los defectos puedan ser arreglados.

Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:

Planificacin de las pruebas. Diseo de las pruebas. Implementacin de las pruebas. Ejecucin de las pruebas. Evaluacin de las pruebas. fundamentales que se

Los productos de desarrollo del software desarrollan en la etapa de Pruebas son:

Plan de Pruebas. Casos de Prueba. Informe de evaluacin de Pruebas. Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuracin de Pruebas, Componentes de Prueba y los Datos de prueba.

Los participantes responsables de las realizar las actividades y los productos de desarrollo del software son:

Diseador de pruebas: Es responsable de la planificacin, diseo, implementacin y evaluacin de las pruebas. Esto conlleva generar el plan de pruebas y modelo de pruebas, implementar los casos de prueba y evaluar los resultados de las pruebas. Los diseadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparacin y evaluacin de las mismas. Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integracin y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecucin, recuperar los errores y garantizar los resultados de las pruebas.

Durante la fase de Inicio puede hacerse parte de la planificacin inicial de las pruebas cuando se define el mbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre todo cuando un producto de desarrollo software es sometido a pruebas de integracin y de sistema. Esto quiere decir que la realizacin de pruebas se centra en las fases de Elaboracin, cuando se prueba la lnea base ejecutable de la arquitectura, y de

construccin, cuando el grueso del sistema est implementado. Durante la fase de Transicin el centro se desplaza hacia la correccin de defectos durante los primeros usos y a las pruebas de regresin. Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cmo probar los primeros productos de desarrollo software pueden ser utilizadas tambin como casos de prueba de regresin que especifican cmo llevar a cabo las pruebas de regresin sobre los productos de desarrollo software siguientes. El nmero de pruebas de regresin necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las ltimas iteraciones requerirn un gran esfuerzo en pruebas de regresin. Es natural, por tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, aunque el modelo de pruebas cambia constantemente debido a:

La eliminacin de casos de prueba obsoletos. El refinamiento de algunos casos de prueba en casos de prueba de regresin. La creacin de nuevos casos de prueba para cada nuevo producto de desarrollo de software.

5.4. Auditora de procesos y gestin La realizacin de una actividad de auditora debe realizarse siguiendo fielmente los cdigos de buenas prcticas de seguridad de sistemas de informacin reconocidos internacionalmente, en este caso la norma ISO17799 y la gua del NIST SP 800-26. En Germinus entendemos que este tipo de auditora debe realizarse con un conocimiento previo de los distintos riesgos y controles que son aplicables a una organizacin, debido a la amplitud del cdigo de buenas prcticas ISO-17799 no tiene sentido auditar todos los controles recomendados si stos no son aplicables a la organizacin, bien porque no existe un riesgo en ese sentido, bien porque el coste de implantacin de dichos controles se ha considerado superior al coste resultante de la materializacin de una amenaza (impacto) o del propio activo. Es por ello que la actividad de auditora de procesos y gestin estar precedida por un trabajo de anlisis del entorno de la organizacin incluyendo:

Anlisis de la poltica de seguridad. Anlisis de los procesos implantados, incluyendo, entre otros, los de gestin y administracin. Entrevistas con los responsables de la seguridad de informacin de la organizacin para determinar los controles establecidos. Revisin de los anlisis de riesgos realizados previamente y en funcin de los cuales se han implantado los controles. Revisin de las auditoras previas realizadas.

Toda vez que se haya realizado el anlisis del entorno se proceder a realizar una revisin exhaustiva de los controles implantados, la correcta

implantacin de los procedimientos y la concordancia con el cdigo de buenas prcticas. Para ello se realizarn entrevistas con distinto personal de la organizacin, el personal concreto a entrevistar ser definido basndose en el estudio del entorno y de la organizacin previamente realizado. Entre el personal entrevistado se incluirn a:

Los responsables de gestin. El personal tcnico encargado de la gestin de la seguridad de cada uno de los sistemas. Usuarios de los sistemas de informacin (muestra aleatoria)

ANEXO 1 PLAN DE DESARROLLO DE SOFTWARE

Fase de Elaboracin (4 semanas de duracin) Comienzo Modelado del Negocio Modelo de Casos de Uso del Negocio y Semana 1 Modelo de Objetos del Negocio Requisitos Glosario Visin Modelo de Casos de Uso Especificacin de Casos de Uso Especificaciones Adicionales Anlisis/Diseo Modelo de Anlisis/Diseo Modelo de Datos Implementacin Prototipos de Interfaces de Usuario Modelo de Implementacin Pruebas Semana 2 Semana 2 Semana 10 Semana 10 Semana 2 Semana 2 Semana 9 Semana 9 Semana 1 Semana 2 Semana 3 Semana 3 Semana 2 aprobado aprobado aprobado aprobado aprobado aprobado Aprobacin

Casos de Pruebas Funcionales Despliegue Modelo de Despliegue

Semana 2

Semana 9

Semana 2

Semana 9

Gestin de Cambios y Configuracin Durante todo el proyecto Gestin del proyecto Semana 7 Plan de Desarrollo del Software en su versin 3.0 y planes de las Iteracin 2 de Elaboracin Ambiente Semana 7

Durante todo el proyecto

ANEXO 2 MODELO DE UN PLAN DE CONFIGURACIN DE SOFTWARE [6] Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepcin del producto y la captura de requisitos inicial hasta la puesta en produccin del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el cdigo como en la documentacin asociada. La Gestin de Configuracin del Software es una disciplina encargada del control de la evolucin de los productos de software. Como todo proceso, la Gestin de Configuracin tambin puede ser sistematizada y automatizada, lo que se denomina un Sistema de Gestin de Configuracin (SGC). Actualmente existen en el mercado diversas herramientas que permiten apoyar una o ms actividades de la Gestin de Configuracin. Definiciones Gestin de Configuracin es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las solicitudes de cambio, y verificando que los elementos estn completos y que sean los correctos. El propsito de la Gestin de Configuracin del Software es establecer y mantener la integridad de los productos de software a travs del ciclo de vida del proceso de software. La Gestin de Configuracin del Software implica la identificacin

de la Configuracin del software en puntos dados en el tiempo, el control sistemtico de los cambios en la Configuracin y el mantenimiento de la integridad y trazabilidad de la Configuracin a travs del ciclo de vida del software. Los productos incluidos son:

Software distribuido al cliente. Documentos de requerimientos del software. Cdigo. Elementos requeridos para crearlos (ejemplo: el compilador)

Aspectos Funcionales 1. Identificacin: Se necesita definir un esquema de identificacin para reflejar la estructura del producto, esto involucra identificar la estructura y clases de componentes, dando a cada uno un nombre, una identificacin de versin y una identificacin de Configuracin. 2. Control: Se deben controlar los cambios que se le hacen a travs del ciclo de vida, asegurando que el software sea consistente a travs de la creacin de una lnea base del producto. 3. Estado: Se debe registrar y reportar el estado de los componentes y solicitudes de cambio. 4. Auditoria y revisin: Se debe validar que el producto este completo y asi mantener la consistencia entre los componentes, asegurando que estn en un estado apropiado a travs de todo el ciclo de vida del producto y que el mismo sea una coleccin bien definida de componentes. ALGUNOS CONCEPTOS PRESENTES EN LA DISCIPLINA Configuracin Las caractersticas funcionales y fsicas de una versin especifica de hardware y elementos de software que combinados de acuerdo a procedimientos de construccin especficos cumplen un propsito particular. Elementos de configuracin de software Definimos como un elemento de Configuracin a una unidad fsica y/o lgica parte de un conjunto mayor de elementos, producida o adquirida, que por sus caractersticas es distinguible de las dems

cuya

evolucin

interesa

administrar.

Son elementos de Configuracin en un proyecto de software: 01. El plan de proyecto. 02. El plan de Gestin de Configuracin. 03. El documento de definicin de requerimientos. 04. Estndares de anlisis, diseo, codificacin, pruebas, y auditoria. 05. Documentos de anlisis del sistema. 06. Documentos de diseo del sistema. 07. Prototipos. 08. Documentos de diseo de alto nivel. 09. Documentos de diseo de bajo nivel. 10. Especificaciones de prueba del sistema. 11. El plan de pruebas del sistema. 12. El Cdigo fuente del programa. 13. Cdigo objeto y ejecutable. 14. Especificaciones de pruebas de unidad. 15. Planes de pruebas de unidad. 16. Documentos de diseo de base de datos. 17. Datos de prueba. 18. Datos del proyecto. 19 .Manuales de usuario. Versin Una versin es una instancia de un elemento de Configuracin. El trmino se usa para sealar a un elemento de Configuracin del software que tiene un conjunto definido de caractersticas funcionales. Revisin Se define revisin como una versin que se construye sobre otra versin anterior. El trmino revisin generalmente se asocia a la nocin de correccin de errores, esto es, hacer cambios a un programa que corrigen solo errores en el diseo lgico pero no afectan las capacidades funcionales documentadas, dado que ningn requerimiento ha cambiado. Variante

Se define variante como una versin que es una alternativa a otra versin. Las variantes pueden permitir a un elemento de Configuracin satisfacer requerimientos en conflicto. Una variante es una nueva versin de un elemento que ser aadida a la Configuracin sin reemplazar a la versin anterior. Por ejemplo, si se desarrolla una aplicacin para varios sistemas operativos, algunas libreras pueden requerir modificaciones para poder ser compiladas o ejecutadas en los diferentes sistemas; la versiones para Unix y para Windows NT de una librera seran variantes del mismo elemento. Lnea base Una lnea base es una especificacin o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a travs de procedimientos formales de control de cambios. El trmino tambin se usa para referirse a una versin particular de un elemento de software que ha sido aprobado. En cualquier caso, la lnea base solo se puede modificar a travs de procedimientos formales de control de cambios. Una lnea base, junto con todos los cambios aprobados a la lnea base, representa la Configuracin aprobada actual. Procesos Asociados El estndar ISO/IEC 12207 ([ISO 12207]) para Procesos del Ciclo de Vida del Software, establece el Proceso de Gestin de Configuracin como uno de los Procesos de Soporte del Ciclo de Vida. Un Proceso de Soporte apoya a otro proceso como una parte integral, con un propsito distinto, y contribuye al xito y a la calidad del proyecto de software. Este proceso consiste de las siguientes actividades: 1. Implementacin del Proceso: Se desarrolla un Plan de Gestin de Configuracin que describe las actividades de Gestin de Configuracin, los procedimientos y el cronograma para su realizacin, y los responsables de dichas actividades. Dicho plan debe ser documentado e implementado. 2. Identificacin de la Configuracin: Se establece un esquema de identificacin de los elementos de software y sus versiones a ser controlados por el proyecto. 3. Control de la Configuracin: Se identifican y registran

las solicitudes de cambio, se analiza y evala los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado. 4. Contabilidad de Estado de la Configuracin: Se preparan registros de Gestin y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo lneas base. 5. Evaluacin de la Configuracin: Se determina y asegura que los elementos de software sean funcionalmente (versus sus requerimientos) y fsicamente completos (es decir, si su diseo y Cdigo reflejan una descripcin tcnica actualizada). 6. Gestin de actualizacin y distribucin: Se controla formalmente la actualizacin y distribucin de los productos de software. En la figura 1 se presenta un modelo de este proceso elaborado utilizando el perfil de UML para modelamiento de procesos de software, propuesto por el Object Management Group (OMG)

El estndar IEEE Std. 1074-1995 ([IEEE 1074]) para el Desarrollo de Procesos del Ciclo de Vida del Software, establece el Proceso de Gestin de Configuracin del Software como uno de los Procesos Integrales. Estos son los Procesos necesarios para completar exitosamente las actividades del proyecto, y son utilizados para asegurar la finalizacin y calidad de las funciones del proyecto. Este proceso consiste de las siguientes actividades: 1. Planificar la Gestin de Configuracin. 2. Desarrollar la Identificacin de la Configuracin.

3. Realizar el Control de la Configuracin. 4. Realizar la Contabilidad de Estado. Escenarios de Configuracin en el Proceso de Software Gestin de configuracin del cdigo fuente La evolucin del Cdigo fuente es quizs el ejemplo mas claro en la Gestin de Configuracin. A lo largo del desarrollo (y posteriormente en el mantenimiento) las modificaciones al software se realizan sobre el Cdigo fuente. Y es segn el Cdigo fuente que se valida la documentacin asociada. Los sistemas administradores de versiones se suelen integrar a los entornos de desarrollo y realizan administracin de versiones del Cdigo fuente. Cada modificacin de uno de los archivos del programa va generando una revisin del mismo, y peridicamente se crean lneas base de todo el proyecto. De este modo, un equipo de desarrollo puede trabajar en paralelo, compartiendo versiones de archivos de Cdigo fuente y actualizndolos peridicamente segn se van creando o modificando los archivos que conforman el proyecto. Gestin de configuracin en el desarrollo de software Como ya habamos comentado, un elemento de Configuracin puede ser prcticamente cualquier producto o subproducto del desarrollo de software. Las especificaciones de requisitos, los documentos de anlisis y de diseo, el Cdigo fuente y ejecutable, y los procedimientos y datos de prueba pueden ser sometidos a control de Configuracin. Con un control riguroso, es posible entonces mantener registro del estado de todos estos elementos, lo que facilita la introduccin de cambios si se tiene registro de las dependencias entre ellos, adems de facilitar la elaboracin de entregables; por ejemplo, si se tiene registro de las dependencias entre los elementos de Configuracin, es posible que si se produce un cambio en las especificaciones, los documentos de anlisis y diseo y el Cdigo fuente asociados puedan ser actualizados sin que tome demasiado tiempo realizar su bsqueda. Gestin de configuracin en el mantenimiento de software En el mantenimiento de software, cobra importancia la funcin del

Comit de Control de Cambios (CCC), que se encarga de recibir, estudiar y aprobar las solicitudes de cambio en el software que son presentadas, sea por los usuarios o por los propios encargados del mantenimiento. En este caso, las funciones de control y de auditoria se vuelven casi indispensables, pues es necesario mantener registro de todas las solicitudes de cambio presentadas y del estado actual de cada una de ellas. Un sistema de Gestin de Configuracin que apoye la Gestin de solicitudes de cambio, debera permitir el registro por parte de los usuarios de las solicitudes de cambio, su revisin por parte del CCC, y si son aprobadas la creacin de ordenes de cambio. Un cambio implica generalmente la actualizacin tanto del Cdigo fuente, como de los documentos de especificacin de requisitos, anlisis y diseo, casos de prueba y manuales. Por lo tanto, en el escenario anterior, resulta de utilidad mantener un registro de las dependencias entre los elementos de Configuracin. El cambio se vera reflejado en la creacin de nuevas versiones de los elementos respectivos. Gestin en la distribucin del software a las PC- Usuarios Cuando se pone en produccin un software, se distribuyen copias del mismo entre los diversos usuarios del sistema. En este escenario, un sistema de Gestin de Configuracin debera permitir registrar las Configuraciones (conjunto de versiones de elementos de Configuracin) que cuenta cada PC - usuario. Puede ocurrir, que si un mismo sistema se vende a distintos clientes, en algn momento surjan requerimientos contradictorios o necesidades que lleven a la creacin de variantes de los elementos de Configuracin. El sistema de Gestin de Configuracin apoyara entonces al momento de estudiar una solicitud de un usuario a conocer cual es la Configuracin con la que esta trabajando. Modelo Genrico 1. Permite la creacin de tipos de elementos de Configuracin. De este modo, es posible que el usuario cree sus propios tipos de elementos dependiendo que es lo que desea controlar. 2. Permite la creacin de tipos de relaciones entre los elementos de Configuracin. Es posible que el usuario cree los tipos de relaciones que desee, y que especifique dependencias para la creacin de nuevas versiones entre el origen y el destino de la relacin. Estas dependencias pueden ser:

Ninguna, Condicional-Origen (s el origen cambia, el destino podra cambiar) Condicional-Destino (s el destino cambia, el origen podra cambiar)

Obligatoria-Origen (s el origen cambia, el destino debe cambiar) Obligatoria-Destino (si el destino cambia, el origen debe cambiar).

3. Cada tipo de elemento y cada tipo de relacin puede tener los campos de informacin adicional que el usuario considere necesarios. 4. Un elemento de Configuracin corresponde a un tipo y sus versiones pueden estar relacionadas con versiones de otros elementos segn se creen relaciones para l. 5. Un elemento de Configuracin tiene un conjunto de versiones asociadas, cada una de las cuales esta asociada al usuario (dueo) que la creo. 6. Un conjunto de versiones de elementos de Configuracin conforma una Configuracin. Es posible de este modo registrar muchas Configuraciones para el mismo software, que pueden diferir en cuanto a versiones, o ser variantes (Configuraciones alternativas).

De este modelo es posible obtener informacin acerca de: 1. Los tipos de elementos sometidos a Gestin de Configuracin. 2. Las relaciones entre dichos elementos. 3.Las dependencias para la creacin de versiones al momento de analizar la introduccin de un cambio. Es posible conocer como un

cambio en un elemento afectara a los dems. 4. Los usuarios que generaron cada versin de un elemento.

ANEXO 03 Descripcin Detallada del SPMP Planes de Gestin de Proyectos Software Pagina de Ttulo Carta de Revisin Prefacio Tabla de Contenidos Lista de Figuras Lista de Tablas 1 Introduccin 1.1 Alcance 1.2 Propsito 1.3 Acuerdo del proyecto 1.4 Evolucin de SPMP 2 Referencias 3 Definiciones 4 Organizacin del Proyecto 4.1 Modelo de Proceso 4.2 Estructura Organizacional 4.3 Limites e Interfaces Organizacionales 4.4 Responsabilidades del Proyecto 5 Procesos Administrativos 5.1 Objetivos y Prioridades Administrativas 5.2 Dependencias, Restricciones y Supuestos. 5.3 Procesos Integrales 5.4 Gestin del Alcance Administrativo 5.5 Planes de gestin del Itinerario 5.6 Plan de gestin del Presupuesto 5.7 Plan de gestin de los Recursos 5.8 Planes de gestin de la Calidad 5.9 Planes de gestin de Riesgos 5.10 Planes de Obtencin de Recursos 5.11 Planes de Manejo Comunicacional 6 Procesos Tcnicos 6.1 Alcance del Producto 6.2 Mtodos, Herramientas y Tcnicas 6.3 Documentacin del Software

Planificacin de las Actividades del Trabajo 7.1 Definiciones de las Actividades y Alcance 7.2 Dependencia de las Actividades 7.3 Itinerario de Actividades 7.4 Presupuesto de Actividades 7.5 Requerimientos de Recursos de las Actividades 8 Componentes Adicionales 8.1 Anexo Pgina de ttulo: Contiene el ttulo de y una nota de revisin para identificar unvocamente el documento. Carta de revisin: Es una hoja separada que contiene el nmero de versin del documento, la fecha de revisin, firma de aprobacin, una lista de las pginas que han sido modificadas en la actual versin y una lista de los nmeros de versin y fechas de revisin para cada una de las versiones previas del SPMP. Prefacio: Indica el alcance de las actividades del SPMP. Tabla de contenido y las listas de figuras y tablas: Proveen los ttulos y los nmeros de pgina. 1 Introduccin Esta parte provee una revisin tanto del proyecto como del producto a ser confeccionado. El alcance del proyecto y el producto, una lista de la entrega del proyecto y las consideraciones de evolucin para e SPMP. 1.1 Alcance Esta parte definira el alcance tanto del proyecto como del producto a ser entregado. 1.2 Propsito Aqu se provee una resumida declaracin de las necesidades del negocio a ser satisfechas por el proyecto, con un conciso resumen de los objetivos del proyecto. 1.3 Acuerdo del proyecto En esta parte se listan los productos que van a ser entregados al cliente, las fechas y lugar de entrega y la cantidad requerida para satisfacer los acuerdos del proyecto. 1.4 Evolucin del SPMP Se especifica que mecanismos son usados para lograr la versin inicial del SPMP y cambios de control del SPMP. 2 Referencias Se provee una completa lista de todos los documentos y otros recursos de informacin referenciados en el SPMP. Cada documento puede ser identificado por el ttulo, nmero de edicin, fecha, autor, y organizacin editora. Otros recursos, como los archivos electrnicos, deben ser identificados de una manera no ambigua usando identificadores como la fecha y nmero de versin.

3 Definiciones Se puede definir o provee referencias de la definicin de todos los trminos y acronismos requeridos para interpretar adecuadamente el SPMP. 4 Organizacin del Proyecto Esta parte especifica el modelo del proceso para el proyecto, describe la estructura organizacional del proyecto, identifica el fin de la organizacin y define las responsabilidades individuales para el proyecto. 4.1 Modelo de Procesos Esta parte define las relaciones entre las funciones del proyecto principal y las actividades por especificacin de tiempo. El modelo de proceso puede ser descrito usando una combinacin de grficos y notacin textual. 4.2 Estructura Organizacional Esta parte describe la estructura de organizacin interna del proyecto. Herramientas grficas tales como una matriz de diagramas podra ser usada para describir las lneas de autoridad, responsabilidad y comunicacin dentro del proyecto. 4.3 Limites e Interfaces Organizacionales Aqu se describe los limites administrativos y gerenciales entre el proyecto y cada una de las siguientes entidades: La organizacin de origen, la organizacin del cliente, la organizacin subcontratada, o cualquier otra organizacin que interactua con el proyecto. 4.4 Responsabilidades del Proyecto En esta parte se identifica el estado natural de cada funcin y actividad del proyecto principal, y identifica individualmente quienes son responsables por esas actividades y funciones. Una matriz de funciones y actividades versus responsabilidades individuales pueden ser usadas para describir las responsabilidades del proyecto. 5 Procesos Administrativos Esta parte especifica los procesos administrativos del proyecto que deben ser consistentes con la declaracin del alcance y puede incluir objetivos y prioridades administrativas. 5.1 Objetivos y Prioridades Administrativas Especificar la filosofa, metas y prioridades para la administracin de las actividades durante el proyecto. Tpicos especficos que pueden ser incluidos son la frecuencia y mecanismos de reporte a ser usados, las prioridades relativas entre los requerimientos y presupuesto del proyecto, procedimientos administrativos de riesgos a seguir y una nota para la adquisicin, modificacin y uso del software existente. 5.2 Dependencias, Restricciones y Supuestos Condiciones sobre las cuales el proyecto esta basado, los eventos externos de los cuales el proyecto depende y las restricciones con las cuales el proyecto va a ser elaborado.

5.3 Procesos Integrales Planifica los procesos integrales necesarios para una exitoso trmino de los proyectos sw. Esos procesos pueden incluir: la configuracin de manejo, asegurar la calidad, verificacin y validacin del sw. 5.4 Gestin del Alcance Administrativo Se especifica el plan de manejo del alcance del proyecto, tambin puede incluir procedimientos para cambios en el alcance del SPMP, adems de la probabilidad de cambios, incluyendo los factores que pudiesen resultar por el cambio del alcance del proyecto. El plan indicara factores que causaron el cambio, los resultados de los cambios y los mtodos por los cuales los cambios fueron documentados, comunicados y controlados. 5.5 Planes de Manejo del Itinerario. Se define los planes para asegurar que el proyecto este terminado a tiempo, adems de, especificar los documentos que sirven como entrada al proyecto. Se deben especificar las herramientas o metodologa que sern usadas para administrar el itinerario. El plan indicara factores que causaron el cambio, los resultados de los cambios y los mtodos por los cuales los cambios fueron documentados, comunicados y controlados. 5.6 Plan de Manejo del Presupuesto Se definen los planes para asegurar que el proyecto sea terminado con el presupuesto establecido, adems de especificar los documentos que sirven como entrada al presupuesto. Se deben especificar las herramientas o metodologa que sern usadas para administrar el presupuesto. El plan indicara factores que causaron el cambio, los resultados de los cambios y los mtodos por los cuales los cambios fueron documentados, comunicados y controlados. 5.7 Plan de Manejo de los Recursos Se especifica los planes de manejo de los recursos requeridos para la exitosa culminacin de esta. El plan puede especificar los mtodos usados para estimar el material, servicios y requerimientos de recursos humanos. Se puede incluir el nmero y nivel de calificacin del personal requerido para completar el proyecto, el nmero y atributos de calidad requerida por el personal y la naturaleza de los servicios contratados. 5.8 Planes de Manejo de la Calidad El plan para asegurar la calidad de los procesos y del proyecto se define en este apartado. El plan puede identificar los estndares del proyecto y los mtodos y recursos requeridos para implementar y asegurar el cumplimiento de esos estndares. 5.9 Planes de Manejo de Riesgos Se definen los planes de manejo de factores de riesgos asociados al proyecto. Esta parte describe los mtodos que seran usados para identificar los factores de riesgo, como fueron evaluados y impacto potencial de los riesgos identificados.

5.10 Planes de Obtencin de Recursos Esta parte incluira una descripcin de los procesos de obtencin de recursos, incluyendo responsabilidades para todos los aspectos del proceso. El plan podra incluir los procesos de obtencin tangible e intangible de recursos; procesos de obtencin de: equipamiento, estimaciones de tiempo de computado, Hw. y Sw. y transportes. 5.11 Planes de Manejo Comunicacional Esta parte maneja la comunicacin relativa del proyecto. Se definiran los mecanismos de reporte, formas de reporte, informacin anticipada, mecanismos de intervencin, y otras herramientas y tcnicas usadas para monitorear y controlar los objetivos del proyecto. 6 Procesos Tcnicos Esta parte planea el manejo del alcance del producto, los mtodos tcnicos, herramientas y tcnicas usadas para la entrega del producto y documentacin del software. 6.1 Alcance del Producto Esta parte contempla los planes de manejo del alcance del producto. En este plan seran incluidos los mtodos por los cuales el alcance del proyecto va a ser medido adems de los requerimientos del producto, adems se incluye los factores que pueden cambiar el alcance del producto. 6.2 Mtodos, Herramientas y Tcnicas Este parte describe el sistema de computacin, metodologas de desarrollo, estructuras de equipos, lenguaje de programacin, herramientas y tcnicas a ser usadas para la especificacin, diseo, construccin, test, integracin, documentos, modificaciones y mantencin del proyecto. 6.3 Documentacin del Software Se describe los planes de documentacin para el proyecto software. Los planes de documentacin especificaran los requerimientos de documentacin y la importancia, referencias, revisiones para la documentacin del sw. El plan de documentacin puede adems contener un estilo de gua, convenciones de nombre y formatos de documentacin. 7 Planificacin de las Actividades del Trabajo Esta parte definen las actividades y sus alcances, identifica las relaciones de dependencia entre las actividades, estado de los recursos, asegurar la calidad y las consideraciones de riesgo. 7.1 Definiciones de las Actividades y Alcance Aqu se especifican y definen las actividades a ser completadas para satisfacer los requerimientos del proyecto. El alcance de cada actividad seria claramente definida, esta identificacin puede ser basada sobre la numeracin de proyectos y/o ttulos descriptivos.

7.2 Dependencia de las Actividades Se especifica el orden entre las actividades del proyecto y tareas asociadas para describir las relaciones de dependencia entre actividades y eventos externos. 7.3 Itinerario de Actividades Estas listas expresan calendarios de tiempo o de incrementos relativos del producto clave sobre el proyecto principal. 7.4 Presupuesto de Actividades Especifica el presupuesto de varias tareas y actividades. 7.5 Requerimientos de Recursos de las Actividades En esta parte se especifica, como una funcin de tiempo, los recursos totales estimados para completar la actividad. Nmeros y tipo de personal, soporte de software y hardware y requerimientos de mantencin para las actividades del producto y tareas. 8 Componentes Adicionales Ciertos componentes adicionales que puedan ser requeridos pueden ser incluidos para ser anexados como material adicional al SPMP. 8.1 Anexo Incluira detalles especficos del personal, detalles de los costos estimados, detalles de las estructuras de trabajo breakdown e informacin suplementaria para una adecuada comprensin del SPMP

Fuentes
1: Tipos de Software, http://tecnomaestros.awardspace.com/tipos_software.php, 2: Metodologa y software para la construccin y seguimiento del Cuadro de Mando Integral en las TICs (European Software Institute), http://winred.com/management/metodologia-y-software-para-la-construccion-y-

seguimiento-del-cuadro-de-mando-integral-en-las-tic-s/gmx-niv116con1642.htm, 3: Control de versiones, http://es.wikipedia.org/wiki/Control_de_versiones, 4: Diagrama de Gantt, http://es.wikipedia.org/wiki/Diagrama_de_Gantt, 5: Tcnica de revisin y evaluacin de programas, http://es.wikipedia.org/wiki/PERT, 5.1: Auditorias de Seguridad, www.germinus.com/sala_prensa/articulos/Auditorias%20Seguridad.pdf, 5.2: Fase de Pruebas, http://lsi.ugr.es/~arroyo/inndoc/doc/pruebas/pruebas_d.php, 6: Gestin de Configuracin del Software, http://www.histaintl.com/soluciones/configuracion/configuracion.php,