INTRODUCCIÓN El desarrollo de software es un proceso tecnológico 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 gestión deficiente del proyecto. El éxito de un proyecto de software se mide en función 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 técnicas gerenciales.

I. METODOLOGÍA DE GESTIÓN DE PROYECTO 1.1 GESTION DE PROYECTOS DE SOFTWARE 1.1.1 MISIÓN, COORDINACIÓN CON OTROS PROYECTOS, DIFERENCIAS Y DOCUMENTACIÓN (AD-HOC, DOCUMENTADO, NORMAS) 1.1.1.1 Misión :
• • •

Que el desarrollo del proyecto esté dentro de los límites marcados de tiempo y presupuesto. Indirectamente garantiza una buena realización técnica. Una buena gestión no garantiza el éxito, pero sin gestión hay fracaso

1.1.1.2 Coordinación 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 más o menos protagonista. Generalmente el proyecto software no se ejecuta de forma aislada sino que tiene que integrarse con otros proyectos que se están realizando en la organización. Cuando se integra con otros proyecto (en curso o en futuro) software de la organización se suele hablar de gestión integrada de la información en la empresa.

1.1.1.3 Diferencia de la gestión de software con otros campos:
• • •

El producto es intangible No hay un proceso software estándar. No hay una relación 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 gráficos, programas de telecomunicaciones, etc. pero se caracterizan por estar muy próximos al hardware, por ser utilizados concurrentemente por numerosos usuarios y por tratarse de programas de amplia

difusión, no estando diseñados normalmente a medida. Esto permite un mayor esfuerzo en su diseño y optimización, pero también 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 estímulos de entrada en un tiempo máximo 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 interacción con el usuario. Un sistema de tiempo real es aquel en el que para que las operaciones computacionales estén correctas no depende solo de que la lógica e implementación de los programas computacionales sea correcto, sino también en el tiempo en el que dicha operación 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 sinfín. Si el Robot llega tarde, la pieza ya no estará donde debía 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 gestión El procesamiento de información de gestión constituye, casi desde los inicios de la informática la mayor de las áreas de aplicación de los ordenadores. Estos programas utilizan grandes cantidades de información almacenadas en bases de datos con objeto de facilitar las transacciones comerciales o la toma de decisiones. Además de las tareas convencionales de procesamiento de datos, en las que el tiempo de procesamiento no es crítico y los errores pueden ser corregidos a posteriori, incluyen programas interactivos que sirven de soporte a transacciones comerciales. Software científico y de ingeniería Otro de los campos clásicos de aplicación de la informática. Se encarga de realizar complejos cálculos sobre datos numéricos de todo tipo. En este caso la corrección y exactitud de las operaciones que realizan

es uno de los requisitos básicos que deben de cumplir. El campo del software científico y de ingeniería se ha visto ampliado últimamente con el desarrollo de los sistemas de diseño, ingeniería y fabricación asistida por ordenador (CAD, CAE y CAM), los simuladores gráficos y otras aplicaciones interactivas que lo acercan más al software de tiempo real e incluso al software de sistemas. Software de ordenadores personales El uso de ordenadores personales y de uso doméstico se ha generalizado a lo largo de la pasada década. Aplicaciones típicas son los procesadores de textos, las hojas de cálculo, bases de datos, aplicaciones gráficas, juegos, etc. Son productos de amplia difusión 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 electrónica de consumo, dotando a estos productos de un grado de inteligencia cada vez mayor. Se aplica a todo tipo de productos, desde un vídeo doméstico hasta un misil con cabeza atómica, pasando por algunos sistemas de control de los automóviles, y realiza funciones muy diversas, que pueden ir desde complicados cálculos en tiempo real a sencillas interacciones con el usuario facilitando el manejo del aparato que los incorpora. Comparten características con el software de sistemas, el software de tiempo real, el software de ingeniería y científico y el software de ordenadores personales. Otro ejemplo de los productos que utilizan este tipo de software son los teléfonos celulares. Software de inteligencia artificial El software basado en lenguajes procedimentales es útil para realizar de forma rápida y fiable operaciones que para el ser humano son tediosas e incluso inabordables. Sin embargo, es difícilmente aplicable a problemas que requieran la aplicación de funciones intelectuales más elevadas, por triviales que nos puedan parecer. El software de inteligencia artificial trata de dar respuesta a estas deficiencias, basándose en el uso de lenguajes declarativos, sistemas expertos y redes neuronales. Un ejemplo de este software es Smart Airport Operations Center, programa de logística 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 logísticas, pero el problema es más sutil que una ecuación gigante. No hay manera de “solucionar” un aeropuerto con sus miles de variables. A cambio, los algoritmos genéticos usan la selección natural, la mutación, el cruce de escenarios subóptimos, permitiendo que el programa encuentre la mejor opción. 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 técnicas. Elevado número de interfases.

1.1.1.4 Documentación

No se puede llamar gestión a lo que es un proceso Ad-Hoc:

Sin planes escritos, registros etc.

Gestión es un proceso documentado :

Si no, no es posible el seguimiento [2] Hoy en día las valoraciones que se hacen de las empresas, consideran como aspecto no-financiero más 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 más importantes a la hora de valorar una empresa, el número uno es la habilidad para ejecutar la estrategia de la empresa, mientras que la calidad de esta estrategia se encuentra en tercera posición. 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 están causados por una estrategia pobre, sino por una ejecución 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 – (denominación en castellano de Balanced Scorecard, desarrollado por Kaplan y Norton a principios de los años noventa) es una herramienta de gestión estratégica que apoya la definición, comunicación y gestión de los objetivos y estrategia de la empresa. Según el CMI la estrategia de una empresa puede definirse en función 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 acentúan en las compañías de Tecnologías de la Información (TI), donde las barreras de comunicación causadas por el uso de idiomas muy distintos entre el departamento de TI y el resto del negocio, provocan una reducción en el potencial que las TI tienen para añadir valor a la empresa identificando nuevas oportunidades de negocio. Ante esta situación se ve la necesidad de crear un lenguaje común en la empresa que ofrezca un marco común de evaluación 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 estén orientadas a conseguir objetivos de negocio y que puedan evaluarse en función de esta aportación al negocio. Conociendo los principios del CMI debemos desarrollar una metodología para llevarlos a las organizaciones de TI, considerando las peculiaridades de estas empresas. Podemos definir cinco perspectivas: Financiera: ¿Cómo añaden valor económico a la empresa nuestros procesos de desarrollo de software y la mejora de dichos procesos? Clientes: ¿Cómo sabemos que nuestros clientes, internos y externos, están 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 añadido una perspectiva más; la de personas. ¿Tienen nuestros empleados las capacidades suficientes para realizar su trabajo?, ¿Son felices con lo que están haciendo y donde lo están haciendo? Infraestructura e innovación: Aquí, para las organizaciones de TI, queremos gestionar aspectos relacionados con la mejora de procesos de software, la tecnología 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 metodología BITS la componen principalmente tres elementos El primero es el Modelo Genérico: consiste en un conjunto de objetivos genéricos que una empresa de TI podría 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 críticos de éxito) existe un conjunto de indicadores cuantitativos para realizar el seguimiento de los mismos. El segundo componente es el Método, que ofrece una forma para desarrollar un CMI para una empresa de modo que en la empresa exista una alineación entre las iniciativas de mejora de procesos de software y los objetivos de negocio. El tercer componente es el Material de Aplicación del método. Aquí podemos encontrar material de apoyo a la hora de aplicar el método, como por ejemplo plantillas que las empresas pueden utilizar, y que facilitan y aceleran el proceso de desarrollar un CMI para una empresa.
✔ ✔ •

Tampoco sería posible la realimentación Y no se podría certificar el proceso de desarrollo.

Normas de la documentación

✔ ✔ ✔

La documentación (que refleja el proyecto) ha de estar ligada a una norma . Esta norma puede estar fijada por la organización o por un estándar Una de las primeras tareas de la gestión 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, técnicas, etc. (VER TEMA 2.1)

1.1.2.1.3 Controlar el proyecto
• • •

Se realizan seguimientos, análisis, 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) configuración software (ANEXO 02) calidad de software verificación y validación mantenimiento desarrollo del personal despliegue.

1.1.2.3 Actividades de control del proyecto:
• • • • • • • • • •

Gestión de requisitos Establecimiento de plan de trabajo y Monitorización progreso Gestión de la garantía de calidad de producto y de proceso Gestión de la configuración Gestión del cambio Gestión del riesgo Selección y formación del personal Gestión de suministradores Medida y análisis Informe y presentaciones

1.1.3 ROLES, JEFE/GESTOR Y ORGANIZACIÓN DEL EQUIPO DE DESARROLLO:CERRADO, ALEATORIO, ABIERTO, SINCRONIZADO

1.1.3.1 Roles asociados a las tareas 1.1.3.1.1 Roles mínimos
• • • •

Jefe o gestor de proyecto. Resp. de configuración. Resp. de calidad. Resp. de desarrollo.

1.1.3.1.2 Roles dependiendo de la aplicación
• • • • •

Resp. Resp. Resp. Resp. Resp.

de de de de de

despliegue. mantenimiento. librerías. la base de datos. safety/seguridad.

1.1.3.2 Jefe/Gestor del proyecto software

Responsable de la gestión del proyecto • Supervisa la adherencia de los procesos a los estándares y normas fijados en el proyecto. Responsable de la planificación y programación de eventos. • Controla el proyecto para mantenerlo dentro de los márgenes de tiempo y presupuesto

1.1.3.3 Organización del equipos de desarrollo Paradigma cerrado Estructura jerárquica tradicional de autoridad (proyectos de los que hay un gran conocimiento previo ). Aleatorio El equipo se estructura libremente en función de la iniciativa del personal. Funcionan bien en entornos tecnológicos muy innovadores pero chocan cuando hay que conseguir un rendimiento ordenado. No facilita la asunción de responsabilidades. Abierto Conjuga los dos anteriores. Se incluyen muchas vías de comunicación y toma de decisiones consensuadas. Adecuados para la resolución de problemas complejos pero no tienen tanto rendimiento como el cerrado.

Sincronizado Se divide el problema en partes disjuntas de forma natural, con una organización clara pero con poca comunicación entre ellas. 1.1.4 NORMAS, ESTÁNDARES Y HERRAMIENTAS 1.1.4.1 Normas y estándares 1.1.4.1.1 Planificación

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 término de forma muy similar considerando una actividad como un conjunto de tareas y una tarea como una acción que transforman entradas en salidas.

1.1.4.2 Herramientas 1.1.4.2.1 Planificación

REVIC y SOFTEST del USAAF

1.1.4.2.2 Control de la configuración La Gestión de Configuración 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 garantía de calidad que se aplica en todas las fases del proceso de ingeniería 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, imágenes, documentación...)

Posibilidad de realizar cambios sobre los elementos almacenados (ej. modificaciones parciales, añadir, borrar, renombrar o mover elementos) • Registro histórico 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 generación de informes con los cambios introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la versión de un conjunto de ficheros, etcétera.
• •

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 PLANIFICACIÓN: (MARCO DESARROLLO, COSTO, PLAN, RIESGOS), RELACIÓN CON REQUISITOS, QUE DEFINE (MARCO, PLANES, ACTIVIDADES). 1.2.1.1 Planificación: Marco de desarrollo del proyecto Definición a alto nivel de normas, estándares, 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 Gestión de riesgos 1.2.1.2 Función 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 organización.

1.2.1.3 Definiciones • Definir un marco de referencia

Definir un plan (ANEXO 03)
✔ ✔

Reflejado en un documento de planificación 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 • Definición de los objetivos y prioridades • Definición de los productos finales en alto nivel • Definición de Entregables
✔ ✔ ✔ •

Entregables hardware Entregables software Entregables de documentación

Definición de límites e interfases con otras empresas.

1.2.2.2 Normas y referencias: customización • Normas o estándares a emplear • Adaptación de dichas normas al presente proyecto • Elección del Modelo de proceso de desarrollo • Metodologías utilizadas 1.2.2.3 Organización del equipo • Definición de la Estructura organizativa • A nivel de asignación de los roles definidos en el SQAP Software Quality Assurance Plan o SQAP (es decir, Plan de Garantía de Calidad de Software) es un documento que organiza el desarrollo del software con el fin de que el proceso de creación de este siga unas pautas que aseguren la calidad del resultado. Este plan de garantía forma parte de la Ingeniería de software. En este documento se organiza el equipo de personas, se elige el ciclo de vida a seguir, se especifican los documentos que harán falta, las revisiones que se harán, las pruebas e incluso cómo realizar el mantenimiento. (ANEXO 04)

1.2.2.4 Mecanismos de monitorización y control
• • • • • • •

Mecanismos de control y seguimiento en función de lo definido en el SQAP Establecimiento de reuniones de seguimiento de proyecto Reuniones internas de seguimiento del proyecto. Reuniones de hitos. Definición de informes de progreso Definición del registro de comunicaciones Control de suministradores

1.2.3 ANÁLISIS DEL COSTE: TAREAS DE DESARROLLO (CSCI/CSC, ETIMACIÓN, AJUSTE, HISTORICO), NO DESARROLLO, AJUSTE PRESUPUESTARIO 1.2.3.1 Descomposición de las tareas no directamente de desarrollo
• • • •

Documentación Control Test Plan más allá del desarrollo
✔ ✔ ✔

No siempre se contemplan, a veces se posponen Definición de plan de despliegue Definición de las actividades de Mantenimiento

Adquisición y recepción de recursos materiales

1.2.3.2 Descomposición de las tareas de desarrollo 1.2.3.2.1 Definición de Paquetes de Trabajo en CSCI/CSC (Computer Software Configuration Item/Computer Software Component)

Fuente para su definición:
✔ ✔ ✔ ✔

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

1.2.3.2.2 Estimación 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 estimación del número de líneas de código de cada componente, normalmente se introduce una distribución estadística. A continuación se fijan unos parámetros globales del proyecto como:

Experiencia, aerotransportado, etc.

criticidad,

El programa proporcionará una distribución en valor medio (incluso varianza) . Y Y

1.2.4 PLAN MATERIALES, TÉCNICAS

DE TRABAJO: RECURSOS HUMANOS HITOS, ANÁLISIS, CAMINOS CRÍTICOS

1.2.4.1 Recursos humanos
• • • •

Organizar el equipo de trabajo en función de la norma y en función del volumen del proyecto. Asignar las horas/hombre al equipo de trabajo. Asignación de Responsabilidades a cada uno de los paquetes. de trabajo. Formación.

1.2.4.2 Recursos materiales
• •

Reparto de los existentes Planes de adquisición

1.2.4.3 Estudiar caminos críticos 1.2.4.3.1 Tecnicas GANTT [4] En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de las diferentes unidades mínimas de trabajo y los grupos de tareas (llamados summary elements en la imagen) o las dependencias entre unidades mínimas de trabajo (no mostradas en la imagen). Desde su introducción los diagramas de Gantt se han convertido en una herramienta básica en la

gestión 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 línea de tiempo en las diferentes actividades haciendo el método más 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 probabilísticos. Normalmente para desarrollar un proyecto específico lo primero que se hace es determinar, en una reunión multidisciplinaria, cuáles son las actividades que se deberá ejecutar para llevar a feliz término el proyecto, cuál es la precedencia entre ellas y cuál será la duración esperada de cada una.

II. METODOLOGÍA DE DESARROLLO DE SOFTWARE 2.1 METODOLOGÍA Y PROCESO DE DESARROLLO DE SOFTWARE Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos 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 ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción. Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución 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 definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo. Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil 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 difícil 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. Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación. 3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolución: El software debe evolucionar, para adaptarse a las

necesidades del cliente. Además 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 señalan a continuación:
• • • • • • • •

Seguimiento y control de proyecto de software. Revisiones técnicas formales. Garantía de calidad del software. Gestión de configuración del software. Preparación y producción de documentos. Gestión de reutilización. Mediciones. Gestión de riesgos.

Pressman [1] caracteriza un proceso de desarrollo de software como se muestra en la Figura 3. Los elementos involucrados se describen a continuación:

Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad. Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto. Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección 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 Quién debe hacer Qué, Cuándo y Cómo debe hacerlo [5].

Figura 3: Relación 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:

Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos. Qué: Un Artefacto1 es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones. Cómo y Cuándo: 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 terminación de ciertos Artefactos.

La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las Prácticas 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 representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza
1

Un artefacto es una pieza de información 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 abstracción de un proceso real.” Los modelos genéricos 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 continuación:
• • • • • • •

Codificar y corregir Modelo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo basado en reutilización Desarrollo incremental Desarrollo en espiral

2.1.1.1. Codificar y corregir (Code-and-Fix) Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:
• •

Escribir código. Corregir problemas en el código.

Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. Este modelo tiene tres problemas principales [7]:

Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos. Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara. El código es difícil de reparar por su pobre preparación 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 ingeniería [8]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases:

Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del

sistema. Se busca hacer esta definición en detalle.

Diseño 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. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.

La interacción 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 corrección de los problemas encontrados en fases previas.

Figura 4: Modelo de desarrollo en cascada. En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción 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 producción y aprobación 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 resolución, 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 difícil responder a cambios en los requisitos.

Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes. 2.1.1.3. Desarrollo evolutivo La idea detrás de este modelo es el desarrollo de una implantación 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 cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

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 más claras. El sistema evoluciona conforme se añaden nuevas características 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 están 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 están:
• •

La especificación 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 más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:

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

Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión. 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 más 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 programación automática. La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte

en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación). Observaciones sobre el desarrollo formal de sistemas:

Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación 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 reutilización Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase: 1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificación 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 más adecuados (fase 1). 3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco. 4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración 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

reutilización

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 están en manos de los desarrolladores del sistema.

2.1.2. Procesos iterativos A continuación se expondrán dos enfoques híbridos, especialmente diseñados 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 repetición 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 combinación 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 más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.

• • •

Algunas de las desventajas identificadas para este modelo son:
• • • •

Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas). Cada incremento debe aumentar la funcionalidad. Es difícil establecer las correspondencias de los requisitos contra los incrementos. Es difícil detectar las unidades o servicios genéricos 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 más 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. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluación y reducción de riesgos: Se realiza un análisis

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 validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto. El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

Figura 9: Modelo de desarrollo en Espiral 2.2. ¿Cuál es el modelo de proceso más adecuado? Cada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre otros). En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la selección 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 están

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: Comparación entre modelos de proceso de software. 2.3. Metodologías para desarrollo de software Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño. La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información 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 análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuación se revisan brevemente cada una de estas categorías de metodologías. 2.3.1. Metodologías estructuradas Los métodos estructurados comenzaron a desarrollarse a

fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE2 (Francia), MÉTRICA3 (España), SSADM4 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson5, Ward & Mellor6, Yourdon & DeMarco7 e Information Engineering8. 2.3.2. Metodologías orientadas a objetos Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java9 o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML)10, la notación OO más popular en la actualidad. Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP)11, OPEN12, MÉTRICA (que también soporta la notación estructurada). 2.3.3. Metodologías tradicionales (no ágiles) Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías 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)

clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema. Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil. 2.3.4. Metodologías ágiles Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento) [11]. Entre las metodologías ágiles identificadas en [11]:
• • • • • • • •

Extreme Programming [6]. Scrum ([12], [13]). Familia de Metodologías Crystal [14]. Feature Driven Development [15]. Proceso Unificado Rational, configuración ágil ([16]). una

Dynamic Systems Development Method [17]. Adaptive Software Development [18]. Open Source Software Development [19].

2.3.4.1. Programación extrema La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más é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 aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Características13

• • • • • • • •

Desarrollo iterativo e incremental Pruebas unitarias continuas Programación en parejas integración del equipo de programación con el cliente Corrección de todos los errores Refactorización del código Propiedad del código compartida Simplicidad en el código

2.3.4.2. Scrum Scrum es un proceso de desarrollo de software iterativo e incremental utilizado comúnmente en entornos basado en la metodología Agile de desarrollo de software. Scrum es un proceso marco que incluye un conjunto de prácticas 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 días (la longitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características 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 reunión de sprint planning. Durante esta reunión, 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 están 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 fácil 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 metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades. 2.3.4.4. Métrica V314 La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil para la sistematización 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 Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos. Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos. Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible. Facilitar la comunicación y entendimiento entre los distintos participantes en la producción 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 operación, mantenimiento y uso de los productos software obtenidos.

Los procesos de la estructura principal de MÉTRICA Versión 3 son los siguientes: • • • PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN. DESARROLLO DE SISTEMAS DE INFORMACIÓN. MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN.

Y define el proceso de desarrollo de sistemas de información en: • • • • • ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS). ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI). DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI). CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI). IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS).

2.3.4.5. Open Source Development Software15 Open Source es software desarrollado con la falta de coordinación, donde los programadores que colaboran libremente, utilizando libremente el código fuente distribuido y la infraestructura de comunicaciones de Internet. El código abierto se basa en la filosofía del software libre. Sin embargo, el código abierto extiende esta ideología ligeramente para presentar un enfoque más comercial que incluye tanto un modelo de negocio y metodología de desarrollo. La catedral y el bazar es la descripción 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 código abierto, no exponer la dinámica. Existen críticas sobre ciertos aspectos que siguen siendo ambiguas, lo que sugiere que el documento no describe el proceso de desarrollo de código abierto.

15

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

III. METODOLOGÍAS DE CONTROL DE CALIDAD DEL SOTWARE
La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía 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 política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.
● ●

El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software. El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software. El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política 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 evaluación.

3.1.¿Como controlar la calidad del software?
Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, 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 métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, 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 categorías de métricas: de complejidad de programa o código, 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: clasificación por tipo, esfera de aplicación, complejidad, etc., de acuerdo con los estándares 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 métodos de valoración de los indicadores: métodos manuales como cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas automatizadas para medir los criterios de cálculo. Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.

3.2.La gestión de la calidad
Gestión de la calidad: "Aspectos de la función de gestión que determinan y aplican la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad". Dentro de la gestión de la calidad se observa:

Gestión de la calidad de software (ISO 9000): Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificación de la calidad, el control de la calidad, el aseguramiento (garantía) de la calidad y la mejora de la calidad, en el marco del sistema de calidad Política de calidad (ISO 9000): Directrices y objetivos generales de una organización, relativos a la calidad, tal como se expresan formalmente por la alta dirección.

La gestión de la calidad se aplica normalmente a nivel de empresa. También puede haber una gestión de calidad dentro de la gestión de cada proyecto.

3.3.El aseguramiento de la calidad
Ante todo se debe conocer:

Aseguramiento de la calidad: "Conjunto de acciones planificadas y sistemáticas 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 sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad.

El aseguramiento de calidad del software se diseña para cada aplicación antes de comenzar a desarrollarla. Hay quienes prefieren decir garantía de calidad en vez de aseguramiento. La garantía, puede confundir con garantía de productos, mientras que el aseguramiento pretende dar confianza en que el producto tiene calidad. El aseguramiento de calidad del software está presente en:
• • • • • • •

Métodos y herramientas de análisis, diseño, programación y prueba. Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software. Estrategias de prueba multiescala. Control de la documentación del software y de los cambios realizados. Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos). Mecanismos de medida (métricas). Registro de auditorias y realización de informes. Métricas de software para el control del proyecto. Verificación y validación del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisión e inspección). La gestión de la configuración del software. Revisiones técnicas y de gestión (su objetivo es la evaluación). Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto correcto?. Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto correctamente?. Auditorias (su objetivo es la confirmación del cumplimiento).

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

Algunos métodos del aseguramiento:
• • • •

3.4.El control de la calidad
Se debe conocer:

Control de calidad: "Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio". Control de la calidad del software: Técnicas y actividades de carácter 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 aplicación de conceptos de gestión de procesos y de mejora de calidad en el desarrollo y mantenimiento de software, que deben ser implementadas por toda organización 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 reacción 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 tecnología 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, sistemático y suficientemente detallado. Además 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 fácilmente 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 adaptación del proceso a la realidad de la empresa debieran garantizar su aplicación 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 día 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 estándares aplicables. Se mide: La utilización, 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 metodologías.

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 ingeniería de software y de administración de proyectos usados en una organización de desarrollo de software y entendiéndose 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 número de áreas de proceso importantes que deben lograrse. Su logro se detecta mediante la satisfacción (o no) de varios metas claras y cuantificables. Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está compuesto por un cierto número de Áreas Claves de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA. Cada KPA identifica una agrupación de actividades y prácticas relacionadas, las cuales cuando son realizadas en forma colectiva permiten lograr alcanzar las metas fundamentales del proceso. Las

KPAs pueden clasificarse Organizacional e Ingeniería.

en

3

tipos

de

proceso:

Gestión,

Las prácticas que deben ser realizadas por cada Area Clave de Proceso están organizadas en 5 Características Comunes, las cuales constituyen propiedades que indican si la implementatción y la institucionalización de un proceso clave es efectivo, repetible y duradero. Estas 5 características son:
• • • • •

Compromiso de la realización. La capacidad de realización. Las actividades realizadas Las mediciones y el análisis La verificación de la implementación.

El modelo CMM se formula de una manera genérica. Es independiente de cualquier método (o metodología) y de cualquier ambiente de tecnología (software o hardware). Los métodos específicos usados por una compañía o agencia no impone restricciones específicas en la utilización del SW-CMM, debido a que sus prácticas se formulan de forma general para que pueda fácilmente adaptarse de manera de satisfacer las necesidades de ambientes particulares. Este modelo debe interpretarse de acuerdo al tamaño de las compañías o agencias, pero es aplicable en el contexto global. Cualquier entidad que desarrolla o mantiene software, independientemente de su tamaño se beneficiará mejorando su proceso de software aplicando el CMM. Uno de los métodos de evaluación 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 determinación de sus puntos fuertes y necesidades de mejoramiento, también permite revisar las prácticas de los proveedores externos, a objeto de que puedan derivar un plan de mejoramiento adecuado a su organización. 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 prácticas básicas de gestión de proyectos e ingeniería de software definidas a partir del nivel 2 o superiores. Una empresa está en el nivel caótico 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 frustración permanentes. La gerencia ocupa una parte significativa de su tiempo en paliar problemas y enfrentar clientes insatisfechos. Ante una situación de crisis permanente, se les hace difícil destinar recursos para definir o

documentar procesos, lo que lleva a un círculo sin salida. Cuando el proyecto se termina, la inversión 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 implementación de prácticas mínimas de administración 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 inversión en procesos para aplicarla en un nuevo proyecto. Este nivel no garantiza que todos los proyectos dentro de la empresa estén necesariamente al mismo nivel de madurez. Algunos pueden estar todavía en el nivel inicial. Luciano Guerrero [1], en cuya página hemos basado gran parte del trabajo ha visto algunos casos en la práctica 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 frustración y descalabro de carreras profesionales. Beneficios de implantar el Nivel 2 El mayor beneficio obtenido de la implementación del nivel 2 por la empresa en la cual se encuentra actualmente [1], es la planificación realista de los proyectos. Antes los cronogramas de proyecto expresaban más los deseos de la gerencia que la realidad. Este principio (el mismo en la cual se basa la magia) conducía una situación de buscar culpables y generar excusas, produciendo al mismo tiempo frustración y desconfianza entre clientes y empleados actualmente en la empresa, los cronogramas son cada día más confiables, y mejora a medida que se acumula más información en las bases de datos de los proyectos pasados. El uso generalizado de métodos de estimación permite al personal del proyecto de justificar plazos y recursos. Aún el "olfato profesional" y la experiencia personal juegan un papel importante en la generación de planes de proyecto, pero ahora son decisiones informadas en vez de simples adivinanzas como en el pasado. Los pasos siguientes Este nivel todavía permite la proliferación y definición insuficiente de los procesos de ingeniería de software. Los proyectos comparten principalmente sus experiencias en materia de administración de proyectos, pero sus métodos técnicos pueden diferir. Aún existe incomunicación entre proyectos, grupos y entre personal y gerencia. Este nivel identifica prácticas de sentido común que son aplicables en todo tipo de organizaciones de desarrollo de software, independientemente de su rubro, tamaño o ambiente de desarrollo. La ausencia de cualquiera de sus prácticas simplemente pone en peligro el éxito de la empresa.

KPAs del Nivel 2 • • • • • • Gestión de Requisitos Planificación del proyecto de software Seguimiento y Supervisión del proyecto Gestión de subcontratos de software Garantía de calidad de software Gestión de configuración del software

3. Nivel 3: El proceso definido El proceso generalizado en todos los proyectos La empresa ha definido un conjunto de procesos, metodologías y herramientas comunes a todos los proyectos iniciados por la corporación. El proceso común está suficientemente documentado en una biblioteca accesible a todo los desarrolladores. Todo el personal ha recibido el entrenamiento necesario para entender el proceso estándar. Existen pautas y criterios definidos para adaptar dicho proceso a las necesidades y características propias de cada proyecto. El nivel de definición 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 reúne estadísticas de los proyectos pasados en curso, permite planificar y comparar el rendimiento. Existen mecanismos de comunicación entre proyectos y departamentos, lo que garantiza una visión común del producto y una rápida acción para enfrentar los problemas. Según el autor [1], ha conocido unas pocas empresas a este nivel y la cosa que más le llamo la atención, fue la satisfacción del personal. En empresas de nivel 1 habitualmente se escuchan quejas y acusaciones. A nivel 3 los empleados tienen una alta valoración de los procesos y entienden claramente la manera en que afecta su desempeño habitual. Los gerentes pueden realizar su verdadera función, 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 pánico 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 organización

• • • • • •

Definición del proceso de la organización Programa de entrenamiento Gestión integrada del software Ingeniería de software del producto Coordinación entre grupos Revisión de pares

4. Nivel 4: El proceso gestionado La calidad planificada y confiable En este nivel la corporación mide la calidad del producto y del proceso de software. Ambos, producto y proceso, son seguidos en forma cuantitativa y se controlan mediante métricas 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 través de todo el proyecto. Los proyectos pueden controlar la variación 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 variación (ruido) al azar, particularmente dentro de líneas de productos establecidas. Es necesario aclarar que el hecho de contar con un sistema de métricas de software no significa que se esté en el nivel 4. Es una virtual señal 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 daño 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 práctica, o incluso que entiendan bien las áreas claves de proceso del nivel 4. Son solamente 2 prácticas, pero imposibles de alcanzar si no se ha implementado firmemente los 2 niveles de madurez anteriores. KPAs del Nivel 4 • • Gestión cuantitativa del proceso Gestión de la calidad del software

5. Nivel 5: El mejoramiento permanente

La calidad planificada y confiable En el Nivel Optimizado, la característica principal es el mejoramiento continuo del proceso, en base a la realimentación cuantitativa y al ensayo de ideas y tecnologías innovadoras. Beneficios de implantar el Nivel 5 del CMM La organización entera se aboca al mejoramiento continuo del proceso. La corporación 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 tecnologías y de implementar cambios al proceso de software. Los proyectos de software analizan los defectos para determinar sus causas. Los proceso de software se evalúan para prevenir que los defectos conocidos vuelvan a ocurrir, asimismo las lecciones aprendidas son difundidas a otros proyectos. Los pasos siguientes No existen más de 10 empresas en el mundo que estén a este nivel (no hay ninguna en países 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 mayoría de las empresas productoras de software. Luciano Guerrero [1] opina que “es una hermosa utopía, pero inalcanzable en el mundo normal.” KPAs del Nivel 5 • • • 2. La familia CMM Hay toda una familia de modelos de madurez (CMM’s), aplicables a otros dominios relacionados con el software. SW-CMM: El modelo CMM lo aplicamos específicamente al ámbito del software . SE- CMM: que significa Systems Engineering, el cual cubre el ámbito de la Ingeniería de Sistemas. P-CMM: que significa Personal CMM, el cual cubre la administración de P-CMM: personal. SA-CMM: que significa Software Acquisition, el cual cubre las prácticas de la adquisición de productos de software. IPD-CMM: que significa Integrated Product Development, el cual cubre el desarrollo de la integración del producto. A continuación pasamos a detallar los cinco niveles de madurez de que consta CMM. 2. ISO / IEC TR 15504 Prevención de defectos Gestión del cambio de tecnología Gestión del cambio del proceso

Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Origen En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para el desarrollo de un modelo que fuera la base de un futuro estándar internacional para la evaluación 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 publicación 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 técnico con la denominación ISO/IEC TR 15504. La instrucción técnica consta de 9 apartados, recogidos en volúmenes independientes que se han ido publicando como redacción definitiva del estándar internacional ISO/IEC 15504 durante el periodo 2003 - 2005. Características
• • •

Establece un marco para métodos de evaluación, no es un método o modelo en sí. Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad. Está alineado con el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación 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 dimensión de proceso agrupa a los procesos en tres grupos que contienen cinco categorías de acuerdo al tipo de actividad: Procesos primarios
• •

CUS: Cliente - Proveedor ENG: Ingeniería

Procesos de soporte

SUP: Soporte

Procesos organizacionales
• •

MAN: Gestión ORG: Organización

Para todos los procesos se definen los componentes: Identificador, Nombre, Tipo, Propósito, Salidas y Notas. Desde la dimensión 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 optimización

3.5.3 METRICA3 La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil para la sistematización 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 Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos. Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos. Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible. Facilitar la comunicación y entendimiento entre los distintos participantes en la producción 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 operación, mantenimiento y uso de los productos software obtenidos.

En una única estructura la metodología MÉTRICA Versión 3 cubre distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a través de interfaces la realización de los procesos de apoyo u organizativos: Gestión de Proyectos, Gestión de Configuración, Aseguramiento de Calidad y Seguridad. La automatización de las actividades propuestas en la estructura de MÉTRICA Versión 3 es posible ya que sus técnicas están soportadas por una amplia variedad de herramientas de ayuda al desarrollo. 3.5.3.1 PROCESOS PRINCIPALES DE MÉTRICA MÉTRICA Versión 3 tiene un enfoque orientado al proceso, ya que la tendencia general en los estándares 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 clasificación y definición de los procesos del ciclo de vida del software. Como punto de partida y atendiendo a dicha norma, MÉTRICA Versión 3 cubre el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Información. MÉTRICA Versión 3 ha sido concebida para abarcar el desarrollo completo de Sistemas de Información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. La metodología 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, técnicas, prácticas y participantes. El orden asignado a las actividades no debe interpretarse como secuencia en su realización, ya que éstas pueden realizare en orden diferente a su numeración o bien en paralelo, como se muestra en los gráficos 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 MÉTRICA Versión 3 son los

siguientes:
● ● ●

PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN. DESARROLLO DE SISTEMAS DE INFORMACIÓN. MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN.

El enfoque del Proceso de Planificación de Sistemas de Información, 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 están sometidas las organizaciones. El entorno de alta competitividad y cambio en el que actualmente se encuentran las organizaciones, hace cada vez más crítico el requerimiento de disponer de los sistemas y las tecnologías de la información con flexibilidad para adaptarse a las nuevas exigencias, con la velocidad que demanda dicho entorno. La existencia de tecnología de reciente aparición, permite disponer de sistemas que apoyan la toma de decisiones a partir de grandes volúmenes de información procedentes de los sistemas de gestión e integrados en una plataforma corporativa. MÉTRICA Versión 3 ayuda en la planificación de sistemas de información facilitando una visión general necesaria para posibilitar dicha integración y un modelo de información global de la organización. En cuanto al Proceso de Desarrollo de Sistemas de Información, para facilitar la comprensión y dada su amplitud y complejidad se ha subdividido en cinco procesos:
● ● ● ● ●

ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS). ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI). DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI). CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI). IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS).

La necesidad de acortar el ciclo de desarrollo de los sistemas de información ha orientado a muchas organizaciones a la elección de productos software del mercado cuya adaptación a sus requerimientos suponía un esfuerzo bastante inferior al de un desarrollo a medida, por no hablar de los costes de mantenimiento. Esta decisión, que es estratégica en muchas ocasiones para una organización, 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 práctica, cada vez más habitual en las organizaciones, de la contratación de servicios externos en relación con los sistemas y tecnologías de la información y las comunicaciones, llevando a la necesidad de una buena gestión y control de dichos servicios externos y del riesgo implícito en todo ello, para que sus resultados supongan un beneficio para la organización. MÉTRICA Versión 3 facilita la toma de decisión y la realización de todas las tareas que comprende el desarrollo de un sistema de información. Desde el enfoque de la norma ISO 12.207, el Proceso de Mantenimiento de Sistemas de Información comprende actividades y tareas de modificación o retirada de todos los componentes de un sistema de información (hardware, software, software de base, operaciones manuales, redes, etc.). Este marco de actuación no es el objetivo de MÉTRICA Versión 3, ya que esta metodología está dirigida principalmente al proceso de desarrollo del software. Por lo tanto, MÉTRICA Versión 3 refleja los aspectos del Mantenimiento, correctivo y evolutivo, que tienen relación 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 MÉTRICA Versión 3 es proporcionar un marco común de referencia para la definición y puesta en marcha de planes específicos de aseguramiento de calidad aplicables a proyectos concretos. Si en la organización ya existe un sistema de calidad,

dichos planes deberán ser coherentes con el mismo, completándolo 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 características inherentes cumple con unos requisitos” [ISO 9000:2000]. El Aseguramiento de la Calidad pretende dar confianza en que el producto reune las características necesarias para satisfacer todos los requisitos del Sistema de Información. Por tanto, para asegurar la calidad de los productos resultantes el equipo de calidad deberá realizar un conjunto de actividades que servirán para: ● Reducir, eliminar y lo más 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 específico que se aplicará durante la planificación del proyecto de acuerdo a la estrategia de desarrollo adoptada en la gestión del proyecto. En el plan de aseguramiento de calidad se reflejan las actividades de calidad a realizar (normales o extraordinarias), los estándares a aplicar, los productos a revisar, los procedimientos a seguir en la obtención de los distintos productos durante el desarrollo en MÉTRICA Versión 3 y la normativa para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su corrección. El grupo de aseguramiento de calidad participa en la revisión 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 están dirigidas a: ● Identificar las posibles desviaciones en los estándares 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 más importantes del aseguramiento de la calidad, debido a que permiten eliminar defectos lo más pronto posible, cuando son menos costosos de corregir. Además existen procedimientos extraordinarios, como las auditorías, aplicables en desarrollos singulares y en el transcurso de las cuales se revisarán tanto las actividades de desarrollo como las propias de aseguramiento de calidad. La detección 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 Análisis, Diseño, Construcción, Implantación y Aceptación 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 información definidos en cada alternativa de solución propuesta, con el fin de identificar las condiciones en que se van a desarrollar y/o a implantar, así como las características que deben reunir en cuanto a operación, mantenibilidad y portabilidad, para satisfacer las necesidades del cliente y los requisitos especificados. La necesidad de establecer un plan específico de aseguramiento de calidad y el grado de intensidad con el que se aplican las actuaciones de calidad, vendrá determinada en función de este estudio y de los riesgos analizados por el equipo de desarrollo. Una vez tomada la decisión 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 estándares de calidad, si existen en la organización, sino se recomienda acudir a los estándares UNE-EN-ISO 9001:2000 Sistemas de Gestión de la Calidad – Requisitos y UNE-ENISO 9000:2000 Sistemas de Gestión 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 también 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: IDENTIFICACIÓN DE LAS PROPIEDADES DE CALIDAD PARA EL SISTEMA

ACTIVIDAD EVS–CAL 2: ESTABLECIMIENTO ASEGURAMIENTO DE CALIDAD

DEL

PLAN

DE

ACTIVIDAD EVS–CAL 3: ADECUACIÓN DEL ASEGURAMIENTO DE CALIDAD A LA SOLUCIÓN

PLAN

DE

3.5.3.2.2 ANÁLISIS DEL SISTEMA DE INFORMACIÓN En este proceso se define de forma detallada el plan de aseguramiento de calidad para un sistema de información, a partir de la especificación resultante del proceso Estudio de Viabilidad del Sistema (EVS). También se detallan los estándares 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 corrección e identificando quiénes son los responsables en cada caso. En el proceso Análisis del Sistema de Información (ASI), el grupo de aseguramiento de calidad se implica directamente en la revisión de los siguientes productos: ● Catálogo de requisitos, comprobando hasta que punto se han definido de una forma que facilite su comprensión y seguimiento. ● Modelos resultantes del análisis, 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 definición los criterios establecidos en el plan de aseguramiento de calidad, con el fin de facilitar en los procesos Diseño del Sistema de Información (DSI), Construcción del Sistema de Información (CSI) e Implantación y Aceptación del Sistema (IAS) la revisión de los distintos niveles de prueba.

ACTIVIDAD ASI-CAL 1: ESPECIFICACIÓN INICIAL DEL PLAN DE ASEGURAMIENTO DE CALIDAD

ACTIVIDAD ASI–CAL 2: ESPECIFICACIÓN DETALLADA DEL PLAN DE ASEGURAMIENTO DE CALIDAD

ACTIVIDAD ASI-CAL 3: REVISIÓN DEL ANÁLISIS DE CONSISTENCIA

ACTIVIDAD ASI-CAL 4: REVISIÓN DEL PLAN DE PRUEBAS

Actividad ASI-CAL 5: Registro de la Aprobación del Análisis del Sistema

3.5.3.2.3 DISEÑO DEL SISTEMA DE INFORMACIÓN Las revisiones del diseño se centran en confirmar que los requisitos especificados en el proceso Análisis del Sistema de Información se han traducido en una arquitectura conforme al entorno tecnológico seleccionado. Asimismo, se revisan los requisitos que deben cumplir los distintos niveles de pruebas (unitarias, de integración, del sistema, de implantación y aceptación) especificados en el plan de pruebas, de acuerdo a los criterios de revisión establecidos en el plan de aseguramiento de calidad. También se realiza una revisión de la identificación de los requisitos no funcionales relacionados con la documentación de usuario e implantación. El siguiente esquema muestra la correspondencia entre las actividades del proceso DSI y las de la interfaz de Aseguramiento de la Calidad.

ACTIVIDAD DSI–CAL 1: REVISIÓN DE LA VERIFICACIÓN DE LA ARQUITECTURA DEL SISTEMA

ACTIVIDAD DSI–CAL 2: REVISIÓN DE LA ESPECIFICACIÓN TÉCNICA DEL PLAN DE PRUEBAS

ACTIVIDAD DSI–CAL 3: REVISIÓN DE LOS REQUISITOS DE IMPLANTACIÓN

ACTIVIDAD DSI-CAL 4: REGISTRO DE LA APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN

3.5.3.2.4 CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN En este proceso el grupo de aseguramiento de calidad revisa los estándares de nomenclatura y normativa aplicada en la generación del código de componentes, en la evaluación de los resultados de las pruebas, en los manuales de usuario y en el esquema de formación. Con respecto a las pruebas, se revisa que se han llevado a cabo las pruebas unitarias, de integración y del sistema según los criterios de selección de verificaciones y casos de prueba asociados que se habrán 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 CSI–CAL 1: REVISIÓN DEL CÓDIGO DE COMPONENTES Y PROCEDIMIENTOS

ACTIVIDAD CSI–CAL 2: REVISIÓN DE LAS PRUEBAS UNITARIAS, DE INTEGRACIÓN Y DEL SISTEMA

ACTIVIDAD CSI–CAL 3: REVISIÓN DE LOS MANUALES DE USUARIO

ACTIVIDAD CSI–CAL 4: REVISIÓN DE LA FORMACIÓN A USUARIOS FINALES

ACTIVIDAD CSI-CAL 5: REGISTRO DE LA APROBACIÓN DEL SISTEMA DE INFORMACIÓN

3.5.3.2.5 IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA El grupo de aseguramiento de calidad en este proceso es responsable de revisar la existencia de un plan de implantación que se habrá elaborado conforme a la estrategia de implantación determinada en el proceso Estudio de Viabilidad del Sistema (EVS) y teniendo en cuenta los requisitos de implantación establecidos en el proceso Diseño del Sistema de Información (DSI).

También deben comprobar que se han realizado las pruebas de implantación y de aceptación según el plan de pruebas establecido en MÉTRICA Versión 3 y la normativa acordada en el plan de aseguramiento de calidad. Revisan la totalidad de las verificaciones y casos de prueba de implantación y aceptación 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 aprobación de las pruebas de implantación y de aceptación por parte de operación 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 producción. 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: REVISIÓN DEL PLAN DE IMPLANTACIÓN DEL SISTEMA

ACTIVIDAD IAS–CAL 2: REVISIÓN IMPLANTACIÓN DEL SISTEMA

DE

LAS

PRUEBAS

DE

ACTIVIDAD IAS–CAL 3: REVISIÓN ACEPTACIÓN DEL SISTEMA

DE

LAS

PRUEBAS

DE

ACTIVIDAD IAS–CAL 4: REVISIÓN DEL PLAN DE MANTENIMIENTO DEL SISTEMA

ACTIVIDAD IAS–CAL 5: REGISTRO DE LA APROBACIÓN DE LA IMPLANTACIÓN DEL SISTEMA

3.5.3.2.6 MANTENIMIENTO DEL SISTEMA DE INFORMACIÓN En el proceso Implantación y Aceptación del Sistema se habrá determinado la necesidad de llevar a cabo un seguimiento y control de la

calidad en los sistemas de información, una vez se encuentren en el entorno de producción. El grupo de aseguramiento de calidad intenvendrá durante el mantenimiento, efectuando revisiones de seguimiento periódicas, más o menos frecuentes según los casos, que sirvan para constatar que el mantenimiento establecido para el sistema de información se realiza de forma correcta. En algún caso, según las implicaciones del cambio, puede ser necesario revisar puntualmente: ● El contenido del plan de pruebas de regresión. ● La ejecución de las pruebas de regresión según 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 petición. ● Las incidencias detectadas con el fin de determinar si puede verse afectada alguna propiedad de calidad. En caso de revisar la ejecución de las pruebas de regresión, se registrará la aprobación de las pruebas por el responsable de mantenimiento. En el siguiente gráfico se aprecian las actividades de Aseguramiento de la Calidad durante el Mantenimiento del Sistema de Información.

ACTIVIDAD MSI-CAL 1: REVISIÓN DEL MANTENIMIENTO DEL SISTEMA DE INFORMACIÓN

ACTIVIDAD MSI–CAL 2: REVISIÓN DEL PLAN DE PRUEBAS DE REGRESIÓN

ACTIVIDAD MSI–CAL3: REVISIÓN DE LA REALIZACIÓN DE LAS PRUEBAS DE REGRESIÓN

IV. METODOLOGÍA DE GESTIÓN 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 sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad. El aseguramiento de calidad del software se diseña para cada aplicación antes de comenzar a desarrollarla y no después. Algunos autores prefieren decir garantía de calidad en vez de aseguramiento. – Garantía, puede confundir con garantía de productos – Aseguramiento pretende dar confianza en que el producto tiene calidad El aseguramiento de calidad del software está presente en los siguientes casos: – Métodos y herramientas de análisis, diseño, programación y prueba – Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del software – Estrategias de prueba multiescala – Control de la documentación del software y de los cambios realizados – Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos) – Mecanismos de medida (métricas) – Registro de auditorias y realización de informes Actividades para el aseguramiento- de calidad del software – Métricas de software para el control del proyecto – Verificación y validación del software a lo largo del ciclo de vida Incluye las pruebas y los procesos de revisión e inspección – La gestión de la configuración 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 público. Aparecerán durante la realización de la auditoría, pero su especificación debe realizarse al principio. Se conoce como garantía de calidad de Software (SQA, Software Quality Assurance) al conjunto de actividades que se aplican a lo largo de todo el proceso de ingeniería del software. SQA engloba: • Métodos y herramientas de análisis, diseño, codificación y prueba. • Revisiones técnicas formales que se aplican durante cada paso de la ingeniería del software. • Pruebas de software secuenciadas en múltiples pasos y con métodos específicos de diseño de casos de prueba. • Control de la documentación del software y de los cambios

realizados. • Procedimientos que aseguren un ajuste a los estándares de desarrollo de software. • Mecanismos de medida y de información. • Métricas para medir la calidad del software. Todo este proceso se realiza de forma interna. La propia organización puede tener un grupo de SQA que se encargue de la realización de todas las tareas necesarias. Es posible tener un grupo de consultores externos dedicados a SQA pero, a poco que la organización tenga una mediana actividad de desarrollo, los costes económicos de esta opción pueden ser elevados. SQA es un proceso de control. La auditoría que puede encargarse de SQA sin sufrir contradicción con la idea de “punto discontinuo de control” es la auditoría 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 sólo pueden ser medidos indirectamente. En cualquiera de los dos casos debemos comparar el software con una referencia y llegar a una indicación de la calidad. Se han propuesto los siguientes factores de calidad del software: • Corrección: 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 precisión requerida. • Eficiencia: La cantidad de recursos de ordenador y de código requeridos por un programa para llevar a cabo sus funciones. • Integridad: La información 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 interoperación: Esfuerzo requerido para acoplar un sistema a otro.

Es difícil 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é métricas utiliza para la evaluación del software. La garantía de calidad del software (SQA) es un «planificado y sistemático diseño 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 estándares establecidos? ¿Las disciplinas técnicas han desempeñado 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 métodos técnicos que ayudan al analista a conseguir una especificación y un diseño de alta calidad. Una vez que se ha creado una especificación, un diseño o un módulo, debe ser garantizada de algún modo su calidad. La actividad central que permite garantizar la calidad es la revisión técnica formal. El personal técnico se reúne con el único propósito de descubrir problemas de calidad. Otro método usado comúnmente es la prueba de software. Este procedimiento combina múltiples pasos con una serie de métodos de diseño de casos de prueba que ayudan a asegurar una efectiva detección de errores. Muchos grupos de desarrollo de software usan la prueba como una red de seguridad para la garantía de la calidad. Se asume que mediante la prueba se descubrirá la mayoría de los errores, mitigando así la necesidad de otras actividades de SQA. El grado de aplicación de procedimientos y estándares en el proceso de ingeniería del software varía ampliamente dependiendo de la organización de la que se trate. Si existen estándares 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 metodología de desarrollo de sistemas que se use en esa organización. Enfoques formales a la SQA Todo lo que se ha comentado hasta ahora de SQA se concreta en la práctica en un conjunto de actividades que se deben realizar durante el desarrollo de sistemas. Debido a esto, previamente se señaló que son actividades de control, no de auditoría;

alternativamente, se les puede llamar actividades de auditoría interna. Segmentos de la comunidad de ingenieros de software vienen sosteniendo que se deben implementar una serie de controles más rigurosos, de tipo matemático y estadístico. Estos controles pueden ser efectuados en cualquier momento, incluso en la fase de explotación de sistemas. Se describirán dos técnicas, que pueden ser el objetivo de un proyecto de auditoría que abarque el área de explotación de SQA: • Proceso limpio de creación de software El proceso limpio de creación del software se centra en la consecución del objetivo de número de defectos nulo. La idea teórica central es conseguir la verificación matemática de la corrección de elementos de un sistema de información. Sin embargo, por el momento no se ha conseguido llevar a la práctica esta idea para sistemas medianamente complejos, aunque no sea totalmente descartable que en el medio plazo se avance en esta dirección. En segundo lugar, se debe proporcionar una certificación de calidad estadística. Para ilustrar este proceso, supongamos que una organización de desarrollo de software recoge información sobre defectos durante un año, tanto en explotación como en construcción 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 deberán ser clasificados en tres categorías: muy graves, graves, menores. Con estas dos clasificaciones (causa e importancia) se podrán establecer conclusiones estadísticas, que permitirán tomar medidas de corrección. Esta técnica permite efectuar una eliminación sistemática de las causas de los defectos empezando por los más serios y mejorando la utilización de los recursos. • Medidas de fiabilidad La fiabilidad del software se define en términos estadísticos como la “probabilidad de operación libre de fallos de un programa de ordenador en un entorno determinado y durante un tiempo específico”. 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 duración total de sus reparaciones, medida como el tiempo medio de la reparación (MTTR, Mean Time To Repare – es el tiempo medio de reparación) desde la comunicación del envío, contando desplazamientos del personal y la duración

de la reparación de la unidad averiada. Muchos investigadores argumentan que esta medida es más eficiente que la medida que se usa generalmente para evaluar la cantidad de errores, que es el número de errores por cada mil líneas de código. 4.3. Métodos y herramientas de análisis, diseño y codificación La calidad del software debe estar diseñada para el producto o sistema, no es algo impuesto a posteriori. Por esta razón, la garantía de calidad del software comienza realmente con un conjunto de herramientas y métodos técnicos que ayudan al analista a conseguir una especificación y un diseño de alta calidad. En un proceso de desarrollo software, existen una serie de fases que vienen determinadas por las tareas básicas que hay que realizar para obtener el producto software. Se definen distintos ciclos de vida de acuerdo a la evolución del software a lo largo de dichas fases. Las fases más típicas son: • Requisitos del Sistema: también llamada análisis de requisitos, especificación o diseño conceptual o diseño de alto nivel. Según (Durán Toro, Bernárdez Jiménez, Corchuelo Gil, & Toro Bonilla, 2000) en (IEEE, 1990) se define: “Requisitos: (a) una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. (b) una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, especificación u otro documento formal. (c) una representación en forma de documento de una condición o capacidad como las expresadas en (a) o (b).”

La ingeniería de requisitos se define como: “Todas las actividades relacionadas con: (a) identificación y documentación de las necesidades del cliente y usuarios, (b) creación de un documento que describe la conducta externa y las restricciones asociadas del sistema que satisfará dichas necesidades. (c) análisis y validación del documento de requisitos para asegurar su consistencia, viabilidad y que sea completo. (d) Evolución de las necesidades.” Existen varias propuestas en cuanto a las actividades que conlleva la ingeniería de requisitos. Por su claridad, se ha utilizado la presentada en (Durán Toro et al., 2000), que comprende tres actividades principales: obtención, análisis y validación. La mayor parte de las normas y autores asumen que el proceso de obtención de los requisitos, su análisis y validación es iterativo por naturaleza, ya que se reconoce que es prácticamente imposible obtener todos los requisitos y que éstos sean correctos sin tener

que volver atrás en algún momento del proceso. Las actividades son:

Obtención (“Elicitation”1) 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 técnicas cuyo resultado deben ser los requisitos orientados al cliente o también llamados requisitos-C.
(1 El término en inglés “elicitatión” se utiliza en la obtención de requisitos para definir la actividad realizada por el analista con el fin de proteger la información que de las necesidades del sistema tienen los usuarios finales, los expertos y los clientes.)

Análisis 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 construcción de modelos, en la que podrían 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. Además, esta actividad debe ser capaz de mostrar el conocimiento tácito, aquello que los usuarios no comentan por olvidarlo o considerarlo obvio. En esta fase ya se están tomando decisiones de cómo hacer el sistema ya que se realiza una descomposición del sistema en subpartes siguiendo la técnica de “divide y vencerás”. Validación de requisitos: los clientes y usuarios deben confirmar que los requisitos- C, una vez analizados, son válidos, correctos y completos, mediante las inspecciones de los documentos generados y mediante la evaluación del prototipo, proceso que por lo general conlleva la obtención de nuevos requisitos. Además 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 (Durán Toro et al., 2000). La manera habitual de expresar los requisitos-C es el lenguaje natural, que puede acompañarse del uso de plantillas y patrones lingüísticos para facilitar su uso. La forma de expresar los requisitos –D suele ser mediante un modelo construido con técnicas estructuradas (DFD, ERD, etc), técnicas orientadas a objetos (OMT, UML, etc) o técnicas 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 participación de los usuarios, requisitos incompletos y frecuentes cambios de los requisitos iniciales), es lógico que muchos estudios se basen

en esta etapa, por lo que las publicaciones relativas a la ingeniería de requisitos han sido abundantes en los últimos años (por ejemplo, los números especiales de las revistas “IEEE Software” Marzo/Abril 1998 o el de “Communications of the ACM” Diciembre 1998 así como diversos libros). Además, existen multitud de métodos de modelado en general que se utilizan para el modelado de los requisitos-D. Otro ejemplo es el proyecto MENHIR: Metodologías, Entornos y Nuevas Herramientas para la Ingeniería de Requisitos (Proyecto de la CICYT TIC 97- 0593-C05-0).

Diseño: también llamado diseño arquitectural o diseño de bajo nivel. Partiendo del modelo de análisis de requisitos obtenido en la fase anterior, se transforma éste en un conjunto de entes físicos (hardware) y entes lógicos (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 acompañado de las razones que lo han aconsejado, que suelen ser ciertas características que en su momento no se conocía, 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 análisis de requisitos y se utilizan para la creación de los requisitos -D (que evidentemente influyen directamente en la fase de diseño), puede darse el caso de que alguno de los requisitos del cliente tengan efecto directo sobre esta fase de diseño. Implantación e Integración: también llamada codificación. Consiste en la codificación del software utilizando un lenguaje de programación siguiendo la estructura y comportamiento determinados en el diseño. Revisiones del software que se aplican durante cada paso del desarrollo del mismo Una vez que se ha creado una especificación y un diseño de un software, debe garantizarse su calidad. Las revisiones del software son un filtro para el proceso de ingeniería del software y se aplican en varios momentos del desarrollo. Sirven para detectar fallos tanto en el análisis como en el diseño y la codificación, 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 más fácilmente al que los origina que a otras personas. Los errores cometidos en pasos anteriores se amplifican en el paso siguiente. Según las estadísticas, las actividades de diseño introducen entre el 50 y el 65 por 100 de todos los errores, por lo que cualquier técnica 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 técnicas formales o inspecciones, llevadas a cabo por ingenieros del software. Las revisiones técnicas formales

son el filtro más efectivo desde el punto de vista de la garantía del software, ya que detectan el 75% de los errores cometidos en el diseño. Los objetivos de la revisión técnica formal son: (a) Descubrir errores en la función, la lógica o la implantación de cualquier representación del software. (b) Verificar que el software bajo revisión alcanza sus requisitos. (c) Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos. (d) Conseguir un software desarrollado de forma uniforme. (e) Hacer que los proyectos sean más manejables. 4.4. Estrategia de prueba La prueba del software es un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y la codificación. La prueba requiere que se descarten las ideas preconcebidas sobre la “corrección” del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezca cuando se detecten errores. En un libro clásico 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 ejecución de un programa con la intención 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 múltiples técnicas de prueba. En (Press m, 1995) se muestran algunas de estas técnicas de prueba. Procedimiento que asegure un ajuste a los estándares de desarrollo del software.  Gestión de configuraciones de software (control de la documentación del software y de los cambios realizados) La gestión de configuraciones del software es una actividad “protectora” que se aplica a lo largo del proceso de ingeniería 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 sólo una vez que el software queda fuera de circulación. Los elementos que componen toda la información producida se denominan configuración del software (programas, documentos que describen los programas y estructuras de datos). La elaboración de la documentación

resulta muy costosa, por lo que es necesario intentar reducirla lo más posible y realizarla cuando los beneficios que conlleve superen el coste de su realización. 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 gestión 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 aquéllos a los que afecte. En (Belin, 1998) se muestran de manera resumida las ideas principales de la gestión de la configuración.  Mecanismos de medida. La medición es una actividad fundamental para cualquier disciplina de ingeniería. Un objetivo importante de la garantía de calidad es seguir la pista a la calidad del software y evaluar el impacto de los cambios de metodología y de procedimiento que intentan mejorar la calidad del software. Para conseguirlo, se deben recolectar métricas del software, como se verá más adelante.  Registro y realización de informes. Son procedimientos para la recolección y divulgación de información de la garantía de calidad del software. Los resultados de las revisiones, auditorías, control de cambios, prueba y otras actividades de la garantía de calidad deben convertirse en una parte del registro histórico de un proyecto. Además, deben ser divulgados a la plantilla de desarrollo para que tenga conocimiento de ellos.

V. AUDITORIAS DE SEGURIDAD [5.1] 5.1 Auditorías Técnicas Centrándonos ahora en las auditorías técnicas, dependiendo de la profundidad de los trabajos, hablaremos de auditorías de vulnerabilidades, que tratan de localizar configuraciones erróneas 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 intrusión o auditorías a nivel de aplicación, en la que los trabajos se expanden para dejar sitio al lado más "creativo y artesano" de los auditores de seguridad, que tratan de explotar errores de programación, la arquitectura de red y las relaciones de confianza, las debilidades de los protocolos de comunicación y los controles de acceso para simular los ataques a una infraestructura de red bajo los perfiles que se consideren de interés (atacante externo con distinto nivel de calificación, usuario interno, auditor, administrador, competencia...) bajo las mismas circunstancias y capacidades (información inicial, puntos de acceso, recursos disponibles...).

Por otro lado, dependiendo de la aproximación que tomemos para realizar las auditorías técnicas, 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 revisión de seguridad analizando la configuración del propio sistema, con acceso al mismo. Una auditoría de seguridad de caja negra normalmente comienza con trabajos desde el exterior, para encontrar puntos débiles y ganar algún 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 basándose en el estándar OSSTMM (Open Source Testing Methodology Manual) o el documento SP 800-46 del NIST (instituto de estándares americano) que contemplan las pruebas a realizar para realizar una revisión de seguridad técnica completa. En el caso de una auditoría 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 estándares reconocidos y guías de "buenas prácticas", como por ejemplo, los trabajos del instituto de estándares 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 análisis en profundidad de la configuración del sistema, aunque en algunos casos una prueba de caja negra se convierte en caja blanca por haber logrado un acceso al sistema a través de alguna vulnerabilidad del mismo u obtener información que pueda analizarse de esta forma (por ejemplo, el código 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 filosofía, es necesario ampliar la información que se posee sobre los sistemas al máximo, incluyendo topología, protocolos utilizados, reglas en los cortafuegos, software empleado,

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

Análisis de la configuración de todos los sistemas operativos implantados: usuarios, ficheros, etc. Análisis de la robustez de las contraseñas utilizadas. Análisis de la configuración del software de base (Web, Mail, cortafuegos, etc.). Análisis del código fuente de las aplicaciones instaladas o desarrolladas a medida. Determinación de las vulnerabilidades presentes en los sistemas debido a la desactualización en la aplicación de parches de seguridad (obsolescencia de los sistemas).

En algunos casos estas tareas de análisis pueden ser automatizadas con algunas herramientas pero en la mayoría de los casos se realizarán de forma manual y requerirán de un conocimiento profundo de los sistemas auditados, recomendaciones del fabricante, etc. Generalmente estas inspecciones, aunque más laboriosas hacen que la tarea analíticacorrectora 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 ningún conocimiento de la infraestructura, garantizando de esta forma que el análisis no tratará de utilizar ningún tipo de información que facilite la tarea de análisis. El propósito de estas pruebas es que el auditor se comporte como si realmente fuese un "atacante" de la infraestructura. Durante un análisis de caja negra normalmente se llevarán 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 identificación de servicios (para determinar qué programas ofrecen los servicios ofrecidos, a través de las cabeceras obtenidas o respuestas programáticas y no fiándose de la lista de puertos TCP/IP conocidos), obtención de información (recuperación de información o datos de configuración del sistema final o sistemas adyacentes que desvelen detalles de la infraestructura auditada) y pruebas de vulnerabilidades en software estándar. Estas últimas pruebas son las más complejas y se realizarán una vez determinados los servicios que se están corriendo, junto con la información disponible de versiones y sistemas operativos. Se basan en una parte que puede ser realizada por herramientas de diagnóstico automáticas 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 caídas en los sistemas auditados.

Una vez se ha conseguido penetrar con éxito en un sistema, la auditoría de caja negra puede continuar hacia otros sistemas adyacentes (generalmente más expuestos una vez traspasado el perímetro) y también derivar hacia análisis de caja blanca. 5.2. Tipos de Pruebas [5.2] 5.2.1. Pruebas de unidad: La prueba de unidad se centra en el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito del módulo. La prueba de unidad hace uso intensivo de las técnicas de prueba de caja blanca. 5.2.2. Prueba de integración: El objetivo es coger los módulos probados en la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Hay dos formas de integración:
• •

Integración no incremental: Se combinan todos los módulos por anticipado y se prueba todo el programa en conjunto. Integración incremental: El programa se construye y se prueba en pequeños segmentos.

En la prueba de integración el foco de atención es el diseño y la construcción de la arquitectura del software. Las técnicas que más prevalecen son las de diseño 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 propósito primordial es ejercitar profundamente el sistema basado en computadora. Algunas de estas pruebas son:

• •

Prueba de validación: Proporciona una seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Además, valida los requerimientos establecidos comparándolos con el sistema que ha sido construido. Durante la validación se usan exclusivamente técnicas de prueba de caja negra. Prueba de recuperación: Fuerza un fallo del software y verifica que la recuperación se lleva a cabo apropiadamente. Prueba de seguridad: Verificar los mecanismos de protección.

• • •

Prueba de resistencia: Enfrenta a los programas a situaciones anormales. Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecución. Prueba de instalación: 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 regresión: Las pruebas de regresión son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que:
• •

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

La prueba de regresión puede implicar la re-ejecución de cualquier tipo de prueba. Normalmente, las pruebas de regresión se llevan a cabo durante cada iteración, ejecutando otra vez las pruebas de la iteración anterior. 5.3. Estrategias de pruebas del software: Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software. Las características generales son:
• • • •

La prueba comienza en el nivel de módulo y trabaja “hacia afuera”. En diferentes puntos son adecuadas a la vez distintas técnicas 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 depuración son actividades diferentes.

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

Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la

iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración. Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo 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 sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, 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:
• • • • •

Planificación de las pruebas. Diseño de las pruebas. Implementación de las pruebas. Ejecución de las pruebas. Evaluación 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 evaluación de Pruebas. Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración 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:

Diseñador de pruebas: Es responsable de la planificación, diseño, implementación y evaluación 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 diseñadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparación y evaluación de las mismas. Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integración y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecución, recuperar los errores y garantizar los resultados de las pruebas.

Durante la fase de Inicio puede hacerse parte de la planificación 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 integración y de sistema. Esto quiere decir que la realización de pruebas se centra en las fases de Elaboración, cuando se prueba la línea base ejecutable de la arquitectura, y de

construcción, cuando el grueso del sistema está implementado. Durante la fase de Transición el centro se desplaza hacia la corrección de defectos durante los primeros usos y a las pruebas de regresión. Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cómo probar los primeros productos de desarrollo software pueden ser utilizadas también como casos de prueba de regresión que especifican cómo llevar a cabo las pruebas de regresión sobre los productos de desarrollo software siguientes. El número de pruebas de regresión necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las últimas iteraciones requerirán un gran esfuerzo en pruebas de regresión. 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 eliminación de casos de prueba obsoletos. El refinamiento de algunos casos de prueba en casos de prueba de regresión. La creación de nuevos casos de prueba para cada nuevo producto de desarrollo de software.

5.4. Auditoría de procesos y gestión La realización de una actividad de auditoría debe realizarse siguiendo fielmente los códigos de buenas prácticas de seguridad de sistemas de información reconocidos internacionalmente, en este caso la norma ISO17799 y la guía del NIST SP 800-26. En Germinus entendemos que este tipo de auditoría debe realizarse con un conocimiento previo de los distintos riesgos y controles que son aplicables a una organización, debido a la amplitud del código de buenas prácticas ISO-17799 no tiene sentido auditar todos los controles recomendados si éstos no son aplicables a la organización, bien porque no existe un riesgo en ese sentido, bien porque el coste de implantación de dichos controles se ha considerado superior al coste resultante de la materialización de una amenaza (impacto) o del propio activo. Es por ello que la actividad de auditoría de procesos y gestión estará precedida por un trabajo de análisis del entorno de la organización incluyendo:
• • • • •

Análisis de la política de seguridad. Análisis de los procesos implantados, incluyendo, entre otros, los de gestión y administración. Entrevistas con los responsables de la seguridad de información de la organización para determinar los controles establecidos. Revisión de los análisis de riesgos realizados previamente y en función de los cuales se han implantado los controles. Revisión de las auditorías previas realizadas.

Toda vez que se haya realizado el análisis del entorno se procederá a realizar una revisión exhaustiva de los controles implantados, la correcta

implantación de los procedimientos y la concordancia con el código de buenas prácticas. Para ello se realizarán entrevistas con distinto personal de la organización, el personal concreto a entrevistar será definido basándose en el estudio del entorno y de la organización previamente realizado. Entre el personal entrevistado se incluirán a:
• • •

Los responsables de gestión. El personal técnico encargado de la gestión de la seguridad de cada uno de los sistemas. Usuarios de los sistemas de información (muestra aleatoria)

ANEXO 1 PLAN DE DESARROLLO DE SOFTWARE
Fase de Elaboración (4 semanas de duración) Comienzo Modelado del Negocio Modelo de Casos de Uso del Negocio y Semana 1 Modelo de Objetos del Negocio Requisitos Glosario Visión Modelo de Casos de Uso Especificación de Casos de Uso Especificaciones Adicionales Análisis/Diseño Modelo de Análisis/Diseño Modelo de Datos Implementación Prototipos de Interfaces de Usuario Modelo de Implementación 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 Aprobación

Casos de Pruebas Funcionales Despliegue Modelo de Despliegue

Semana 2

Semana 9

Semana 2

Semana 9

Gestión de Cambios y Configuración Durante todo el proyecto Gestión del proyecto Semana 7 Plan de Desarrollo del Software en su versión 3.0 y planes de las Iteración 2 de Elaboración Ambiente Semana 7

Durante todo el proyecto

ANEXO 2 MODELO DE UN PLAN DE CONFIGURACIÓN DE SOFTWARE [6] Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción del mismo, y posteriormente desde el inicio del mantenimiento hasta su retiro, se van realizando una serie de cambios, tanto en el código como en la documentación asociada. La Gestión de Configuración del Software es una disciplina encargada del control de la evolución de los productos de software. Como todo proceso, la Gestión de Configuración también puede ser sistematizada y automatizada, lo que se denomina un Sistema de Gestión de Configuración (SGC). Actualmente existen en el mercado diversas herramientas que permiten apoyar una o más actividades de la Gestión de Configuración. Definiciones Gestión de Configuración 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 estén completos y que sean los correctos. El propósito de la Gestión de Configuración del Software es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software. La Gestión de Configuración del Software implica la identificación

de la Configuración del software en puntos dados en el tiempo, el control sistemático de los cambios en la Configuración y el mantenimiento de la integridad y trazabilidad de la Configuración a través del ciclo de vida del software. Los productos incluidos son:
• • • •

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

Aspectos Funcionales 1. Identificación: Se necesita definir un esquema de identificación para reflejar la estructura del producto, esto involucra identificar la estructura y clases de componentes, dando a cada uno un nombre, una identificación de versión y una identificación de Configuración. 2. Control: Se deben controlar los cambios que se le hacen a través del ciclo de vida, asegurando que el software sea consistente a través de la creación de una línea base del producto. 3. Estado: Se debe registrar y reportar el estado de los componentes y solicitudes de cambio. 4. Auditoria y revisión: Se debe validar que el producto este completo y asi mantener la consistencia entre los componentes, asegurando que estén en un estado apropiado a través de todo el ciclo de vida del producto y que el mismo sea una colección bien definida de componentes. ALGUNOS CONCEPTOS PRESENTES EN LA DISCIPLINA Configuración Las características funcionales y físicas de una versión especifica de hardware y elementos de software que combinados de acuerdo a procedimientos de construcción específicos cumplen un propósito particular. Elementos de configuración de software Definimos como un elemento de Configuración a una unidad física y/o lógica parte de un conjunto mayor de elementos, producida o adquirida, que por sus características es distinguible de las demás

y

cuya

evolución

interesa

administrar.

Son elementos de Configuración en un proyecto de software: 01. El plan de proyecto. 02. El plan de Gestión de Configuración. 03. El documento de definición de requerimientos. 04. Estándares de análisis, diseño, codificación, pruebas, y auditoria. 05. Documentos de análisis del sistema. 06. Documentos de diseño del sistema. 07. Prototipos. 08. Documentos de diseño de alto nivel. 09. Documentos de diseño de bajo nivel. 10. Especificaciones de prueba del sistema. 11. El plan de pruebas del sistema. 12. El Código fuente del programa. 13. Código objeto y ejecutable. 14. Especificaciones de pruebas de unidad. 15. Planes de pruebas de unidad. 16. Documentos de diseño de base de datos. 17. Datos de prueba. 18. Datos del proyecto. 19 .Manuales de usuario. Versión Una versión es una instancia de un elemento de Configuración. El término se usa para señalar a un elemento de Configuración del software que tiene un conjunto definido de características funcionales. Revisión Se define revisión como una versión que se construye sobre otra versión anterior. El término revisión generalmente se asocia a la noción de corrección de errores, esto es, hacer cambios a un programa que corrigen solo errores en el diseño lógico pero no afectan las capacidades funcionales documentadas, dado que ningún requerimiento ha cambiado. Variante

Se define variante como una versión que es una alternativa a otra versión. Las variantes pueden permitir a un elemento de Configuración satisfacer requerimientos en conflicto. Una variante es una nueva versión de un elemento que será añadida a la Configuración sin reemplazar a la versión anterior. Por ejemplo, si se desarrolla una aplicación para varios sistemas operativos, algunas librerías pueden requerir modificaciones para poder ser compiladas o ejecutadas en los diferentes sistemas; la versiones para Unix y para Windows NT de una librería serían variantes del mismo elemento. Línea base Una línea base es una especificación o producto revisado y aprobado formalmente, que sirve como base para el desarrollo posterior, y puede ser modificado solo a través de procedimientos formales de control de cambios. El término también se usa para referirse a una versión particular de un elemento de software que ha sido aprobado. En cualquier caso, la línea base solo se puede modificar a través de procedimientos formales de control de cambios. Una línea base, junto con todos los cambios aprobados a la línea base, representa la Configuración aprobada actual. Procesos Asociados El estándar ISO/IEC 12207 ([ISO 12207]) para Procesos del Ciclo de Vida del Software, establece el Proceso de Gestión de Configuración 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 propósito distinto, y contribuye al éxito y a la calidad del proyecto de software. Este proceso consiste de las siguientes actividades: 1. Implementación del Proceso: Se desarrolla un Plan de Gestión de Configuración que describe las actividades de Gestión de Configuración, los procedimientos y el cronograma para su realización, y los responsables de dichas actividades. Dicho plan debe ser documentado e implementado. 2. Identificación de la Configuración: Se establece un esquema de identificación de los elementos de software y sus versiones a ser controlados por el proyecto. 3. Control de la Configuración: Se identifican y registran

las solicitudes de cambio, se analiza y evalúa los cambios, se aprueba o rechaza la solicitud, se implementa, verifica y distribuye el elemento de software modificado. 4. Contabilidad de Estado de la Configuración: Se preparan registros de Gestión y reportes de estado que muestren el estado e historia de los elementos de software controlados, incluyendo líneas base. 5. Evaluación de la Configuración: Se determina y asegura que los elementos de software sean funcionalmente (versus sus requerimientos) y físicamente completos (es decir, si su diseño y Código reflejan una descripción técnica actualizada). 6. Gestión de actualización y distribución: Se controla formalmente la actualización y distribución 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 estándar IEEE Std. 1074-1995 ([IEEE 1074]) para el Desarrollo de Procesos del Ciclo de Vida del Software, establece el Proceso de Gestión de Configuración 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 finalización y calidad de las funciones del proyecto. Este proceso consiste de las siguientes actividades: 1. Planificar la Gestión de Configuración. 2. Desarrollar la Identificación de la Configuración.

3. Realizar el Control de la Configuración. 4. Realizar la Contabilidad de Estado. Escenarios de Configuración en el Proceso de Software Gestión de configuración del código fuente La evolución del Código fuente es quizás el ejemplo mas claro en la Gestión de Configuración. A lo largo del desarrollo (y posteriormente en el mantenimiento) las modificaciones al software se realizan sobre el Código fuente. Y es según el Código fuente que se valida la documentación asociada. Los sistemas administradores de versiones se suelen integrar a los entornos de desarrollo y realizan administración de versiones del Código fuente. Cada modificación de uno de los archivos del programa va generando una revisión del mismo, y periódicamente se crean líneas base de todo el proyecto. De este modo, un equipo de desarrollo puede trabajar en paralelo, compartiendo versiones de archivos de Código fuente y actualizándolos periódicamente según se van creando o modificando los archivos que conforman el proyecto. Gestión de configuración en el desarrollo de software Como ya habíamos comentado, un elemento de Configuración puede ser prácticamente cualquier producto o subproducto del desarrollo de software. Las especificaciones de requisitos, los documentos de análisis y de diseño, el Código fuente y ejecutable, y los procedimientos y datos de prueba pueden ser sometidos a control de Configuración. Con un control riguroso, es posible entonces mantener registro del estado de todos estos elementos, lo que facilita la introducción de cambios si se tiene registro de las dependencias entre ellos, además de facilitar la elaboración de entregables; por ejemplo, si se tiene registro de las dependencias entre los elementos de Configuración, es posible que si se produce un cambio en las especificaciones, los documentos de análisis y diseño y el Código fuente asociados puedan ser actualizados sin que tome demasiado tiempo realizar su búsqueda. Gestión de configuración en el mantenimiento de software En el mantenimiento de software, cobra importancia la función 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 Gestión de Configuración que apoye la Gestión de solicitudes de cambio, debería permitir el registro por parte de los usuarios de las solicitudes de cambio, su revisión por parte del CCC, y si son aprobadas la creación de ordenes de cambio. Un cambio implica generalmente la actualización tanto del Código fuente, como de los documentos de especificación de requisitos, análisis y diseño, 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 Configuración. El cambio se vera reflejado en la creación de nuevas versiones de los elementos respectivos. Gestión en la distribución del software a las PC- Usuarios Cuando se pone en producción un software, se distribuyen copias del mismo entre los diversos usuarios del sistema. En este escenario, un sistema de Gestión de Configuración debería permitir registrar las Configuraciones (conjunto de versiones de elementos de Configuración) que cuenta cada PC - usuario. Puede ocurrir, que si un mismo sistema se vende a distintos clientes, en algún momento surjan requerimientos contradictorios o necesidades que lleven a la creación de variantes de los elementos de Configuración. El sistema de Gestión de Configuración apoyaría entonces al momento de estudiar una solicitud de un usuario a conocer cual es la Configuración con la que esta trabajando. Modelo Genérico 1. Permite la creación de tipos de elementos de Configuración. De este modo, es posible que el usuario cree sus propios tipos de elementos dependiendo que es lo que desea controlar. 2. Permite la creación de tipos de relaciones entre los elementos de Configuración. Es posible que el usuario cree los tipos de relaciones que desee, y que especifique dependencias para la creación de nuevas versiones entre el origen y el destino de la relación. Estas dependencias pueden ser:
• • •

Ninguna, Condicional-Origen (sí el origen cambia, el destino podría cambiar) Condicional-Destino (sí el destino cambia, el origen podría 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 relación puede tener los campos de información adicional que el usuario considere necesarios. 4. Un elemento de Configuración corresponde a un tipo y sus versiones pueden estar relacionadas con versiones de otros elementos según se creen relaciones para él. 5. Un elemento de Configuración tiene un conjunto de versiones asociadas, cada una de las cuales esta asociada al usuario (dueño) que la creo. 6. Un conjunto de versiones de elementos de Configuración conforma una Configuración. 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 información acerca de: 1. Los tipos de elementos sometidos a Gestión de Configuración. 2. Las relaciones entre dichos elementos. 3.Las dependencias para la creación de versiones al momento de analizar la introducción de un cambio. Es posible conocer como un

cambio en un elemento afectara a los demás. 4. Los usuarios que generaron cada versión de un elemento.

ANEXO 03 Descripción Detallada del SPMP Planes de Gestión de Proyectos Software Pagina de Título Carta de Revisión Prefacio Tabla de Contenidos Lista de Figuras Lista de Tablas 1 Introducción 1.1 Alcance 1.2 Propósito 1.3 Acuerdo del proyecto 1.4 Evolución de SPMP 2 Referencias 3 Definiciones 4 Organización 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 Gestión del Alcance Administrativo 5.5 Planes de gestión del Itinerario 5.6 Plan de gestión del Presupuesto 5.7 Plan de gestión de los Recursos 5.8 Planes de gestión de la Calidad 5.9 Planes de gestión de Riesgos 5.10 Planes de Obtención de Recursos 5.11 Planes de Manejo Comunicacional 6 Procesos Técnicos 6.1 Alcance del Producto 6.2 Métodos, Herramientas y Técnicas 6.3 Documentación del Software

7

Planificación 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 Página de título: Contiene el título de y una nota de revisión para identificar unívocamente el documento. Carta de revisión: Es una hoja separada que contiene el número de versión del documento, la fecha de revisión, firma de aprobación, una lista de las páginas que han sido modificadas en la actual versión y una lista de los números de versión y fechas de revisión 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 títulos y los números de página. 1 Introducción Esta parte provee una revisión 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 evolución para e SPMP. 1.1 Alcance Esta parte definiría el alcance tanto del proyecto como del producto a ser entregado. 1.2 Propósito Aquí se provee una resumida declaración 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 Evolución del SPMP Se especifica que mecanismos son usados para lograr la versión inicial del SPMP y cambios de control del SPMP. 2 Referencias Se provee una completa lista de todos los documentos y otros recursos de información referenciados en el SPMP. Cada documento puede ser identificado por el título, número de edición, fecha, autor, y organización editora. Otros recursos, como los archivos electrónicos, deben ser identificados de una manera no ambigua usando identificadores como la fecha y número de versión.

3 Definiciones Se puede definir o provee referencias de la definición de todos los términos y acronismos requeridos para interpretar adecuadamente el SPMP. 4 Organización del Proyecto Esta parte especifica el modelo del proceso para el proyecto, describe la estructura organizacional del proyecto, identifica el fin de la organización 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 especificación de tiempo. El modelo de proceso puede ser descrito usando una combinación de gráficos y notación textual. 4.2 Estructura Organizacional Esta parte describe la estructura de organización interna del proyecto. Herramientas gráficas tales como una matriz de diagramas podría ser usada para describir las líneas de autoridad, responsabilidad y comunicación 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 organización de origen, la organización del cliente, la organización subcontratada, o cualquier otra organización que interactua con el proyecto. 4.4 Responsabilidades del Proyecto En esta parte se identifica el estado natural de cada función 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 declaración del alcance y puede incluir objetivos y prioridades administrativas. 5.1 Objetivos y Prioridades Administrativas Especificar la filosofía, metas y prioridades para la administración de las actividades durante el proyecto. Tópicos específicos 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 adquisición, modificación 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 término de los proyectos sw. Esos procesos pueden incluir: la configuración de manejo, asegurar la calidad, verificación y validación del sw. 5.4 Gestión del Alcance Administrativo Se especifica el plan de manejo del alcance del proyecto, también puede incluir procedimientos para cambios en el alcance del SPMP, además de la probabilidad de cambios, incluyendo los factores que pudiesen resultar por el cambio del alcance del proyecto. El plan indicaría factores que causaron el cambio, los resultados de los cambios y los métodos 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, además de, especificar los documentos que sirven como entrada al proyecto. Se deben especificar las herramientas o metodología que serán usadas para administrar el itinerario. El plan indicaría factores que causaron el cambio, los resultados de los cambios y los métodos 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, además de especificar los documentos que sirven como entrada al presupuesto. Se deben especificar las herramientas o metodología que serán usadas para administrar el presupuesto. El plan indicaría factores que causaron el cambio, los resultados de los cambios y los métodos 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 culminación de esta. El plan puede especificar los métodos usados para estimar el material, servicios y requerimientos de recursos humanos. Se puede incluir el número y nivel de calificación del personal requerido para completar el proyecto, el número 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 estándares del proyecto y los métodos y recursos requeridos para implementar y asegurar el cumplimiento de esos estándares. 5.9 Planes de Manejo de Riesgos Se definen los planes de manejo de factores de riesgos asociados al proyecto. Esta parte describe los métodos que serían usados para identificar los factores de riesgo, como fueron evaluados y impacto potencial de los riesgos identificados.

5.10 Planes de Obtención de Recursos Esta parte incluiría una descripción de los procesos de obtención de recursos, incluyendo responsabilidades para todos los aspectos del proceso. El plan podría incluir los procesos de obtención tangible e intangible de recursos; procesos de obtención de: equipamiento, estimaciones de tiempo de computado, Hw. y Sw. y transportes. 5.11 Planes de Manejo Comunicacional Esta parte maneja la comunicación relativa del proyecto. Se definirían los mecanismos de reporte, formas de reporte, información anticipada, mecanismos de intervención, y otras herramientas y técnicas usadas para monitorear y controlar los objetivos del proyecto. 6 Procesos Técnicos Esta parte planea el manejo del alcance del producto, los métodos técnicos, herramientas y técnicas usadas para la entrega del producto y documentación del software. 6.1 Alcance del Producto Esta parte contempla los planes de manejo del alcance del producto. En este plan serían incluidos los métodos por los cuales el alcance del proyecto va a ser medido además de los requerimientos del producto, además se incluye los factores que pueden cambiar el alcance del producto. 6.2 Métodos, Herramientas y Técnicas Este parte describe el sistema de computación, metodologías de desarrollo, estructuras de equipos, lenguaje de programación, herramientas y técnicas a ser usadas para la especificación, diseño, construcción, test, integración, documentos, modificaciones y mantención del proyecto. 6.3 Documentación del Software Se describe los planes de documentación para el proyecto software. Los planes de documentación especificarían los requerimientos de documentación y la importancia, referencias, revisiones para la documentación del sw. El plan de documentación puede además contener un estilo de guía, convenciones de nombre y formatos de documentación. 7 Planificación 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 identificación puede ser basada sobre la numeración de proyectos y/o títulos 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 función de tiempo, los recursos totales estimados para completar la actividad. Números y tipo de personal, soporte de software y hardware y requerimientos de mantención 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 Incluiría detalles específicos del personal, detalles de los costos estimados, detalles de las estructuras de trabajo “breakdown” e información suplementaria para una adecuada comprensión del SPMP

Fuentes
1: Tipos de Software, http://tecnomaestros.awardspace.com/tipos_software.php, 2: Metodología y software para la construcción y seguimiento del Cuadro de Mando Integral en las TIC´s (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: Técnica de revisión y evaluación 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: Gestión de Configuración del Software, http://www.histaintl.com/soluciones/configuracion/configuracion.php,

Sign up to vote on this title
UsefulNot useful