Mejoramiento del Proceso de Software

Capacitación de Vanguardia para Desarrolladores

Mejoramiento del Proceso de Software

Febrero de 2000


Definición de Ingeniería

• Ingeniería es el uso de principios para encontrar diseños que puedan satisfacer múltiples objetivos que compiten entre sí, con recursos limitados y otras restricciones, bajo condiciones de incertidumbre.


Un modelo de Ingeniería

Control

Proceso

Mediciones Acción

Metas

Obligaciones

Necesidades

Recursos

Producto


Definición de Ingeniería de Software*

La Ingeniería de Software es (1) la aplicación de un enfoque sistemático, disciplinado y cuantificable del desarrollo, operación y mantenimiento del software, esto es, la aplicación de la ingeniería al software. (2) El estudio de los enfoques como en (1).

* IEEE Std 610.12


Problemas de la IS

• El software es intangible y no está limitado por las leyes de la física.

• La disciplina es relativamente nueva, comparada con otras ingenierías, y muchos conceptos importantes son inmaduros.

• No hay todavía un cuerpo de conocimientos universalmente aceptado.

• Aunque ya hay estándares, hay pocas presiones del mercado que impulsen su aceptación.


Estado legal de la IS en EUA

• La Ingeniería de Software no está entre las 36 ingenierías registradas en Estados Unidos.

• 48 estados de la unión americana tienen leyes prohibiendo que un individuo sin licencia se anuncie como ingeniero.

• Texas prohibió a sus universidades ofrecer grados de maestría en ingeniería de software.


Capas de la Ingeniería de Software

• Proceso. Define un marco de trabajo para un conjunto de áreas clave de proceso (ACP’s), que se debe establecer para la entrega efectiva de la tecnología de Ingeniería de Software.

• Métodos. Indican cómo construir técnicamente el software.

• Herramientas. Proporcionan un soporte automático o semiautomático para el proceso y para los métodos.


Definiciones de Proceso

• Una secuencia de pasos realizados con un propósito determinado (IEEE Std. 610).

• El conjunto de actividades, métodos y prácticas usadas en la producción y evolución del software (SEI CMM).


El Proceso


Los aspectos de un proceso


Los aspectos de un proceso

• Considere una orquesta tratando de tocar una sinfonía:– Sin maestro (el proceso no es administrado).– Sin notas musicales (el proceso no está

documentado).– Sin práctica (no hay entrenamiento para el

proceso).– Cada quien tocando sus notas (el proceso no es

reforzado).


Del producto al proceso

• Muchas organizaciones están centradas en el producto. En esos ambientes, la gente pone más énfasis en cosas concretas. Se espera que la salida de cualquier actividad tome una forma tangible. Se puede confundir un documento del proceso como el proceso. En esas organizaciones hay resistencia a las actividades que no contribuyen directamente a objetivos de corto plazo, y muchas veces se posponen hasta que no haya “actividades críticas”.


Madurez de Procesos


El Proceso

• Marco de trabajo del proceso común– Actividades del marco de trabajo.

• Conjunto de tareas.– Tareas. – Hitos, entregas.– Puntos SQA.

– Actividades de protección


El Proceso

• Para caracterizar un proceso de software, se establece 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, independientemente de su tamaño.

• Las actividades de protección, como garantía de calidad del software y medición, son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.


ROI


ROI

• Un estudio reportó los siguientes beneficios:– $490-2004 USD de ahorro por Ingeniero de

Software al año.– 9-67% de incremento anual de productividad.– 15-23% de reducción del tiempo de desarrollo.– 10-94% de reducción de defectos.– ROI de 4:1 a 8.8:1.


Calidad: viendo el bosque

• La satisfacción del cliente se ha convertido en la fuerza que hace que muchas empresas sobrevivan en un mundo de competitividad creciente.

• En las empresas de desarrollo de software ha ido cobrando sentido la percepción de que la ingeniería de software es el camino para construir sistemas de alta calidad.



• La administración de la calidad involucra los siguientes elementos: Definición de objetivos, Normas, Un sistema.

• Definición de objetivos. Las demandas de una norma empiezan con un compromiso escrito y una organización bien definida, para proceder con detalladas instrucciones procesales para cada paso, desde compras hasta la terminación y entrega del producto.



• Normas. Puede haber varias normas dentro del mismo sistema: normas para materiales y componentes comprados, la habilidad de los proveedores para entregar según requerimientos, conformidad con los requerimientos del producto y otros más. Todo ello debe estipularse en procedimientos e instalarse un sistema para su verificación.



• Un sistema. Definiciones y procedimientos por sí mismos no son suficientes. Uno necesita de un sistema de medición para compras, recepción de materiales, comportamiento del proceso inspección final y entregas. También se necesitan pruebas y técnicas de medición y un sistema para probar y calibrar el equipo de pruebas en sí.



• Intentos de normalizar la función de calidad en el desarrollo de software– Métricas– Puntos de Función. Iso 14143.– ISO 9000-3– SQA– CMM– ISO 15504


Mediciones

Cuando pueda medir lo que está diciendo y expresarlo con números, ya conoce algo sobre ello; cuando no pueda medir, cuando no pueda expresar lo que dice con números, su conocimiento es precario y deficiente: puede ser el comienzo del conocimiento, pero en tus pensamientos apenas estás avanzando hacia el escenario de la ciencia.

Lord Kelvin


Mediciones

• La medición se puede aplicar al proceso del software con el intento de mejorarlo sobre una base continua.

• El Ingeniero del Software puede utilizar la medición para ayudar a evaluar la calidad de productos técnicos y para ayudar en la toma de decisiones tácticas a medida que el proyecto evoluciona.

• La clave para manejar los riesgos es la medición.


Mediciones

• Se sabe que negocios exitosos tienen mediciones exitosas.

• Una medida proporciona una indicación cuantitativa de extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos de un proceso o producto.

• Las mediciones pueden ser directas o indirectas.


Mediciones

• Una métrica es una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. Las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo.


Mediciones

• Un indicador es una métrica o combinación de métricas que proporcionan una visión profunda que permite al gestor del proyecto o a los ingenieros del software ajustar el proceso, el proyecto o el producto para que las cosas salgan mejor.


Mediciones

• Los indicadores de proyecto permiten al gestor de proyectos del software– Evaluar el estado del proyecto en curso.– Seguir la pista de los riesgos potenciales.– Detectar las áreas de problemas antes de que se

conviertan en críticas.– Ajustar el flujo y las áreas del trabajo.– Evaluar la habilidad del equipo del proyecto en

controlar la calidad de los productos de trabajo de la ingeniería de software.


Mediciones

Prácticas de Software

Datos Cualitativos: Proceso, Recursos, Automatización y Negocio

Datos cuantitativos: Duración, Esfuerzo, Tamaño y Defectos

Capacidad de Proceso

Niveles de desempeño

Prácticas de software

mejoradas


Métricas

• Mediciones– Errores detectados antes de la entrega del software por

el desarrollador.– Errores detectados en la revisión técnica formal.– Defectos detectados e informados por los usuarios

finales.– Productos de trabajo entregados.– Esfuerzo humano.– Tiempo consumido.– Ajuste con la planificación.


Métricas

– Líneas de código producidas.– Puntos de función producidos.– Velocidad de ejecución.– Funcionalidad.– Eficiencia.– Complejidad.– Facilidad de mantenimiento.– Fiabilidad.


Métricas

• Métricas– Indices de defectos (por individuo).– Indices de defectos (por módulo).– Indices de defectos (por proyecto).– Indice de errores encontrados durante el desarrollo.– Indice de errores encontrados durante revisiones técnicas

formales.– Líneas de código o puntos de función por módulo y

función.


Métricas

– Páginas de documentación por KLDC o PF.– Porcentaje del tiempo ocupado en revisión.– Errores por KLDC o PF.– Defectos por KLDC o PF.– Costo por KLDC o PF.– Errores/persona-mes.– LDC o PF por persona-mes.– Costo por página de documentación.


Métricas

• Etiqueta de métricas del software– Utilice el sentido común y una sensibilidad organizativa

al interpretar datos de métricas.– Proporcione una retroalimentación regular a particulares

y equipos que hayan trabajado en la recopilación de medidas y métricas.

– No utilice métricas para evaluar a particulares.– Trabaje con profesionales y equipos para establecer

objetivos claros y métricas que se vayan a utilizar para alcanzarlos.


Métricas

– No utilice nunca métricas que amenacen a particulares o equipos.

– Los datos de métricas que indican un área de problemas no se deberían considerar “negativos”. Estos datos son meramente un indicador de mejora del proceso. Se deben manejar como “áreas de oportunidad”.

– No se obsesione con una sola métrica y excluya otras métricas importantes.


Métricas

• Criterios para seleccionar métricas:– Debe existir una necesidad de ciertos datos.– Los datos colectados soportan los objetivos del

programa de mediciones de la organización.– El costo de colectar los datos se justifica por su

utilidad.– Los datos se deben colectar en el punto adecuado

del ciclo de vida.


Métricas

– Los datos deben ser seguros y correctos.– Los datos deben recogerse oportunamente.– Se debe proteger datos confidenciales.


Métricas

• Hay dos tendencias en métricas: Líneas de código (métricas orientadas al tamaño) y puntos de función (métricas orientadas a la función).

• Ventajas de LDC:– Se puede calcular fácilmente.– Hay varios modelos que toman LDC como

entrada.– Hay un amplio conjunto de datos y literatura.


Métricas

• Desventajas de LDC:– Son dependientes del lenguaje de programación.– Perjudican a los programas más cortos, pero bien

diseñados.– Su estimación requiere un nivel de detalle difícil

de alcanzar.


Métricas

• Ventajas de Puntos de función:– Se han convertido en el estándar de medición

(ISO 14143).– Hay una base estadística que comprueba el

modelo.– Hay ampliaciones al modelo.– Son independientes del lenguaje.– Se desprenden directamente del análisis y diseño.


Métricas

• Desventajas de Puntos de Función:– En un inicio, es necesaria una mayor preparación

en puntos de función que en líneas de código.– Es una medida indirecta, en contraposición a las

líneas de código.– Puede variar fuertemente el número de puntos de

función encontrados si no se sigue el estándar, o si se descuida la capacitación.


Métricas y líneas base

• Si nosotros medimos el tamaño de nuestro software en puntos de función, podemos expresar un resultado de productividad como el número de puntos de función producidos por persona/mes.

• Si nosotros medimos una variedad de nuestros sistemas de software o de nuestros esfuerzos en proyectos de software, pronto estableceremos lo que se llama comúnmente línea base.



• Esta línea base nos dará varios datos de puntos de niveles de desempeño basados en diversos grados de productividad y desempeños de calidad.

• No todos los esfuerzos dentro de una organización tienen la misma tasa de desempeño. Los resultados de dibujar un conjunto de proyectos resultan en el despliegue de varios niveles de productividad, o tasas de desarrollo.



• Con estos gráficos, debemos reconocer y comprender los varios grados de desempeño de procesos y finalmente entender las causas para las variaciones en desempeño. Aquí es donde los datos cualitativos se vuelven críticos. Los datos cualitativos describen como construimos y mantenemos nuestros sistemas.



• Típicamente se construyen dos líneas base:– La línea base de sistemas, que es simplemente

una colección de tamaños de sistemas.– La línea base de desarrollo es típicamente el

resultado de los desarrollos recientemente terminados. Se grafican el tamaño del software y el esfuerzo para producirlos, y se calculan tasas de desempeño.



• Con las líneas base de la empresa en la mano, lo que sigue es su comparación con el resto de la industria. Aquí es importante tener cuidado:

• ¿Para qué industria son representativos los datos, y cuál es la mezcla de los datos?– ¿Qué período de tiempo está representado por los

datos?– ¿Qué tan válidos son los datos?



• Con los puntos de función podemos obtener otras cuatro métricas base.– Productividad. Puntos de Función / Esfuerzo. Se

mide en PF/PM (PM = Persona/Mes).– Tiempo para embarque. Puntos de Función /

Duración. Se mide en PF/M (M = Mes).– Calidad. Defectos / Puntos de Función. – Negocio. Costo / Puntos de Función.


ISO 9000

• ISO 9000 se publicó en 1978.• Hay tres tipos de Normas: del producto, de

calibración y medición, y de administración de calidad.

• Las normas del producto prescriben requerimientos para los componentes que forman el producto. También estipulan especificaciones sobre cómo deben juntarse los componentes (el proceso) para formar el producto.


ISO 9000

• Para un producto dado, sus especificaciones deben estar en conformidad con todas las normas para productos en las operaciones de fabricación, desde sus componentes adquiridos hasta el artículo terminado, usando normas publicadas y sistemas de medida, como un requisito fundamental de un sistema gerencial de calidad ISO 9000.


ISO 9000

• Las calibraciones y mediciones dentro del proceso de fabricación son parte integral de ISO 9000.

• ISO 9000 es una norma para sistemas gerenciales de calidad. Tales sistemas deberán incluir tanto las normas de productos individuales como calibración y mediciones, así como la creación de un sistema global para asegurar la continuidad de la operación del proceso como un todo, desde la compra de materiales hasta la entrega al cliente.


ISO 9000

• ISO 9000 ha sido adoptada como la norma armonizada para el manejo de la calidad.

• ISO 9000 e ISO 14000 son normas voluntarias, pero pueden ser obligatorias si los clientes lo exigen.

• No es concebible que alguien pueda lograr la ISO 9000 sin por lo menos elaborar el artículo en el proceso apropiado, y aplicar las normas de salud y seguridad que se requieren.


ISO 9000

• Para la parte de salud y seguridad de software es necesario cumplir con la ISO 9241, la norma ergonómica del software.

• Desde Diciembre de 1992, las exportaciones hacia el Mercado Común Europeo están sujetas por ley a cumplir con ISO 9241.

• La ISO 9241 es una norma de 20 partes, de la 10 en adelante tenemos cientos de páginas que hablan de cómo escribir software.


ISO 9000

• Una de las características sobresalientes de la ISO 9000 para la gerencia es que automáticamente provee, por un lado, controles para asegurar la calidad de la producción y las entregas y, por el otro, reduce desperdicios, tiempos muertos y deficiencias laborales incrementando, por ende, la productividad.


ISO 9000

• ISO 9000 es un conjunto de 31 normas para un sistema gerencial de calidad.

• La principal norma que atañe al software es la ISO 9000-3:1991, cuya primera edición fue publicada en 1991, y que denomina: Gestión de calidad y normas de aseguramiento de calidad. Parte 3: Guías generales para la aplicación del ISO 9000 al desarrollo, abastecimiento y mantenimiento del software.


ISO 9000

• En la introducción de 9000-3 se indica que el proceso de desarrollo de software es muy diferente del de la mayoría de los demás tipos de productos industriales. En el desarrollo del software algunas actividades están relacionadas a fases particulares del proceso de desarrollo, mientras que otras pueden aplicarse a través de todo el proceso.


ISO 9000

• El hecho de que una norma ISO esté surgiendo no libera a las compañías de la responsabilidad de adoptarla, ya que su misma existencia la hace un código de práctica, obligando a los fabricantes a adoptarla si van a cumplir con la confiabilidad del producto. (Rothery, Brian. ISO 9000, p. 159).


ISO 9000

• Cuando existe una norma de diseño o código de práctica, debe ser utilizada dicha norma o código. En todos los casos en los que existan normas de componentes, proceso o seguridad, éstas deben ser un requerimiento mínimo. (Rothery, Brian. ISO 9000, p. 215).


TickIt

• La BSI es la asociación británica miembro de ISO. La BSI elaboró una guía llamada TickIt para aplicar la norma ISO 9001 e ISO 9000-3 en el software. Esta guía ya va en la versión 4.0, y exige el cumplimiento de la norma ISO/IEC 12207 (procesos de ciclo de vida del software), para que una empresa de software pueda tener el certificado ISO 9000. Muchas de las empresas más grandes de software están certificadas en este esquema.


TickIt

• La BSI es el mayor cuerpo de certificación independiente del mundo (y tal vez la agencia con más prestigio).

• BSI ha dado el servicio de certificación a empresas de software desde 1979.

• La guía de TickIt incluye listas actualizadas de los estándares, bases de datos en CD-ROM y listas de literatura recomendada, así como una guía de sitios en el Web.


TickIt

• TickIt tiene 11 cuerpos de certificación, y ha entregado certificados ISO 9000 a 1400 organizaciones de software de todo el mundo. Estos certificados incluyen los logotipos tanto de la BSI como de TickIt. Publica una revista TickIt International, conteniendo las últimas actualizaciones en el esquema TickIt.

• TickIt es el camino normal para que una empresa de software se certifique en ISO 9000.


Estándares ISO

• ISO/IEC JTC1/SC7 es el responsable de los estándares internacionales sobre ingeniería de software. Fue formado en 1987 de tres comités técnicos existentes, y heredó sus programas de trabajo.

• Los objetivos de SC7 son la estandarización de procesos, productos y tecnologías para la ingeniería de software y productos o sistemas conteniendo software.


Estándares ISO

• ISO/IEC 2382-1: 1993. Vocabulario. Parte 1: Términos fundamentales.

• ISO/IEC 2382-7: 1989. Vocabulario. Parte 7: Programación de computadoras.

• ISO/IEC 2382-20: 1990. Vocabulario. Parte 20: Desarrollo de sistemas.

• ISO 5806:1984. Procesamiento de información. Especificación de tablas de decisión simples.


Estándares ISO

• ISO 5807:1985. Procesamiento de información. Símbolos de documentación y convenciones para datos, programas y diagramas de flujo de sistemas, diagramas de redes de programas y diagramas de recursos de sistemas.

• ISO 6592:1985. Procesamiento de información. Guías para la documentación de sistemas de aplicación basados en computadoras (DIS WG2).

• ISO 6593:1985. Procesamiento de información. Flujo de programas para el procesamiento de archivos secuenciales por medio de grupos de registros.


Estándares ISO

• ISO/IEC 8631:1989. Construcción de programas y convenciones para su representación.

• ISO 8790:1987. Sistemas de procesamiento de información. • ISO/IEC 9126:1991. (CD 14598). Evaluación de productos

de software (WG6).• ISO 9127:1988. Sistemas de procesamiento de información.

Documentación de usuario e información de cubierta para paquetes de software para el consumidor.


Estándares ISO

• ISO/IEC TR 9294:1990. Guías para la administración de la documentación del software.

• ISO/IEC 11411:1995. Representación para la comunicación humana de software de transición de estados.

• ISO/IEC 12119:1994. Paquetes de software. Requerimientos de calidad y prueba.

• DTR 12182. Categorización del software. (WG9).• ISO/IEC 12207:1995. Procesos para el ciclo de vida del

software.


Estándares ISO

• CD 12220. Proceso del ciclo de vida del software. Administración de la configuración para el software. (WG8).

• ISO/IEC TR 12382:1992. Indice permutado del vocabulario de tecnología de información.

• ISO/IEC 14102:1995. Guía para la evaluación y selección de herramientas CASE.

• DIS 14143. Medición con puntos de función. (WG12).• DTR 14399. Mapa de estándares relevantes de ingeniería de

software. (WG9).


Estándares ISO

• DTR 14471. Adopción de herramientas CASE. (WG4).• ISO/IEC 14568:1997. Lenguaje de diagramas de

intercambio para diagramas con estructura de árboles.• CD 14756. Medición y tasa de desempeño de software de

sistemas basados en computadora. (WG6).• DTR 14759. Modelo de ciclo de vida de software para

simular y prototipar. (WG7).• WD 14764. Mantenimiento de software. (WG7).• DIS 15026. Niveles de integridad de sistemas y software

(WG9).


Estándares ISO

• DTR 15271. Guía para ISO/IEC 12207 (Procesos de ciclo de vida del software).

• WD 15288. Procesos de ciclo de vida de sistemas (WG7).• WD 15289. Guías para el contenido de productos de

información de procesos para el ciclo de vida de software. (WG2).

• 15474-15479. Definición de datos de ingeniería de software y su intercambio. (WG11).

• ISO/IEC 15504:1998. Aseguramiento de procesos de software.


ISO 12207

• ISO/IEC 12207 Procesos de ciclo de vida del software, da un marco común para desarrollar y administrar software.

• Hay una proliferación de estándares, procedimientos, métodos, herramientas y ambientes para desarrollar software.

• Esta proliferación ha creado dificultades, especialmente en la administración del software y su ingeniería, especialmente al integrar productos y servicios.


ISO 12207

• La disciplina del software necesita migrar de esta proliferación a un marco común que pueda ser usado para “hablar el mismo lenguaje” al crear y administrar software. El 12207 provee este marco común.

• El marco cubre el ciclo de vida del software desde su conceptualización hasta su retiro, y consiste de procesos para adquirir y suministrar productos y servicios de software. Adicionalmente, el marco permite controlar y mejorar estos procesos.


ISO 12207

• ISO 12207 puede ser usado para:– Adquirir, suministrar, desarrollar, operar y mantener

software.– Soportar las funciones arriba mencionadas mediante el

aseguramiento de calidad, administración de la configuración, revisiones conjuntas, auditorías, verificación, validación, resolución de problemas y documentación.

– Administrar y mejorar tanto al personal como a los procesos de la organización.


ISO 12207

– Establecer administración de software y ambientes de ingeniería basados en los procesos de ciclo de vida que se adapten para servir a las necesidades del negocio.

– Ayudar a un mejor entendimiento entre clientes y proveedores y entre las partes involucradas en el ciclo de vida de un producto de software.

– Facilitar la comercialización global del software.


ISO 12207

• ISO 12207 contiene procesos, actividades y tareas a ser aplicadas durante la adquisición de un sistema que contiene software, un producto de software stand-alone, un servicio de software y durante el suministro, desarrollo, operación y mantenimiento de productos de software. Software incluye la parte de software del firmware.


ISO 12207

• Este estándar internacional también provee un proceso que puede ser empleado para definir, controlar y mejorar los procesos de ciclo de vida del software.

• Este estándar internacional es escrito para los consumidores de sistemas y productos de software, y para los suministradores, desarrolladores, operadores, mantenedores, administradores, responsables de calidad de software y usuarios de productos de software.


ISO 12207

• Este estándar internacional describe la arquitectura de los procesos de ciclo de vida del software, pero no especifica los detalles de cómo implementar o realizar las actividades y tares incluidas en los procesos.

• El software no prescribe un modelo particular de ciclo de vida o un método de desarrollo de software.


ISO 12207

• Este estándar internacional agrupa las actividades que deben ser realizadas durante el ciclo de vida del software en cinco procesos primarios, ocho procesos de soporte, y cuatro procesos organizacionales. Cada proceso del ciclo de vida está dividido en un conjunto de actividades; cada actividad está dividida en un conjunto de tareas. Subcláusulas a.b denota un proceso, a.b.c. una actividad, y a.b.c.d. una tarea.


ISO 12207

• Proceso de adquisición. Define las actividades del cliente, la organización que adquiere un sistema, producto o servicio de software. Sus actividades:– Iniciación.– Preparación de la propuesta.– Preparación del contrato y actualización.– Monitoreo del proveedor.– Aceptación y terminación.


ISO 12207

• Algunas tareas: Analizar si se debe comprar o desarrollar (interna o externamente); la preparación de la propuesta debe contener: los requerimientos del sistema, el alcance del proyecto, instrucciones para postores, lista de los productos de software, términos y condiciones, control de subcontratos y restricciones técnicas; se deben marcar los hitos; el contrato debe especificar el copyright, uso, garantía y derechos de licencias; el cliente debe hacer uso de los procesos de revisión conjunta y auditoría para monitorear al proveedor, se puede auxiliar también de los procesos de verificación y validación; una vez aceptado, el cliente asume la administración de la configuración.


ISO 12207

• Proceso del proveedor. Define las actividades del proveedor, la organización que suministra el sistema, producto o servicio de software al cliente. – Iniciación.– Preparación de la respuesta.– Contrato.– Planeación.– Ejecución y control.– Revisión y evaluación.– Entrega y terminación.


ISO 12207

• Algunas tareas son: El proveedor debe decidir si participa o no en el proyecto; debe definir y preparar una propuesta en respuesta a la petición de propuesta; en el contrato debe poder realizar modificaciones como parte del mecanismo de control de cambios; en la planeación, el proveedor debe establecer requerimientos para los planes de administración y seguimiento del proyecto, así como para asegurar la calidad de los productos o servicios de software; una vez que se tienen los requerimientos de planeación, debe revisar la posibilidad de subcontratar o comprar parte del proyecto, para disminuir los riesgos.


ISO 12207

• El proveedor debe revisar su estructura organizacional, su ambiente de ingeniería, el aseguramiento de calidad, la incorporación del cliente y del usuario, la administración de riesgos, la política de seguridad, la capacitación; debe coordinar las actividades de revisión, interfaces y comunicación con la organización del cliente; debe conducir o soportar las reuniones informales, la revisión de aceptación, prueba de aceptación, las revisiones conjuntas y las auditorías del cliente conforme esté especificado en el contrato y en el plan del proyecto; debe dar asistencia al cliente para soportar la entrega del producto o servicio de software, conforme esté especificado.


ISO 12207

• Proceso del desarrollo. Define las actividades del desarrollador, la organización que define y desarrolla el producto de software. Actividades:– Implementación del proceso.– Análisis de los requerimientos del sistema.– Diseño de la arquitectura del sistema.– Análisis de los requerimientos del software.– Diseño de la arquitectura del software.– Diseño detallado del sistema.– Codificación y prueba.


ISO 12207

– Integración del software.– Prueba de aptitud del software.– Integración del sistema.– Prueba de aptitud del sistema.– Instalación del software.– Soporte de aceptación del software.

• Si no está estipulado en el contrato, el desarrollador debe seleccionar un modelo de ciclo de vida apropiado al alcance, magnitud y complejidad del proyecto.


ISO 12207

• El desarrollador deberá seleccionar, ajustar y usar aquellos estándares, herramientas, métodos y lenguajes (si no están estipulados en el contrato), que estén documentados, sean apropiados y establecidos por la organización; deberá desarrollar planes para conducir las actividades del proceso de desarrollo; deberá desarrollar y documentar un diseño de alto nivel para la base de datos; deberá realizar un diseño detallado para cada componente de software; deberá actualizar la documentación del usuario conforme sea necesario; deberá desarrollar y documentar cada unidad de software y cada tabla, y probar cada unidad de software.


ISO 12207

• El desarrollador deberá evaluar el diseño, código, pruebas, resultado de las pruebas y documentación del usuario considerando la cobertura de la prueba, la conformidad a resultados previstos, la facilidad de la integración del sistema y su prueba y la facilidad de operación y mantenimiento; deberá integrar el software con el hardware y con otros sistemas; deberá desarrollar un plan para instalar el producto de software en el ambiente objetivo que haya sido designado en el contrato.


ISO 12207

• Proceso de operación. Define las actividades del operador, la organización que da el servicio de operar un sistema de cómputo en su ambiente de producción para sus usuarios. Sus actividades:– Proceso de implementación.– Prueba operacional.– Operación del sistema.– Soporte al usuario.


ISO 12207

• Algunas de las tareas son: El operador deberá establecer procedimientos para recibir, grabar, problemas de ajuste, y proveer retroalimentación; para cada liberación del producto de software, el operador debe realizar una prueba operacional y al satisfacer los criterios específicos, liberar el producto de software para su operación; el operador deberá dar asistencia y consultoría a los usuarios conforme sea necesario.


ISO 12207

• Proceso de mantenimiento. Define las actividades del mantenedor, la organización que provee el servicio de mantener el producto de software; esto es, administrar las modificaciones al producto de software en producción. Este proceso incluye la migración y el retiro del producto de software.– Proceso de implementación.– Análisis del problema y de la modificación.– Implementación de la modificación.– Revisión y aceptación del mantenimiento.


ISO 12207

– Migración.– Retiro del software.

• El mantenedor deberá analizar el reporte de problema o la petición de modificación para ver su impacto en la organización, el sistema y los sistemas con los que tiene interfaces, determinando su tipo (correctivo, mejora, preventivo o de adaptación a un nuevo ambiente), alcance (tamaño de la modificación, costo y tiempo) y que tan crítico es; deberá reproducir o verificar el problema; deberá analizar que documentación, unidades de software y versiones serán necesario modificar.


ISO 12207

• El mantenedor deberá conducir revisiones para determinar la integridad del sistema modificado; si un sistema o producto de software (incluyendo datos) es migrado a un nuevo ambiente, se deberá asegurar que cualquier producto de software producido o modificado durante la migración está en conformidad con este estándar; podrán ser conducidas operaciones en paralelo de los ambientes nuevo y viejo; para el retiro de software se realiza un plan que establezca: el cese total o parcial del soporte después de un período de tiempo, la responsabilidad para cualquier soporte futuro, la disponibilidad de los respaldos de datos; se deberá notificar a los usuarios de los planes de retiro.


ISO 12207

• Proceso de documentación. Define las actividades para guardar la información producida por los procesos del ciclo de vida. Tiene las actividades:– Implementación del proceso.– Diseño y desarrollo.– Producción.– Mantenimiento.


ISO 12207

• Se hará un plan, identificando los documentos que se producirán durante el ciclo de vida del producto de software, para cada documento se pondrá su título, propósito, audiencia objetivo, procedimientos y responsabilidades para la entrada, desarrollo, revisión, modificación, aprobación, producción, almacenamiento, distribución, mantenimiento y administración de la configuración; se hará un estándar para unificar el formato de los documentos.


ISO 12207

• Proceso de administración de la configuración. Define las actividades de administración de la configuración. Consta de éstas actividades:– Implementación del proceso.– Identificación de la configuración.– Control de la configuración.– Contabilidad del estado de la configuración.– Evaluación de la configuración.– Administración de la liberación y entrega.


ISO 12207

• Se hará un plan para la administración de la configuración; se establecerá un esquema para identificar los elementos de configuración de software y sus versiones a controlar; se identificarán y registrarán las peticiones de cambios, análisis y evaluación de los cambios, aprobación o rechazo de la petición; e implementación, verificación y liberación del elemento de software modificado; se administrarán registros y reportes de estado que muestren el estado y la historia de elementos controlados incluyendo las líneas base del software; se controlará formalmente la liberación y entrega de los productos de software y su documentación.


ISO 12207

• Proceso de aseguramiento de calidad. Define las actividades para asegurar de forma objetiva que los productos y procesos están en conformidad con los requerimientos específicos y se adhieren a los planes establecidos. Las revisiones conjuntas, auditorías, verificaciones y validaciones pueden ser usadas como técnicas del aseguramiento de calidad. Consta de las siguientes actividades:– Implementación del proceso.– Aseguramiento del producto.


ISO 12207

– Aseguramiento del proceso.– Aseguramiento de los sistemas de calidad.

• Se desarrollará un plan para conducir las actividades de aseguramiento de la calidad de los procesos y tareas. Incluirá: Estándares de calidad, metodologías, procedimientos y herramientas para realizar las actividades de aseguramiento de calidad, procedimientos para revisión de contratos, procedimientos para la identificación, colecta, llenado, mantenimiento y disposición de registros de calidad.


ISO 12207

• Los registros de las actividades de aseguramiento de calidad estarán disponibles al cliente, conforme al contrato; para la entrega de los productos de software, se asegurará que satisfacen totalmente los requerimientos contractuales y son aceptables al cliente; se asegurará que las prácticas internas de Ingeniería de Software, los ambiente de desarrollo y prueba, y las librerías cumplan con el contrato; se asegurará que el grupo de trabajo tengan las habilidades y el conocimiento necesarios para satisfacer los requerimientos del proyecto y hayan recibido la capacitación necesaria; se asegurará conformidad con ISO 9001 si es especificado en el contrato.


ISO 12207

• Proceso de verificación. Define las actividades (para el cliente, el proveedor o una parte independiente), para verificar los productos y servicios de software en distinta profundidad dependiendo del proyecto de software. Consiste de las siguientes actividades:– Implementación del proceso.– Verificación.


ISO 12207

• Se debe determinar si el proyecto garantiza un esfuerzo de verificación y el grado de independencia de la organización de ese esfuerzo; se debe determinar que actividades del ciclo de vida y que productos de software deben ser verificados, basándose en el alcance, magnitud, complejidad y su aspecto crítico; los problemas y no conformidades encontrados en la verificación entran en el proceso de resolución de problemas; se realiza verificación del contrato, del proceso, de los requerimientos, del diseño, del código, de la integración y de la documentación.


ISO 12207

• Proceso de validación. Define las actividades (para el cliente, el proveedor, o una parte independiente) para validar los productos de software o el proyecto de software. Actividades:– Implementación del proceso.– Validación.

• Se hace una determinación para ver si el proyecto garantiza el esfuerzo de validación y el grado de independencia de la organización de tal esfuerzo.


ISO 12207

• Se hace un plan de validación. Este incluye: los elementos a ser validados, las tareas de validación a realizar, los recursos, responsabilidades y tiempos para la validación y los procedimientos para propagar los reportes de validación al cliente y otras partes; se prepara un juego de pruebas; se prueba con carga de trabajo, en la frontera, y con entradas aisladas; se prueba la habilidad del producto de trabajar solo y minimizar el efecto de los errores, esto es, que tanto se degrada después de una falla, necesidad de asistencia del operador; se prueba que usuarios representativos puedan realizar sus tareas usando el producto de software.


ISO 12207

• Proceso de revisión conjunta. Define las actividades para evaluar el estado y productos de una actividad. Este proceso debe ser entre dos partes, donde una parte (la parte revisora) revisa a la otra parta (la parte revisada). Sus actividades:– Implementación del proceso.– Revisiones de la administración del proyecto.– Revisiones técnicas.


ISO 12207

• Las revisiones conjuntas se hacen en ciertos hitos especificados en el plan del proyecto; las partes deben acordar su agenda, los productos de software a ser revisados, alcance y procedimientos; los resultados de la revisión deben ser documentados y distribuidos; el estado del proyecto debe ser evaluado contra el plan, viendo el progreso, manteniendo el control del proyecto, cambiando la dirección del proyecto y evaluando los riesgos; las revisiones técnicas deben proporcionar evidencia de que los productos de software están completos, cumplen con los estándares y especificaciones, se adhieren a la planeación y están listos para la siguiente etapa.


ISO 12207

• Proceso de auditoría. Define las actividades para determinar cumplimiento con los requerimientos, planes y contrato. Este proceso es entre dos partes, donde una parte (la parte auditora) audita los productos de software y las actividades de la otra parte (la parte auditada). Sus actividades son:– Implementación del proceso.– Auditoría.


ISO 12207

• Las auditorías se hacen en los hitos predeterminados en el plan del proyecto; los auditores no deben tener ninguna responsabilidad directa con los productos de software y las actividades que auditan.

• Las auditorías persiguen: que los productos de software reflejen la documentación del diseño, que la revisión y los requerimientos de prueba sean adecuados para la aceptación del producto, que los juegos de datos cumplan con la especificación, que los reportes de prueba sean corregidos y las discrepancias resueltas, que las actividades se conduzcan conforme el plan y que los costos se adhieran a lo planeado.


ISO 12207

• Proceso de resolución de problemas. Define un proceso para analizar y remover los problemas (incluyendo no conformidades), de cualquier fuente o recurso, que hayan sido descubiertos durante el desarrollo, operación, mantenimiento u otros procesos. Sus actividades son:– Implementación del proceso.– Resolución de problemas.


ISO 12207

• El proceso debe asegurar que todos los problemas detectados sean rápidamente reportados y entren en este proceso; el proceso debe contener un esquema para categorizar y priorizar los problemas; un análisis debe detectar tendencias en los problemas; la resolución de problemas debe ser evaluada: cuando se resolvió, cuando se revierte una tendencia negativa, o cuando se introdujeron nuevos problemas; cuando se detecte un problema, se elabora un reporte que describe su detección, para luego tras analizarlo y resolverlo, ver su causa, y en que tendencia encaja.


ISO 12207

• Proceso de administración. Define las actividades básicas de la administración, incluyendo la administración del proyecto, relativo a la ejecución de los procesos del ciclo de vida.– Iniciación y definición del alcance.– Planeación.– Ejecución y control.– Revisión y evaluación.– Cierre.


ISO 12207

• El administrador establece la factibilidad del proceso checando que los recursos (personal, materiales, tecnología y ambiente) requeridos estén disponibles y que los períodos de tiempo sean alcanzables. En la planeación el administrador realiza la programación de actividades, estimación del esfuerzo, los recursos adecuados, la distribución de tareas, la asignación de responsabilidades, la cuantificación de los riesgos, las mediciones de control de calidad, los costos, y proveer ambiente e infraestructura; cuando se cierra el proyecto, se revisan los resultados y registros de los productos de software, actividades y tareas. Estos registros se archivan.


ISO 12207

• Proceso de infraestructura. Define las actividades básicas para establecer la infraestructura subyacente a los procesos del ciclo de vida. Sus actividades son:– Implementación del proceso.– Establecimiento de la infraestructura.– Mantenimiento de esta infraestructura.


ISO 12207

• La infraestructura deber ser definida y documentada para cumplir con los requerimientos del proceso; la configuración de la infraestructura debe ser planeada y documentada: funcionalidad, desempeño, seguridad, disponibilidad, requerimientos de espacio, equipamiento, costos y limitaciones de tiempo; la infraestructura debe ser instalada a tiempo para la ejecución de los procesos relevantes; la infraestructura debe ser mantenida, monitoreada y modificada para asegurar que continua satisfaciendo los requerimientos de los procesos.


ISO 12207

• Proceso de mejora. Define las actividades básicas que una organización (esto es, el cliente, proveedor, desarrollador, operador, mantenedor, o el administrador de otro proceso) realiza para establecer, medir, controlar y mejorar sus procesos del ciclo de vida. Sus actividades son:– Establecimiento del proceso.– Medición del proceso.– Mejora del proceso.


ISO 12207

• Se debe desarrollar, documentar y aplicar un proceso de medición; los registros deben ser guardados y mantenidos; la organización debe efectuar mejorar a sus procesos como resultado de la medición y revisión de los procesos actuales; se colectan y analizan datos históricos, técnicos y de evaluación para lograr comprensión de las fortalezas y debilidades de los procesos empleados; se colectan, mantienen y usan datos del costo de calidad. Estos datos son usados para establecer el costo tanto de la prevención como de la resolución de problemas y no conformidades.


ISO 12207

• Proceso de capacitación. Define las actividades para dar una capacitación adecuada al personal. Sus actividades son:– Implementación del proceso.– Desarrollo del material de la capacitación.– Implementación del plan de capacitación.


ISO 12207

• Se revisan los requerimientos para hacer previsiones a tiempo de las habilidades requeridas por la administración y la dirección técnica. Se determinan los tipos y niveles de entrenamiento requerido. Se hace un plan de capacitación; se hacen manuales de capacitación; se implementa el plan y se da capacitación al personal, se guardan los registros de la capacitación; se debe asegurar que la mezcla correcta de categorías del personal apropiadamente entrenado está disponible para las actividades y tareas planeadas en un tiempo adecuado.


CMM

• Una técnica de aseguramiento del proceso de desarrollo de software es la metodología del SEI (Software Engineering Institute) desarrollada por Watts Humphrey. Hecha por encargo del Departamento de Defensa de EUA para sus proveedores, usa un modelo de medida de la madurez, llamado el CMM (Capability Maturity Model).


CMM

• CMM es una aplicación de los conceptos de administración de procesos de TQM (Total Quality Managenment) al software.

• La fuente original de estos conceptos es Quality is Free, de Philip Crosby, que describe como evolucionan cinco etapas al adoptar prácticas de calidad. El marco de madurez de software fue hecho por Ron Radice y sus colegas, bajo la dirección de Humphrey, en la IBM, en 1985.


CMM

• El SEI ha desarrollado un modelo completo de funciones de ingeniería de software que deberían estar presentes conforme las organizaciones alcanzan diferentes niveles de madurez del proceso. Para esto, se utiliza un cuestionario de evaluación y un esquema de cinco grados.

• El CMM proporciona una medida de la efectividad global de la IS en una empresa.


CMM

Prácticas de Software

Datos Cualitativos

Capacidad del Proceso

Prácticas de Software Mejoradas


CMM

• La capacidad de un proceso de software es su habilidad para producir resultados planeados, donde un proceso es una serie de pasos realizados con un objetivo determinado, y un proceso de software se define como un conjunto de actividades, métodos, prácticas y transformaciones que la gente emplea para desarrollar y mantener un software sus productos asociados.


CMM

• Se puede ver que el CMM está altamente enfocado al aspecto cualitativo del aseguramiento del proceso. No hay medidas cuantitativas asociadas directamente con el modelo de madurez del SEI. En otras palabras, no hay manera, basados en el aseguramiento, de determinar el valor cuantitativo de mover una organización del nivel 1 al nivel 2. Por lo tanto, se deben hacer mediciones paralelamente al uso del CMM.


CMM

• El modelo del SEI es un modelo estático de aseguramiento del proceso. Se requiere una organización que empiece en el nivel más bajo. Se deben satisfacer todos los requerimientos de ese nivel antes de realizar oportunidades en la siguiente etapa de madurez. El beneficio es el desarrollo de una trayectoria de prioridades para la mejora del proceso.


CMM

• Al capturar y analizar datos cualitativos de manera comprobable, el SEI trabaja muy bien. Donde el proceso del SEI se muestra corto es que no provee medidas cuantitativas del aseguramiento resultante. Asumimos que si nos movemos hacia arriba en la escala de madurez, incrementaremos nuestros niveles de productividad y calidad, pero sin medidas cuantitativas, nunca lo sabremos con certeza.


CMM

• Nivel 1. Inicial. El proceso de software se caracteriza según el caso, y ocasionalmente incluso de forma caótica. Se definen pocos procesos, y el éxito depende del esfuerzo individual.

• En el nivel 1, la capacidad es una característica de los individuos, y no de la organización.


CMM

• Nivel 2. Repetible. Se establecen los procesos de gestión del proyecto para hacer seguimiento del coste, de la planificación y de la funcionalidad. Para repetir éxitos anteriores en proyectos con aplicaciones similares se aplica la disciplina necesaria para el proceso.

• En nivel 2 se definen estándares del proyecto de software, y la organización se asegura de que sean seguidos.


CMM

• Nivel 3. Definido. El proceso de software de las actividades de gestión y de ingeniería se documenta, se estandariza y se integra dentro de un proceso de software de toda una organización. Todos los proyectos utilizan una versión documentada y aprobada del proceso de la organización para el desarrollo y mantenimiento del software. En este nivel se incluyen todas las características definidas para el nivel 2.


CMM

• En el nivel 3 el proceso incluye tanto a la Ingeniería de Software como a la administración de procesos y los integra en un todo coherente.

• Así, la organización explota prácticas efectivas de Ingeniería de Software cuando se estandarizan sus procesos de software.


CMM

• Nivel 4. Gestionado. Se recopilan medidas detalladas del proceso de software y de la calidad del producto. Mediante la utilización de medidas detalladas, se comprenden y controlan cuantitativamente tanto los productos como el proceso del software. En este nivel se incluyen todas las características definidas para el nivel 3.


CMM

• Nivel 5. Optimizado. Mediante un resultado cuantitativo del proceso y de las ideas y tecnologías innovadoras, se posibilita una mejora del proceso. En este nivel se incluyen todas las características definidas para el nivel 4.


CMM

• Las organizaciones pueden escoger mejoras a procesos en cualquier momento, aún antes de estar preparados para avanzar al nivel en que dichas mejoras están recomendadas. Sin embargo, deberían entender que la estabilidad de estas mejoras es un riesgo, dado que la base para la institucionalización de estas mejoras no está completa.


CMM

• Por ejemplo, un proceso bien definido, que es característica del nivel 3, puede estar en riesgo si las prácticas de nivel 2 son deficientes. Similarmente, la colecta de datos de nivel 4 puede llevar a resultados sin interpretación, debido a la inconsistencia en el proceso de desarrollo de software y las mediciones.


CMM

• Por otro lado, organizaciones que se mueven del nivel 1 al nivel 2 tienden a establecer tienden a establecer un SEPG (Software Engineering Process Group), que es un atributo del nivel 3. Aunque no es necesario en nivel 2, puede ser útil para alcanzar el nivel 2.


CMM

• Otra perspectiva interesante es la visibilidad del proceso de software:– Nivel 1. El proceso de software es una caja negra.– Nivel 2. El proceso de construir el software se ve como

una serie de cajas negras con visibilidad en puntos de transición (milestones o hitos).

– Nivel 3. La estructura interna de las cajas, es visible.– Nivel 4. Los procesos definidos son instrumentados y

aplicados cuantitativamente.– Nivel 5. Nuevas mejoras son intentadas continuamente.


CMM

• Tenemos tres tipos de mejoras conforme aumenta la madurez de una organización:– Predecibilidad. La diferencia entre los resultados

planeados y los obtenidos se reduce.– Control. La variación de los resultados planeados y los

obtenidos se reduce.– Efectividad. Sus costos decrecen, el tiempo de desarrollo

es menor y se incrementan tanto la productividad como la calidad.


CMM

• El SEI ha asociado áreas clave del proceso ACP (Key Process Area KPA) a cada uno de los niveles de madurez. Las ACP describen las funciones de Ingeniería de Software que se deben presentar para satisfacer una buena práctica a un nivel en particular. Cada ACP se describe identificando las características siguientes:– Objetivos. Los objetivos globales que debe alcanzar la

ACP.


CMM

– Compromisos. Requisitos que se deben cumplir para lograr los objetivos, y que proporcionan una prueba del intento por ajustarse a los objetivos.

– Capacidades. Aquellos elementos que deben encontrarse para permitir que la organización cumpla los objetivos.

– Actividades. Las tareas específicas que se requieren para lograr la función ACP.

– Métodos para supervisar la implementación.– Métodos para verificar la implementación.


CMM

• Los niveles de madurez indican capacidad de proceso y contienen:– Areas claves de proceso (KPA), que persiguen

objetivos y están organizados por:• Características comunes, que marcan la forma

de implementar la KPA, y contienen:– Prácticas clave, que describen actividades o

infraestructura.


CMM

• Las siguientes KPA se deberían lograr en cada nivel de madurez del proceso– Nivel 2 de Madurez del Proceso.

• Gestión de requisitos.• Planificación del proyecto de software.• Seguimiento y supervisión del proyecto de software.• Gestión de subcontratación del software.• Garantía de calidad del software.• Gestión de configuración del software.


CMM

– Nivel 3 de madurez del proceso• Enfoque del proceso de la organización.• Definición del proceso de la organización.• Programa de capacitación.• Gestión de integración del software.• Ingeniería de productos de software.• Coordinación entre grupos.• Revisiones periódicas.


CMM

– Nivel 4 de madurez del Proceso• Gestión cuantitativa del proceso.• Gestión de calidad del software.

– Nivel 5 de madurez del Proceso• Prevención de defectos.• Gestión de cambios de tecnología.• Gestión de cambios del proceso.


CMM

• Cada una de las KPA se definen con un conjunto de prácticas clave que contribuyen a cumplir estos objetivos. Las prácticas clave son normas, procedimientos y actividades que deben ocurrir antes de que se haya instituido completamente un área de proceso clave.


CMM

• El SEI define a los indicadores clave como aquellas prácticas clave o componentes de prácticas clave que ofrecen una visión mayor para lograr los objetivos de un área clave de proceso. Las cuestiones de valoración se diseñan para averiguar la existencia (o falta) de un indicador clave.


CMM

• Pasos para la adopción de CMM.– Paso 1. Armar un grupo. Este grupo debe ser entrenado

en los conceptos fundamentales de CMM así como en el aseguramiento y en el método de evaluación.

– Paso 2. Llenar el cuestionario de madurez.– Paso 3. Hacer un análisis de respuesta al cuestionario.– Paso 4. Visita en sitio de personal acreditado.– Paso 5. Hallazgos de la visita.– Paso 6. Calendarización de actividades para alcanzar los

KPA.


CMM-KPA

Gestión de requisitos. • Su propósito es establecer y mantener un acuerdo

con el cliente sobre los requerimientos de un proyecto de software.

• Este acuerdo cubre tanto requerimientos técnicos como no técnicos (p. ej., fechas de entrega), y forma la base para la estimación, planeación, realización y ajuste de las actividades del proyecto durante su ciclo de vida.


CMM-KPA

• Los requerimientos deben estar documentados, y ser elaborados mediante una política establecida. Se debe garantizar que haya fondos suficientes para encontrar los requerimientos, y medir el estado de cada requerimiento y los cambios en los requerimientos. Deben servir para elaborar una línea base para uso del SIG y mantenimientos, así como lograr que las actividades y la planeación sean consistentes con los requerimientos.


CMM-KPA

Planificación del proyecto de software.• Su propósito es establecer planes razonables para

realizar la ingeniería de software y la administración del proyecto.

• Se debe designar un administrador del proyecto, y la planeación se debe sujetar a una política determinada. Se debe estimar el tamaño del software (en PF o LDC), producir un plan, identificar y asegurar los riesgos.


CMM-KPA

• La planeación debe estar documentada, las responsabilidades asignadas, se debe determinar el ciclo de vida apropiado, la estimación de tamaño debe estar documentada y usar datos históricos (de existir), se deben establecer recursos de hardware especiales o escasos.

• Se debe de medir el logro de hitos, compararlo con el plan, medir el trabajo completado, el esfuerzo realizado, y los fondos invertidos en el proyecto.


CMM-KPA

Seguimiento y supervisión del proyecto de software.• El propósito es dar una visibilidad adecuada al

progreso del proyecto, de forma que se puedan tomar acciones efectivas cuando el proyecto se aleje de su plan.

• Se va comparando el esfuerzo realizado, el costo, el tiempo y el tamaño del software contra el plan, cuando divergen, se puede modificar el plan, los requerimientos, o los recursos.


CMM-KPA

• El administrador del proyecto asigna responsabilidades explícitas para las tareas del proyecto, se lleva un seguimiento de solicitudes de cambios y de cambios a requerimientos, así como de cambios al plan, se ajusta el tamaño del proyecto, se lleva el control del costo del proyecto, del uso de hardware crítico, del plan de riesgos, de las revisiones formales, del alcance de hitos, y se añade información histórica a las líneas base.


CMM-KPA

Gestión de subcontratación del software.• El propósito es seleccionar outsourcing calificado y

administrarlo efectivamente.• En el outsourcing, la planeación, seguimiento y

supervisión del proyecto es llevada por el despacho contratado. Dicho despacho deberá ser seleccionado en atención a su capacidad para realizar el trabajo, previa evaluación realizada por los contratantes.


CMM-KPA

• Una evaluación eficiente es la evaluación de capacidad de software del SEI.

• Una buena gestión del outsourcing frecuentemente requiere interacciones frecuentes cara a cara, y un estudio de requerimientos especialmente detallado. Se debe controlar con revisiones formales y periódicas, por monitoreos de nuestro grupo de SQA, y con revisiones periódicas de las líneas base del despacho contratado.


CMM-KPA

Garantía de calidad del software.• Su propósito es dar una visibilidad adecuada del

proceso con el que se construye el software, así como del producto construido.

• El grupo de SQA revisa y audita el producto y las actividades, checando que se cumplan los procedimientos y estándares adoptados, y notificando a grupos e individuos de desviaciones encontradas.


CMM-KPA

• El grupo de SQA debe tener recursos adecuados, y haber sido entrenado para estas actividades. Este grupo debe gozar de independencia, y maneja un plan de calidad. Revisa la sujeción de los otros grupos a los estándares y procedimientos, organiza las pruebas formales, le da seguimiento a los errores encontrados, controla las líneas base de errores y defectos, e implanta los estándares de calidad. El grupo de SQA se audita externamente.


CMM-KPA

Gestión de configuración del software.• Su propósito es establecer y mantener la integridad

de los productos del proyecto de software durante su ciclo de vida.

• La administración de la configuración incluye los productos de software que son desarrollados para el cliente (como los requerimientos, el código y la documentación), como las herramientas para crear ese software (como compiladores).


CMM-KPA

• Se integra un grupo (SCCB Software Configuration Control Board), que recibe recursos y entrenamiento en esta área, y elabora un plan y un procedimiento para la administración de la configuración. Se crea un depósito, se administra y se construye una línea base de esta tarea. Se imprimen reportes del depósito y de la línea base, y se realizan auditorías de sujeción al procedimiento.


CMM-KPA

Enfoque del proceso de la organización.• Su propósito es establecer la responsabilidad de la

organización en las actividades del proceso de software, con miras a mejorar la capacidad de dicho proceso.

• Para esto se crea un grupo técnico (SEPG Software Engineering Process Group) que se responsabiliza del desarrollo y mantenimiento de los estándares de proceso de la organización.


CMM-KPA

• Este grupo recibe recursos y capacitación, y elabora un plan de trabajo. Se considera una base de datos para el seguimiento de proyectos, se establecen mecanismos para monitorear y evaluar nuevos procesos, métodos y herramientas, y cuando proceda, adoptarlos como parte de los procesos de la organización. Se establecen tiempos (entre año y medio y tres años), para hacer revisiones generales del proceso.


CMM-KPA

Definición del proceso de la organización.• Aquí, se pretende desarrollar y mantener un

conjunto de procesos de software que mejoren el desempeño de los proyectos y den una base para beneficios acumulativos de largo plazo en la organización.

• Estos procesos deben incluir descripciones de ciclos de vida, guías y criterios para adopción de procesos.


CMM-KPA

• Se desarrollan los estándares de procesos en base a un procedimiento por escrito, especificando las interfaces internas de proceso (relativas al ciclo de vida), y las interfaces externas (relativas a la prueba del sistema, la administración del contrato y la documentación).

• Los procesos son descompuestos en sus partes constituyentes, y se establece el orden e interdependencias de estas partes.


CMM-KPA

• También se debe incluir la base de datos de procesos de la organización (estimaciones y mediciones de tamaño, esfuerzo y costo; datos de productividad, mediciones de calidad, etc.,) y una librería de la documentación relacionada con procesos (los estándares, los procedimientos, los planes de desarrollo de software, los planes de mediciones, los materiales de entrenamiento, etc.).


CMM-KPA

Programa de capacitación.• Su propósito es desarrollar las habilidades y el

conocimiento de las personas, para que puedan desarrollar sus roles efectiva y eficientemente.

• Se pretende que se planee la capacitación, que se prevean las habilidades y el conocimientos que se van a requerir, y que las personas reciban ese entrenamiento.


CMM-KPA

• Debe existir un grupo que coordine esta tarea, y disponer de recursos adecuados. Se recaban las necesidades de todos los proyectos, se elabora un plan de capacitación, se ubican fuentes de capacitación (internas y externas), se establecen prerequisitos, objetivos y criterios de evaluación para cada curso, se controlan los materiales de los cursos, y se lleva un registro de la capacitación.


CMM-KPA

Gestión de integración del software.• Su propósito es integrar la ingeniería del software y

las actividades administrativas, en un proceso definido y coherente.

• Se debe de lograr que los proyectos usen versiones adaptadas del proceso de software de la organización, y que sean planeados y administrados conforme al proceso de software definido por la organización.


CMM-KPA

• Para esto, cada proyecto adapta el proceso, se desarrolla y revisa el plan de desarrollo de cada proyecto, se administra de acuerdo con el estándar, se usa la base de datos del proceso de software para planeación y estimación, se administra el tamaño del software de acuerdo con un procedimiento, se aplican factores de contingencia producto del análisis de riesgos, y se identifican las actividades de la ruta crítica.


CMM-KPA

Ingeniería de productos de software.• Su propósito es realizar consistentemente un

proceso de software bien definido que integre todas las actividades de ingeniería de software para producir productos de software correctos, de forma consistente, efectiva y eficiente.

• Se pretende que los productos de software que se hagan guarden consistencia entre si.


CMM-KPA

• Las actividades incluyen el análisis y desarrollo de requerimientos, el desarrollo de la arquitectura del software, el diseño del software, la codificación, la integración de los componentes del software, la prueba del software, la documentación necesaria para realizar las tareas (requerimientos, diseño, plan de pruebas y procedimientos de prueba), así como la documentación de operación y mantenimiento.


CMM-KPA

Coordinación entre grupos.• El propósito es establecer caminos para que el grupo

de Ingeniería de Software participe activamente con los otros grupos de ingeniería de forma que se mejore el proyecto y se satisfagan las necesidades del cliente efectiva y eficientemente.

• Las interacciones entre grupos deben ser planeadas y administradas para asegurar la calidad e integridad del sistema entero.


CMM-KPA

• Para esto, todo el personal de desarrollo debe recibir capacitación para el trabajo en grupo, y los responsables de tareas de cada grupo de ingeniería deben recibir orientación en los procesos, métodos y estándares usados por los otros grupos de ingeniería. Se elabora un plan de comunicación de los compromisos intergrupales, se encuentran y negocian las dependencias entre grupos de ingeniería, y se fijan intercambios periódicos.


CMM-KPA

Revisiones periódicas.• El propósito de las revisiones periódicas es remover

defectos de los productos desarrollados en etapa temprana y de manera eficiente.

• Los resultados de las revisiones no deben ser usados para evaluar el desempeño de personas.

• Deben nombrarse lideres de revisiones periódicas, que elaboran el plan de revisiones e identifican con los líderes de proyecto los productos a revisar.


CMM-KPA

• Los revisores reciben entrenamiento en los objetivos, principios y métodos de las revisiones periódicas. Las revisiones periódicas pueden también incluir aspectos como cumplimiento con los estándares, completud, corrección, reglas de construcción y facilidad de mantenimiento. Los resultados de las revisiones periódicas se almacenan en una base de datos, y se realizan auditorías del grupo de SQA a las revisiones.


CMM-KPA

Gestión cuantitativa del proceso.• El propósito es controlar cuantitativamente el

desempeño del proceso de los proyectos de software.

• Esto involucra establecer objetivos para el desempeño, hacer mediciones del desempeño, analizar las mediciones y hacer ajustes para mantener el desempeño dentro de límites aceptables.


CMM-KPA

• Cuando el desempeño del proceso se estabiliza, los límites aceptables se establecen como una línea base. Se construye un plan para la administración cuantitativa del proceso. Se establecen límites aceptables para cada métrica, y se comparan los valores obtenidos contra los esperados, se examinan los procesos para predecir problemas o oportunidades de mejora, y se toman acciones cuando alguna medición está debajo de los límites.


CMM-KPA

Gestión de calidad del software.• El propósito es desarrollar una comprensión

cuantitativa de la calidad de los productos de software y alcanzar metas de calidad.

• Incluye definir objetivos de calidad para los productos de software, establecer planes para encontrar esos objetivos, monitorear y ajustar los planes, los productos de software y las actividades para satisfacer las necesidades del cliente.


CMM-KPA

• Se hace uso de herramientas como simuladores de ciclo de vida, de análisis cuantitativo y de auditoría de código. El plan de calidad es ajustado al inicio del proyecto, al alcanzar hitos, y cuando los requerimientos cambian de forma significativa. El plan cubre los puntos donde se mide la calidad del software, y se miden cuantitativamente aspectos como la funcionalidad, y las facilidades de uso y de mantenimiento.


CMM-KPA

Prevención de defectos.• El propósito es identificar la causa de defectos y

prevenir su repetición.• Para esto, se analizan los defectos que han ocurrido

en el pasado y se toman acciones concretas para prevenir la repetición de estos tipos de defectos en el futuro. La prevención de defectos sirve para aprender lecciones de proyectos anteriores.


CMM-KPA

• Para realizar la prevención de defectos, se realizan reuniones, donde se analizan los defectos y se busca sus causas. Se asigna el defecto a alguna categoría de causas (capacitación inadecuada, mala comunicación, no se identificaron detalles de un problema, errores en procedimientos manuales (de dedo), etc.). Si es procedente, se busca modificar el proceso para que en el futuro no se vuelva a presentar este tipo de error.


CMM-KPA

Gestión de cambios de tecnología.• El propósito es identificar nuevas tecnologías u

lograr una adopción de forma ordenada.• Involucra que nuevas tecnologías sean identificadas,

seleccionadas e incorporadas en la organización. El objetivo es mejorar la calidad de software, aumentar la productividad y disminuir la planeación para el desarrollo de productos.


CMM-KPA

• Se realizan esfuerzos pilotos con tecnologías no probadas, antes de que sean incorporadas en proyectos normales. Estos esfuerzos pilotos se deben realizar en un ambiente que se relevante en un ambiente de desarrollo o de mantenimiento. Se forma un grupo y se le asignan recursos adecuados. Este grupo desarrolla y mantiene un plan de cambios de tecnología. Las tecnologías aprobadas se incorporan al proceso.


CMM-KPA

Gestión de cambios del proceso.• Aquí el propósito es mejorar continuamente los

procesos de software usados en la organización, con el objetivo de aumentar la calidad del software y la productividad, y disminuir el tiempo de desarrollo de productos.

• Se definen objetivos de mejora de los procesos, y de forma sistemática se implementan mejoras en los estándares de procesos.


CMM-KPA

• Se establecen programas de capacitación y de incentivos para lograr que todos en la organización participen en las actividades de mejora de los procesos. Se elabora un plan de mejoras, donde se establecen las áreas de procesos que puedan tener una mejora más alta, estableciendo objetivos cuantificables tanto a corto como a largo plazo para lograr las mejoras de los procesos. Se llevan registros de todas las mejoras.


CMM

• El número de empresas certificadas por CMM es creciente, aunque reducido (para 1997, 155 organizaciones habían alcanzado el nivel 2, 90 el nivel 3, 10 el nivel 4 y 3 el nivel 5).

• Un hecho que afecta el prácticamente nulo número de empresas en niveles cuatro y cinco, es que solamente se necesita nivel tres para ser un proveedor del Departamento de Defensa de EUA.


CMM

• En 1994, el SEI informó que la media en la mejora de 13 organizaciones que habían mejorado su proceso era:– 35% de aumento en la productividad al año.– 22% de detección temprana de defectos al año.– 19% de reducción del tiempo para entrega al año.– 39% de reducción de reportes de defectos post-entrega

al año.– 5 dólares de retorno de inversión por cada dólar

invertido.


ISO 15504 (SPICE)

• El ISO 15504 es el resultado de la ISO para tener un estándar de proceso de software, a partir de:– Capability Maturity Model, del SEI de Carnegie Mellon.– Bootstrap, del Bootstrap Institute.– Trillium, de Northern Telecom.– Otros esquemas de mejoramiento de proceso de

software.


ISO 15504 (SPICE)

• Las organizaciones pueden usar el estándar de varias maneras:– Modo de determinación de capacidad. Para ayudar a

determinar la capacidad de un proveedor potencial de software.

– Modo de mejora del proceso. Para ayudar a mejorar su propio proceso de desarrollo de software.

– Modo de autoevaluación. Ayuda a determinar la habilidad para llevar a cabo un nuevo proyecto.


ISO 15504 (SPICE)

• Los beneficios de un estándar internacional en el aseguramiento del proceso de software son los siguientes:– Ayuda a los clientes a determinar la capacidad de sus

proveedores de software, y asegura los riesgos de contratar a un proveedor en vez de otro.

– Los proveedores de software tendrán un solo esquema de aseguramiento de proceso, no varios como es el caso en la actualidad.


ISO 15504 (SPICE)

– Las organizaciones de software tendrán una herramienta reconocida internacionalmente para soportar sus programas de mejoramiento continuo de sus procesos.

– Ayudará a los administradores a asegurarse de que el proceso está alineado con las necesidades de negocio de su organización.

– Les ayuda a los auditores al tener un marco que define todos los aspectos para realizar una evaluación (Paulk, 1995 y Zahran, 1998).


ISO 15504 (SPICE)

• El grupo ISO para realizar este estándar comenzó sus trabajos en Junio de 1991, con el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination). Este proyecto fue aceptado como el ISO 15504, y está vigente y a la venta en las organizaciones miembro de ISO en el mundo.

• Spice tuvo dos años de prueba para ser ajustado en campo, antes de ser publicado como estándar.


ISO 15504 (SPICE)


ISO 15504 (SPICE)

• Para administrar las actividades técnicas del desarrollo de SPICE, se establecieron centros técnicos en los siguientes sitios:– Europa (Defence Research Agency Malvern).– Estados Unidos (Software Engineering Institute).– Canadá (Bell Canada).– Cuenca del Pacífico (Griffith University).


ISO 15504 (SPICE)

• El conjunto de normas de que se compone el ISO 15504 son:– 15504-1. Conceptos y parte introductoria (Informativa).– 15504-2. Modelo de referencia para procesos y

capacidad de procesos (Normativa). Esta es la parte equivalente a CMM.

– 15504-3. Realización de una evaluación (Normativa).– 15504-4. Guía para la realización de evaluaciones

(Informativa).


ISO 15504 (SPICE)

– 15504-5. Modelo de evaluación y guía de indicadores (Informativa).

– 15504-6. Guía para la calificación de auditores (Informativa).

– 15504-7. Guía para el uso en el mejoramiento del proceso (Informativa).

– 15504-8. Guía para la determinación de la capacidad del proceso (Informativa).

– 15504-9. Vocabulario (Informativa).


ISO 15504 (SPICE)


ISO 15504 (SPICE)

• La norma ISO 15504-2, o Baseline Practices Guide (BPG) define los objetivos y actividades que son esenciales para un buena ingeniería de software. La BPG describe las actividades que se requieren, y no cómo se deben implementar. BPG es equivalente a CMM.


ISO 15504 (SPICE)

• Este estándar da una clasificación de los procesos normalmente emprendida por organizaciones preocupadas por el desarrollo, mantenimiento, adquisición, suministro y operación de software. Las categorías de procesos están fuertemente alineadas con ISO/IEC 12207.


ISO 15504 (SPICE)

• A diferencia de CMM, BPG agrupa los procesos en cinco categorías distintas:– Procesos Cliente-Proveedor (Customer-Supplier Process

CUS).– Procesos de Ingeniería (Engineering Process ENG).– Procesos de Soporte (Support Process SUP).– Procesos de Administración (Management Process Man).– Procesos de Organización (Organization Process Org).


ISO 15504 (SPICE)


ISO 15504 (SPICE)

Procesos Cliente-Proveedor (CUS).– Adquisición de productos o servicios de software. Sirve

para obtener el producto o servicio que satisfaga la necesidad expresada por el usuario. Para esto se lleva al desarrollo de un contrato que exprese las expectativas y responsabilidades tanto del cliente como del proveedor.

– Administrar las necesidades del cliente. Lograr la colecta y procesamiento de las necesidades del cliente y los requerimientos para todo el ciclo de vida del software. Aquí se establece una buena comunicación y se documentan y aceptan los requerimientos.


ISO 15504 (SPICE)

– Suministro del software. Su propósito es el empaque, entrega e instalación del software en los sitios del cliente, así como asegurar que la calidad del software que es entregado sea la definida en los requerimientos.

– Operación del software. Para soportar la operación correcta y eficiente durante su uso en el ambiente instalado. Para esto se identifican y resuelven los riesgos de su introducción y operación, se corre el software en su ambiente operacional y se provee el soporte para resolver los problemas de operación.


ISO 15504 (SPICE)

– Proveer servicio al cliente. Establecer y mantener un nivel aceptable de servicio para soportar un uso efectivo del software. Para esto se identifican las necesidades actuales de servicio, se mide la satisfacción del cliente tanto con el servicio como con el producto por si mismo, y se tienen reuniones con el usuario.


ISO 15504 (SPICE)

Procesos de ingeniería (ENG).– Desarrollo de requerimientos y diseño del sistema.

Establecer los requerimientos (funcionales y no funcionales) del sistema, e identificar la arquitectura en la cual los requerimientos del sistema puedan ser resueltos.

– Desarrollo de requerimientos del software. Definir los requerimientos del software y sus interfaces, desarrollando requerimientos correctos y posibles de probar, así como la estrategia para definir su prioridad.


ISO 15504 (SPICE)

– Desarrollo del diseño del software. Su propósito es definir un diseño para el software que resuelva los requerimientos y pueda ser probado contra ellos. Para esto se elabora el diseño de una arquitectura que describe los principales componentes del software, se diseñan las interfaces internas y externas de cada componente, se desarrolla un diseño detallado que describe las unidades de software, y se establece la rastreabilidad entre los requerimientos y el diseño del software.


ISO 15504 (SPICE)

– Implementación del diseño del software. Producir unidades ejecutables de software y verificar que cumplan con el diseño. Para esto se definen los criterios de verificación de las unidades contra los requerimientos del software, se producen todas las unidades de software definidas en el diseño y se realiza una verificación de las unidades de software contra el diseño.


ISO 15504 (SPICE)

– Integración y prueba de software. Integrar todas las unidades de software. Para esto se desarrolla un estrategia de integración consistente con la estrategia de liberación, se verifica la integridad del software usando los criterios de aceptación definidos y se graban los resultados de la prueba.

– Integración y prueba del sistema. Integrar el componente de software con otros componentes, tales como el manual de operación y el hardware, produciendo el sistema que satisfaga las expectativas del usuario expresadas en los requerimientos del sistema.


ISO 15504 (SPICE)

– Mantener al sistema y al software. Para administrar modificaciones, migraciones y retiros de componentes del sistema (como hardware, software, manuales y redes), en respuesta a peticiones del usuario. El origen de las peticiones debe ser un problema o la necesidad de mejora o adaptación. El objetivo es modificar y/o retirar sistemas o software existente mientras se preserva la integridad de la operación.


ISO 15504 (SPICE)

Procesos de soporte (SUP).– Desarrollar la documentación. Desarrollar y mantener

los documentos que guarden la información producida por un proceso o actividad dentro de un proceso. Para esto se identifican todos los documentos a ser producidos por el proceso o proyecto, especificando el contenido y propósito de todos los documentos, así como su planeación, los estándares a ser aplicados en los documentos, su desarrollo y mantenimiento.


ISO 15504 (SPICE)

– Realizar la administración de la configuración. Su propósito es establecer y mantener la integridad de todos los productos de trabajo de un proceso o proyecto. Para esto se identifican, definen y controlan mediante líneas base todos los elementos relevantes generados por el proceso o proyecto, se controlan sus modificaciones y versiones, se graba y reporta el estado de los elementos y peticiones de modificación, se asegura la completud y consistencia de los elementos y se controla su almacenamiento, manejo y embarque.


ISO 15504 (SPICE)

– Realizar el aseguramiento de calidad. Asegurar que los productos y actividades de un proceso o proyecto cumplan con todos los estándares aplicables, procedimientos y requerimientos. Para esto se identifican y planean las actividades de aseguramiento de calidad, se identifican los estándares de calidad, metodologías, procesos y herramientas para realizar el aseguramiento, se identifican recursos y responsables para la realización de estas actividades, se garantiza su independencia del proceso de desarrollo, y se realizan las actividades conforme a lo planeado.


ISO 15504 (SPICE)

– Realizar la verificación de productos. Confirmar que cada producto de un proceso o proyecto satisfaga los requerimientos por los que fue construido. Para esto se identifican los criterios para verificar todos los productos, se realizan las actividades de verificación y se encuentran y remueven los defectos eficientemente de los productos producidos por el proyecto.


ISO 15504 (SPICE)

– Realizar la validación de los productos. Confirmar que los requerimientos específicos para el uso de un producto fueron satisfechos. Para esto se identifican los criterios de validación, se realizan las actividades de validación y se proporciona evidencia de que los productos son adecuados para su uso.


ISO 15504 (SPICE)

– Realizar revisiones conjuntas. Para que el usuario tenga el entendimiento del progreso contra los objetivos del contrato, y que se debe hacer para ayudar al desarrollo de un producto que satisfaga al cliente. Para esto se evalúa el estado y productos, se planean las revisiones conjuntas, y se da seguimiento a las acciones derivadas de las revisiones.


ISO 15504 (SPICE)

– Realización de auditorías. Para confirmar independientemente que los productos y procesos empleados cumplen con los requerimientos especificados. Para esto se determina cumplimiento con los requerimientos, planes y contrato, y se garantiza que la auditoría sea hecha por una parte independiente.

– Realizar la resolución de problemas. Para asegurar que todos los problemas descubiertos sean analizados y removidos, y sean identificadas tendencias. Para esto se deben resolver los problemas de manera oportuna, sensible y documentada, y tener un mecanismo para reconocer las tendencias en los problemas identificados.


ISO 15504 (SPICE)

Procesos de Administración (MAN).– Administrar el proyecto. Su propósito es definir los

procesos necesarios para establecer, coordinar y administrar un proyecto y los recursos necesarios para producir un producto. Para esto se define el alcance del proyecto, se miden, estiman y planean las tareas y los recursos, se identifican y administran las interacciones entre elementos en el proyecto y con otros proyectos, y se toman medidas correctivas cuando no se alcanzan las metas del proyecto.


ISO 15504 (SPICE)

– Administrar la calidad. Su propósito es administrar la calidad de los servicios y productos del proyecto y asegurarse de que satisfagan al consumidor. Para esto se establecen metas de calidad, basadas en los requerimientos de calidad del cliente, se definen y usan métricas para medir los resultados de las actividades del proyecto, se identifican de forma sistemática buenas prácticas de la ingeniería de software, y se integran a los modelos empleados, se realizan actividades de calidad y se toman acciones correctivas cuando no se alcanzan los objetivos de calidad.


ISO 15504 (SPICE)

– Administrar los riesgos. Para identificar y mitigar de forma continua los riesgos que se pueden dar a lo largo de la vida del proyecto. Así, se identifican los riesgos del proyecto, se analizan y se determina la prioridad en la que se van a aplicar recursos para administrarlos, se definen e implementan estrategias adecuadas, se definen y aplican métricas de riesgos y se toman medidas correctivas cuando no se alcanzan los progresos esperados.


ISO 15504 (SPICE)

– Administrar los subcontratos. El objetivo es seleccionar outsourcing de calidad y administrar su desempeño. Para esto se establece que partes del proyecto serán subcontratadas, se califica el potencial del outsourcing mediante una medición de su desempeño para realizar la función requerida, se asigna el subcontrato, regularmente se obtiene información del avance técnico del subcontrato, se mide el cumplimiento del outsourcing contra los estándares y procedimientos acordados, se mide la calidad de los productos y servicios desarrollados por el outsourcing.


ISO 15504 (SPICE)

Procesos de organización (ORG).– Ingeniería del negocio. Su propósito es dar a los

individuos de la organización una visión que les ayude a hacer su función de forma efectiva. La mejora del proceso ocurre en el contexto de un negocio, y debe caminar hacia los objetivos del negocio. Para este punto, se define una visión, misión, objetivos y metas del negocio, y se hace que lo conozcan todos los empleados. Se hacen cambios individuales para lograr que todos los trabajos contribuyan efectivamente a la visión de la organización.


ISO 15504 (SPICE)

– Definir el proceso. El objetivo es construir una librería reutilizable de definiciones del proceso (incluyendo estándares, procedimientos y métodos) que pueda soportar un desempeño estable y repetible de la ingeniería de software y de la administración del proceso.

– Mejorar el proceso. Para mejorar de forma continua la efectividad y eficiencia del proceso usado en la organización. Para esto se deben entender las fortalezas y debilidades del proceso de la organización, hacer cambios al proceso de forma controlada, así como planear y monitorear actividades de mejora.


ISO 15504 (SPICE)

– Proveer recursos humanos calificados. Se trata de dar a la organización y a los proyectos gente que posea habilidades y conocimiento para realizar sus roles de manera efectiva y trabajar juntos como un grupo cohesivo. Para esto hay que identificar los roles y habilidades requeridos para los proyectos, establecer procedimientos formales para el reclutamiento y selección de personal, diseñar y conducir capacitación para asegurar que todos los individuos tengan las habilidades requeridas para realizar sus tareas y definir criterios objetivos contra los que se pueda medir el desempeño individual y grupal.


ISO 15504 (SPICE)

– Proveer infraestructura para la ingeniería de software. Proveer un ambiente confiable y estable con un conjunto integrado de métodos y herramientas de desarrollo de software para su uso en los proyectos de la organización. La infraestructura debe ser consistente y soportar el proceso definido.


ISO 15504 (SPICE)

• La evolución de la capacidad del proceso es expresada en términos de atributos del proceso que pueden ser evaluados sobre la base de lograrlos, dando una medida de la capacidad del proceso. Cada atributo del proceso describe una faceta de la capacidad total de administrar y mejorar la efectividad de un proceso al alcanzar su propósito y contribuir a las metas de negocio de la organización.


ISO 15504 (SPICE)

• Hay que notar que ISO 15504 define la capacidad por proceso, mientras que CMM versión 1.1 define la capacidad por organización.


ISO 15504 (SPICE)


ISO 15504 (SPICE)

• Nivel 0. Incompleto. En este nivel, no se obtiene el propósito del proceso. No son fácilmente identificables los productos o salidas del proceso. El proceso no está implementado, o falla en alcanzar su objetivo.


ISO 15504 (SPICE)

• Nivel 1. Realizado. El propósito del proceso normalmente se alcanza. La realización no es rigurosamente planeada y seguida. Los individuos en la organización reconocen que una acción se puede realizar. Hay productos identificables para el proceso. El proceso tiene el atributo de realizado. En la ejecución del proceso se siguen prácticas definidas, y éstas prácticas son iniciadas y seguidas usando productos de entrada que producen productos de salida que satisfacen el propósito del proceso.


ISO 15504 (SPICE)

• Nivel 2. Planeado y seguido. El proceso desarrolla productos de calidad aceptable con períodos establecidos de tiempo y recursos definidos. Los productos se sujetan a requerimientos y estándares específicos. El proceso tiene el atributo de administrado: se producen los productos dentro de tiempos y recursos establecidos. El producto tiene el atributo de administrado: los productos están documentados y controlados para cumplir sus requerimientos funcionales y no funcionales, y cumple con las metas de calidad del producto.


ISO 15504 (SPICE)

• Nivel 3. Establecido. El proceso se realiza y administra usando un proceso definido basado en los buenos principios de la ingeniería de software. Son aprobadas implementaciones individuales del proceso, hechas a la medida, del proceso documentado y estandarizado. El proceso posee el atributo de definido: se usa una definición de proceso basada en el proceso estándar, que ayuda al proceso a contribuir con los objetivos de negocio de la organización. El proceso posee el atributo de recursos: se dispone de recursos humanos capacitados en la infraestructura del proceso.


ISO 15504 (SPICE)

• Nivel 4. Predecible. El proceso definido se realiza de manera consistente dentro de límites de control definidos. Son recolectadas y analizadas medidas detalladas del desempeño. Esto da una comprensión cuantitativa de la capacidad del proceso y una mayor habilidad para predecir el desempeño. La calidad del trabajo se conoce cuantitativamente. El proceso tiene el atributo de medido: la ejecución del proceso es controlada por metas y mediciones. El proceso tiene el atributo de controlado: el proceso es controlado mediante la colecta y análisis de mediciones para controlar y corregir, cuando es necesario, el desempeño del proceso.


ISO 15504 (SPICE)

• Nivel 5. Optimizado. El desempeño del proceso se optimiza para cumplir con las necesidades del negocio actuales y futuras. Se establecen metas cuantitativas de efectividad y eficiencia basadas en las metas de negocio de la organización. El proceso está bajo un refinamiento y mejora continua. Hay una comprensión cuantitativa de los cambios en el proceso. El proceso tiene el atributo de cambio: la definición, administración y desempeño del proceso son controlados de mejor forma. El proceso tiene el atributo de la mejora continua: se identifican e implementan cambios en el proceso para asegurar la mejora continua.


ISO 15504 (SPICE)

• La medición de la capacidad del proceso de define como un número ordinal del 0 (incompleto) al 5 (optimizado).

• Cada uno de los atributos del proceso se califica:– (N) No realizado. No existe evidencia de la realización

de este atributo. – (P) Parcialmente realizado. Existe alguna evidencia.– (L) Fuertemente realizado. Hay evidencia significativa.– (F) Totalmente realizado.


CMM e ISO 15504

• El SEI trabajó con ISO para construir un estándar internacional para el aseguramiento del proceso del software, su mejora y su evaluación. El desarrollo del estándar ISO será de influencia en la versión 2 de CMM, tanto como el CMM fue de influencia en las actividades de ISO (Paulk, 1995).


CMM e ISO 15504

• Un proceso en 15504 sustituyen a un área clave de proceso (KPA) de CMM. Hay que notar que CMM contiene 18 KPA, mientras que 15504 contiene 29 procesos. Algunos KPA permanecen como un proceso 15504 (como la administración de la configuración, las revisiones conjuntas, o el aseguramiento de calidad), algunas KPA se desglosan en varios procesos 15504 (como la gestión de requerimientos, que se desglosa en administrar las necesidades del cliente, desarrollo de requerimientos y diseño del sistema y desarrollo de requerimientos del software).


CMM e ISO 15504

• Adicionalmente, algunos procesos 15504 no tienen equivalente en KPA de CMM, la Ingeniería del negocio, y el suministro del software.

• Además, ISO 15504 añade un nivel de madurez 0, a los 5 niveles de madurez de CMM.


Administración de Requerimientos

• Es difícil establecer exactamente lo que un sistema debería hacer.

• Ingeniería de requerimientos: el proceso de establecer los servicios que el sistema suministrará y las limitaciones bajo las cuales debe operar.

• Un requerimiento puede ser un requerimiento funcional, que describe una función o servicio del sistema, o un requerimiento no funcional, que es una limitación impuesta al sistema.



• Los requerimientos se tienen que validar.• Si no se validan, un error será propagado al diseño y

a la implementación. Un cambio de requerimientos implica que se tienen que cambiar el diseño y la implementación, así como repetir los procesos de prueba del sistema y validación.

• El costo de corregir en la implementación un requerimiento es hasta 100 veces mayor que corregir un error de programación.



• El análisis de requerimientos es un proceso importante. La aceptación de un sistema luego de que ha sido desarrollado depende de que el analista haya descubierto los requerimientos reales del cliente.



• El análisis de requerimientos es difícil por varias razones:– Los clientes muchas veces no saben que esperar de un

sistema, más que a rasgos generales.– Los clientes expresan los requerimientos en sus términos,

que tienen un conocimiento implícito.– Distintos clientes tienen distintos requerimientos y

pueden expresarlos de distintas formas.– El ambiente en que se hace el sistema es dinámico, por lo

que es inevitable que va a haber cambios.



Comprensión del dominio

Validación de requerimientos

Recolección de requerimientos

Clasificación

Priorización

Resoluciónde conflictos

Definición yespecificación de

requerimientos



• Hay varios esquemas (complementarios) para hacer el análisis de requerimientos.– Análisis orientado a los distintos puntos de vista

de los participantes.– Análisis basado en un método.– Análisis basado en la frontera del sistema.– Análisis basado en factores sociales y

organizacionales.



• Con la Administración de requerimientos:– Se establecen las bases para que los clientes y los

proveedores se pongan de acuerdo en lo que va a hacer el producto de software.

– Se reduce el tiempo de desarrollo.– Se proveen las bases para estimar costos y

calendarios, así como para validar y verificar.– Se facilita la inducción a los usuarios.– Sirve como base para la mejora.



• No existen estándares ISO para la administración de requerimientos, pero IEEE ha publicado dos estándares:– IEEE Std 1233 (1996-1998). IEEE Guide for

Developing System Requirements Specifications.– IEEE Std 830 (1993-1998). IEEE

Recommended practice for Software Requirements Specifications.



• Ambos estándares están escritos en conformidad con ISO 12207.

• Tanto IEEE 1233 como IEEE 830 constan de alrededor de 30 páginas, incluyendo apéndices.

• IEEE 1233 afirma que no es un estándar obligatorio, y que se escribió bajo la premisa de que bajo el estado actual del desarrollo de software no se puede garantizar o soportar un estándar formal.



• Ambos estándares entran en la categoría de prácticas recomendadas.

• Las principales definiciones que muestran son:– Requerimiento. (A) Una condición o capacidad que el

usuario necesita para solucionar un problema o alcanzar un objetivo. (B) Una condición o capacidad que un sistema o un componente de un sistema debe poseer para satisfacer un contrato, estándar, especificación u otro documento impuesto. (C) Una referencia escrita de una condición o capacidad como en (A) o en (B).



– Requerimiento bien formado. Una funcionalidad de un sistema (una capacidad) que puede ser validada, que un sistema debe poseer para solucionar un problema o alcanzar un objetivo, y es evaluada mediante mediciones y limitado su alcance.

– Requerimiento derivado. Un requerimiento deducido o inferido de la colección de requerimientos a una solución de un sistema en particular.

– Requerimiento en bruto. Un requerimiento del cliente o del ambiente que no ha sido analizado ni formulado como un requerimiento bien formado.



• IEEE 1233 se centra en construir el SyRS (System Requirements Specification), que presenta los resultados de definir las necesidades, el concepto de operación, y las tareas de análisis de sistemas. Por lo tanto, es una descripción de lo que los clientes del sistema esperan que haga, el ambiente del sistema, el perfil de uso del sistema, sus parámetros de desempeño, su calidad y efectividad esperadas.



• IEEE 830 se centra en construir la SRS (Software Requirements Specifications), que es una especificación de un cierto producto o programa de software, que realiza ciertas funciones en un ambiente específico.

• Ambos estándares están en cumplimiento de la norma ISO 12207.


IEEE Std 1233

• Un System Requirements Specification (SyRS) normalmente se ve como una descripción de caja negra de lo que el sistema debe de hacer, en términos de las interacciones entre sistemas o interfaces con su ambiente externo.

• El SyRS incluye las etapas de diseño, implementación, integración, prueba, manufactura, empleo, operación y mantenimiento.


IEEE Std 1233


IEEE Std 1233

• Los requerimientos deben ser clasificados por su identificación, prioridad, que tan crítico es, factibilidad, riesgo, fuente y tipo.

• Los tipos de requerimientos son:– Entrada (p. ej. recibir datos externos).– Salida (p. ej. exportar a un formato particular).– Fiabilidad (p. ej. tiempo promedio entre fallas).– Disponibilidad (p. ej. horas estimadas de operación).– Facilidad de mantenimiento (p. ej. facilidad con la cual

los componentes pueden ser reemplazados).


IEEE Std 1233

– Desempeño (p. ej. Tiempo de respuesta).– Facilidad de acceso (p. ej. diferentes trayectorias de

navegación para principiantes y usuarios expertos).– Condiciones ambientales (p. ej. niveles de polvo que

deben ser tolerados).– Ergonomía (p. ej. uso de ciertos colores para reducir

cansancio ocular).– Higiene (p. ej. límites para la radiación magnética).– Seguridad (limitaciones al acceso de datos, usuarios

autorizados y no autorizados).


IEEE Std 1233

– Facilidad (p. ej. uso de la red eléctrica doméstica).– Transportabilidad (p. ej. límites de peso para la

portabilidad).– Entrenamiento (p. ej. incluya tutoriales o capacitación

basada en computadora).– Documentación (p. ej. ayuda en línea).– Interfaces externas (p. ej. soporte para un estándar de

comunicaciones).


IEEE Std 1233

– Prueba. (p. ej. soporte para diagnóstico remoto).– Previsiones de calidad (p. ej. intervalos mínimos de

calibración).– Políticas y regulaciones (p. ej. políticas de oficinas de

protección al medio ambiente).– Compatibilidad con el sistema actual (p. ej. usa el

sistema telefónico analógico por default).– Políticas y estándares técnicos (p. ej. productos que

satisfagan un estándar determinado).– Conversión (p. ej. puede aceptar datos producidos por

versiones anteriores del sistema).


IEEE Std 1233

– Capacidad de crecimiento (p. ej. puede soportar un número adicional de usuarios).

– Instalación (p. ej. habilidad para poner el nuevo sistema en servicio).


IEEE Std 1233

• Algunas dificultades que surgen cuando se hacen requerimientos bien formados son: Hacer el diseño y la implementación, sobreespecificar, limitaciones innecesarias, requerimientos no acotados y supuestos.


IEEE Std 1233

• Para el desarrollo de un SyRS se sigue un proceso iterativo. Los cuatros subprocesos son:– Identificar los requerimientos del cliente, el ambiente y

la experiencia de la comunidad técnica.– Construir requerimientos bien formados.– Organizar los requerimientos en un SyRS.– Presentar el SyRS en varias presentaciones para distintas

audiencias.


IEEE Std 1233


IEEE Std 1233

• El proceso para administrar los requerimientos debe asegurar lo siguiente:– El proceso está dirigido a resultados y ayuda a la

producción del conjunto de requerimientos.– Se definen las fronteras del sistema.– Todos los requerimientos que se solicitan, se evalúan y

documentan.– Los requerimientos son validados o eliminados (si son

inválidos) del conjunto de requerimientos.


IEEE Std 1233

– Se revisa la consistencia cuando muchos individuos contribuyen al desarrollo del conjunto de requerimientos.

– El desarrollo del conjunto de requerimientos es entendido, a un nivel adecuado de detalle, por todos los individuos que participan en el proceso.


IEEE Std 1233

• Algunas técnicas para identificar requerimientos, son:– Grupos de trabajo estructurados.– Lluvia de ideas o sesiones de solución de problemas.– Entrevistas.– Inspecciones o cuestionarios.– Observación de patrones de trabajo.– Observación de la estructura organizacional y las

políticas ambientales.


IEEE Std 1233

– Revisión de la documentación técnica.– Análisis de mercado.– Evaluación de los sistemas de la competencia.– Ingeniería de reversa.– Simulaciones.– Prototipos.– Procesos y sistemas de medición del desempeño.


IEEE Std 1233

• Para construir requerimientos bien formados el analista debe:– Asegurar que cada requerimiento es necesario y corto.– Definir las condiciones apropiadas (mediciones

cuantitativas o cualitativas) para cada requerimiento, y evitar palabras ambiguas.

– Prevenir las dificultades de los requerimientos.


IEEE Std 1233

– Asegurar que los requerimientos sean leíbles, usando palabras y conceptos simples, un acomodo y relación uniforme, una notación uniforme, y un uso correcto del lenguaje y la ortografía.

– Asegurar la capacidad de que puedan ser probados.


IEEE Std 830

• Al hacer un SRS se debe de considerar:– Funcionalidad.– Interfaces externas.– Desempeño.– Atributos (consideraciones de portabilidad,

facilidad de mantenimiento, corrección, seguridad, facilidad de uso, etcétera).

– Limitantes de diseño impuestas a la implementación.


IEEE Std 830

• Características de un SRS:– Un SRS es correcto si y sólo si los requerimientos que

establece son los que el software debe cumplir.– Un SRS es no ambiguo, si y sólo si tiene una sola

interpretación.– Un SRS es completo si tiene todos los requerimientos

significativos, define las respuestas del software a todos los tipos de datos en todas las situaciones posibles, y no contiene elementos sin definir.


IEEE Std 830

– Un SRS es internamente consistente si y sólo si no hay conflictos entre los requerimientos descritos.

– Un SRS es agrupado por importancia y/o estabilidad si cada requerimiento en él tiene un identificador para indicar la importancia (esencial, condicional u opcional) o estabilidad de ese requerimiento.

– Un SRS es verificable si y sólo si todos los requerimientos establecidos son verificables. Un requerimiento es verificable si existe algún proceso costeable con el cual una persona o máquina pueden checar que el software cumple el requerimiento.


IEEE Std 830

– Un SRS es modificable si y sólo si su estructura y estilo son tales que cualquier cambio a los requerimientos puede ser hecho fácil, completa y consistentemente conservando la estructura y estilo.

– Un SRS es rastreable si es claro el origen de cada uno de sus requerimientos, y si facilita las referencias de cada requerimiento en el desarrollo y en el resto de la documentación.


IEEE Std 830

• El SRS debe ser preparado mediante el trabajo conjunto del cliente y el proveedor de software.

• Se deben tener dos consideraciones para la evolución de un SRS: La especificación de los requerimientos debe ser tan completa y directa como sean su conocimiento al momento de definirlos, y se debe seguir un proceso formal para identificar, controlar, seguir y reportar cambios a los requerimientos.


IEEE Std 830

• Al escribir el SRS se debe distinguir claramente entre la identificación de limitantes al diseño y la elaboración del diseño. Aunque cada requerimiento limita las alternativas de diseño, no es el tiempo de hacer el diseño.

• También debe quedar claro que el SRS determina el producto de software, no el proceso para producir el producto de software.


IEEE Std 830

• Los requerimientos del proyecto representan entendimiento entre el consumidor y el proveedor de software sobre aspectos del contrato pertenecientes a la producción del software, y no deben ser incluidos en el SRS. Aquí entran aspectos como: costo, tiempos de entrega, forma de avance, métodos de desarrollo de software, aseguramiento de calidad, criterios de verificación y validación, criterios de aceptación.


IEEE Std 830

• Estos requerimientos del proyecto se especifican en otros documentos, como el plan de desarrollo del software, el plan de aseguramiento de calidad del software, o un plan de trabajo.


IEEE Std 830

Tabla de contenido1. Introducción.

1.1. Propósito.1.2. Alcance.1.3. Definiciones,

acrónimos.1.4. Referencias.1.5. Revisión.

2. Descripción global.2.1. Perspectiva del

producto.

2.2. Funciones del producto.

2.3. Perfil del usuario.2.4. Limitaciones.2.5. Supuestos y

dependencias.3. Requerimientos

específicos.Apéndices.Indice.


IEEE Std 830

• En el propósito, se especifica además la audiencia del SRS.

• En el alcance, se identifica el nombre del producto, se delimita la frontera de la aplicación, se describe brevemente, incluyendo los beneficios, objetivos y metas.

• En las referencias se citan todas las fuentes del SRS, y donde se pueden obtener. Se puede manejar como apéndice.


IEEE Std 830

• En la revisión, se describe el resto del SRS, así como se explica la organización del SRS.

• En la descripción global no se especifican requerimientos, sino más bien el background de estos requerimientos.


IEEE Std 830

• En la perspectiva del producto, se pone la interacción del producto con las interfaces del sistema, las interfaces de usuario (especificando las características lógicas de cada interfaz entre el usuario y el producto, y todos los aspectos de optimización de la interfaz que debe cumplir el sistema), las interfaces con el hardware y con otros software, los protocolos de comunicaciones y las restricciones de memoria (en caso de haber).


IEEE Std 830

• En la perspectiva del producto también se indican las características de la operación (los distintos tipos de operación, los períodos de uso, las operaciones de respaldo y recuperación), así como los requerimientos de adaptación al sitio (especificación de los sitios en los que va a correr el software, así como sus instalaciones particulares).


IEEE Std 830

• En las funciones del producto se da un resumen de las principales funciones que el software debe realizar, sin mencionar la gran cantidad de detalles que cada una de estas funciones requieren.

• En el perfil del usuario se indica su nivel educacional, experiencia y capacidad técnica.


IEEE Std 830

• Las limitaciones incluyen: políticas, limitaciones del hardware, interfaces a otras aplicaciones, concurrencia, funciones de auditoría, funciones de control, requerimientos de lenguajes, protocolos de señales, requerimientos de fiabilidad, que tan crítica es la aplicación, consideraciones de seguridad y cualquier otro elemento que limite las opciones del desarrollo.


IEEE Std 830

• En los supuestos y dependencias se construye una lista de los factores que pueden afectar los requerimientos del SRS. Estos factores no constituyen limitantes del diseño, sino situaciones que de darse, pueden afectar a los requerimientos.


IEEE Std 830

• Requerimientos específicos. En esta parte el SRS debe contener todos los requerimientos del software a un nivel de detalle que le permita a los desarrolladores diseñar un sistema que satisfaga estos requerimientos, y a los probadores probar que el sistema satisface estos requerimientos.


IEEE Std 830

• Estos requerimientos por lo menos deben incluir todas las entradas y salidas del sistema, y todas las funciones realizadas en respuesta a una entrada o para realizar una salida. Esta es la mayor y más importante parte del SRS.


IEEE Std 830

• Para interfaces externas es necesario incluir su nombre, descripción, si es de entrada o salida, su rango válido, precisión o tolerancia, su unidad de medida, tiempo de respuesta, sus relaciones con otras entradas/salidas, la organización o formato de sus ventanas, sus formatos de datos y de comandos, y sus mensajes de terminación.


IEEE Std 830

• Para los requerimientos de funcionalidad, es necesario definir las validaciones de las entradas, la secuencia exacta de operaciones, las respuestas a situaciones anormales, sus parámetros y las relaciones entre entradas y salidas.


IEEE Std 830

• Para los requerimientos de desempeño, se deben incluir tanto los estáticos (como el número de terminales que se deben de soportar, o el número de usuarios concurrentes, o el volumen de información), como los dinámicos (como el número de transacciones y tareas, así como la cantidad de datos que se deben procesar para determinados períodos de tiempo, tanto normales como picos).


IEEE Std 830

• Requerimientos Lógicos para Base de Datos. Especifican los requerimientos lógicos para cualquier información que se pone en la base de datos. Esta información puede incluir: Tipos de información, frecuencia de uso, formas de acceso, entidades y relaciones, limitaciones de integridad y requerimientos de persistencia.

• Para las limitantes del diseño, se especifican aquellas impuestas externamente, debido al hardware, a estándares, etcétera.


IEEE Std 830

• Para el cumplimiento de estándares, se especifican los requerimientos derivados de estándares o regulaciones existentes.

• Atributos del software. Es importante especificarlos para que puedan ser verificados de manera objetiva. Incluyen la confiabilidad, disponibilidad, seguridad, facilidad de mantenimiento, portabilidad, etcétera.


IEEE Std 830

• Excepto para sistemas triviales, los requerimientos detallados son grandes. Por esta razón, hay que tener cuidado para organizarlos de forma óptima, con el fin de mejorar su comprensión. No hay una organización óptima para todos los sistemas. Distintas clases de sistemas utilizan mejor distintas organizaciones de requerimientos.


IEEE Std 830

• En este estándar el apéndice A consta de ocho plantillas, que corresponden a diferentes formas de organizar los requerimientos.– Modo de sistema (A1 y A2). Algunos sistemas se

comportan de manera distinto en función del modo del sistema (por ejemplo, entrenamiento, normal, emergencia).

– Clases de usuarios (A3). Algunos sistemas proveen distintos conjuntos de funciones a distintas clases de usuarios.


IEEE Std 830

– Objetos (A.4). Los objetos son entidades del mundo real que tienen una contraparte en el sistema. Los objetos deben compartir atributos y servicios, y se agrupan en clases.

– Servicio (A5). Requiere una secuencia de pasos para efectuar el resultado deseado. Cada servicio normalmente se describe en una serie de parejas evento-acción.

– Estímulos (A.6). Algunos sistemas pueden ser organizados al describir sus funciones en términos de estímulos.


IEEE Std 830

• Respuesta (A.6). Describir las funciones para soportar la generación de una respuesta.

• Jerarquía funcional (A.7). Cuando ninguno de los esquemas de organización anteriores es de ayuda, se puede agrupar la funcionalidad organizándola por entradas comunes, salidas comunes, o métodos de acceso comunes. Se pueden usar diagramas de flujo de datos y diccionarios de datos para mostrar las relaciones entre las funciones y los datos.


IEEE Std 830

• En ocasiones, más de una forma de organización puede ser apropiada. En esos casos, hay que organizar los requerimientos específicos por múltiples jerarquías en base a las necesidades específicas del sistema. Por ejemplo (A.8) muestra la combinación de clases de usuarios y servicios.


IEEE Std 830

• Hay muchas notaciones, métodos y herramientas disponibles para ayudar en la documentación de requerimientos. Por ejemplo, cuando se organizan por modo, ayudan las máquinas de estado finito o diagramas de estado; cuando se organizan por objetos, ayuda el análisis orientado a objetos; cuando se organizan por servicio, ayudan los diagramas de transición de estados; y cuando se organizan por jerarquía funcional, ayudan los diagramas de flujo y los diccionarios de datos.


IEEE Std 830

• Es común incluir también:– Tabla de contenidos.– Indice.– Apéndices: formatos de entradas y salidas de datos,

análisis de costos, información de background que puede ayudar a los lectores del SRS, una descripción de los problemas que solucionará el software, instrucciones especiales para el código y el medio para cumplir la seguridad, exportación de datos, carga inicial, u otros requerimientos.


Puntos de Función

• Fueron propuestos por Allan Albretch de IBM en 1979.

• Con el tiempo, se creo el IFPUG (International Function Point Users Group), quién promulga el Counting Practices Manual, que contiene los estándares actuales para el proceso de conteo.


Puntos de Función

• En Junio de 1995 fueron aprobados por la ISO con la norma ISO 14143 Functional Size Measurement, producto del esfuerzo del grupo de trabajo 12 (WG12) del subcomité 7 (SC7), encargado de la normalización en Ingeniería de software, del comité técnico conjunto 1 (JTC1) de la Comisión Electrotécnica Internacional (IEC) de la Organización Internacional de Estandarización (ISO).


Puntos de Función

• EL ISO/IEC JTC1/SC7/WG12 está cobijado bajo la Organización Australiana miembro de ISO (Standards Australia www.standards.com.au).

• Los puntos de función son la métrica más importante, pero es sólo una de las métricas necesarias.

• Los puntos de función son la medida normalizada para hacer comparaciones entre segmentos de la industria.


Puntos de Función

• Los puntos de función fueron desarrollados en un ambiente de sistemas de información, y han sufrido una ampliación (para soportar interfaz gráfica), y tres variantes:– Método Mark II.– Puntos de característica.– Puntos 3D.


Puntos de Función

• Dado que los puntos de función representan la funcionalidad que el usuario va a ver, nunca es demasiado pronto para hacer el análisis funcional.

• El proceso para contar puntos de función variará según el estado particular de una aplicación. Normalmente hay menos información disponible en las etapas iniciales del proceso de desarrollo. Hay mucha más información cuando la aplicación está desarrollada y en producción.


Puntos de Función

• Al inicio del desarrollo, la única información disponible puede ser verbal. Durante el proceso de desarrollo, la información disponible para el conteo se incrementa al incluir algunos de los siguientes documentos que son de ayuda al contar los Puntos de Función:


Puntos de Función

– Declaración de propósito.– Documentos de requerimientos.– Diagramas del sistema de alto nivel.– Diagramas Entidad-Relación.– Especificaciones funcionales.– Especificaciones del sistema.– Modelos lógicos de datos.– Esquema de la base de datos.


Puntos de Función

– Modelos de proceso.– Especificaciones módulo/programa.– Impresiones de pantallas para sistemas de línea.– Diccionario de datos.– Copias o esquemas de reportes.– Manuales de usuario.– Materiales de entrenamiento.– Ayuda del sistema


Puntos de Función

• Se efectúan cuentas de Puntos de Función en los siguientes puntos:– Etapa de requerimientos.– Diseño detallado.– Prueba.– Puesta en marcha.– Mantenimiento.


Puntos de Función

• La metodología para contar Puntos de Función incluye siete pasos:1. Determinar el tipo de cuenta de punto de

función.2. Identificar la frontera de la aplicación.3. Identificar todas las funciones de datos y su

complejidad.


Puntos de Función

4. Identificar todas las funciones transaccionales y su complejidad.

5. Determinar la cuenta de Puntos de Función no ajustados.

6. Determinar el valor del factor de ajuste, por medio de catorce características generales del sistema.

7. Calcular la cuenta final ajustada de Puntos de Función.


Puntos de Función. Paso 1

• Hay tres tipos de cuenta de Puntos de Función:– Cuenta de Puntos de Función para proyectos de

desarrollo.– Cuenta de Puntos de Función para proyectos de

Mejora.– Cuenta de Puntos de Función para aplicaciones.



• Cuenta de Puntos de Función para proyectos de desarrollo. Cuenta la funcionalidad provista a usuarios finales con la primera instalación de la aplicación. Incluye la cuenta de Puntos de Función para aplicaciones, así como cualquier funcionalidad requerida para conversión de datos.



• Cuenta de Puntos de Función para proyectos de Mejora. Mide modificaciones a aplicaciones existentes e incluye la funcionalidad combinada provista a los usuarios al añadir, eliminar o cambiar funciones.

• Cuenta de Puntos de Función para aplicaciones. Mide una aplicación instalada. Da una cuenta de la funcionalidad entregada a usuarios finales por la aplicación.



• Identificar la frontera de nuestro sistema. Aquí se indica el límite entre el proyecto o la aplicación y las aplicaciones externas. Sus reglas:

• La frontera es basada en el punto de vista del usuario.– La frontera entre las aplicaciones relacionadas se

basa en funcionalidades de negocio separadas, y no sobre implementaciones tecnológicas.



– La frontera inicial de una aplicación cambia cuando la aplicación se modifica para aumentar su funcionalidad. La funcionalidad añadida puede expandir la frontera, y la funcionalidad eliminada puede contraer la frontera. La funcionalidad cambiada puede cambiar el tamaño en Puntos de Función de la aplicación.



• Los proyectos de desarrollo y proyectos de mejora frecuentemente incluyen más que una sola aplicación. En este caso, las múltiples fronteras de aplicaciones deben ser identificadas y contadas por separado.

• Las fronteras no se pueden establecer al nivel de un programa o un módulo, los Puntos de Función deben ser contados al nivel de aplicación más alto.



• Identificar las funciones de datos. Las funciones de datos se refieren a datos lógicos almacenados y disponibles para actualización y recuperación. Los tipos de datos son identificados tanto como ILF (Internal Logical Files) como EIF (External Interface Files).



• Una aplicación debe ser contada con el mismo número de ILF y de EIF independientemente de que su estructura física esté en archivos planos, bases de datos jerárquicas o relacionales, o objetos.



• Primero intentamos contar las funciones de datos por dos razones:– Debemos saber cuales ILF y EIF son mantenidos

y/o usados por cada función transaccional para poderle asignar su tasa de complejidad.

– Al identificar primero los archivos, nos da una buena pista para identificar las funciones transaccionales.



• Un ILF es un grupo identificable por el usuario de datos lógicamente relacionados o de información de control mantenidos mediante un proceso elemental de la aplicación dentro de la frontera de la aplicación.

• Un ILF no debe ser dependiente o atribuir su existencia a otro ILF.

• ILF’s son típicamente entidades en segunda o tercera forma normal.



• Un proceso elemental es la más pequeña unidad de actividad que tiene sentido para el usuario.

• Las siguientes reglas se aplican para contar ILF:– Los datos o información de control forman un grupo de

datos que satisfacen requerimientos del usuario.– Este grupo de datos debe ser mantenido dentro de la

frontera de la aplicación, mediante un proceso elemental.– Este grupo de datos no debe ser contado como un EIF.



• Cuando un grupo de datos ha sido identificado como un ILF, no puede ser contado como un EIF dentro de la misma aplicación, aunque sea usado como por referencia por otras transacciones, ni puede ser contado como un EIF durante un proyecto ampliado para esa aplicación.



• Algunos ejemplos de ILF:– Datos de transacciones de la aplicación, como registro

de inventarios, de capacitación de empleados, transacciones de tarjeta de crédito, ventas de productos, llamadas de clientes, cuentas por pagar.

– Niveles de seguridad y claves mantenidas dentro de la aplicación.

– Datos de auditoría mantenidos dentro de la aplicación.– Datos de ayuda mantenidos dentro de la aplicación.– Datos de edición mantenidos dentro de la aplicación.



– Parámetros de datos mantenidos dentro de la aplicación.– Archivos de error mantenidos dentro de la aplicación.– Respaldo forzoso o datos históricos mantenidos dentro

de la aplicación.

• Los siguientes ejemplos son ILF incorrectos:– Archivos temporales o versiones del mismo archivo.– Archivos de trabajo.– Archivos de ordenación.



– Vistas de archivos con datos extraídos de otros ILF o EIF para desplegarlos o imprimirlos.

– Archivos introducidos por causa tecnológica.– Indices o relaciones, a menos que contengan atributos no

llave mantenidos por separado.– Archivos mantenidos por otras aplicaciones y usados

únicamente para lectura o referencia.– Respaldo normal de datos.– Archivos que contengan transacciones abortadas, las

cuales no se mantienen por separado.



• Un EIF (External Interface File) es un grupo identificable por el usuario de datos lógicamente relacionados o de información de control usados por la aplicación pero mantenidos dentro de la frontera de una aplicación diferente.

• Las siguientes reglas se aplican para contar EIF:– El grupo de datos usado es mantenido

externamente a la aplicación que estamos contando.



– El grupo de datos no es mantenido por la aplicación que estamos contando.

– El grupo de datos identificado ha sido contado como ILF por otra aplicación.

– El grupo de datos no ha sido contado como ILF por la aplicación que estamos contando.



• Una vez contado un EIF ya no podemos volverlo a contar dentro de la misma aplicación, aunque sea usado por otras transacciones de la aplicación, o contenga distintos datos del mismo archivo.

• Los siguientes son ejemplos de EIF:– Datos extraídos o leídos de otras aplicaciones.– Datos de auditoría, ayuda o edición mantenidos

fuera de la aplicación.– Parámetros mantenidos fuera de la aplicación.



– Password o datos de seguridad mantenidos fuera de la aplicación.

– Archivos de errores mantenidos fuera de la aplicación.

– Respaldos o históricos obligatorios mantenidos fuera de la aplicación.

• Los siguientes son ejemplos de EIF incorrectos:– Archivos temporales o versiones de un archivo.– Archivos de trabajo.



– Datos recibidos de otra aplicación para mantener uno o varios ILF dentro de la aplicación que estamos contando (esto es considerado datos transaccionales).

– Datos mantenidos por la aplicación que estamos contando y usados en otra aplicación.

– Datos formateados y enviados por la aplicación que estamos contando a otras aplicaciones.

– Archivos de ordenamiento.



– Partes de archivo, o vistas de archivos, que contengan datos extraídos de EIF anteriormente contados.

– Archivos ocasionados por tecnologías.– Indices alternativos, relaciones o conexiones, a

menos que contengan campos no llave.



• Complejidad y contribución de ILF y EIF. El número de ILF y EIF, junto con su complejidad funcional para cada uno, determinan la contribución de las funciones de datos a la cuenta no ajustada de Puntos de Función. A cada ILF y EIF se le debe asignar una complejidad basado en el número de DET (Data Element Types) y RET (Record Element Types) asociados con el ILF y el EIF.



• Las reglas para contar DET:– Contar un DET por cada campo reconocible por

el usuario del ILF o EIF.– Contar un sólo DET para cada llave en ILF o EIF

necesaria para soportar relaciones– Contar un sólo DET para campos repetidos que

son idénticos en formato y sólo existen para seguir las múltiples ocurrencias del dato (como campos de ventas mensuales).



• Los RET son subgrupos de datos (opcionales u obligatorios) contenidos dentro del ILF o EIF. Los subgrupos se corresponden con relaciones padre-hijo en el diseño relacional.

• Las reglas para contar RET:– Cuente un RET para cada subgrupo del ILF o del

EIF.– Si no hay subgrupos, cuente el ILF o el EIF como

un RET.



• Las funciones transaccionales: EI (External Input), EO (External Output) y EQ (External inquiries), realizan los procesos de actualización, recuperaciones, salidas, etcétera. Cada una tiene su propia cuenta de Puntos de Función con su correspondiente matriz de complejidad.



• Una EI (External Input) es un proceso elemental que procesa datos o información de control que entra de fuera de la aplicación. Los datos procesados mantienen uno o más ILF. La información de control puede o no mantener un ILF.

• Para medir los datos o información de control que procesa una EI, sus juegos de reglas están separados.



• Las siguientes reglas de conteo se deben cumplir para los datos a ser procesados para poder ser contados como una EI: – Los datos deben ser recibidos de fuentes externas

a la aplicación.– Los datos en al menos un ILF deben ser

mantenidos mediante un proceso elemental de la aplicación.



• Las siguientes reglas de conteo se deben cumplir para la información de control a ser procesada para poder ser contadas como una EI: – La información de control debe ser recibida de

fuentes externas a la aplicación.– La información de control debe ser especificada

por el usuario para asegurar conformidad con los requerimientos de negocio de la aplicación.



• Para el proceso identificado, se debe aplicar alguna de las siguientes dos reglas:– La lógica de procesamiento debe ser única y

diferente de otros EI dentro de la aplicación. La lógica de procesamiento es definida como cualquiera de los requerimientos especificados por el usuario para completar un proceso elemental: Uso de ediciones, algoritmos o cálculos, o referencia al uso de un ILF o EIF.



– Los datos identificados son distintos de otras EI para la aplicación. La información de control procesada puede o no mantener un ILF.

• Algunos ejemplos de EI son:– Datos transaccionales usados para mantener un

ILF, como una venta, un recibo, una cita, una transferencia, etcétera.

– Entradas de pantalla que mantienen un ILF o proveen información de control.



– Mensajes de otras aplicaciones que requieren procesarlos.

– Entradas de batch que mantengan un ILF o provean información de control.

– Funciones de usuario que inicien control o introduzcan datos.

– Datos físicos que inicien procesamiento.– Mantenimiento de cualquier ILF, incluyendo

ayuda, parámetros, mensajes, etcétera.



– Archivos de transacciones de otras aplicaciones (estos pueden incluir múltiples transacciones de un tipo distinto que requieran un procesamiento único y separado, por ejemplo, ventas de contado y por tarjeta de crédito, en cuyo caso provienen de múltiples EI).

– Archivos de datos mantenidos en aplicaciones anteriores, que requieran un esfuerzo de conversión en un nuevo ILF.



• Los siguientes son ejemplos de EI erróneos:– La parte de entrada de una consulta.– Menús, usados para navegación o selección, pero

que no mantengan un ILF.– Pantallas de seguridad para firmarse en el

sistema, pero que no mantienen un ILF.– Formas distintas de invocar la misma lógica.– Lógica para llenar datos en la pantalla.



– Pantallas para refrescar o cancelar datos.– Respuestas a mensajes que le piden al usuario

confirmar alguna acción.– Datos pasados entre batch y línea en la misma

aplicación. No cruzan la frontera del sistema.– Datos pasados en cliente-servidor dentro de la

misma aplicación.



• La cuenta de los EI junto con la complejidad relativa de cada uno, determina la aportación de EI a la cuenta de Puntos de Función no ajustada. La complejidad de cada EI se basa de los números de DET (Data Element Type) y FTR (File Types Referenced) asociados con cada EI.

• Un FTR es la suma de los ILF o EIF mantenidos o referenciados.



• Reglas para contar DET en EI:– Contar un DET por cada campo que cruze la

frontera de la aplicación para completar un proceso elemental.

– Contar un DET para cada campo calculado por la aplicación y mantenido en un ILF.

– Hay que contar un sólo DET para todas las respuestas del sistema que indican que ocurrió un error durante el procesamiento.



– Contar un sólo DET para la capacidad de especificar la acción a ser tomada por un EI.

– Contar un DET para cada serie de línea de comando provocadas por la invocación de una tecla de función.

• Reglas para contar FTR:– Contar un FTR para cada ILF mantenido por el

proceso, o para cada EIF referenciado.



• Un EO (External Output) es un proceso elemental de la aplicación que genera datos o información de control que sale de la frontera de la aplicación.

• Las reglas para conteo de EO:– Los datos o la información de control deben salir

de la frontera de la aplicación.– Los datos o la información de control deben ser

enviados mediante un proceso elemental de la aplicación.



• Además, debe aplicar alguna de estas dos reglas:– La lógica de procesamiento debe ser única y

distinta de otros EO dentro de la aplicación. – Los campos identificados son distintos de otros

EO para la aplicación. • Algunos ejemplos de EO:

– Reportes que requieran el uso de algoritmos o cálculos.



• Transferencia de datos, de archivos o de mensajes a otras aplicaciones.

• Varios archivos de datos, cada uno producido mediante un proceso elemental separado y distinto, enviados a otra aplicación.

• Un reporte de conversión que informa del esfuerzo migrar datos como parte de un proyecto de desarrollo o de mejora. Debe ser incluido en la cuenta del proyecto, y no en la aplicación.



• Mensajes de información que no sean para manejo de errores ni mensajes de confirmación.

• Información calculada mostrada en una pantalla.• Gráficas, como gráficas de barras o de pastel.• Etiquetas de código de barras.• Respuestas calculadas regresadas por vía telefónica.• Información histórica en microfichas.



• Los siguientes son ejemplos de EO incorrectos:– Reportes idénticos con distintos valores, como

diferente título de departamento.– Sumario de campos contenidos en un reporte de

detalle (contado como otro EO).– Datos de cancelación o de repintar.– Reacomodo de un conjunto de datos sin otra

lógica de procesamiento.



– Datos que son leídos por otra aplicación de datos mantenidos por la aplicación que contamos.

– La parte de salida de una consulta.– Ayuda (contada como un EQ).– Procedimiento de salida de la aplicación.– Múltiples formas de invocar el mismo proceso de

salida.



– Datos idénticos enviados a más de una aplicación.

– Sentencias SQL ad-hoc escritas por el usuario.– Datos pasados entre el batch y la línea de la

aplicación. No cruzan la frontera.– Datos pasados entre el cliente y el servidor de la

aplicación. No cruzan la frontera.– Mensajes de error o de confirmación de acción.



• La cuenta física de EO, junto con la complejidad relativa de cada uno, determinan la contribución de EO a la cuenta no ajustada de PF. A cada EO se le asigna una complejidad basada en el número de DET (Data Element Type) y FTR (File Types Referenced) asociados con el EO.



• Reglas para contar DET en EO:– Contar un DET por cada campo que aparezca en

el EO.– No contar encabezados, títulos, número de

página o campos de fecha u hora.• Reglas para contar FTR en EO:

– Contar un FTR para cada ILF o EIF usado durante el procesamiento del EO.



• Un EQ es un proceso elemental de la aplicación, que está hecho de una combinación entrada-salida que produce una recuperación de datos. La parte de entrada es la información de control que especifica la lógica con la que se van a recuperar los datos. La parte de salida no contiene datos derivados. No se puede mantener a un ILF durante el proceso.



• Las siguientes reglas deben aplicar para contar un EQ:– La parte de entrada debe recibirse fuera de la

frontera de la aplicación.– La parte de salida debe salir de la frontera de la

aplicación.– Los datos deben recuperarse de uno o mas

ILF/EIF.



– La parte de salida no debe contener datos calculados.

– Entre la elaboración de la petición, la recuperación y la salida deben constituir un proceso elemental.

– El proceso debe ser autocontenido y dejar a la aplicación en un estado consistente.

– El proceso no debe actualizar un ILF.



• Para el proceso identificado como EQ, debe aplicar alguna de las dos siguientes reglas:– La lógica de procesamiento en la entrada o salida

debe ser única o diferente de otros EQ de la aplicación.

– Los datos en la entrada o en la salida deben ser diferentes de los datos de otros EQ.



• Algunos ejemplos de EQ:– Datos de transacciones que son recuperados de

uno o más ILF o EIF, y desplegados bajo un criterio de entrada.

– Funciones de usuario que se desplieguen en una vista o un browse.

– Recuperaciones de datos anteriores a un proceso de edición o eliminación.



– Vistas para firmarse en el sistema.– Cada nivel de la ayuda, por ejemplo, por sistema,

por campo y por pantalla, contando una vez cada nivel.

– Recuperaciones de datos mantenidos mediante una interfaz electrónica o telefónica.

– Recuperaciones de correo electrónico.– List Box para obtener datos mantenidos.



• Los siguientes son ejemplos de EQ erróneos:– Formas distintas de invocar la misma lógica.– Consultas que pueden ser accesadas de múltiples

pantallas o áreas de una aplicación (contar una sola vez).

– Menús usados para navegación que no recuperen datos mantenidos.

– Mensajes de error o de confirmación.



– Pantallas de firma que faciliten la entrada al usuario pero no involucren seguridad.

– Reacomodo de un conjunto de datos sin otra lógica de procesamiento.

– Respuestas a mensajes de confirmación de datos.– Datos que no son recuperados de datos

mantenidos. Por ejemplo, código alambrado.



– Sistema de documentación en línea.– Datos pasados entre la línea y el batch de la

misma aplicación. No traspasan la frontera de la aplicación.

– Datos pasados entre el cliente y el servidor de la misma aplicación. No traspasan la frontera de la aplicación.



• La cuenta de EQ, junto con la complejidad relativa de cada uno, determinan la contribución de EQ a la cuenta de PF no ajustados. La complejidad se asigna en base al número de DET (Data Element Type) como de FTR (Files Types Referenced) asociados tanto con la entrada como con la salida. La más alta de las dos complejidades es la complejidad del EQ.



• Las reglas para contar DET para la parte de entrada de un EQ:– Cuente un DET para cada campo que cruze la

frontera de la aplicación, en la parte de entrada de la consulta.

– Contar un DET por cada campo que esté en la condición para encontrar los registros adecuados.



– Contar un sólo DET para todas las respuestas del sistema a errores durante la consulta.

• Las reglas para contar DET para la parte de salida de un EQ:– Contar un DET para cada campo o llave que

cruce la frontera de la aplicación y aparezca en la salida de la consulta.

– No contar campos producto de la implementación o de la tecnología.



– No contar títulos ni encabezados.• Para contar los FTR, contar todos los ILF y EIF

leídos durante el procesamiento de la EQ. Esta misma regla aplica tanto a la parte de entrada como a la parte de salida de la EQ.



• La cuenta de Puntos de Función no ajustados es simplemente la suma de los Puntos de Función aportados por los ILF (Internal Logical Files), EIF (External Interface Files), EI (External Inputs), EO (External Outputs), y EQ (External Inquiries).



• En este paso es necesario calcular el VAF (Value Adjustment Factor), que se utiliza como un multiplicador de la Cuenta de Puntos de Función no ajustada, para calcular la Cuenta Ajustada de Puntos de Función.

• El VAF es calculado mediante la identificación del peso de las catorce GSC (General System Characteristics).



• Las GSC son:I. Comunicaciones de Datos.II. Procesamiento Distribuido de Datos.III. Desempeño.IV. Configuración fuertemente usada.V. Tasa de Transacciones.VI. Entrada de datos en línea.VII. Eficiencia de usuario final.



VIII. Actualización en línea.IX. Procesamiento complejo.X. Reusabilidad.XI. Facilidad de instalación.XII. Facilidad de operación.XIII. Sitios múltiples.XIV. Facilidad de cambio.



• Cada GSC debe ser evaluada en términos de su DI (Degree of Influence), en una escala de 0 a 5:0 No presente, o no tiene influencia.1 Influencia incidental.2 Influencia moderada.3 Influencia promedio.4 Influencia significativa.5 Fuerte influencia.



I. Comunicaciones de datos. La información de control y los datos son enviados o recibidos mediante comunicaciones. Todas las comunicaciones de datos necesitan algún tipo de protocolo.0 Aplicación es de procesamiento batch en una PC

stand alone.1 Aplicación es batch pero tiene entrada de datos

remota o impresión remota.



2 Aplicación es batch pero tiene entrada de datos remota e impresión remota.

3 Colecta de datos en línea o teleprocesamiento del front-end a un proceso batch o una consulta al sistema.

4 Más de un front-end, pero la aplicación soporta un sólo protocolo de teleprocesamiento.

5 Más de un front-end, pero la aplicación soporta varios protocolos de teleprocesamiento.



II. Procesamiento Distribuido de Datos. Unicamente aplicaciones distribuidas o en tiempo real deben tener valor en esta categoría. La mayoría de las aplicaciones tienen cero.0 La aplicación no tiene transferencia de datos o

procesamiento de funciones entre sistemas componentes.

1 La aplicación prepara datos para el usuario final mediante hojas electrónicas o DBMS.



2 Existen datos que son preparados para transferencia, transferidos y procesados en otro componente del sistema (no el usuario final).

3 El procesamiento distribuido y la transferencia de datos es en línea y en una sola dirección.

4 El procesamiento distribuido y la transferencia de datos es en línea y en ambas direcciones.

5 El procesamiento de funciones es hecho en el componente más apropiado del sistema.



III. Desempeño. 0 No hay requerimientos especiales de desempeño

establecidos por el usuario.1 Los requerimientos de desempeño se establecen

y revisan, pero no son necesarias acciones especiales.

2 Tiempo de respuesta o volumen es crítico durante horas pico. No se requiere un diseño especial de utilización de la CPU.



3 Tiempo de respuesta o volumen es crítico durante todas las horas de negocio. No es necesario un diseño especial de uso de CPU.

4 Los requerimientos de desempeño son tan fuertes que requieren análisis del desempeño de tareas en la fase de diseño.

5 Adicionalmente, se usan herramientas de análisis de desempeño en el diseño, desarrollo y/o implementación para cumplir con tiempos.



IV. Configuración fuertemente usada.0 No hay restricciones de operación explícitas o

implícitas.1 Existen restricciones operacionales, pero son

menos restrictivas que aplicaciones normales.2 Existen algunas consideraciones de seguridad o

velocidad.3 Hay requerimientos específicos de procesador

para ciertas partes de la aplicación.



4 Son establecidas restricciones de operación que requieren limitaciones especiales en el procesador central o en un procesador dedicado.

5 Adicionalmente, hay ciertas limitaciones de la aplicación en componentes distribuidos en el sistema.



V. Tasa de Transacciones. 0 No se anticipa un período pico de transacciones.1 Se anticipa un pico de transacciones (mensual,

trimestral, semestral o anual).2 Se anticipa un pico de transacciones semanal.3 Se anticipa un pico de transacciones diario.



4 Altas tasas de transacciones requieren tareas de análisis de desempeño en la fase de diseño.

5 Altas tasas de transacciones requieren herramientas de análisis de desempeño en las fases diseño, desarrollo y/o instalación.



VI. Entrada de datos en línea.0 Todas las transacciones son batch.1 Del 1% al 7% de las transacciones son en línea.2 Del 8% al 15% son en línea.3 Del 16% al 23% son en línea.4 Del 24% al 30% son en línea.5 Más del 30% son en línea.



VII. Eficiencia de usuario final. Las funciones de línea entregadas enfatizan la eficiencia de usuario final. Estas funciones incluyen: – Ayudas de navegación.– Menús.– Documentación o ayuda en línea.– Movimiento automático del cursor.– Scrolling.– Impresión remota (para transacciones en línea).



– Uso de teclas de función.– Ejecución de trabajos batch mediante transacciones en

línea.– Selección de cursores.– Alto uso de colores, negritas, subrayado y otros

indicadores de vídeo.– Interfaz de ratón.– Copia dura de documentación de usuario mediante

transacciones en línea.– Ventanas pop-up.



– Tan pocas pantallas como sea posible para cumplir una función de negocio.

– Soporte bilingüe (cuenta por cuatro).– Soporte multilingüe (cuenta por seis).

• 0 Ningún ítem.• 1 De uno a tres ítems.• 2 De 4 a 5 ítems.• 3 Seis o más ítems, pero no hay requerimientos específicos

del usuario con respecto a la eficiencia.



• 4 Seis o más ítems, y los requerimientos fijados para Eficiencia de usuario final son tan fuertes que requieren tareas de diseño para incluir factores humanos.

• 5 Seis o más ítems, y los requerimientos fijados para Eficiencia de usuario final son tan fuertes que requieren uso de procesos y herramientas especiales para demostrar que los objetivos se alcancen.



VIII. Actualización en línea. La aplicación provee actualización en línea de ILF.0 Ninguna.1 Actualización en línea de uno a tres archivos de

control. El volumen de actualización es bajo, y la recuperación es sencilla.

2 Actualización en línea de cuatro o más archivos de control. El volumen de actualización es bajo, y la recuperación es sencilla.



3 Actualizaciones en línea mayores de ILF.4 Adicionalmente, es esencial la protección contra

pérdida de datos, que ha sido diseñada y programada en el sistema.

5 Adicionalmente, altos volúmenes involucran consideraciones de costo en el proceso de recuperación. Se implementan procedimientos altamente automatizados de recuperaciones, con un mínimo de intervención de operación.



IX. Procesamiento complejo. Es característico de la aplicación. Incluye lo siguiente:– Control sensible al usuario (por ejemplo, procesos de

auditoría) y/o procesamiento específico para niveles de seguridad.

– Hay mucho procesamiento que resulta de excepciones por transacciones incompletas.

– Procesamiento complejo para manejar varias posibilidades de entrada/salida, como multimedia o independencia de dispositivos.



– Alto procesamiento lógico.– Alto procesamiento matemático.

• Estas características se miden como sigue:0 Ninguna de ellas.1 Cualquiera de ellas.2 Dos de ellas.3 Tres de ellas.4 Cuatro de ellas.5 Todas ellas.



X. Reusabilidad. La aplicación y el código de la aplicación ha sido especialmente diseñado, desarrollado y soportado para ser reutilizado en otras aplicaciones.0 No hay código reusable.1 Código reusable es usado dentro de la aplicación.2 Menos del 10% de la aplicación es código

reusable.



3 Más del 10% de la aplicación es código reusable.4 La aplicación fue específicamente empacada y/o

documentada para ser fácilmente reusable, y se adaptó el código fuente para ser general.

5 La aplicación fue específicamente empacada y/o documentada para ser fácilmente reusable, y se adaptó el código fuente para ser general, lo que implica un mantenimiento parametrizado.



XI. Facilidad de instalación.0 No hay consideraciones especiales establecidas por el

usuario, y no se requiere un setup especial para la instalación.

1 No hay consideraciones especiales establecidas por el usuario, pero se requiere un setup especial para la instalación.



2 Requerimientos de conversión e instalación fueron establecidos por el usuario, y fueron entregadas y probadas guías de instalación y conversión. No se considera importante la conversión en el proyecto.

3 Como en el anterior, pero sí se considera importante la conversión en el proyecto.

4 Como en (2), pero se entregan y prueban herramientas automáticas de instalación y conversión.

5 Como en (3), pero se entregan y prueban herramientas automáticas de instalación y conversión.



XII. Facilidad de operación.0 No hay consideraciones operacionales especiales

establecidas por el usuario, más que los procedimientos de respaldo.

1-4 Seleccionar los siguientes ítems para la aplicación. Cada ítem vale por uno, excepto que se enuncie lo contrario.

• Se proveen procesos de comienzo, respaldo y recuperación, con intervención del operador.



• Se proveen procesos de comienzo, respaldo y recuperación, sin intervención del operador (cuenta por dos).

• La aplicación minimiza la necesidad de montaje de cintas magnéticas.

• La aplicación minimiza la necesidad de manejo de papel.

5 La aplicación se diseña para trabajo sin operador, del comienzo al fin de la aplicación. Hay recuperación de errores automática.



XIII. Sitios múltiples. La aplicación ha sido especialmente diseñada para instalarse en múltiples lugares para múltiples organizaciones.0 Instalación en un solo sitio.1 La necesidad de múltiples sitios fue considerada en el

diseño, y la aplicación fue diseñada para operar únicamente bajo un ambiente de hardware y software.

2 La necesidad de múltiples sitios fue considerada en el diseño, y la aplicación fue diseñada para operar sólo bajo ambientes similares de hardware y software.



3 La necesidad de múltiples sitios fue considerada en el diseño, y la aplicación fue diseñada para operar bajo distintos ambientes de hardware y software.

4 Son provistos y probados tanto el plan de soporte como la documentación para soportar la aplicación en múltiples sitios, y la aplicación es desarrollada como en (1) o en (2).

5 Son provistos y probados tanto el plan de soporte como la documentación para soportar la aplicación en múltiples sitios, y la aplicación es desarrollada como en (3).



XIV. Facilidad de cambio. La aplicación ha sido específicamente diseñada, desarrollada y soportada para facilitar el cambio.0 No hay requerimientos especiales del usuario

para diseñar la aplicación para minimizar o facilitar el cambio.

1-5 Seleccione cuáles de los siguientes ítems aplican:



– Se proveen facilidades para reportes o consultas flexibles, para manejar peticiones sencillas, por ejemplo, lógica and/or para un sólo ILF.

– Se proveen facilidades para reportes o consultas flexibles, para manejar peticiones de complejidad promedio, por ejemplo, lógica and/or para más de un ILF (cuenta por dos).

– Se proveen facilidades para reportes o consultas flexibles, para manejar peticiones de complejidad grande, por ejemplo, lógica and/or para más de un ILF (cuenta por tres).



– Se guardan datos de control en tablas que son mantenidas por el usuario con procesos en línea, pero los cambios tienen efectos hasta el día siguiente.

– Se guardan datos de control en tablas que son mantenidas por el usuario con procesos en línea, pero los cambios tienen efecto inmediatamente (cuenta por dos).



• Las catorce GSC (General System Characteristic) se representan en el VAF (Value Adjustment Factor). Cuando es aplicado, el VAF ajusta la cuenta de Puntos de Función no ajustada +/- 35% para producir la Cuenta Ajustada de Puntos de Función.



• Como regla general, esperamos que una aplicación batch sencilla tenga un TDI (Total Degree of Influence) menor a 15, una aplicación batch compleja entre 15 y 30, una aplicación interactiva entre 30 y 45, y un sistema en tiempo real, de telecomunicaciones o de control de procesos, entre 30 y 60.



• Para calcular el VAF se siguen estos pasos:– Evaluar los catorce GSC, determinando el DI

(Degree of Influence) para cada uno.– Añadir los DI de las catorce GSC, para producir

el TDI (Total Degree of Influence).– Usar el TDI de la aplicación en la siguiente

ecuación:VAF = (TDI * 0.01) + 0.65



• Cuenta de Puntos de Función para proyectos de desarrollo. Esta cuenta tiene tres componentes:– Cuenta de Puntos de Función No Ajustados: la

suma de ILF, EIF, EI, EO, EQ.– El VAF (Value Adjustment Factor).



– Funcionalidad de conversión al transferir datos anteriores a los nuevos ILF mediante software (esto consiste a menudo en abrir los viejos archivos (contar como EI o entrada de datos a los ya contados nuevos archivos ILF)) y posiblemente un EO para un reporte de conversión.



• La fórmula para esta cuenta es:DFP = (UFP + CFP) * VAF– DFP. Development Project Function Point

Count.– UFP. Unadjusted Function Point.– CFP. Conversion Function Point.– VAF. Value Adjustment Factor.



• Cuenta de Puntos de Función para proyectos de Mejora. La fórmula es:EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL *

VAFB)– EFP. Enhancement Project Function Point Count.– ADD. Cuenta de Puntos de Función No Ajustados de

aquellas funciones añadidas por la mejora.– CFP. Conversion Function Points.– VAFA. Value Adjustment Factor posterior a la

modificación del proyecto.



– CHGA. Puntos de Función No Ajustados para aquellas funciones modificadas por la mejora del proyecto (Esto refleja el valor de las funciones después de la modificación, no sólo los campos añadidos por la modificación).

– DEL. Cuenta de Puntos de Función No Ajustados para aquellas funciones que fueron borradas del proyecto mejorado.

– VAFB. Value Adjustment Factor de la aplicación antes del proyecto de mejora.



• Cuenta de Puntos de Función para aplicaciones. Hay dos momentos distintos en los que se puede realizar esta cuenta:– Cuando la aplicación se desarrolla por primera

vez.– Cuando un proyecto de mejora ha cambiado el

valor de la funcionalidad de la aplicación.



• La AFP (Application Function Point) después de una mejora se calcula con la ecuación:AFP = [(UFPB + ADD + CHGA) - (CHGB + DEL)] *

VAFA– UFPB. Unadjusted Function Point Before the

Enhancement Proyect.– ADD. Cuenta de Puntos de Función No Ajustados de

aquellas funciones añadidas por la mejora.– VAFA. Value Adjustment Factor posterior a la

modificación del proyecto.



– CHGA. Puntos de Función No Ajustados para aquellas funciones modificadas por la mejora del proyecto (Esto refleja el valor de las funciones antes de la modificación).

– CHGB. Puntos de Función No Ajustados para aquellas funciones modificadas por la mejora del proyecto (Esto refleja el valor de las funciones después de la modificación).

– DEL. Cuenta de Puntos de Función No Ajustados para aquellas funciones que fueron borradas del proyecto mejorado.


Reglas de conteo en GUI

• Hay varias interfaces gráficas en el mercado: Windows, Presentation Manager, System 7, Open Look, Motif y Next.

• Para ellas, se ha ampliado el modelo de Puntos de Función.

1. Se conservan los ILF, EIF, EI, EO y EQ. Cada uno de ellos tendrá su propia cuenta basada en su matriz de complejidad.



2. Las funciones del usuario que crean, actualicen o borren datos serán contadas como External Inputs. Hay que asegurarse de que se mantienen datos, y no es sólo una ventana. Las funciones Save y Save As normalmente proveen las funciones para añadir y cambiar. No contar la misma función varias veces cuando distintas teclas realicen la misma función.

3. La selección de un elemento de un List Box, normalmente es un DET sobre un EI y no un EI separado.



4. Las funciones del usuario que recuperan y extraen datos basándose en una selección y petición del usuario, para desplegar el resultado, serán contadas como EQ; puede ser un List Box o de un File Open sin datos calculados.

5. Las funciones de usuario que incluyen cálculo para el despliegue de datos, serán contadas como external outputs. Esto incluye el File Open.

6. Usualmente las funciones de impresión crean copias impresas del despliegue y deberán ser contadas como otros external inquiries (sin datos calculados) o external outputs (con datos calculados).



7. Las instrucciones para imprimir pueden, sin embargo, proveer funcionalidad de negocio que debería ser contada como un External Input.

8. La funcionalidad automáticamente provista por Windows o el sistema operativo, y no por la aplicación, no debería ser contada, como maximizar o minimizar una ventana, a menos que se esté midiendo la funcionalidad del Windows.

9. Los menús, iconos, barras de desplazamientos y otros dispositivos de navegación no deben ser contados a menos que regresen datos recuperados por el usuario.



10. Instrucciones de salida son también de tipo de navegación, para regresar el control al sistema o a un programa, y no deben ser contados.

11. Selecciones de un menú (barra de herramientas, pull-down, pop-up, iconos o botones) pueden servir como la parte de entrada de un EQ o una tecla para realizar un EI o seleccionar un EO.

12. Las listas de selección, serán contadas como EQ cuando ellas recuperen y desplieguen datos; la selección de uno de los ítems desplegados por point and click usualmente no será una función, sino un DET.



13. Un slider o un radio button cuenta como un DET en un EI o en la parte de entrada de un EQ, y no como un DET para cada opción, sin embargo, si se aceptan varias selecciones, como en check box, entonces cada opción es un DET.

14. Los mensajes que no sean de errores o de confirmación, como de estado, de información o de advertencia, son usualmente EO.

15. Las EI de control deberían ser contadas cuando aseguren conformidad con funcionalidad de negocio.

16. La ayuda se cuenta normalmente, con un EQ por nivel de ayuda por aplicación.


Grupo de SQA

• El grupo de SQA es el conjunto de individuos (tanto perfiles administrativos como técnicos) que planean e implementan las actividades de aseguramiento de calidad del proyecto para garantizar que se siguen los pasos del proceso y cumplen los estándares.

• El SQA debe tener un canal de comunicación con la dirección, independiente del líder de proyecto, o del SIG.


Grupo de SQA

• La planeación y ejecución de las pruebas de aceptación de un sistema debe ser hecha de forma independiente a los desarrolladores. La razón es técnica: tal independencia garantiza que los probadores no estén contaminados por las decisiones de diseño e implementación hechas por los desarrolladores.


Grupo de SQA

• Es necesario que el grupo de SQA pueda realizar sus trabajos sin ser influenciados por la planeación del proyecto y las presiones de costos. Este grupo debe ser visto como los ojos y los oídos de la dirección.

• Debido a que puede haber conflicto de intereses para que un grupo SQA se audite a sí mismo, lo conveniente es que expertos independientes realicen esta actividad.


Grupo de SQA

• La capacitación necesaria para un líder de revisiones periódicas (o revisiones técnicas formales) incluye:– Los objetivos, principios y métodos de las

revisiones periódicas.– Planear y organizar una revisión periódica.– Evaluar la rapidez y criterios de terminación para

una revisión periódica.– Conducir y facilitar una revisión periódica.


Grupo de SQA

– Reportar los resultados de una revisión periódica.– Afinar y confirmar el trabajo de las acciones

originadas por una revisión periódica.– Colectar y reportar los datos requeridos para las

revisiones periódicas.


Grupo de SQA

• La capacitación necesaria para un revisor de revisiones periódicas (o revisiones técnicas formales) incluye:– Tipos de revisiones periódicas (p. ej., de

requerimientos, de diseño del software, de código y de procedimientos de prueba de software).

– Los objetivos, principios y métodos de las revisiones periódicas.


Grupo de SQA

– Roles de revisores.– Estimar el esfuerzo para preparar y participar en

revisiones periódicas.


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 de la codificación.

• No es raro que una fábrica de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en la prueba.

• En casos extremos la prueba puede costar de tres a cinco veces más que el resto de pasos juntos.


Prueba

• Un efecto importante de la prueba es que da una mejor comprensión de los productos del desarrollo de software y de cómo se pueden prevenir los defectos.

• La prueba se debe centrar en el producto, y no en el productor. Tampoco debe tomarse en cuenta en la evaluación del desempeño de una persona. Lo peor que podemos hacer es conducir la prueba hacia un ambiente negativo o de recriminación.


Prueba

• Objetivos de la prueba:– La prueba es un proceso de ejecución de un

programa con la intención de descubrir un error.– Un buen caso de prueba es aquel que tiene una

alta probabilidad de mostrar un error no descubierto hasta entonces.

– Una prueba tiene éxito si descubre un error no detectado hasta entonces.


Prueba

• La prueba no puede asegurar la ausencia de defectos, sólo puede demostrar que existen defectos en el software.

• Hay un mito en los errores, y es que existen porque somos malos en lo que hacemos, y lo tediosa que es la prueba es un justo castigo a nuestros errores.


Prueba

• Principios para la prueba del software:– A todas las pruebas se les debería poder hacer un

seguimiento hasta los requisitos del cliente.– Las pruebas deben planificarse mucho antes de

que empiecen.– El 80% de todos los errores descubiertos durante

las pruebas surgen al hacer un seguimiento de sólo el 20% de todos los módulos del programa.


Prueba

– Las pruebas deberían empezar por lo pequeño y progresar hacia lo grande.

– No son posibles las pruebas exhaustivas.– Para ser más efectivas, las pruebas deberían ser

conducidas por un equipo independiente.– Los criterios para la prueba deberían ser

revisados por los clientes o por los usuarios finales.


Prueba

• La elaboración de una prueba se base en:– El nivel de prueba a realizar.– La estrategia de prueba seleccionada.– La cobertura de prueba a realizar.

• Los niveles de prueba incluyen:– Prueba de unidad.– Prueba de integración.– Prueba de sistema.– Prueba de aceptación.


Prueba

• Las estrategias de prueba incluyen:– Funcional (caja negra).– Estructural (caja blanca).– Estadística (regresión).

• La cobertura de la prueba incluye:– Cobertura de sentencia.– Cobertura de trayectoria.– Cobertura de rama.– Revisión de uso.


Prueba

• Prueba de Caja negra. Conociendo la función específica para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestren que cada función es completamente operativa, y al mismo tiempo buscando errores en cada función.


Prueba

• Prueba de Caja blanca. Conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que todas las piezas encajan, o sea, que la operación interna se ajusta a las especificaciones y que todos los componentes se han comprobado de forma adecuada.


Prueba

• Los resultados de la prueba se deben almacenan en una base de datos, que puede contener:– Descripción del defecto.– Categoría del defecto.– Severidad del defecto.– Unidades conteniendo el defecto.– Unidades afectadas por el defecto.– Actividad donde el defecto fue introducido.


Prueba

– Tipo de revisión que identificó el defecto.– Descripción del escenario siendo ejecutado

cuando se identificó el defecto.– Resultado esperado y resultado encontrado que

identificó el defecto.– Tiempo invertido en encontrar el defecto.– Tiempo de trabajo por corregir el defecto.– Fecha de detección del defecto.


Prueba

– Fecha de corrección del defecto.– Tamaño de la unidad que contiene el defecto.– Duración de la reunión de revisión.– Número de defectos encontrados en la reunión

de revisión.


Bibliografía

• Garmus, David; Herron, David. Measuring the Sortware Process. A Practical Guide to Funcional Measurements. First Edition. Yourdon Press, USA, 1996. 234p.

• Konrad, Michael; Paulk, Mark; An Overview of SPICE’s Model for Process Management. Proceedings of the Fifth International Conference on Software Quality. Austin, Texas, October 1995. pp. 291-301.

• McConnell, Steve. Desarrollo y gestión de proyectos informáticos. McGraw Hill. 1996.


Bibliografía

• Moore, James W. Software Engineering Standards, a User’s Road Map. IEEE Computer Society, USA. 1998. 298p.

• Paulk, Mark et. al. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, U.S.A. 1995. 442p.

• Paulk, Mark; Konrad, Michael E.; García, Suzanne; CMM Versus SPICE Architecture. Software Process Newsletter IEEE (3):1995, pp 7-11.

• Pressman, Roger. Ingeniería de software. Un enfoque práctico. Cuarta Edición. McGraw Hill. España, 1997.


Bibliografía

• Rothery, Brian. ISO 9000, Segunda Edición. Editorial Panorama, México, 1998. 284p.

• Sanders, Joc; Curran, Eugene. Sofware Quality. ACM Press. Great Britain, 1995, 180p.

• Sommerville, Ian. Software Engineering. Fifth Edition. Addison-Wesley, 1996.

• Tingey, Michael O. Comparing ISO 9000, Malcolm Baldrige, and the SEI CMM for Software. Prentice Hall, 1997.

• Zahran, Sami. Software Process Improvement. Addison Wesley, 1998.

Mejoramiento del Proceso de Software

Documents

Transcript of Mejoramiento del Proceso de Software