la calidad del software como fase importante en el
TRANSCRIPT
1
“LA CALIDAD DEL SOFTWARE COMO FASE IMPORTANTE EN EL PROCESO DE PRODUCCION.”
TESIS
QUE PARA OBTENER EL TITULO DE
LICENCIADO EN SISTEMAS DE INFORMACION
ADMINISTRATIVA
Presenta
MAYRA ANGELICA GARCIA CASTILLO
Guaymas, Sonora; MAYO 2012
2
AGRADECIMIENTO Y DEDICATORIAS.
AGRADEZCO.
Agradezco a mi entorno que me dio las facultades para pensar en mi futuro y sobre
todo en mis padres fieles, amigos, acompañantes y consejeros que si no fuera por
sus sacrificios no estaría en estos momentos.
Al Mtro. Roberto Limón Ulloa, maestro, ya que su asesoramiento me estimulo para
seguir creciendo intelectualmente, y por haberme ayudado cuando más lo necesite
para sacar adelante mi trabajo, muchas gracias maestro, ya que usted fue una fuente
muy importante para la preparación de este trabajo.
Al Mtro. Marco Antonio Tellechea Rodriguez, maestro y coordinador, me ayudo
bastante a lo largo de mi carrera, dándome consejos claros y exactos para cada
situación que se presentaba, siempre queriendo lo mejor para mí y mis compañeros,
muchas gracias maestro.
Gracia a la vida que tengo y a mis amigos que más quiero si no fuera por ellos mis
sueños no lo habría cumplido.
No tengo más palabras para seguir diciendo el gran regocijo que me da poder
terminar esta carrera en donde profesores y compañeros dejan parte de su vida, para
dar vida a las ilusiones de niña y que hoy en día se hace realidad.
Solo sé que este camino es solo el comienzo de una gran historia. Gracias a mi
familia.
Muchas gracias a todos.
ii
3
Dedicatorias .
A dios: Este trabajo lo dedico especialmente a Dios, por todas las bendiciones que de Él he
recibido, por permitirme estar con mi familia y amigos, personas que hoy son fuente
de mi inspiración para seguir adelante día con día. En especial a mi madre, ya que
ella ha sido un apoyo muy importante para mi y mis hermanos, por ellos he logrado
llegar hasta donde me lo he propuesto.
A mi madre: Margarita García Casti l lo . La mujer que me apoyo todos estos años, por su infinito amor, cariño, comprensión y
apoyo. Por acompañarme en los buenos y malos momentos, por ayudarme a que
este momento llegara. Porque me alimentaste de fe, me nutriste de optimismo,
siempre estuviste a mi lado cuando necesite de un consejo, a ti que me ayudaste a
ver posible, todo aquello que para mi parecía imposible te amo mami. Muchas
gracias por todo.
Todo lo que soy se la debo a mi mamá. Atribuyo todos mis éxitos en esta vida a la
enseñanza moral, intelectual y física que recibí de mi mama que haberme enseñado
que las cosas del mundo son mejor si se obtiene con esfuerzo y mucho empeño, sin
importar los que nos cueste siempre va a tener un buen resultado porque son fruto
de nuestra dedicación constante.
A mis hermanos María Antonieta Martínez, Jose de Jesús
Martínez, Delia Margarita Martínez y Juan Carlos
Martínez.
iii
4
Por su apoyo y confianza, tratando de ser una mejor persona como ellos, y superar
una meta en mi vida acompañada de estas personas tan bellas que son mis
hermanos.
RESUMEN.
Desde los albores de a disciplina de la calidad del software, queda patente la
dificultad para que los artefactos generados al alcance de un nivel de calidad optimo
dentro de unos límites de tiempo y costo. Dada la naturaleza lógica del producto, se
asume que la calidad de un software depende sobre la manera y el proceso usado
para desarrollarlo. Los modelos de evaluación y mejora de procesos y su
estandarización, han tomado un papel determinante en la identificación, integración,
medición y optimización de las buenas practica existentes en la organización y el
desarrollo del software. El presente trabajo pretende repasar aquellos modelos de
mayor difusión (CMMI), centrándose en su evolución y estructura, aspectos clave,
aplicando comparativas y comentando el estado actual de cada estándar. Por ultimo
intentaremos destacar las aportaciones del modelado y simulación del proceso del
software con sistemas dinámicos como herramientas de mejora de los procesos de
una organización dentro de los estándares.
Cada vez con más frecuencia se escuchan las siglas CMMI alrededor del desarrollo y
mantenimiento del software. Pero, ¿Qué es realmente CMMI?
En esta sesión se trata de dar respuesta a estos interrogantes, comenzando con una
situación que introduce el contexto, problemas y desafíos que actualmente afectan al
mundo del desarrollo y mantenimiento del software. Como aplicación clara del marco
dinámico, se propone su utilización en el entorno del modelo CMMI, como
herramienta de soporte para la evolución entre los diferentes niveles de madurez.
iv
5
INDICE PÁGINA
AGRADECIMIENTOS II
DEDICATORIAS III
RESUMEN
IV
ÍNDICE
V
INDICE DE FIGURAS
IX
1. INTRODUCCIÓN 10
1.1 Antecedentes 11
1.2 Planteamiento del problema 11
1.2 Justificación 12
1.3 Objetivo 13
2. DESARROLLO DEL TRABAJO 14
2.1 ¿Qué es calidad? 15
2.2 ¿Qué es calidad del software? 16
2.2.1 El aseguramiento de calidad del software se diseña 17
Para cada aplicación antes de comenzar a desarrollarla
v
6
2.2.2 La garantía en el producto tiene calidad 17
2.2.3 El aseguramiento de calidad del software 17
2.2.4 Inspecciones técnicas formales en todos los pasos del proceso de
desarrollo del software 17
2.2.5 Estrategias de prueba multiescala. Control de la documentación
del software y de los cambios realizados. 17
2.2.6 Procedimientos para ajustarse a los estándares 17
2.2.7 Mecanismos de medida (métricas). Registro de auditorías y
realización de informes. 17
2.3 Algunos métodos del aseguramiento del software: 17
2.3.1 Revisiones técnicas y de gestión 17
2.3.2 Inspección 17
2.3.3 Pruebas 17
2.3.4 Requisitos implícitos o expectativas 17
2.4 El principio tecnológico define las técnicas a utilizar en el proceso de
desarrollo del software 18
2.5 Algunos conceptos de software 18
2.6 Desarrollo del software 19
2.6.1 Abstract 19
2.6.2 Fundamentos del análisis de Requerimientos 19
2.6.3 Análisis de Requerimientos 20
2.6.4 Tareas de Análisis 21
vi
7
2.6.5 Principios de Análisis 24
2.6.6 El dominio de la Información 24
2.6.7 Partición 26
2.6.8 Visiones lógicas y físicas 26
2.6.9 Construcción de prototipos de software 27
2.6.10 Un escenario para la construcción de prototipos 27
2.6.11 Especificaciones 29
2.6.12 Principios de especificación 30
2.6.13 Métodos de análisis de requerimientos 33
2.6.14 Metodologías de análisis de requerimientos 34
2.6.15 Métodos de análisis orientados al flujo de datos 35
2.6.16 Diagramas de flujos de datos 36
2.6.17 Diccionario de datos 36
2.6.18 Descripciones funcionales 37
2.6.19 Métodos orientados a la estructura de datos 38
2.6.20 Desarrollo de sistemas de Jackson 38
2.6.21 Requerimientos de las bases de datos 39
2.6.22 Características de las bases de datos 40
2.7 El modelo CMM 40
2.8 Niveles del CMM 41
vii
vi
vii vii
8
2.9 Beneficios de la implantación del modelos CMM 42
2.9.1 Errores del ciclo de vida del software
2.9.2 Reducción de las desviaciones en plazo de los proyectos 43
2.9.3 Mayor tolerancia al cambio e incremento de la capacidad de
adopción y adaptación de nuevas tecnologías.
43
2.9.4 Mejora en la rapidez y efectividad de respuesta ante exigencias
del negocio. 43
2.9.5 Mejora en la colaboración y comunicación 43
2.9.6 Mitigación de riesgo 43
2.9.7 Reducción de los costes del proyecto 43
2.10 Implementación en la organización 43
2.11 Componentes requeridos 46
2.12 Componentes esperados 46
2.13 Componentes informativos 47
III CONCLUSIONES 48
3.1 Conclusión 48
BIBLIOGRAFIAS 50
viii
9
INDICES DE FIGURAS.
Figura Num.1 la gestión y control de calidad del software
19
Figura Num.2 Los análisis de requerimiento
22
Figura Num.3 El análisis de requerimientos por áreas
23
Figura Num.4 Dominio de la información
26
Figura Num.5 Representación del flujo de la información
36
Figura Num.6 Diagrama de flujos de datos
37
Figura Num.7 Los niveles de CMM
43
Figura Num.8 Representación continua del modelo CMM
45
ix
10
I INTRODUCCION.
Uno de los problemas que se afrontan actualmente en la esfera de la computación es
la calidad del software. Desde los 70´s, este tema ha sido motivo de preocupación
para especialistas, ingenieros, investigadores y comercializadores de software.
La calidad del software es un conjunto de cualidades que lo caracterizan y que
determinan su utilidad y existencia. La calidad es sinónimo de eficiencia,
confiabilidad, corrección, mantenibilida, portabilidad, usabilidad, seguridad e
integridad.
La obtención de un software con calidad implica la utilización de metodologías o
procedimientos estándares para el análisis, diseño, programación y prueba del
software que permitan uniformar la filosofía de trabajo, para lograr una mayor
confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
11
productividad, tanto para la labor de desarrollo para el control de la calidad del
software
Lograr el éxito en la producción del software es hacerlo con calidad y demostrar su
buena calidad. Para logro de esto es el presente trabajo se muestra el modelo de
mejora o evaluación de procesos de desarrollo y mantenimiento de sistemas y
productos de software, este conocido como CMMI (Capability Maturity Model
Integration – Modelo de Madurez de Capacidad Integrada)
1.1 ANTECENDENTES.
El nivel de competitividad de las empresas de las empresas se fundamenta en su
capacidad tecnológica y de innovación se mide de acuerdo al proceso de evolución
en la competitividad de las empresas.
El proceso evolutivo que posiciona el nivel de competitividad de las empresas, se
basa en sus prácticas establecidas en todas sus áreas y departamentos, de acuerdo
a características que reflejan sus capacidades operativas y tecnológicas.
La incorporación de nueva tecnología de procesos de producción de las empresas,
redunda básicamente en el incremento de la productividad y en la reducción de
costos, de tal manera que ello se reduce directamente en un aumentó en la posición
competitiva de la empresa. Para elevar la competitividad y la innovación de las
empresas se tiene que incrementar la inversión en actividades de investigación y
desarrollo, lo que incluye la administración y gestión tecnológica, formación de
personal, servicio tecnológico y sistemas de calidad necesarios.
Los sistemas de calidad han pasado se simples mecanismos para asegurar la
repetición eficiente de operaciones a plataformas cobre las cuales se han establecido
sistemas de administración por tecnología. Esto ha permitido a las empresas
progresar hacia sistemas de “ero defectos” y ocuparse en originar el cambio en sus
nichos de mercado.
Por este motivo existen en el mundo varios modelos de mejora de procesos de
software, sin embargo todos coinciden en que el objetivo primordial que consiste en
12
incrementar la productividad de las empresas y de que las personas cuenten con la
mejor tecnología o un buen software, a través de prácticas para el mejoramiento
continuo en la calidad del software.
1.2 Planteamiento del problema.
El interés del hombre por obtener satis factores adecuados ha existido siempre, de
igual forma, en todo momento, se han buscado la calidad y los bajos costos, sin
embargo las estrategias para alcanzarlos se han modificado continuamente a las
condiciones cambiantes de la sociedad. La calidad de un producto o de un sistema
en su mayoría parte como consecuencia de la calidad de os procesos empleados en
su desarrollo y mantenimiento.
En el proceso de productividad y en los productos de software es una existencia
creciente, dado que cada vez es más amplio el uso de software en procesos que son
críticos para las organizaciones. Por este motivo de exigencia se tiene que conocer
¿Cómo obtener un software con calidad?
1.3 Justificación.
En 1968, se celebraba en Garmish Alemania la primera conferencia del software en
el cual se hablo de la calidad en el proceso de producción y en los productos de
software es una exigencia creciente, dado que cada vez es más amplio el uso de
software en proceso que son críticos para la organizaciones.
Desde los albores de las disciplinas del software, queda patente a dificultad para que
los artefactos generados alcancen un nivel de calidad optimo dentro de los límites de
tiempo y costo. Dada la naturaleza lógica del producto, se asume que la calidad de
un sistema de software depende de sobremanera de la calidad del proceso usando
13
para desarrollarlo. Los modelos de evacuación y mejora de procesos y su
estandarización, han tomado un papel determinante en la identificación, integración,
medición y optimización de las buenas prácticas existentes en la organización y el
desarrollo del software.
No se puede medir la calidad de software de forma correcta debido a su naturaleza,
la certificación se da a los procesos, la correcta consecución de los mismos
garantizaría un buen software. No se puede medir al software como tal, sino los
atributos que la conforman, tales métodos de medida deben ser exactos.
El usuario final mide la calidad del software según lo que tenga o no, es en ese
sentido de que la calidad del software depende de quién juzgue. El hecho de que una
empresa tenga certificación en calidad del software no garantiza que su software sea
de calidad.
1.4 Objetivo.
Demostrar que es la mejora o evaluación de un software y los procesos de desarrollo
y mantenimiento de sistemas, productos de software y calidad e el software de
cualquier organización.
14
II DESARROLLO DEL TRABAJO.
La década de los noventa se caracterizo pues la palabra CALIDAD, normalmente sin
importar a que elemento y áreas se hicieron referencia; gerencial, objetivos de
consumo, servicios, administración, gestión, atención al público, universidades,
hospitales, líneas aéreas, gobiernos, bancos, etc. La ciencia no escapa de este
fenómeno: medicina, economía, ingeniería, biología, sociología, etc. En definitiva
todos dicen tenerla y dominarla, pero como conocer y dominar un concepto tan
15
amplio y diferente, subjetivo y muchas veces ambiguo. Que ni siquiera la mayoría de
las personas podrían dar una definición exacta de lo que es calidad.
El software no escapa de esta realidad pero sin lugar a duda se enfrenta con muchos
más obstáculos para poder dominar la calidad en comparación con otras ciencias.
2.1 ¿Qué es Calidad? El termino Calidad tiene muchas definiciones, pero la básica es aquella que dice que
aquel producto o servicio que nosotros adquiramos satisfaga nuestras expectativas
sobradamente. Es decir, que aquel servicio o producto funcione tal y como nosotros
queramos y para realizar aquella tarea o servicio que nos tiene que realizar. Con
todo y a pesar de esta definición el término "Calidad" siempre será entendido de
diferente manera por cada uno de nosotros, ya que para unos la Calidad residirá en
un producto y en otros en su servicio posventa de este producto, por poner un
ejemplo. Lo cierto es que nunca llegaremos a definir exactamente lo que representa
el término Calidad a pesar de que últimamente este término se haya puesto de
moda.
La Calidad Total es el estadio más evolucionado dentro de las sucesivas
transformaciones que ha sufrido el término Calidad a lo largo del tiempo. En un
primer momento se habla de Control de Calidad, primera etapa en la gestión de la
Calidad que se basa en técnicas de inspección aplicadas a Producción.
Posteriormente nace el Aseguramiento de la Calidad, fase que persigue garantizar
un nivel continuo de la calidad del producto o servicio proporcionado. Finalmente se
llega a lo que hoy en día se conoce como Calidad Total, un sistema de gestión
empresarial íntimamente relacionado con el concepto de Mejora Continua y que
incluye las dos fases anteriores. Los principios fundamentales de este sistema de
gestión son los siguientes:
Consecución de la plena satisfacción de las necesidades y expectativas del cliente
(interno y externo).
16
Desarrollo de un proceso de mejora continua en todas las actividades y procesos
llevados a cabo en la empresa (implantar la mejora continua tiene un principio pero
no un fin).
Total compromiso de la Dirección y un liderazgo activo de todo el equipo directivo.
Participación de todos los miembros de la organización y fomento del trabajo en
equipo hacia una Gestión de Calidad Total.
Involucración del proveedor en el sistema de Calidad Total de la empresa, dado el
fundamental papel de éste en la consecución de la Calidad en la empresa.
Identificación y Gestión de los Procesos Clave de la organización, superando las
barreras departamentales y estructurales que esconden dichos procesos.
Toma de decisiones de gestión basada en datos y hechos objetivos sobre gestión
basada en la intuición. Dominio del manejo de la información.
La filosofía de la Calidad Total proporciona una concepción global que fomenta la
Mejora Continua en la organización y la involucración de todos sus miembros,
centrándose en la satisfacción tanto del cliente interno como del externo. Podemos
definir esta filosofía del siguiente modo: Gestión (el cuerpo directivo está totalmente
comprometido) de la Calidad (los requerimientos del cliente son comprendidos y
asumidos exactamente) Total (todo miembro de la organización está involucrado,
incluso el cliente y el proveedor, cuando esto sea posible).
2.2 ¿Que es Calidad del software?
La obtención de un software con calidad implica la utilización de metodologías o
procedimientos estándares para el análisis, diseño, programación y prueba del
software que permitan uniformar la filosofía de trabajo.
Los requisitos del software son la base de las medidas de calidad. La falta de
concordancia con los requisitos es una falta de calidad.
17
Los estándares o metodologías definen un conjunto de criterios de desarrollo que
guían la forma en que se aplica la ingeniería del software. Si no se sigue ninguna
metodología siempre habrá falta de calidad
Conjunto de actividades planificadas y sistemáticas necesarias para aportar la
confianza en que el producto (software) satisfará los requisitos dados de calidad.
2.2.1 El aseguramiento de la calidad: "Conjunto de acciones planificadas y
sistemáticas necesarias para proporcionar la confianza adecuada de que un producto
o servicio satisfará los requerimientos dados sobre calidad".
2.2.2 La garantía, puede confundir con garantía de productos, mientras que el
aseguramiento pretende dar confianza en que el producto tiene calidad.
2.2.3 El aseguramiento de calidad del software está presente en: Métodos y
herramientas de análisis, diseño, programación y prueba.
2.2.4 Inspecciones técnicas formales en todos los pasos del proceso de desarrollo
del software.
2.2.5 Estrategias de prueba multiescala. Control de la documentación del software y
de los cambios realizados.
2.2.6 Procedimientos para ajustarse a los estándares (y dejar claro cuando se está
fuera de ellos).
2.2.7 Mecanismos de medida (métricas). Registro de auditorías y realización de
informes.
Las actividades para el aseguramiento de calidad del software se detallan en:
Métricas de software para el control del proyecto. Verificación y validación del
Software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisión e
inspección).
2.3 Algunos métodos del aseguramiento del software: 2.3.1 Revisiones técnicas y de gestión (su objetivo es la evaluación).
2.3.2 Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto
correcto?
18
2.3.3 Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto
correctamente?
2.3.4 Existen algunos requisitos implícitos o expectativas que a menudo no se
mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen
mantenimiento) que también puede implicar una falta de calidad.
2.4 El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.
El principio administrativo contempla las funciones de planificación y control del
desarrollo del software, así como la organización del ambiente o centro de ingeniería
de software. El principio ergonómico define la interfaz entre el usuario y el ambiente
automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad
del software, pero no la asegura. Para el aseguramiento de la calidad es necesario
su control o evaluación.
A partir del siguiente gráfico se observa la interrelación existente entre la Gestión de
la Calidad, el Aseguramiento de la Calidad y el Control de la Calidad del software.
19
Figura 1. La Gestión y Control de Calidad del Software
2.5 Algunos conceptos de software. El software son programas con distitos procedimientos con ordenamiento lógicos que
ayudan a que las tareas se realicen de una manera más rápida.
Un sistema se pude definir que es un conjunto de funciones y procedimientos
encaminados al desarrollo, capturacion y almacenamiento de infomación para el
mejoramiento de una organización.
2.6 Desarrollo del software. El proceso de desarrollo de software, el cual es la base para que todo proyecto
independientemente de cuál sea su porte – se realice de forma correcta y entendible.
2.6.1 Abstract
20
Cuando se va a desarrollar un software intervienen muchas personas como los
clientes que es el que tiene el problema es su empresa y desea que sea solucionado,
para esto existe el analista de sistema quien es el encargado de hacerle llegas todos
los requerimientos y necesidades que tiene el cliente a los programadores.
Se utilizan varias metodologías que se aplican hoy en día para su construcción.
2.6.2 Fundamentos del Análisis de Requerimientos
Se define como el conjunto de técnicas y procedimientos que nos permiten conocer
los elementos necesarios para definir un proyecto de software. Es la etapa más
crucial del desarrollo de un proyecto de software.
La IEEE los divide en funcionales y no funcionales:
Funcionales: Condición o capacidad de un sistema requerida por el usuario para
resolver un problema o alcanzar un objetivo.
No Funcionales: Condición o capacidad que debe poseer un sistema par satisfacer
un contrato, un estándar, una especificación u otro documento
formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una especificación
completa de los requerimientos de los mismos. Independientemente de lo bien
diseñado o codificado que esté, un programa pobremente especificado decepcionará
al usuario y hará fracasar el desarrollo.
La tarea de análisis de los requerimientos es un proceso de descubrimiento y
refinamiento, El ámbito del programa, establecido inicialmente durante la
ingeniería del sistema, es refinado en detalle. Se analizan y asignan a los distintos
elementos de los programas las soluciones alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel activo en la
especificación de requerimientos. El cliente intenta reformular su concepto, algo
nebuloso, de la función y comportamiento de los programas en detalles concretos, El
21
que desarrolla el software actúa como interrogador, consultor y el que resuelve
los problemas.
El análisis y especificación de requerimientos puede parecer una tarea relativamente
sencilla, pero las apariencias engañan. Puesto que el contenido de comunicación es
muy alto, abundan los cambios por mala interpretación o falta de información. El
dilema con el que se enfrenta un ingeniero de software puede ser comprendido
repitiendo la sentencia de un cliente anónimo: "Sé que crees que comprendes lo que
piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo
quise decir".
2.6.3 Análisis de Requerimientos
El análisis de requerimientos es la tarea que plantea la asignación de software a nivel
de sistema y el diseño de programas (Figura 1). El análisis de requerimientos facilita
al ingeniero de sistemas especificar la función y comportamiento de los programas,
indicar la interfaz con otros elementos del sistema y establecer las ligaduras de
diseño que debe cumplir el programa. El análisis de requerimientos permite al
ingeniero refinar la asignación de software y representar el dominio de la información
que será tratada por el programa. El análisis de requerimientos de al diseñador la
representación de la información y las funciones que pueden ser traducidas
en datos, arquitectura y diseño procedimental. Finalmente, la especificación de
requerimientos suministra al técnico y al cliente, los medios para valorar la calidad de
los programas, una vez que se haya construido.
22
Figura 2. Los Análisis de Requerimientos.
2.6.4 Tareas del Análisis El análisis de requerimientos puede dividirse en cuatro áreas:
1.- Reconocimiento del problema
2.- Evaluación y síntesis
3.- Especificación
4.- Revisión.
Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de
proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los
programas que se usó para generar las estimaciones de la planificación. A
continuación, debe establecerse la comunicación necesaria para el análisis, de forma
que se asegure el reconocimiento del problema.
Las formas de comunicación requeridas para el análisis se ilustran en la (Figura 3).
El analista debe establecer contacto con el equipo técnico y de gestión del
usuario/cliente y con la empresa que vaya a desarrollar el software. El gestor del
programa puede servir como coordinador para facilitar el establecimiento de los
caminos de comunicación. El objetivo del analista es reconocer los elementos
básicos del programa tal como lo percibe el usuario/cliente.
23
Figura 3. El análisis de Requerimientos por Áreas.
La evaluación del problema y la síntesis de la solución es la siguiente área principal
de trabajo del análisis. El analista debe evaluar el flujo y estructura de la información,
refinar en detalle todas las funciones del programa, establecer las características de
la interface del sistema y descubrir las ligaduras del diseño, Cada una de las tareas
sirve para descubrir el problema de forma que pueda sintetizarse un enfoque o
solución global.
Las tareas asociadas con el análisis y especificación existen para dar una
representación del programa que pueda ser revisada y aprobada por el cliente. En un
mundo ideal el cliente desarrolla una especificación de requerimientos del software
24
Completamente por sí mismo. Esto se presenta raramente en el mundo real. En el
mejor de los casos, la especificación se desarrolla conjuntamente entre el cliente y el
técnico.
Una vez que se hayan descrito las funcionalidades básicas, comportamiento,
interface e información, se especifican los criterios de validación para demostrar una
comprensión de una correcta implementación de los programas. Estos criterios
sirven como base para hacer una prueba durante el desarrollo de los programas.
Para definir las características y atributos del software se escribe una especificación
de requerimientos formal. Además, para los casos en los que se desarrolle un
prototipo se realiza un manual de usuario preliminar.
Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana
del proceso de desarrollo, Pero de hecho, este borrador del manual de
usuario fuerza al analista a tomar el punto de vista del usuario del software. El
manual permite al usuario / cliente revisar el software desde una perspectiva de
ingeniería humana y frecuentemente produce el comentario: "La idea es correcta
pero esta no es la forma en que pensé que se podría hacer esto". Es mejor descubrir
tales comentarios lo mas tempranamente posible en el proceso.
Los documentos del análisis de requerimiento (especificación y manual de usuario)
sirven como base para una revisión conducida por el cliente y el técnico. La revisión
de los requerimientos casi siempre produce modificaciones en la función,
comportamiento, representación de la información, ligaduras o criterios de validación.
Además, se realiza una nueva apreciación del plan del proyecto de software para
determinar si las primeras estimaciones siguen siendo validas después
del conocimiento adicional obtenido durante el análisis.
2.6.5 Principios del Análisis
En la pasada década, se desarrollaron varios métodos de análisis y especificación
del software. Los investigadores han identificado los problemas y sus causas y
desarrollando reglas y procedimientos para resolverlos. Cada método de análisis
25
tiene una única notación y punto de vista. Sin embargo, todos los métodos de
análisis están relacionados por un conjunto de principios fundamentales:
El dominio de la información, así como el dominio funcional de un problema debe ser
representado y comprendido.
El problema debe subdividirse de forma que se descubran los detalles de una
manera progresiva (o jerárquica).
Deben desarrollarse las representaciones lógicas y físicas del sistema.
Aplicando estos principios, el analista enfoca el problema sistemáticamente. Se
examina el dominio de la información de forma que pueda comprenderse su función
mas completamente. La partición se aplica para reducir la complejidad. La
visión lógica y física del software, es necesaria para acomodar las ligaduras lógicas
impuestas por los requerimientos de procesamiento, y las ligaduras físicas impuestas
por otros elementos del sistema.
2.6.6 El dominio de la Información
Todas las aplicaciones del software pueden colectivamente llamarse procesamiento
de datos. Este término contiene la clave de lo que entendemos por requerimientos
del software. El software se construye para procesar datos; para transformar datos
de una forma a otra; esto es, para aceptar entrada, manipularla de alguna forma y
producir una salida. Este establecimiento fundamental de los objetivos es verdad
tanto si construimos software por lotes para un sistema de nominas, como software
empotrado en tiempo real para controlar el flujo de la gasolina de un motor de
automóvil; el dominio de la información contiene tres visiones diferentes de los datos
que se procesan por los programas de computadoras: 1) el flujo de información; 2) el
contenido de la información y 3)la estructura de la información. Para comprender
completamente el dominio de la información, deben considerarse cada una de estas
tres partes.
26
El flujo de la información representa la manera en la que los datos cambian conforme
pasan a través de un sistema. Refiriéndonos a la Figura 3, la entrada se transforma
en datos intermedios y más adelante se transforma en la salida.
Figura 4. Dominio de la Información.
2.6.7 Partición
Normalmente los problemas son demasiado grandes y complejos para ser
comprendidos como un todo. Por esta razón, tendemos a particionar (dividir) tales
problemas en partes que puedan ser fácilmente comprendidas, y establecer
interfases entre las partes, de forma que se realice la función global. Durante el
27
análisis de requerimientos, el dominio funcional y el dominio de la información del
software pueden ser particionados.
En esencia la partición descompone un problema en sus partes constituyentes.
Conceptualmente, establecemos una representación jerárquica de la función o
información y luego partimos el elemento superior mediante: 1) incrementando los
detalles, moviéndonos verticalmente en la jerarquía, o 2) descomponiendo
funcionalmente el problema, moviéndonos horizontalmente en la jerarquía.
2.6.8. Visiones Lógicas y Físicas
La visión lógica de los requerimientos del software presenta las funciones que han de
realizarse y la información que ha de procesarse independientemente de los detalles
de implementación.
La visión física de los requerimientos del software presenta una manifestación del
mundo real de las funciones de procesamiento y las estructuras de información. En
algunos casos se desarrolla una representación física como el primer paso del
diseño del software. Sin embargo la mayoría de los sistemas basados
en computador, se especifican de forma que se dictan ciertas recomendaciones
físicas.
2.6.9. Construcción de Prototipos de Software
En análisis debe ser conducido independientemente del paradigma de ingeniería de
software aplicado. Sin embargo, la forma que ese análisis tomara puede variar. En
algunos casos es posible aplicar los principios de análisis fundamental y derivar a
una especificación en papel del software desde el cual pueda desarrollarse un
28
diseño. En otras situaciones, se va a una recolección de los requerimientos, se
aplican los principios de análisis y se construye un modelo de software, llamado un
prototipo, según las apreciaciones del cliente y del que lo desarrolla. Finalmente, hay
circunstancias que requieren la construcción de un prototipo al comienzo del análisis,
puesto que el modelo es el único mediante el que los requerimientos pueden ser
derivados efectivamente.
2.6.10 Un escenario para la construcción de prototipos
Todos los proyectos de ingeniería de software comienzan con una petición del
cliente. La petición puede estar en la forma de una memoria que describe un
problema, un informe que define un conjunto de objetivos comerciales o del producto,
una petición de propuesta formal de una agencia o compañía exterior, o una
especificación del sistema que ha asignado una función y comportamiento al
software, como un elemento de un sistema mayor basado en computadora.
Suponiendo que existe una petición para un programa de una de las formas dichas
anteriormente, para construir un prototipo del software se aplican los siguientes
pasos:
Evaluar la petición del software y determinar si el programa a desarrollar es un buen
candidato para construir un prototipo.
Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos, es
esencial que: el cliente participe en la evaluación y refinamiento del prototipo, y el
cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna.
Finalmente, la naturaleza del proyecto de desarrollo tendrá una fuerte influencia en
la eficacia del prototipo.
Dado un proyecto candidato aceptable, el analista desarrolla una representación
abreviada de los requerimientos.
29
Antes de que pueda comenzar la construcción de un prototipo, el analista debe
representar los dominios funcionales y de información del programa y desarrollar un
método razonable de partición. La aplicación de estos principios de análisis
fundamentales, pueden realizarse mediante los métodos de análisis de
requerimientos.
Después de que se haya revisado la representación de los requerimientos, se crea
un conjunto de especificaciones de diseño abreviadas para el prototipo.
El diseño debe ocurrir antes de que comience la construcción del prototipo. Sin
embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura a
nivel superior y a los aspectos de diseño de datos, en vez de hacia el diseño
procedimental detallado.
El software del prototipo se crea, prueba y refina
Idealmente, los bloques de construcción de software preexisten se utilizan para crear
el prototipo de una forma rápida. Desafortunadamente, tales bloques construidos
raramente existen.
Incluso si la implementación de un prototipo que funcione es impracticable, es
escenario de construcción de prototipos puede aun aplicarse. Para las aplicaciones
interactivas con el hombre, es posible frecuentemente crear un prototipo en papel
que describa la interacción hombre-maquina usando una serie de hojas de historia.
Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la
prueba" de la aplicación y sugiere modificaciones.
Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el
cliente puede examinar una representación implementada de los requerimientos del
programa, sugerir modificaciones que harán al programa cumplir mejor las
necesidades reales.
Se repiten iterativamente hasta que todos los requerimientos estén formalizados o
hasta que el prototipo haya evolucionado hacia un sistema de producción.
El paradigma de construcción del prototipo puede ser conducido con uno o dos
objetivos en mente: el propósito del prototipado es establecer un conjunto de
30
requerimientos formales que pueden luego ser traducidos en la producción de
programas mediante el uso de métodos y técnicas de ingeniería de programación, o
el propósito de la construcción del prototipo es suministrar un continuo que pueda
conducir al desarrollo evolutivo de la producción del software. Ambos métodos tienen
sus meritos y amos crean problemas.
2.6.11 Especificación
No hay duda de que la forma de especificar tiene mucho que ver con la calidad de la
solución. Los ingenieros de software que se han esforzado en trabajar con
especificaciones incompletas, inconsistentes o mal establecidas han experimentado
la frustración y confusión que invariablemente se produce. Las consecuencias se
padecen en la calidad, oportunidad y completitud del software resultante.
Hemos visto que los requerimientos de software pueden ser analizados de varias
formas diferentes. Las técnicas de análisis pueden conducir a una especificación en
papel que contenga las descripciones graficas y el lenguaje natural de los
requerimientos del software. La construcción de prototipos conduce a una
especificación ejecutable, esto es, el prototipo sirve como una representación de los
requerimientos. Los lenguajes de especificación formal conducen a representaciones
formales de los requerimientos que pueden ser verificados o analizados.
2.6.12 Principios de Especificación
31
La especificación, independientemente del modo en que se realice, puede ser vista
como un proceso de representación. Los requerimientos se representan de forma
que conduzcan finalmente a una correcta implementación del software.
Baltzer y Goldman proponen ocho principios para una buena especificación:
- Separar funcionalidad de implementación.
Primero, por definición, una especificación es una descripción de lo que se desea, en
vez de cómo se realiza (implementa). Las especificaciones pueden adoptar dos
formas muy diferentes. La primera forma es la de funciones matemáticas: dado algún
conjunto de entrada, producir un conjunto particular de salida. La forma general de
tales especificaciones es encontrar [un/el/todos] resultado tal que P (entrada), donde
P representa un predicado arbitrario. En tales especificaciones, el resultado a ser
obtenido ha sido expresado enteramente en una forma sobre el que (en vez de
cómo). En parte, esto es debido a que el resultado es una función matemática de la
entrada (la operación tiene puntos de comienzo y parada bien definidos) y no esta
afectado por el entorno que le rodea.
- Se necesita un lenguaje de especificación de sistemas orientado al proceso.
Considerar una situación en la que el entorno sea dinámico y sus cambios afecten al
comportamiento de alguna entidad que interactúe con dicho entorno. Su
comportamiento no puede ser expresado como una función matemática de su
entrada. En vez de ello, debe emplearse una descripción orientada al proceso, en la
cual la especificación del que se consigue mediante la especificación de un modelo
del comportamiento deseado en términos de respuestas funcionales, a distintos
estímulos del entorno.
- Una especificación debe abarcar el sistema del cual el software es una
componente.
Un sistema está compuesto de componentes que interactúan. Solo dentro del
contexto del sistema completo y de la interacción entre sus partes puede ser definido
el comportamiento de una componente específica. En general, un sistema puede ser
modelado como una colección de objetos pasivos y activos. Estos objetos están
interrelacionados y dichas relaciones entre los objetos cambian con el tiempo. Estas
32
relaciones dinámicas suministran los estímulos a los cuales los objetos activos,
llamados agentes, responden. Las respuestas pueden causar posteriormente
cambios y, por tanto, estímulos adicionales a los cuales los agentes deben
responder.
- Una especificación debe abarcar el entorno en el que el sistema opera.
Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser
especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un
sistema compuesto de objetos que interactúan, pasivos y activos, de los cuales el
sistema especificado es una agente, Los otros agentes, los cuales son por definición
inalterables debido a que son parte del entorno, limitan el ámbito del diseño
subsecuente y de la implementación. De hecho, la única diferencia entre el sistema y
su entorno es que el esfuerzo de diseño e implementación subsecuente opera
exclusivamente sobre la especificación del sistema. La especificación del entorno
facilita que se especifique la interfaz del sistema de la misma forma que el propio
sistema, en vez de introducir otro formalismo.
- Una especificación de sistema debe ser un modelo cognitivo.
La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo
de diseño o implementación. Debe describir un sistema tal como es percibido por su
comunidad de usuario. Los objetivos que manipula deben corresponderse con
objetos reales de dicho dominio; los agentes deben modelar los individuos,
organizaciones y equipo de ese dominio; y las acciones que ejecutan deben modelar
lo que realmente ocurre en el dominio. Además, debe ser posible incorporar en la
especificación las reglas o leyes que gobiernan los objetos del dominio.
Algunas de estas leyes proscriben ciertos estados del sistema (tal como “dos objetos
no pueden estar en el mismo lugar al mismo tiempo”), y por tanto limitan el
comportamiento de los agentes o indican la necesidad de una posterior elaboración
para prevenir que surjan estos estados.
- Una especificación debe ser operacional.
33
La especificación debe ser completa y lo bastante formal para que pueda usarse
para determinar si una implementación propuesta satisface la especificación de
pruebas elegidas arbitrariamente. Esto es, dado el resultado de una implementación
sobre algún conjunto arbitrario de datos elegibles, debe ser posible usar la
especificación para validar estos resultados. Esto implica que la especificación,
aunque no sea una especificación completa del como, pueda actuar como un
generador de posibles comportamientos, entre los que debe estar la implementación
propuesta. Por tanto, en un sentido extenso, la especificación debe ser operacional.
- La especificación del sistema debe ser tolerante con la incompletitud y aumentable.
Ninguna especificación puede ser siempre totalmente completa. El entorno en el que
existe es demasiado complejo para ello. Una especificación es siempre un modelo,
una abstracción, de alguna situación real (o imaginada). Por tanto, será incompleta.
Además, al ser formulad existirán muchos niveles de detalle. La operacionalidad
requerida anteriormente no necesita ser completa. Las herramientas de análisis
empleadas para ayudar a los especificadores y para probar las especificaciones,
deben ser capaces de tratar con la incompletitud. Naturalmente esto debilita el
análisis, el cual puede ser ejecutado ampliando el rango de comportamiento
aceptables, los cuales satisfacen la especificación, pero tal degradación debe reflejar
los restantes niveles de incertidumbre.
- Una especificación debe ser localizada y débilmente acoplada.
Los principios anteriores tratan con la especificación como una entidad estática. Esta
surge de la dinámica de la especificación. Debe ser reconocido que aunque el
principal propósito de una especificación sea servir como base para el diseño e
implementación de algún sistema, no es un objeto estático pre compuesto, sino un
objeto dinámico que sufre considerables modificaciones. Tales modificaciones se
presentan en tres actividades principales: formulación, cuando se está creando una
especificación inicial; desarrollo, cuando la especificación se está elaborando durante
el proceso iterativo de diseño e implementación; y mantenimiento, cuando la
especificación se cambia para reflejar un entorno modificado y/o requerimientos
funcionales adicionales.
34
2.6.13 Métodos de Análisis de Requerimientos
Las metodologías de análisis de requerimientos combinan procedimientos
sistemáticos con una notación única para analizar los dominios de información y
funcional de un problema de software; suministra un conjunto de heurísticas para
subdividir el problema y define una forma de representación para las visiones lógicas
y físicas. En esencia, los métodos de análisis de requerimientos del software, facilitan
al ingeniero de software aplicar principios de análisis fundamentales, dentro del
contexto de un método bien definido.
La mayoría de los métodos de análisis de requerimiento son conducidos por la
información. Estos es, el método suministra un mecanismo para representar el
dominio de la información. Desde esta representación, se deriva la función y se
desarrollan otras características de los programas.
El papel de los métodos de análisis de requerimientos, es asistir al analista en la
construcción de “una descripción precisa e independiente” del elemento software de
un sistema basado en computadora.
2.6.14. Metodologías de Análisis de Requerimientos
Las metodologías de análisis de requerimientos facilitan al analista la aplicación de
los principios fundamentales del análisis de una manera sistemática.
Características Comunes
Aunque cada método introduce nueva notación y heurística de análisis, todos los
métodos pueden ser evaluados en el contexto de las siguientes características
35
comunes:
Mecanismos para el análisis del dominio de la información
Método de representación funcional
Definición de interfaces
Mecanismos para subdividir el problema
Soporte de la abstracción
Representación de visiones físicas y lógicas
Aunque el análisis del dominio de la información se conduce de forma diferente en
cada metodología, pueden reconocerse algunas guías comunes. Todos los métodos
se enfocan (directa o indirectamente) al flujo de datos y al contenido o estructura de
datos. En la mayoría de los casos el flujo se caracteriza en el contexto de las
transformaciones (funciones) que se aplican para cambiar la entrada en la salida. El
contenido de los datos puede representarse explícitamente usando un mecanismo de
diccionario o, implícitamente, enfocando primero la estructura jerárquica de los datos.
Las funciones se describen normalmente como transformaciones o procesos de la
información. Cada función puede ser representada usando una notación específica.
Una descripción de la función puede desarrollarse usando el lenguaje natural, un
leguaje procedimental con reglas sintácticas informales o un lenguaje de
especificación forma.
2.6.15 Métodos de Análisis Orientados al Flujo de Datos
La información se transforma como un flujo a través de un sistema basado en
computadora. El sistema acepta entrada de distintas formas; aplica un hardware,
36
software y elementos humanos para transformar la entrada en salida; y produce una
salida en distintas formas. La entrada puede ser una señal de control transmitida por
un transductor, una serie de números escritos por un operador humano, un paquete
de información transmitido por un enlace a red, o un voluminoso archivo de datos
almacenado en memoria secundaria. La transformación puede comprender una
sencilla comparación lógica, un complejo algoritmo numérico, o un método de
inferencia basado en regla de un sistema experto. La salida puede encender una
sencilla red o producir un informe. En efecto, un modelo de flujo de datos puede
aplicarse a cualquier sistema basado en computadora independientemente del
tamaño o complejidad.
Una técnica para representar el flujo de información a través del sistema basado en
computadora se ilustra en la figura 5. La función global del sistema se representa
como una transformación sencilla de la información, representada en la figura como
una burbuja. Una o más entradas. Representadas como flechas con etiqueta,
conducen la transformación para producir la información de salida. Puede observarse
que el modelo puede aplicarse a todo el sistema o solo a un elemento de software.
La clave es representar la información dada y producida por la transformación.
Figura 5. Representación del flujo de la información.
2.6.16 Diagramas de Flujos de Datos
Conforme con la información se mueve a través del software, se modifica mediante
una serie de transformaciones. Un diagrama de flujos de datos (DFD), es una técnica
37
grafica que describe el flujo de información y las transformaciones que se aplican a
los datos, conforme se mueven de la entrada a la salida. La forma básica de un DFD
se ilustra en la figura 5. El diagrama es similar en la forma a otros diagramas de flujo
de actividades, y ha sido incorporado en técnicas de análisis y diseños propuesto por
Yourdon y Constantine, DeMarco y Gane y Sarson. También se le conoce como un
grafo de flujo de datos o un diagrama de burbujas.
Figura 6. Diagrama de flujos de datos.
2.6.17 Diccionario de Datos Un análisis del dominio de la información puede ser incompleto si solo se considera
el flujo de datos. Cada flecha de un diagrama de flujo de datos representa uno o más
elementos de información. Por tanto, el analista debe disponer de algún otro método
para representar el contenido de cada flecha de un DFD.
Se ha propuesto el diccionario de datos como una gramática casi formal para
describir el contenido de los elementos de información y ha sido definido da la
siguienteforma:
El diccionario de datos contiene las definiciones de todos los datos mencionados en
el DFD, en una especificación del proceso y en el propio diccionario de datos. Los
datos compuestos (datos que pueden ser además divididos) se definen en términos
de sus componentes; los datos elementales (datos que no pueden ser divididos) se
38
definen en términos del significado de cada uno de los valores que puede asumir.
Por tanto, el diccionario de datos está compuesto de definiciones de flujo de datos,
archivos (datos almacenados) y datos usados en los procesos (transformaciones).
2.6.18 Descripciones Funcionales
Una vez que ha sido representado el dominio de la información (usando un DFD y un
diccionario de datos), el analista describe cada función (transformación)
representada, usando el lenguaje natural o alguna otra notación estilizada. Una de
tales notaciones se llama ingles estructurado (también llamado lenguaje de diseño
del programa o proceso (LDP)). El ingles estructurado incorpora construcciones
procedimentales básicas –secuencia, selección y repetición-junto con frases del
lenguaje natural, de forma que pueden desarrollarse descripciones procedimentales
precisas de las funciones representadas dentro de un DFD.
2.6.19 Métodos Orientados a la Estructura de Datos
Hemos ya observado que el dominio de la información para un problema de software
comprende el flujo de datos, el contenido de datos y la estructura de datos. Los
métodos de análisis orientados a la estructura de datos representan los
requerimientos del software enfocándose hacia la estructura de datos en vez de al
flujo de datos.
Aunque cada método orientado a la estructura de datos tiene un enfoque y notación
distinta, todos tienen algunas características en común:
todos asisten al analista en la identificación de los objetos de información clave
(también llamados entidades o ítems) y operaciones (también llamadas acciones o
39
procesos); todos suponen que la estructura de la información es jerárquica;
todos requiere que la estructura de datos se represente usando la secuencia,
selección y repetición; y todos dan una conjunto de pasos para transformar una
estructura de datos jerárquica en una estructura de programa.
Como los métodos orientados al flujo de datos, los métodos de análisis orientados a
la estructura de datos proporcionan la base para el diseño de software. Siempre
puede extenderse un método de análisis para que abarque el diseño arquitectural y
procedimental del software.
2.6.20 Desarrollo de Sistemas de Jackson
El Desarrollo de Sistema de Jackson (DSJ) se obtuvo a partir del trabajo de M.A.
Jackson sobre el análisis del dominio de la información y sus relaciones con el
diseño de programas y sistemas. En palabras de Jackson: “El que desarrolla el
software comienza creando un modelo de la realidad a la que se refiere el sistema, la
realidad que proporciona su materia objeto [del sistema]...”
Para construir un DSJ el analista aplica los Siguientes pasos:
1. Paso de las acciones y entidades. Usando un método muy similar a la técnica de
análisis orientada al objeto, en este paso se identifican las entidades (persona,
objetos u organizaciones que necesita un sistema para producir o usar información) y
acciones (los sucesos que ocurren en el mudo real que afectan a las entidades).
Paso de estructuración de las entidades. Las acciones que afectan a cada entidad
son ordenadas en el tiempo y representadas mediante diagramas de Jackson (una
notación similar a un árbol).
2. Paso de modelación inicial. Las entidades y acciones se representan como un
modelo del proceso; se definen las conexiones entre el modelo y el mundo real.
Paso de las funciones. Se especifican las funciones que corresponden a las acciones
40
definidas.
3. Paso de temporización del sistema. Se establecen y especifican las características
de planificación del proceso.
4. Paso de implementación. Se especifica el hardware y software como un diseño.
Los últimos tres pasos del DSJ están muy relacionados con el diseño de sistemas.
2.6.21 Requerimientos de las Bases de Datos
El análisis de requerimientos para una base de datos incorpora las mismas tareas
que el análisis de requerimientos del software. Es necesario un contacto estrecho
con el cliente; es esencial la identificación de las funciones e interfaces; se requiere
la especificación del flujo, estructura y asociación de la información y debe
desarrollarse un documento formal de los requerimientos.
Un tratamiento completo del análisis de las bases de datos va más allá del ámbito de
este paper.
2.6.22 Características de las bases de datos
El termino base de datos se ha convertido en uno de los muchos tópicos del campo
de las computadoras. Aunque existen muchas definiciones elegantes, definiremos
una base de datos como: una colección de información organizada de forma que
facilita el acceso, análisis y creación de informes. Una base de datos contiene
entidades de información que están relacionadas vía organización y asociación. La
arquitectura lógica de una base de datos se define mediante un esquema que
representa las definiciones de las relaciones entre las entidades de información. La
41
arquitectura física de una base de datos depende de la configuración del hardware
residente. Sin embargo, tanto el esquema (descripción lógica) como la organización
(descripción física) deben adecuarse para satisfacer los requerimientos funcionales y
de comportamiento para el acceso al análisis y creación de informes.
2.7 El Modelo CMM El CMM (Capability Maturity Model for Software), es decir, Modelo de Madurez de
Capacidades. Fue creado por el Software Engineering Institute (SEI) y tiene como
Meta el describir los elementos principales para llegar a cabo los procesos de
software de una forma efectivos. El CMM consiste en una serie de procedimientos
destinados a evaluar y mejorar los procesos de desarrollo, implementación y
mantenimiento del software. Aunque aún está envías desarrollo, es un estándar que
la industria acepta para evaluar y garantizar la calidad y madurez de sus
aplicaciones. Por otro lado, hay CMMs para procesos que no son estrictamente en el
sector del software, como por ejemplos BMP (Business Process Management).
2.8 Niveles del CMM CMM define cinco niveles de madurez para una organización y proporciona un marco
para moverse a partir de un nivel al siguiente. Las guías CMM contienen actividades
diseñadas para ayudar a una organización para mejorar sus procesos con la meta de
alcanzar capacidad de repetición, y control de los mismos. El CMM ha ganado
considerable credibilidad en las industrias intensivas en el uso de conocimientos. La
implantación del CMM ha permitido mejoras considerables en la calidad de los
productos y bajado perceptiblemente el costo del desarrollo dentro de grandes
compañías.
42
Las organizaciones han probado que mejorando sus procesos de desarrollo, CMM
del nivel 1 al nivel 3, puede bajar su costo por hasta 50-60%. Aun mas, quienes han
estado en el negocio de la productividad del desarrollo del software por años,
sostienen que la rentabilidad resultada de mejoras en productividad y reducción en
tiempo de llegada al mercado.
Los niveles del CMM son:
Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el
desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de
ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los
proyectos se basa la mayoría de las veces en el esfuerzo personal, aunque a
menudo se producen fracasos y casi siempre retrasos y sobre costes. El resultado de
los proyectos es impredecible.
Repetible. En este nivel las organizaciones disponen de unas prácticas
institucionalizadas de gestión de proyectos, existen unas métricas básicas y un
razonable seguimiento de la calidad. La relación con subcontratistas y clientes está
gestionada sistemáticamente.
Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones
disponen de correctos procedimientos de coordinación entre grupos, formación del
personal, técnicas de ingenierías más detalladas y un nivel más avanzado de
métricas en los procesos. Se implementan técnicas de revisión por pares (peer
reviews).
Gestionado. Se caracteriza por que las organizaciones disponen de un conjunto de
métricas significativas de calidad y productividad, que se usan de modo sistemático
para la toma de decisiones y la gestión de riesgos. El software resultante es de alta
calidad.
Optimizado. La organización completa está volcada en la mejora continua de los
procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de
innovación.
43
Figura 7. Los niveles CMMI
2.9. Beneficios de la implantación del modelo CMM 2.9.1 Mayor efectividad en la detección de errores a lo largo del ciclo de vida del
desarrollo del software, reduciendo drásticamente el número de defectos.
2.9.2 Reducción de las desviaciones en plazo de los proyectos.
2.9.3 Mayor tolerancia al cambio e incremento de la capacidad de adopción y
adaptación de nuevas Tecnologías.
2.9.4 Mejora en la rapidez y efectividad de respuesta ante exigencias del negocio.
2.9.5 Mejora en la colaboración y comunicación.
2.9.6 Mitigación de Riesgo.
2.9.7 Reducción de los costes del proyecto
2.10 Implementación en la organización:
44
Una empresa que decide implementar el modelo CMM, indica que no sólo se
preocupa por la calidad de su organización sino que quiere constituir un proceso
continúo de mejora.
Una de las principales ventajas de una empresa que implanta CMM es que es mucho
más flexible a la hora de integrar nuevos procesos.
Capability Maturity Model Integration (CMMI) es un modelo para la mejora de
procesos que proporciona a las organizaciones los elementos esenciales para
procesos eficaces.
Su idea principal es presentar una estructura a seguir para el desarrollo de software,
de tal forma a que se pueda controlar y medir cada parte del proceso completo de
desarrollo.
Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la
actualidad hay dos áreas de interés cubiertas por los modelos de CMMI: Desarrollo y
Adquisición.
La versión actual de CMMI es la versión 1.2. Hay tres constelaciones de la versión
1.2 disponible:
CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue
liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y
servicios.
CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue
liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro,
adquisición y contratación externa en los procesos del gobierno y la industria.
CMMI para servicios (CMMI-SVC o CMMI for Services), actualmente un borrador,
está diseñado para cubrir todas las actividades que requieren gestionar, establecer y
entregar Servicios.
Dentro de la constelación CMMI-DEV, existen dos modelos:
CMMI-DEV
CMMI-DEV + IPPD (Integrated Product and Process Development)
45
Independientemente de la constelación/modelo que opta una organización, las
practicas CMMI deben adaptarse a cada organización en función de sus objetivos de
negocio.
Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una
organización es evaluada (por ejemplo, usando un método de evaluación como
SCAMPI) y recibe una calificación de nivel 1-5 si sigue los niveles de Madurez (si
bien comienza con el nivel 2). En ese caso de que quiera la organización, puede
coger Áreas de proceso y en vez de por niveles de madurez puede obtener los
niveles de capacidad en cada una de las áreas de proceso, obteniendo el “Perfil de
Capacidad” de la organización.
Figura 8. Representación continúa del modelo CMM.
46
El modelo para software (CMM-SW) establece 5 niveles de madurez para clasificar a
las organizaciones, en función de qué áreas de procesos consiguen sus objetivos y
se gestionan con principios de ingeniería. Es lo que se denomina un modelo
escalonado, o centrado en la madurez de la organización.
Es lo que se denomina un modelo escalonado, o centrado en la madurez de la
organización. La selección de las áreas de proceso esta prefijado, habiendo 7 PA
para el nivel de madurez 2(ml2), 11 para el ML3, 2 para el ML4 y 2 para el ML5.
El modelo para ingeniería de sistemas (SE-CMM) establece 6 niveles posibles de
capacidad para una de las 22 áreas de proceso implicadas en la ingeniería de
sistemas. No agrupa los procesos en 5 tramos para definir el nivel de madurez de la
organización, sino que directamente analiza la capacidad de cada proceso por
separado. Es lo que se denomina un modelo continuo.
En el equipo de desarrollo de CMMI había defensores de ambos tipos de
representaciones. El resultado fue la publicación del modelo con dos
representaciones: continua y escalonada. No son equivalentes, y cada organización
puede optar por adoptar la que se adapte a sus características y prioridades de
mejora si existe una “stagging” equivalente que nos dice un Nivel de Madurez
equivale a tener en un conjunto de PA determinado un determinado Nivel de
Capacidad.
La visión continua de una organización mostrará la representación de nivel de
capacidad de cada una de las áreas de proceso del modelo.
La visión escalonada definirá a la organización dándole en su conjunto un nivel de
madurez del 1 al 5.
2.11 Componentes Requeridos Área de proceso: Conjunto de prácticas relacionadas que son ejecutadas de forma
conjunta para conseguir un conjunto de objetivos.
Componentes Requeridos
47
Objetivo genérico: Los objetivos genéricos asociados a un nivel de capacidad
establecen lo que una organización debe alcanzar en ese nivel de capacidad.
El logro de cada uno de esos objetivos en un área de proceso significa mejorar el
control en la ejecución del área de proceso.
Objetivo específico: Los objetivos específicos se aplican a una única área de proceso
y localizan las particularidades que describen que se debe implementar para
satisfacer el propósito del área de proceso.
2.12 Componentes Esperados Práctica genérica: Una práctica genérica se aplica a cualquier área de proceso
porque puede mejorar el funcionamiento y el control de cualquier proceso.
Práctica específica: Una práctica específica es una actividad que se considera
importante en la realización del objetivo específico al cual está asociado.
Las prácticas específicas describen las actividades esperadas para lograr la meta
específica de un área de proceso.
2.13 Componentes informativos Propósito
Notas introductorias
Nombres
Tablas de relaciones práctica - objetivo
Prácticas
Productos típicos
Sub-prácticas: Una sub-práctica es una descripción detallada que sirve como guía
para la interpretación de una práctica genérica o específica.
48
Ampliaciones de disciplina: Las ampliaciones contienen información relevante de una
disciplina particular y relacionada con una práctica específica.
Elaboraciones de prácticas genéricas: Una elaboración de una práctica genérica es
una guía de cómo la práctica genérica debe aplicarse al área de proceso.
III CONCLUSIONES
49
3.1 conclusión. Lograr el éxito en la producción del software es hacerlo con calidad y demostrar su
buena calidad. Esto solo es posible con la implantación de un sistema para
aseguramiento de la calidad del software.
La combinación de técnicas tradicionales o convencionales de la ingeniería del
software con la técnicas de modelado y simulación dinámica del proceso de
desarrollo de software, persigue como objetivo fundamental el ofrece un marco de
trabajo desde el que sea posible, entre otras actividades, evaluar las consecuencias
de diferentes acciones de mejora de procesos, realizar la experimentación de
diferentes escenarios y favorecer la formación y adquisición de experiencia en el
ámbito de la gestión del proyecto.
Como ventaja principal del marco propuesto, seria importante destacar que el propio
proceso de creación de los modelos de simulación se utiliza como principal conductor
de otro proceso orientado hacia la definición de bases de datos históricas dentro de
las organizaciones. El análisis de datos reales y simulados va a ofrecer dos ventajas:
la posibilidad de validar los modelos de simulación, con lo que aumentara la precisión
de los resultados cuantitativos; y, la determinación de los efectos reales de la mejora
de los procesos en la organización.
Como aplicación clara del marco dinámico, se propone su utilización en el entorno
del modelo CMM, como herramienta de soporte para la evolución entre los
diferentes niveles de madurez.
50
BIBLIOGRAFÍA
Gabriel Baudes. Calidad de la ingeniería del software. Página web consultada el día 24 de junio de 2009 ver: www.dmi.uib.es/bbuades/calidad/sid014.html Joaquín Gracia. CMM-CMMI. Página web consultada el día 24 de junio de 2009 ver: http://.ingenierosoftware.com/calidad/cmmi.php
51
Juan Manuel Luzuriaga. Inspecciones de software. Página web consultada el día 24 de junio de 2009 ver: http://www.monografias.com/trabajos6/isof/isof.shtml Msc. Alejandro Bedini G. Calidad de Software. Página web consultada el día 24 de junio de 2009 ver: www.willydev.net/descargas/articulos/general/calidadsotfware.pdf Oscar M. Fernández Carrasco, Delba García León y Alfa Beltrán. Un enfoque actual sobre calidad de software. Página web consultada el día 24 de junio de 2009 ver: www.bvs.sld.cu/revistas/aci/vol3395/aci05395.htm