dise o de una herramienta auditora para validar la calidad...

DISEÑO DE UNA HERRAMIENTA AUDITORA PARA VALIDAR LA CALIDAD DE SOFTWARE BASADA EN EL MODELO CMMI NIVEL 2

JAVIER MAURICIO AGUILERA MARTÍNEZ JORGE MÁXIMO HERNÁNDEZ SOTO

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

BOGOTÁ D.C. 2010

2

DISEÑO DE UNA HERRAMIENTA AUDITORA PARA VALIDAD LA CALIDAD DE SOFTWARE BASADA EN EL MODELO CMMI NIVEL 2

JAVIER MAURICIO AGUILERA MARTÍNEZ JORGE MÁXIMO HERNÁNDEZ SOTO

Proyecto de grado como requisito para optar por el título de Ingeniero de Sistemas.

Asesora María Teresa Amorocho Ingeniera de Sistemas

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

BOGOTÁ D.C. 2010

3

Bogotá D.C., Mayo de 2010

Nota de aceptación __________________________ __________________________ __________________________ __________________________ Presidente del jurado __________________________ Firma del jurado __________________________ Firma del jurado

4

Dedico este proyecto a mis Padres, Ana Martínez y Serafín Aguilera a quienes amo con todo mí ser y por quienes estoy siendo el ingeniero que ellos han querido que sea. A mis hermanas Sara Isabel y Andrea Sofía quienes son mi ejemplo a seguir, un ejemplo de profesionalismo puro y dedicado. A mi Familia y amigos que han logrado forjar en mí un carácter de profesionalismo y lealtad hacia mis creencias y deberes. Agradezco a toda la familia de la UNIVERSIDAD DE SAN BUENAVENTURA, por estos 5 años de enseñanza constante, de apoyo incondicional y de brindarme más que un simple lugar de enseñanza, más que una Universidad, este lugar se convirtió en mi segundo hogar donde conocí gente maravillosa que nunca voy a olvidar.

Javier Mauricio Aguilera Martínez

Este proyecto lo dedico a mi familia, quienes han estado durante todo este proceso, a mis hermanos por ser un ejemplo de vida, a mis padres que han hecho sacrificios inmensos para hacer de mi la persona que soy, a mi Universidad de San Buenaventura por todo el conocimiento y los buenos momentos, mis profesores por enseñarme todo lo acá plasmado, a mis amigos por estar ahí en las buenas y en las malas. Gracias.

Jorge Máximo Hernández Soto

5

TABLA DE CONTENIDO

INTRODUCCIÓN..............................................................................................12 1. PLANTEAMIENTO DEL PROBLEMA ....................................................13 1.1. ANTECEDENTES.....................................................................................13 1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA...........................14 1.3. JUSTIFICACIÓN ....................................................................................14 1.4. OBJETIVOS...........................................................................................15 1.4.1. Objetivo General. ...................................................................................15 1.4.2. Objetivos Específicos. ............................................................................15 1.5. ALCANCES Y LIMITACIONES ..............................................................15 1.5.1. Alcances.................................................................................................15 1.5.2. Limitaciones. ..........................................................................................16 2. MARCO DE REFERENCIA....................................................................17 2.1. TEORICO CONCEPTUAL .....................................................................17 2.1.1. Entrega por etapas.................................................................................19 2.1.2. Concepto de software. ...........................................................................20 2.1.3. Análisis de requerimientos. ....................................................................21 2.1.4. Diseño Global.........................................................................................21 2.1.5. Objetivo del Nivel 2 de CMMI.................................................................21 2.1.5.1. Áreas de proceso del Nivel 2 de CMMI...............................................22 2.1.5.2. Componentes y Área de proceso del Modelo CMMI..........................22 3. METODOLOGÍA ....................................................................................23 3.1. ENFOQUE DE LA INVESTIGACIÓN .....................................................23 3.2. LÍNEA DE INVESTIGACIÓN..................................................................23 3.2.1. Línea Institucional. .................................................................................23 3.2.2. Sub. Línea de la facultad de ingeniería. .................................................23 3.2.3. Campo de investigación. ........................................................................23 3.3. TÉCNICAS DE RECOLECCIÓN DE DATOS.........................................23 3.4. POBLACIÓN Y MUESTRA ....................................................................23 4. DESARROLLO INGENIERIL .................................................................25 4.1. METODOLOGIA DEL PROYECTO .......................................................25

6

4.2. CONCEPTO DE SOFTWARE................................................................25 4.2.1. Levantamiento de información. ..............................................................25 4.2.2. Descripción del Sistema.........................................................................26 4.2.3. Motor de base de datos propuesto.........................................................26 4.3. ANÁLISIS DE REQUERIMIENTOS .......................................................26 4.3.1. Requerimientos funcionales. ..................................................................26 4.3.2. Requerimientos no funcionales ..............................................................27 4.3.3. Casos de uso. ........................................................................................27 4.3.3.1. Actores............................................................................................27 4.3.3.2. Formatos y diagramas de Casos de Uso. .......................................27 4.4. DISEÑO GLOBAL. .................................................................................42 4.4.1. Diagramas de Secuencia. ......................................................................42 4.4.2. Diagramas de Secuencia Gestión de Requisitos. ..................................42 4.4.3. Diagramas de Secuencia Planificación del Proyecto. ............................43 4.4.4. Diagramas de Secuencia Monitorización y control del proyecto. ...........44 4.4.5. Diagramas de Secuencia Medición y Análisis........................................45 4.4.6. Diagramas de Secuencia Aseguramiento de Calidad. ...........................46 4.4.7. Diagramas de Secuencia Gestión de la Configuración. .........................47 4.4.8. Diagrama de Transición de Estados. .....................................................48 4.4.9. Mapa del Sitio. .......................................................................................50 4.4.10.Definición de pruebas………………………………………………………..54 4.4.10.1. Pruebas funcionales........................................................................54 4.4.10.2. Pruebas de rendimiento. .................................................................54 4.4.11.Definición de etapas…………………………………………………………54 4.4.12.Modelo de base de datos……………………………………………………55 4.5. ETAPA 1: INGRESO A LA PÁGINA PRINCIPAL...................................57 4.5.1. Diseño detallado. ...................................................................................57 4.5.2. Codificación............................................................................................57 4.6. ETAPA 2. MENU PÁGINA PRINCIPAL..................................................59 4.6.1. Diseño detallado. ...................................................................................59 4.6.2. Codificación. ..........................................................................................59 4.6.3. Pruebas de rendimiento. ........................................................................60 4.7. ETAPA 3. GESTION DE REQUISITOS .................................................60 4.7.1. Diseño detallado. ...................................................................................61 4.7.2. Codificación............................................................................................61 4.7.3. Pruebas de rendimiento. ........................................................................61 4.8. ETAPA CUATRO. PLANIFICACION DEL PROYECTO.........................63 4.8.1. Diseño detallado. ...................................................................................63 4.8.2. Codificación............................................................................................63

7

4.8.3. Pruebas de rendimiento. ........................................................................63 4.9. ETAPA QUINTA. MONITORIZACION Y CONTROL DEL PROYECTO.65 4.9.1. Diseño detallado. ...................................................................................65 4.9.2. Codificación............................................................................................65 4.9.3. Pruebas de rendimiento. ........................................................................65 4.10. ETAPA SEXTA. MEDICION Y ANALISIS...........................................67 4.10.1. Diseño detallado...…………………………………………………………..67 4.10.2 Codificación............................................................................................67 4.10.3.Pruebas de rendimiento. ........................................................................67 4.11. ETAPA SEPTIMA. ASEGURAMIENTO DE CALIDAD .......................69 4.11.1 Diseño detallado. ...................................................................................69 4.11.2 Codificación............................................................................................69 4.11.3.Pruebas de rendimiento. ........................................................................70 4.12. ETAPA OCTAVA. GESTION DE LA CONFIGURACION ...................71 4.12.1.Diseño detallado. ...................................................................................71 4.12.2 Codificación............................................................................................71 4.12.3.Pruebas de rendimiento. ........................................................................71 5. PRESENTACIÓN DE ANÁLISIS DE RESULTADOS.............................73 5.1. RESULTADO INGENIERIL ....................................................................73 5.2. RESULTADOS DE ENCUESTAS ..........................................................73 5.3. RETROALIMENTACIÓN........................................................................75 6. CONCLUSIONES ..................................................................................76 7. RECOMENDACIONES ..........................................................................78 BIBLIOGRAFÍA.................................................................................................79 WEBGRAFIA ....................................................................................................80 GLOSARIO .......................................................................................................81

8

LISTA DE FIGURAS

Pág. Figura 1. Modelo de ciclo de vida de entrega por etapas .................................20 Figura 2. Componentes del Modelo CMMI Nivel 2............................................22 Figura 4. Diagrama de casos de uso general. ..................................................29 Figura 5. Diagrama de casos de uso disponibilidad del servicio en línea. ........30 Figura 6. Diagrama de casos de uso autenticar usuario...................................31 Figura 7. Diagrama de casos de uso Seleccionar servicio de chequeo a realizar. .............................................................................................................32 Figura 8. Diagrama de casos de uso Gestión de requisitos..............................34 Figura 9. Diagrama de casos de uso planificación del proyecto. ......................35 Figura 10. Diagrama de casos de uso monitorización y control del proyecto. ..36 Figura 11. Diagrama de casos de uso medición y análisis. ..............................37 Figura 12. Diagrama de casos de uso Aseguramiento de calidad. ...................39 Figura 13. Diagrama de casos de uso Gestión de la configuración. .................41 Figura 14. Diagrama de secuencia gestión de requisitos. ................................42 Figura 15. Diagrama de secuencia planificación del proyecto. .........................43 Figura 16. Diagrama de secuencia Monitorización y control del proyecto. .......44 Figura 17. Diagrama de secuencia medición y análisis. ...................................45 Figura 18. Diagrama de secuencia aseguramiento de calidad. ........................46 Figura 19. Diagrama de secuencia gestión de la Configuración. ......................47 Figura 20. Representación gráfica del diagrama de transición de estados.......48 Figura 21. Mapa del sitio...................................................................................50 Figura 22. Diseño Base de datos......................................................................56

9

Figura 23. Diseño pagina principal....................................................................57 Figura 24. Diseño menú, pagina principal.........................................................59 Figura 25. Gestión de Requisitos......................................................................61 Figura 26. Planificación del Proyecto................................................................63 Figura 27. Monitorización y Control del Proyecto..............................................65 Figura 28. Medición y Análisis. .........................................................................67 Figura 29. Aseguramiento de Calidad...............................................................69 Figura 30. Gestión de la Configuración.............................................................71 Figura 31. Resultados Encuesta – Pregunta 1..................................................73 Figura 32. Resultados Encuesta – Preguntas 2, 3............................................74 Figura 33. Resultados Encuesta – Preguntas 4, 5............................................74 Figura 34. Resultados Encuesta – Preguntas 6, 7, 8........................................75

10

LISTA DE TABLAS

Pág. Tabla 1. Clasificación de empresas………………………………………………. 14 Tabla 2. Identificar disponibilidad del servicio en línea…………………………. 30 Tabla 3. Autenticar usuario………………………………………………………….31 Tabla 4. Seleccionar servicio de chequeo a realizar……………………………..32 Tabla 5. Gestión de requisitos………………………………………………………33 Tabla 6. Planificación del proyecto…………………………………………………34 Tabla 7. Monitorización y control del proyecto……………………………………35 Tabla 8. Medición y análisis…………………………………………………………36 Tabla 9. Aseguramiento de calidad………………………………………………...38 Tabla 10. Gestión de la configuración……………………………………………..40 Tabla 11 Prueba Rendimiento etapa 1…………………………………………….58 Tabla 12. Prueba Rendimiento etapa 2……………………………………………60 Tabla 13. Prueba Rendimiento etapa 3……………………………………………62 Tabla 14. Prueba Rendimiento etapa 4……………………………………………64 Tabla 15. Prueba Rendimiento etapa 5……………………………………………66 Tabla 16. Prueba Rendimiento etapa 6……………………………………………68 Tabla 17. Prueba Rendimiento etapa 7……………………………………………70 Tabla 18. Prueba Rendimiento etapa 8……………………………………………72

11

LISTA ANEXOS

Pág.

ANEXO 1. Encuesta…………………………………………………………………82 ANEXO 2. Ficha técnica y resultados encuestas…………………………………83 ANEXO 3. Marco Legal……………………………………………………………...85 ANEXO 4. Check List creados……………………………………………………...89 ANEXO 5. Manual Usuario………………………………………………………….99

12

INTRODUCCIÓN

El concepto de calidad ha tomado mayor fuerza en los distintos tipos de empresas, siendo este uno de los mayores referentes a la hora de hacer negocios. Este conocimiento no es ajeno al software. A medida que el tiempo trascurrió se hizo más evidente la escasez de metodologías que permitieran evaluar las diferentes etapas de vida que conlleva el diseño y desarrollo de software, generando un problema continuo ya que el software podía funcionar de manera correcta pero no realizaba la tarea para la cual era diseñado, generando infinidad de convenientes como la extensión de los plazos de entrega, incremento en los costos, re-diseño de la aplicación, etc. traduciéndose en pérdidas costos de garantías para las empresas desarrolladoras. Cuando se piensa en implementar una metodología que evalúe la calidad en los procesos con los cuales un software es desarrollado, las empresas tienden a pensarlo más de dos veces, ya que todo esto es un proceso costoso y dispendioso con el cual pueden cumplir o no los requisitos para poder certificarse en algunas de las metodologías existentes, con este proyecto no pretendemos crear una nueva metodología, sino dar unos lineamientos con los cuales las PYMES puedan comprobar si están listas para poder realizar una valoración a nivel 2 en CMMI.

13

1. PLANTEAMIENTO DEL PROBLEMA

1.1. ANTECEDENTES Durante los primeros años de la informática, el software se consideraba como un añadido. La programación era un "arte", para el que no existían metodologías, era un proceso que se realizaba sin planificación alguna. En esta época toda la programación se desarrollaba en la medida para cada necesidad concreta, y en consecuencia tenía muy poca difusión, habitualmente quien lo escribía era porque lo necesitaba, y era quien lo mantenía. La Ingeniería del Software, es el término utilizado por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN celebrada en Garmisch (Alemania)1, en octubre de 1968, previamente había sido utilizado por el holandés Edsger Dijkstra en su obra The Humble Programmer. Puede definirse según Alan Davis como "la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de costos razonable, de software que satisfaga las necesidades de los usuarios" .En una segunda época (a partir de mitad de la década de 1960) se estableció el software como producto y aparecieron las empresas dedicadas al desarrollo y distribución masiva del mismo. La tercera era comenzó a mediados de la década de 1970, época en la que los sistemas informáticos aumentaron mucho en su complejidad, y nacieron las redes de computadores. Esto supuso mucha presión para los desarrolladores, aunque los computadores para uso personal, apenas estaban difundidos. En la década de 1980 el departamento de defensa de los Estados Unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos crecían sin control, las fechas se alargaban cada vez más. Siendo esta situación algo intolerable ,se decidió convocar a un comité de expertos para que solucionase estos problemas, es así que en el año 1983 dicho comité concluyó que se debía crea un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa de este país. Software Engineering Institute (SEI)2 es un instituto federal estadounidense de investigación y desarrollo, fundado por el Congreso de los Estados Unidos en 1984 para desarrollar modelos de evaluación y mejora en el desarrollo de software, que dieran respuesta a los problemas que generaba al ejército estadounidense la programación e integración de los subsistemas de software

1 Universidad de Sevilla – España //www.lsi.us.es 2008/10/10 5:20 pm 2 Buscador Web - //www.wikipedia.org 2008/10/10 5:25 pm

14

en la construcción de complejos sistemas militares. Financiado por el Departamento de Defensa de los Estados Unidos y administrado por la Universidad Carnegie Mellon. Permitiendo que se pudiese desarrollar un modelo de calidad del software, este se define como un conjunto de buenas prácticas para el ciclo de vida del software.

1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA En Colombia son pocas las medianas empresas de desarrollo de software que implementan procesos de aseguramiento de la calidad, debido a su poco conocimiento del mercado y pocos recursos económicos no se pueden certificar o implementar modelos de calidad en los diferentes estándares que existen para desarrollar software de alta calidad. Hoy en día el país cuenta con gran número de empresas desarrolladoras de software, las cuales a su vez trabajan y sirven a una gran parte de las grandes compañías del país en el desarrollo de sus plataformas, páginas Web, software a la medida, entre otros. De aquí dichas compañías deben cerciorarse que los productos que diseñan, e implementan para entregar a sus clientes son de la más alta calidad posible. Tabla 1. Clasificación de empresas MICRO EMPRESA Activo inferior a 500SMMLV PEQUEÑA EMPRESA Activo entre 501 y 5000 SMMLV MEDIANA EMPRESA Activo entre 5001 y 15000 SMMLV GRANDE EMPRESA Activo superiores a 15001 SMMLV

A partir de estos sucesos se puede formular la siguiente pregunta de investigación ¿Qué características técnicas y funcionales debe tener una herramienta auditora para verificar el cumplimiento de todos los requisitos en el desarrollo de software de alta calidad?

1.3. JUSTIFICACIÓN Con el desarrollo de este proyecto se pretende que las empresas puedan autoevaluar sus procesos de desarrollo de software mediante la verificación de los procesos de alta calidad estipulados en el nivel dos (2) del estándar de calidad de CMMI, que se deben cumplir para que el producto final tenga un alto nivel de confiabilidad y que cumpla todos los requisitos que desea el cliente.

15

Lo anterior, con la finalidad que las empresas puedan incursionar en nuevos mercados, así como, el asegurar la calidad del software desarrollado tanto para exportación como para consumo interno en el país. Se realizó una encuesta a Ingenieros de empresas de desarrollo y calidad de software (Ver figuras 31, 32, 33 y 34) y una vez obtenidos los resultados de esta, se determinó que el 100% de los Ingenieros encuestados que trabajan en este tipo de compañías creen que es fiable la implementación de este producto en sus respectivas empresas. Los ingeni0eros necesitan tener una herramienta que les facilite los procesos de verificación de calidad. Según los resultados, a ellos les gustaría que se implementara este medio de verificación de calidad para el desarrollo de sus actividades.

1.4. OBJETIVOS 1.4.1. Objetivo General. Diseñar una herramienta que permita realizar una auditoría a medianas empresas desarrolladoras de software según el estándar de calidad del nivel 2 de CMMI, bajo el criterio de comprobación por Check List.

1.4.2. Objetivos Específicos. • Determinar las características fundamentales de aseguramiento de calidad

del modelo CMMI aplicables al contexto nacional. Nivel 2. • Diseñar los Check List a implementar en la herramienta según las

características determinadas en el modelo de calidad CMMI nivel 2. • Determinar los requerimientos funcionales y no funcionales para el desarrollo

de la herramienta de aseguramiento de calidad. • Diseñar un prototipo funcional de la herramienta de auditoría diseñada. • Realizar las pruebas de modelamiento de datos para verificar usabilidad y

veracidad de los resultados.

1.5. ALCANCES Y LIMITACIONES 1.5.1. Alcances. El producto final debe ser un diseño funcional del software que verifique mediante chequeos de lista y métricas establecidas, que la compañía a la que se le realice esta prueba, cumpla con lo requerido en el modelo CMMI Nivel 2 para la buena elaboración y desarrollo de software de alta calidad. Como producto de este proyecto se entregará un diseño funcional de software y el prototipo de la herramienta de auditoría desarrollada, así como los respectivos manuales técnicos y de usuario que soportan dicha aplicación.

16

1.5.2. Limitaciones. Este proyecto propondrá el modelamiento y diseño de una herramienta de software para la auditoría de los procesos de desarrollo del software con miras al aseguramiento de la calidad de este en las medianas empresas, su posterior desarrollo e implementación en empresas del sector no está contemplada pues depende de estas.

17

2. MARCO DE REFERENCIA

2.1. TEORICO CONCEPTUAL

Para poder diseñar, modelar e implementar este proyecto es indispensable conocer en qué consiste la auditoría y el aseguramiento de calidad en las empresas de desarrollo de software y cuáles son sus ventajas y desventajas.

La auditoria se define como el proceso sistemático que consiste en obtener y evaluar puntualmente las evidencias sobre eventos, ya sean económicos, informáticos, etc. Con el fin de determinar el grado de certeza en los criterios o normas ya establecidas, para luego realizar un informe detallado, por esto lo que se realizará es una auditoría de sistemas, ya que esta es la encargada de realizar la evaluación de normas, controles, técnicas y procedimientos que se tienen establecidos en una empresa para lograr confiabilidad, oportunidad, seguridad y confidencialidad de la información que se procesa a través de los sistemas de información. La auditoría de sistemas es una rama especializada de la auditoría que promueve y aplica conceptos de auditoría en el área de sistemas de información. El desarrollo de un software auditor es el objetivo final para el control de procesos y supervisión, capaz de estar ejerciendo un control continuo de las operaciones del área de procesamiento y de desarrollo de software. Para lo que se tiene en cuenta la manera correcta para cumplir con las necesidades del cliente de una manera óptima. Es necesario hablar del aseguramiento de la calidad porque consiste en tener y seguir un conjunto de acciones planificadas y sistemáticas, implantadas dentro del Sistema de Calidad de la empresa. Estas acciones deben ser demostrables para proporcionar la confianza adecuada (tanto a la propia empresa como a los clientes) de que se cumplen los requisitos del Sistema de la calidad. Esta herramienta de auditoría de desarrollo de software va dirigida hacia las medianas empresas (PYMES) que generan software, por lo que esta herramienta apoyará los procesos de evolución del software que se va a desarrollar. Por lo cual se evaluaran los procesos del desarrollo por medio del modelo CMMI Nivel 2 para así lograr el cumplimiento de la meta que es desarrollar software con calidad entre los estándares de las norma ISO para la producción de un producto de calidad. La auditoría de desarrollo de software generará un gran impacto sobre las medianas empresas que producen software ya que por medio de esta herramienta se logrará obtener mejoras en la eficiencia, integridad,

18

confiabilidad y la calidad que deben ser satisfechos en la generación de software3. Los Factores que determinan la calidad del software se clasifican en tres grupos:

• Operaciones del producto • Revisión del producto • Transición del producto

Es difícil, y en algunos casos imposibles, desarrollar medidas directas de los factores de calidad del software. Cada factor de calidad4 Fc se puede obtener como combinación de una o varias métricas: Fc= c1 * m1 + c2 * m2 + … + cn * mn

• ci factor de ponderación de la métrica i, que dependerá de cada aplicación específica

• mi métrica i • Habitualmente se puntúan de 0 a 10 en las métricas y en los factores de

calidad Las métricas para el aseguramiento de la calidad de software son:

• Facilidad de auditoría • Exactitud • Normalización de las comunicaciones • Completitud • Concisión • Consistencia • Estandarización de los datos • Tolerancia de errores • Eficiencia de la ejecución • Facilidad de expansión • Generalidad • Independencia del hardware • Instrumentación • Modularidad • Facilidad de operación • Seguridad

3 Metodología para el desarrollo de Software, http://www.scribd.com/doc/8255409/Metodologias-para-la-geston-y-desarrollo-de-Software 2008/10/12 2:30 pm 4 http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF

19

• Auto documentación • Simplicidad • Independencia del sistema software • Facilidad de traza • Formación

2.1.1. Entrega por etapas. La entrega por etapas es un modelo del ciclo de vida clásico en el que el software se desarrolla en etapas sucesivas, desarrollando normalmente las capacidades más importantes. Además esta metodología mejora más la planificación percibida que la planificación real (Ver Figura 1).

Las características más sobresalientes de esta metodología son:

• Detección precoz de problemas, cuando se planifica hacer entregas iniciales y

frecuentes, se obtiene informes de progreso frecuente e indiscutible. Si el proyecto posee problemas, se descubrirán dentro de la primera o segunda entrega, no hay que esperar hasta que finalice todo el desarrollo.

• Reducir el error de estimación, la entrega por etapas evita el problema de la

mala estimación entregando pronto y frecuentemente. En vez de hacer una gran estimación para el proyecto completo, puede hacer varias estimaciones pequeñas para muchas entregas.

• Mejora de la calidad del código, en algunos enfoques tradicionales se sabe que

alguien leerá el código y tendrá que mantenerlo, en entrega por etapas se hace necesario leer el código y modificarlo muchas veces.

20

Figura 1. Modelo de ciclo de vida de entrega por etapas

El número y el contenido de las etapas se definen una vez se tengan los requerimientos y el diseño global del software. En el proceso de concepto de software se define el sistema, partiendo de un levantamiento de información con los usuarios finales, donde se determinarán los requerimientos funcionales y los no funcionales. En el Análisis de requerimientos se identifican y definen los casos de uso y actores del sistema, para limitar y definir las funcionalidades del sistema. En el Diseño global se establece la arquitectura del sistema, se diseña el modelo de base de datos a usar y se realiza un modelo de transición de estados. 2.1.2. Concepto de software. En el levantamiento de información se usan diferentes técnicas para la recolección de requerimientos, entre ellas se pueden mencionar las entrevistas, encuestas, visitas de campo, revisión de registros, entre otras. Para el levantamiento de información de la herramienta auditora de calidad, se utilizaron las encuestas como técnica de recolección, debido a que el problema radica en la capacidad de las empresas para desarrollar software de alta calidad según los estándares y mediciones establecidas. A partir de las técnicas de recolección se obtuvieron las necesidades del usuario, con el fin de llegar a la Descripción del Sistema.

21

2.1.3. Análisis de requerimientos. En el análisis de requerimientos se busca comprender los requisitos del sistema logrando la estructuración de una solución, se contesta la pregunta del “que” del sistema. A partir del levantamiento de información realizado, se organizarán los requerimientos según su tipo, es decir, Funcionales y No Funcionales. 2.1.4. Diseño Global. En el diseño global se transforma la arquitectura general de análisis, a una arquitectura particular y detallada del sistema que satisfaga todos los requisitos del sistema, donde las condiciones idealizadas durante el análisis se reemplazan por requisitos del ambiente de implantación particular. Se contesta la pregunta del “cómo” del sistema. Se define la arquitectura del sistema teniendo en cuenta los requerimientos no funcionales del sistema. 2.1.5. Objetivo del Nivel 2 de CMMI. El objetivo principal del nivel 2 de CMM-CMMI es que en los proyectos de la organización exista una gestión de los requisitos y que los procesos (formas de hacer las cosas) estén planeados, ejecutados, medidos y controlados5. Explicado un poco más: • El uso de los procesos al nivel administrado permitirá que la forma de trabajar permanezca aun cuando hay problemas de fechas. Cuando se realizan estas prácticas, los proyectos se ejecutan y gestionan de acuerdo con los planes del proyecto. • El estado de los componentes de trabajo (análisis, diseño, código, documentación,…) están visibles (estado de avance) a la gerencia en puntos definidos (hitos del proyecto). Se sabe cuánto trabajo está hecho y cuánto queda por hacer. • Los compromisos adquiridos con todas las personas involucradas en el proyecto se revisan de acuerdo a las necesidades. Los elementos de trabajo se revisan con las personas involucradas y son controlados. Estos elementos de trabajo satisfacen las especificaciones, estándares y objetivos. • No todas las áreas de CMMI nivel 2 hacen parte del proyecto, ya que de acuerdo al análisis no se tomo el área de gestión de proveedores debido a que esta área se enfoca más a las maquilas que son contratadas por las empresas para realizar desarrollos de diversas índoles.

5 Axentia - http://www.sergiovillagra.com/Contenidos/Recursos/WP03%20Una%20Introduccion%20a%20CMMI.pdf 2009/09/15 1:25 pm

22

2.1.5.1. Áreas de proceso del Nivel 2 de CMMI 6. Estas ideas se materializan en las siguientes áreas de proceso, estas son las áreas que manejara la herramienta prototipo:

• Gestión de Requisitos (CM) • Planificación de proyectos (PP) • Monitorización y Control de proyectos • Medición y Análisis • Aseguramiento de la calidad (PPQA) • Gestión de la configuración

2.1.5.2. Componentes y Área de proceso del Modelo CMMI. Figura 2. Componentes del Modelo CMMI Nivel 2

Un área de proceso es un conjunto de prácticas relacionadas que cuando son implementadas colectivamente, satisfacen un conjunto de objetivos considerados importantes para mejorar esa área de proceso7.

6 http://www.ingenierosoftware.com/.../cmm-cmmi-nivel-2.php 7 Monografias. Modelo de calidad - http://www.monografias.com/trabajos57/modelo-calidad-cmmi/modelo-calidad-cmmi2.shtml 2009/09/15 2:10 pm

23

3. METODOLOGÍA

3.1. ENFOQUE DE LA INVESTIGACIÓN

Empírico-analítico: cuyo interés es el técnico, orientado a la interpretación y transformación del mundo material; proporciona una estructura particular a la metodología de investigación en tanto que orienta el trabajo a la contraestación permanente de las aseveraciones teóricas con la verificación experimental, de manera que los cálculos generados a través de modelos matemáticos y simulaciones computacionales se deben retroalimentar con la experimentación, en la búsqueda de información cada vez mas confiable y práctica para la solución del problema. Esta simbiótica debe llevar consigo una relación teórica al menos presumible entre variables, de manera que se puedan establecer relaciones funcionales entre ellas; igualmente y de acuerdo con los medios experimentales, también se deben establecer los parámetros experimentales convenientes.

3.2. LÍNEA DE INVESTIGACIÓN 3.2.1. Línea Institucional. Tecnologías actuales y sociedad. 3.2.2. Sub. Línea de la facultad de ingeniería. Sistemas de información y

comunicación.

3.2.3. Campo de investigación. Auditoría Informática.

3.3. TÉCNICAS DE RECOLECCIÓN DE DATOS La recopilación de la información para el desarrollo de este proyecto se basa en investigación documental en primera instancia y posteriormente se realizarán encuestas a pequeños y medianos desarrolladores y por último se aplicará un Check List con el fin de poder generar los parámetros básicos de la herramienta a desarrollar. Estos Check List se realizaron basados en el estudio de CMMI para nivel 2 por los integrantes del grupo.

3.4. POBLACIÓN Y MUESTRA

Las encuestas a elaborar se realizarán a diversas empresas desarrolladoras de software de la zona en que nos movemos, es decir, principalmente de Bogotá D.C. Teniendo en cuenta las siguientes personas:

24

• Ingenieros de sistemas • Desarrolladores de software • Consultores • Analistas • Diseñadores de software • Documentadores • Gerentes de las compañías • Presidentes de las compañías • Personal de recursos humanos

o Dichas encuestas se harán alrededor de 50 encuestas para tener un buen grupo de trabajo de datos.

25

4. DESARROLLO INGENIERIL

4.1. METODOLOGIA DEL PROYECTO Las metodologías orientan por medio de métodos y técnicas, el camino correcto para la creación y uso de software, llevándolas a cabo durante la ejecución y el mantenimiento de este. La aplicación para auditar los procesos de verificación de calidad, cuenta con el apoyo de una metodología que respaldará su información, ejecución y mantenimiento de modo que cuente con la mejor calidad, basándose en la Ingeniería de software. Para la selección de la metodología, se debe tener en cuenta que la aplicación es considerada un sistema flexible, reutilizable, y documentado8. Es por esto que la metodología utilizada durante el desarrollo de la aplicación es la denominada “Entrega por Etapas”, debido a que esta metodología, además de reducir los riesgos implícitos en la construcción del producto de software, también mejora la visibilidad del progreso del producto.

4.2. CONCEPTO DE SOFTWARE 4.2.1. Levantamiento de información. Para llevar a cabo el proceso de levantamiento de información se seleccionaron diferentes Ingenieros de Sistemas de empresas desarrolladores de software de Bogotá D.C. Al azar. A cada uno de ellos se le realizó una encuesta de tipo no probabilístico con muestreo accidental. Estas encuestas fueron realizadas en su totalidad por por los integrantes del grupo mediante el estudio de CMMI a nivel 2 y los aspectos más importantes para el contexto empresarial Colombiano.

•••• Aporte de los encuestados: Los encuestados coincidieron en que la herramienta para verificar la calidad del software debe ser intuitiva y fácil de usar. Los servicios más importantes que debe tener el producto son: Operaciones del producto, Revisión del producto y Transición del producto.

La gran mayoría de estas personas conocen los estándares de calidad existentes y tienen presente que requerimientos se deben cumplir para el cumplimiento de dichos estándares.

• Necesidades del usuario: Se requiere información disponible, al detalle y consolidada. Obtener los resultados de las métricas que se ingresen para

8 MCCONNELL, Steve, Desarrollo y Gestión de Proyectos Informáticos. Madrid McGraw-Hill.1996. p592.

26

verificar el estado del producto que se esta desarrollando. 4.2.2. Descripción del Sistema. La herramienta es accesible a través de un portal Web que se deberá montar en el Servidor Web interno de la compañía, al cual debe dársele una dirección interna y que solo tenga acceso el personal escogido para esta labor. Una vez montada la aplicación el acceso es restringido y para ejecutarse se requiere de logearse, el usuario deberá tener cuenta de usuario y contraseña, esta deberá estar sujeta al controlador del dominio de la compañía ya que deberá ser el mismo usuario y contraseña con las que acceda al sistema en general de la compañía. La aplicación presenta en su pantalla principal el nombre de la aplicación, información básica sobre el manejo del producto, las opciones con las cuales se presenta la ejecución de la herramienta y dos (2) links, uno del mapa de sitio completo y el segundo para las instrucciones de uso. 4.3. Motor de base de datos propuesto. MySQL es un gestor que posee

muchas características; una de las principales es la gran velocidad en la ejecución de consultas a la base de datos comparado con Postgress que es 2 o 3 veces más lento que MySQL9. Cabe destacar que una de las razones más importantes para elegir Mysql es la integración que posee con el lenguaje seleccionado que es php, la conexión se realiza de manera sencilla, además no consume tantos recursos como lo haría Postgresql. Mysql posee mayor rendimiento y mayor velocidad al conectar con el servidor y la cantidad de información y documentación que existe para Mysql es mucho mayor que para Postgress. Respecto a Oracle la cantidad de recursos que consume y la simplicidad del diseño de la base de datos no da lugar para realizarla bajo este sistema gestor.

4.4. ANÁLISIS DE REQUERIMIENTOS 4.4.1. Requerimientos funcionales. A continuación se encuentra el listado de requerimientos funcionales identificados: • Autenticación e identificación del servidor donde se va a montar la aplicación. • Validación correcta de los campos de cada formulario (Check List). • Consulta rápida de los resultados obtenidos después de realizar el chequeo de aspectos generales. • Consulta rápida de los resultados obtenidos después de realizar el chequeo de planificación del proyecto. 9 PostGreSQL vs. MysSQL, http://www.netpecos.org/dosg/mysql_postgres/x108.html , 07/08/2008 10:45 AM.

27

• Consulta rápida de los resultados obtenidos después de realizar el chequeo de gestión de requisitos. • Consulta rápida de los resultados obtenidos después de realizar el chequeo de resultados del desarrollo. 4.4.2. Requerimientos no funcionales . A continuación se encuentra el listado de requerimientos no funcionales identificados: • El sistema debe ser desarrollado en PHP debido a que este lenguaje puede utilizarse en conjunto con HTML y XHTML. • La disponibilidad debe ser equivalente a la que trabaje el servidor que soporta el portal Web de donde se valla a montar. • El tiempo de respuesta accediendo a la página principal de la aplicación debe ser menor a 20 segundos. • El tiempo de respuesta en el redireccionamiento entre página principal y secundarias debe ser menor a 20 segundos. 4.3.3. Casos de uso. Los casos de uso permiten identificar los requerimientos necesarios para el buen funcionamiento del prototipo, a continuación se definen los actores y los casos de uso. Los casos de uso han sido realizado por los integrantes del grupo, habiendo estudiado el ciclo de vida del proyecto y habiendo extraído la información con la cual se va a realizar el proyecto, se hizo un estudio ingenieril de la información que se posee y se procedió a realizar los casos de uso para modelar la interacción del usuario con el sistema. 4.3.3.1. Actores. En el desarrollo del prototipo para la verificación de Software de Calidad para las medianas empresas desarrolladoras de software en Bogotá D.C., se encuentra un (1) solo actor principal, que corresponden “Gestor de calidad ”, (teniendo en cuenta que este actor puede ser cualquier persona del grupo de trabajo encargado en la planificación, desarrollo, control y ejecución del proyecto). No existe el actor “Administrador” en este proyecto, ya que la información presentada será solo verificaciones que se haga con el sistema, es decir toda la información estará implícita en el programa y este solo entrará a compilarla y dar un resultado final de aprobación o no y se guardaran los resultados en la base de datos. 4.3.3.2. Formatos y diagramas de Casos de Uso. El diagrama de casos de uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.

28

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: • Actores. • Casos de uso. • Relaciones entre casos de uso. Los formatos de casos de uso definen los objetivos, actores, curso normal de eventos, precondiciones, flujo alternativo de eventos, poscondiciones, entre otros. Todos los formatos de casos de uso fueron realizados por el grupo de trabajo, extrayendo de la información capturada y con los conocimientos en el tema se produjo cada caso de uso para modelar el flujo de la información con la que cuenta el usuario para realizar esta validación de calidad de software, para mas detalle del ciclo de trabajo a realizar ver (figura 4, figura 5, figura 6, figura 7, figura 8, figura 9, figura 10, figura 11, figura 12 y figura 13).

29

Figura 4. Diagrama de casos de uso general.

En este primer caso de uso, se muestra toda la iteración del usuario (Gestor), con el sistema, se modelan los nueve (9) casos de uso que se seleccionaron para toda la validación del sistema. En este caso general se ve desde como el usuario entra al sistema, se valida, hasta como realiza cada etapa del sistema, ya se entrara a ver en cada diagrama como es la iteración del usuario con el sistema mas específicamente.

30

Tabla 2. Identificar disponibilidad del servicio en línea. Caso de uso Identificar Disponibilidad

del Servicio en Línea. Código: C1

Objetivo Identificar si el servicio está en línea, para poder acceder a la URL destinada.

Actores Gestor Curso normal de eventos 1. El Gestor ingresa la URL en donde

se encuentra el aplicativo 2. Dependiendo si el sitio está activo y la URL es correcta deberá ingresar al portal, de lo contrario saldrá fallo de conexión.

Precondiciones El Gestor debe tener un dispositivo (PC) y saber la URL donde se encuentra la herramienta para poder acceder.

Flujo alternativo de eventos Ninguno Poscondiciones Usuario redirigido a la página principal

para autenticarse. Figura 5. Diagrama de casos de uso disponibilidad del servicio en línea.

Este diagrama muestra como el usuario ingresa al sistema, y por funciones internas del servidor Web de la compañía al ingresar la URL en la cual este guardado el portal, deberá estar en línea para poder ingresar, de lo contrario el mismo sistema debe informar al usuario que no esta disponible.

31

Tabla 3. Autenticar usuario. Caso de uso Autenticar usuario Código: C2 Objetivo Permitir el acceso al sistema Actores Gestor Curso normal de eventos 1. El gestor ingresa su nombre de

usuario y su contraseña 2. El gestor envía los datos al servidor

Precondiciones 1. C1. 2. El gestor debe trabajar en la empresa y tener nombre de usuario, contraseña y permisos

Flujo alternativo de eventos 3. Nombre de usuario o contraseña incorrectas, o usuario sin permisos, el servidor debe informar al gestor que los datos no son validos o de lo contrario no está registrado

Poscondiciones Usuario autenticado en el sistema Figura 6. Diagrama de casos de uso autenticar usuario.

Este diagrama muestra como una vez ingresada la URL destino y el sistema estando en línea, enviara al usuario al pantallazo principal del portal, donde le pedirá que se identifique, el usuario deberá colocar aquí su nombre de usuario y contraseña.

32

Tabla 4. Seleccionar servicio de chequeo a realizar. Caso de uso Seleccionar servicio de

Chequeo a Realizar. Código: C3

Objetivo Seleccionar el servicio deseado, ya sea: • Gestión de Requisitos • Planificación de proyectos • Monitorización y Control de

proyectos • Medición y Análisis • Aseguramiento de la calidad • Gestión de la configuración

Actores Gestor Curso normal de eventos 1. El gestor mediante una serie de lista

donde se encuentran las opciones, debe seleccionar el chequeo que desea realizar.

Precondiciones 1. C2. Flujo alternativo de eventos 2. No elegir ningún chequeo a realizar. Poscondiciones Usuario redirigido a la página del

chequeo que haya seleccionado. Figura 7. Diagrama de casos de uso Seleccionar servicio de chequeo a realizar.

33

Este diagrama muestra como el usuario una vez validado sus datos, es llevado a la página donde encontrara el menú de selección para comenzar a realizar su labor de gestor de calidad. Tabla 5. Gestión de requisitos. Caso de uso Gestión de requisitos Código: C4 Objetivo Realizar una verificación de las

acciones que se hacen en el desarrollo del software mediante un Check List, a la gestión de requisitos.

Actores Gestor Curso normal de eventos 1. El Gestor elige en el menú de

servicios la opción “Gestión de requisitos 2. El Gestor accede a una pantalla en donde se encuentra el listado del chequeo a realizar a la gestión de requisitos y lo efectúa.

Precondiciones C3 Flujo alternativo de eventos Ninguno Poscondiciones Chequeo de Gestión de requisitos

realizado.

34

Figura 8. Diagrama de casos de uso Gestión de requisitos.

Este diagrama muestra como el usuario comienza su labor y escoge un primer chequeo a realizar, en este caso Gestión de Requisitos. Tabla 6. Planificación del proyecto. Caso de uso Planificación del

Proyecto. Código: C5

Objetivo Realizar una verificación de las acciones que se hacen en el desarrollo del software mediante un Check List, a la planificación del proyecto.


servicios la opción “Planificación del Proyecto”. 2. El Gestor accede a una pantalla en donde se encuentra el listado del chequeo a realizar a la planificación del proyecto y lo efectúa.

35

Precondiciones C3 Flujo alternativo de eventos Ninguno Poscondiciones Chequeo de la planificación del

proyecto realizado. Figura 9. Diagrama de casos de uso planificación del proyecto.

Este diagrama muestra como el usuario sigue con su labor y escoge un otro chequeo a realizar, en este caso Planificación del Proyecto.

Tabla 7. Monitorización y control del proyecto. Caso de uso Monitorización y control

del proyecto. Código: C6

Objetivo Realizar una verificación de las acciones que se hacen en el desarrollo del software mediante un Check List, a la monitorización y control del proyecto.


servicios la opción “Monitorización y control del proyecto”. 2. El Gestor accede a una pantalla en

36

donde se encuentra el listado del chequeo a realizar a la monitorización y control del proyecto y lo efectúa.

Precondiciones C3 Flujo alternativo de eventos Ninguno Poscondiciones Chequeo de la monitorización y

control del proyecto realizado. Figura 10. Diagrama de casos de uso monitorización y control del proyecto.

Este diagrama muestra como el usuario sigue con su labor y escoge un otro chequeo a realizar, en este caso Monitorización y Control del Proyecto. Tabla 8. Medición y análisis. Caso de uso Medición y análisis. Código: C7 Objetivo Realizar una verificación de las

acciones que se hacen en el desarrollo del software mediante un Check List, a la medición y análisis.

Actores Gestor

37

Curso normal de eventos 1. El Gestor elige en el menú de servicios la opción “medición y análisis”. 2. El Gestor accede a una pantalla en donde se encuentra el listado del chequeo a realizar a la medición y análisis y lo efectúa.

Precondiciones C3 Flujo alternativo de eventos Ninguno Poscondiciones Chequeo de la medición y análisis

realizado.

Figura 11. Diagrama de casos de uso medición y análisis.

Este diagrama muestra como el usuario sigue con su labor y escoge un otro chequeo a realizar, en este caso Medición y Análisis.

38

Tabla 9. Aseguramiento de calidad. Caso de uso Aseguramiento de

calidad. Código: C8

Objetivo Realizar una verificación de las acciones que se hacen en el desarrollo del software mediante un Check List, al aseguramiento de calidad.


servicios la opción “aseguramiento de calidad”. 2. El Gestor accede a una pantalla en donde se encuentra el listado del chequeo a realizar al aseguramiento de calidad y lo efectúa.

Precondiciones C3 Flujo alternativo de eventos Ninguno Poscondiciones Chequeo del aseguramiento de

calidad realizado.

39

Figura 12. Diagrama de casos de uso Aseguramiento de calidad.

Este diagrama muestra como el usuario sigue con su labor y escoge un otro chequeo a realizar, en este caso Aseguramiento de Calidad.

40

Tabla 10. Gestión de la configuración. Caso de uso Gestión de la

configuración. Código: C9

Objetivo Realizar una verificación de las acciones que se hacen en el desarrollo del software mediante un Check List, a la gestión de la configuración.


servicios la opción “gestión de la configuración”. 2. El Gestor accede a una pantalla en donde se encuentra el listado del chequeo a realizar a la gestión de la configuración y lo efectúa.

Precondiciones C3 Flujo alternativo de eventos Ninguno Poscondiciones Chequeo de la gestión de la

configuración realizado.

41

Figura 13. Diagrama de casos de uso Gestión de la configuración.

Este diagrama muestra como por ultimo el usuario escoge el último chequeo a realizar, en este caso Gestión de la Configuración.

42

4.5. DISEÑO GLOBAL. 4.5.1. Diagramas de Secuencia. Se realizaron diagramas de secuencia para mostrar los objetos como líneas de vida a lo largo de cada servicio y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. En este caso solo se encuentran seis (6) diagramas de secuencia, uno para los aspectos generales, otro para la planificación del proyecto, otro para la gestión de requisitos y otro para los resultados del desarrollo. (Ver figura 14, figura 15, figura 16, figura 17, figura 18 y figura 19). 4.5.2. Diagramas de Secuencia Gestión de Requisitos . Figura 14. Diagrama de secuencia gestión de requisitos.

43

4.5.3. Diagramas de Secuencia Planificación del Pro yecto.

Figura 15. Diagrama de secuencia planificación del proyecto.

44

4.5.4. Diagramas de Secuencia Monitorización y cont rol del proyecto.

Figura 16. Diagrama de secuencia Monitorización y control del proyecto.

45

4.5.5. Diagramas de Secuencia Medición y Análisis.

Figura 17. Diagrama de secuencia medición y análisis.

46

4.5.6. Diagramas de Secuencia Aseguramiento de Cali dad.

Figura 18. Diagrama de secuencia aseguramiento de calidad.

47

4.5.7. Diagramas de Secuencia Gestión de la Configu ración.

Figura 19. Diagrama de secuencia gestión de la Configuración.

48

4.5.8. Diagrama de Transición de Estados. Se utilizaron diagramas de transición de estados para modelar aspectos dinámicos del sistema y modelar el comportamiento individual de cada objeto durante su ciclo de vida. El comportamiento de un objeto es modelado en términos del estado en el cual se encuentra, qué acciones se ejecutan en cada estado y cuál es el estado al que transita después de un determinado evento.

Figura 20. Representación gráfica del diagrama de transición de estados.

La Figura 20 muestra el diagrama de transición de estados de los servicios de chequeo de listas de: aspectos generales, planificación del proyecto, gestión de requisitos y resultados del desarrollo.

1. Identificar estación de trabajo • Identificar el tipo de hardware y software con el cual se va acceder a la

plataforma.

1→2. Ingreso de URL destino

• Ingresar la URL donde se encuentra guardada la aplicación.

• Enviar URL para verificación y conexión con el sitio.

49

2→1 identificar estación de trabajo.

• URL incorrecta o no encontrada.

2→3. Autenticar Usuario

• Recibir código y contraseña del usuario.

• Establecer conexión a la base de datos.

3→4. Formulario de selección de Check List

• Visualizar el formulario de Check List en la pantalla con los chequeos disponibles.

4→5. Solicitud de Check List elegido

• Visualizar el formulario de Check List en la pantalla con los chequeos disponibles.

5→6. Retorno del Check List “Gestión de Requisitos”

• Visualizar el resultado del chequeo realizado en gestión de requisitos, una vez finalizadas las preguntas se arrojaran las respuestas de aceptación o no por parte del Gestor.

5→7. Retorno del Check List “Planificación del proyecto”

• Visualizar el resultado del chequeo realizado en la planificación del proyecto, una vez finalizadas las preguntas se arrojaran las respuestas de aceptación o no por parte del Gestor.

5→8. Retorno del Check List “Monitorización y control del proyecto”

• Visualizar el resultado del chequeo realizado en la monitorización y control del proyecto, una vez finalizadas las preguntas se arrojaran las respuestas de aceptación o no por parte del Gestor.

5→9. Retorno del Check List “Medición y Análisis”

• Visualizar el resultado del chequeo realizado en la medición y análisis, una vez finalizadas las preguntas se arrojaran las respuestas de aceptación o no por parte del Gestor.

5→10. Retorno del Check List “Aseguramiento de Calidad”

• Visualizar el resultado del chequeo realizado en el aseguramiento de calidad, una vez finalizadas las preguntas se arrojaran las respuestas de aceptación o no por parte del Gestor.

50

5→11. Retorno del Check List “Gestión de la Configuración” • Visualizar el resultado del chequeo realizado en la gestión de la

configuración, una vez finalizadas las preguntas se arrojaran las respuestas de aceptación o no por parte del Gestor.

6, 7, 8, 9, 10, 11→12. Salir. • Salir del aplicativo después de haber terminado cualquiera de los seis

(6) Check List especificados.

4.5.9. Mapa del Sitio. El mapa del sitio indica la representación en forma gráfica del aplicativo en este caso del sitio WEB, también indica los enlaces entre cada página y el orden de subordinación. El mapa del sitio para los servicios chequeo de lista de aspectos generales, planificación del proyecto, gestión de requisitos y resultados del desarrollo es el que se muestran en la figura 21. Figura 21. Mapa del sitio.

54

4.5.10. Definición de pruebas. Las pruebas que se realizan a la aplicación para asegurar el correcto funcionamiento de ésta, son pruebas funcionales y pruebas de rendimiento. No se realizó la prueba de Stress debido a que no se contaba con un servidor Web en el cual montar la aplicación y ver su respuesta en este. Estas pruebas se realizaron ya que se adaptan mejor a la metodología del proyecto. 4.5.10.1. Pruebas funcionales. Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para la herramienta. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el Check List.

4.5.10.2. Pruebas de rendimiento. Son las pruebas que se realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un sistema en condiciones particulares de trabajo. También puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. 4.5.11. Definición de etapas. Se definieron las etapas según su funcionalidad, en su totalidad son seis etapas compuestas por los módulos que se requieren para la aplicación. En estas etapas se realizará un diseño más detallado de cada modulo, una descripción de las funciones de codificación y sus respectivas pruebas. Estas se especifican a continuación: • Etapa 1: En esta etapa, estará compuesta por el módulo acceso (casos de

uso C1 y C2), el cual tiene relación con el sistema de acceso y validación del usuario. En esta etapa se desarrollan los casos de uso: C1, Identificar disponibilidad del servicio en línea y C2, Autenticar usuario.

• Etapa 2: Se realiza el menú de servicios de chequeo que presentara la

55

página y se crea la página principal del aplicativo. En esta etapa se desarrolla el caso de uso C3, seleccionar tipo de chequeo a realizar.

• Etapa 3: Se realiza la página de gestión de requisitos. En esta etapa se

desarrolla el caso de uso: C4, gestión de requisitos. • Etapa 4: Se realiza la página de planificación del proyecto. En esta etapa se

desarrolla el caso de uso: C5, planificación del proyecto. • Etapa 5: Se realiza la página de monitorización y control del proyecto. En

esta etapa se desarrolla el caso de uso: C6, monitorización y control del proyecto.

• Etapa 6: Se realiza la página de medición y análisis. En esta etapa se

desarrolla el caso de uso: C7, medición y análisis. • Etapa 7: Se realiza la página de aseguramiento de calidad. En esta etapa se

desarrolla el caso de uso: C8, aseguramiento de calidad. • Etapa 8: Se realiza la página de gestión de la configuración. En esta etapa

se desarrolla el caso de uso: C9, gestión de la configuración. 4.5.12. Modelo de base de datos. El modelo de base de datos es la representación de las tablas de la base de datos y los atributos de las mismas, indicando las relaciones entre cada tabla junto con sus llaves primarias y foráneas. Del modelo de la base de datos del portal Web sólo se tuvieron en cuenta las siguientes cinco tablas con sus respectivos atributos: • Usuario • Proyecto • Resultado • Rol • Área A continuación se muestra el modelo de bases de datos para el prototipo GESTION DE CALIDAD (Ver Figura 22).

56

Figura 22. Diseño Base de datos.

La Base de Datos fue realizada bajo el estudio de la información que se tenia, ya que no esta planteada la implantación en una compañía real, se trabajaron estas 5 tablas que poseen los atributos y descripciones del usuario, rol que desempeña en la compañía, su debida identificación, el área en el cual se esta trabajando, el proyecto al cual se le esta realizando el seguimiento y su respectivo resultado.

57

4.6. ETAPA 1: INGRESO A LA PÁGINA PRINCIPAL 4.6.1. Diseño detallado. En la Figura 23 se muestra el diseño de la página principal de la herramienta. Figura 23. Diseño pagina principal.

4.6.2. Codificación. La pagina principal se compone de dos (2) partes, la primera es la identificación del servicio que se esta utilizando, donde el aplicativo verifica que el servicio este activo o en línea. A continuación el usuario es llevado a una página principal donde deberá identificarse, ingresando su usuario que en este caso será la cedula y su clave que es personal.

58

Tabla 11 Prueba Rendimiento etapa 1.

Información General

Nombre:

ETAPA 1: PRUEBA DE RENDIMIENTO: Accediendo a página principal

Analista Javier Mauricio Aguilera

Jorge Máximo Hernández

Versión Set de Pruebas OO1

Hora de prueba 5:30 PM

Fecha de prueba 31-05-2010

TIEMPOS

T. Acceso 1 T. Acceso 2 T. Acceso 3 T. Acceso 4 T. Acceso 5

10,6 sg 11,55 sg 11,85 sg 12,66 sg 10,02 sg

Segundos Tiempo más alto: 12,85sg Tiempo más bajo 10,02sg Promedio: 11,336sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en validar si el usuario se encuentra registrado en la base de datos o no.

59

4.7. ETAPA 2. MENU PÁGINA PRINCIPAL 4.7.1. Diseño detallado. En la Figura 24 se muestra el diseño del formulario de selección de Servicios que presta la herramienta, con los diferentes check List que se pueden realizar.

Figura 24. Diseño menú, pagina principal.

4.7.2. Codificación. El menú de la selección de servicios que presta esta herramienta es simplemente un formulario de redireccionamiento a los servicios de Check List, para ingresar a cada uno de los chequeos se determino un nombre para cada uno. Para capturar estos datos y que la pagina los redirecciones se utiliza la función:

<a href="tesis2.html#">GESTION DE REQUSITOS</a> <a href="tesis4.html#">PLANIFICACION DEL PROYECTO</a> <a href="tesis3.html#">MONITORIZACION Y CONTROL DEL PROYECTO</a> <a href="tesis5.html#">MEDICION Y ANALISIS</a> <a href="tesis6.html#">ASEGURAMIENTO DE CALIDAD</a> <a href="tesis7.html#">GESTION DE LAM CONFIGURACION</a> </div>.

Con este menú se podrá seleccionar cualquier tipo de lista y ser realizada.

60

4.7.3. Pruebas de rendimiento.

En esta prueba se accede al formulario principal Tabla 12. Prueba Rendimiento etapa 2. Información General

Nombre:

ETAPA 2: PRUEBA DE RENDIMIENTO: Accediendo a Servicios de Check List




Hora de prueba 5:40 PM Fecha de prueba 31-05-2010

TIEMPOS


6,2 sg 4,85 sg 5,47 sg 5,09 sg 5,25 sg

Segundos

Tiempo más alto: 6,2sg

Tiempo más bajo 4,85sg

Promedio: 5,372sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en validar si el usuario al validar sus datos es enviado a la pagina principal de selección de los check List.

61

4.8. ETAPA 3. GESTION DE REQUISITOS 4.8.1. Diseño detallado. En la Figura 25 se muestra el diseño de la página de Check List de Gestión de Requisitos.

Figura 25. Gestión de Requisitos.

4.8.2. Codificación. El servicio para realizar este chequeo se compone de una página Web al igual que la página principal. La cual contiene un listado de preguntas cerradas para verificar los objetivos que se están evaluando del software, en esta página de gestión de requisitos primero se verifican las normativas y preacuerdos establecidos con el cliente para la realización de un software. Estas preguntas fueron el resultado del análisis correspondiente a el área realizado por los integrantes del grupo. 4.8.3. Pruebas de rendimiento. En esta prueba se puede apreciar el tiempo de respuesta después del llenado de cada una de las preguntas que componen el formulario seguido de presionar clic en finalizar, llevándonos al formulario de resultado.

62

Tabla 13. Prueba Rendimiento etapa 3. Información General

Nombre:

ETAPA 3: PRUEBA DE RENDIMIENTO: Gestión de Requisitos.




Hora de prueba 5:50 PM

Fecha de prueba 31-05-2010

TIEMPOS


8,2 sg 7,94 sg 8,43 sg 8,62 sg 8,21 sg

Segundos Tiempo más alto: 8,62sg


Promedio: 8,28sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en Ingresar a la página de Check List seleccionada (Gestión de Requisitos).

63

4.9. ETAPA CUATRO. PLANIFICACION DEL PROYECTO 4.9.1. Diseño detallado. En la Figura 26 se muestra el diseño de la página de Check List de Planificación del Proyecto. Figura 26. Planificación del Proyecto.

4.9.2. Codificación. El servicio para realizar este chequeo se compone de una página Web al igual que la página principal. La cual contiene un listado de preguntas cerradas para verificar los objetivos que se están evaluando del software, en esta página de Planificación del proyecto se establecen tiempos y objetivos a cumplir para el cumplimiento del desarrollo. Estas preguntas fueron el resultado del análisis correspondiente a el área realizado por los integrantes del grupo 4.9.3. Pruebas de rendimiento. En esta prueba se puede apreciar el tiempo de respuesta después del llenado de cada una de las preguntas que componen el formulario seguido de presionar clic en finalizar, llevándonos al formulario de resultado.

64


Nombre:

ETAPA 4: PRUEBA DE RENDIMIENTO: Planificación del Proyecto





TIEMPOS


6,27 sg 5,01 sg 5,14 sg 5,21 sg 5,4 sg



Promedio: 5,406sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en Ingresar a la página de Check List seleccionada (Planificación del Proyecto).

65

4.10. ETAPA QUINTA. MONITORIZACION Y CONTROL DEL PR OYECTO 4.10.1. Diseño detallado. En la Figura 27 se muestra el diseño de la página de Check List de Monitorización y Control del Proyecto.

Figura 27. Monitorización y Control del Proyecto.

4.10.2. Codificación. El servicio para realizar este chequeo se compone de una página Web al igual que la página principal. La cual contiene un listado de preguntas cerradas para verificar los objetivos que se están evaluando del software, en esta página de Monitorización y Control del Proyecto se verifican que todos los requisitos especificados y/o pedidos por el cliente se cumplan a cabalidad y cumplan las especificaciones para las cuales han sido creados. Estas preguntas fueron el resultado del análisis correspondiente a el área realizado por los integrantes del grupo 4.10.3. Pruebas de rendimiento. En esta prueba se puede apreciar el tiempo de respuesta después del llenado de cada una de las preguntas que componen el formulario seguido de presionar clic en finalizar, llevándonos al formulario de resultado.

66


Nombre:

ETAPA 5: PRUEBA DE RENDIMIENTO: Monitorización y Control del Proyecto.





TIEMPOS


5,27 sg 5,11 sg 5,34 sg 5,51 sg 5,45 sg



Promedio: 5,336sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en Ingresar a la página de Check List seleccionada (Monitorización y Control del Proyecto).

67

4.11. ETAPA SEXTA. MEDICION Y ANALISIS 4.11.1. Diseño detallado. En la Figura 28 se muestra el diseño de la página de Check List de Medición y Análisis. Figura 28. Medición y Análisis.

4.11.2. Codificación. El servicio para realizar este chequeo se compone de una página Web al igual que la página principal. La cual contiene un listado de preguntas cerradas para verificar los objetivos que se están evaluando del software, en esta página de medición análisis y se verifican que todos los resultados que deben salir de todo el desarrollo ingenieril del producto, certificando que todos los procesos y acciones han sido hechas y establecidas en plena ejecución y conocimiento por el cliente. Estas preguntas fueron el resultado del análisis correspondiente a el área realizado por los integrantes del grupo 4.11.3. Pruebas de rendimiento. En esta prueba se puede apreciar el tiempo de respuesta después del llenado de cada una de las preguntas que componen el formulario seguido de presionar clic en finalizar, llevándonos al formulario de resultado

68


Nombre:

ETAPA 6: PRUEBA DE RENDIMIENTO: Medición y Análisis





TIEMPOS


5,45 sg 5,25 sg 5,02 sg 5,49 sg 5,29 sg



Promedio: 5,3sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en Ingresar a la página de Check List seleccionada (Medición y Análisis).

69

4.12. ETAPA SEPTIMA. ASEGURAMIENTO DE CALIDAD 4.12.1. Diseño detallado. En la Figura 29 se muestra el diseño de la página de Check List de Aseguramiento de Calidad.

Figura 29. Aseguramiento de Calidad.

4.12.2. Codificación. El servicio para realizar este chequeo se compone de una página Web al igual que la página principal. La cual contiene un listado de preguntas cerradas para verificar los objetivos que se están evaluando del software, en esta página de aseguramiento de calidad y se verifican que todos los resultados que deben salir de todo el desarrollo ingenieril del producto, certificando que todos los procesos y acciones han sido hechas y establecidas en plena ejecución y conocimiento por el cliente. Estas preguntas fueron el resultado del análisis correspondiente a el área realizado por los integrantes del grupo.

70

4.12.3. Pruebas de rendimiento. Tabla 17. Prueba Rendimiento etapa 7. Información General

Nombre:

ETAPA 6: PRUEBA DE RENDIMIENTO: Aseguramiento de Calidad.





TIEMPOS


5,57 sg 5,20 sg 5,42 sg 5,10 sg 5,45 sg



Promedio: 5,348sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en Ingresar a la página de Check List seleccionada (Aseguramiento de la Calidad).

71

4.13. ETAPA OCTAVA. GESTION DE LA CONFIGURACION 4.13.1. Diseño detallado. En la Figura 30 se muestra el diseño de la página de Check List de la Gestión de la Configuración. Figura 30. Gestión de la Configuración

.

4.13.2. Codificación. El servicio para realizar este chequeo se compone de una página Web al igual que la página principal. La cual contiene un listado de preguntas cerradas para verificar los objetivos que se están evaluando del software, en esta página de la gestión de la configuración y se verifican que todos los resultados que deben salir de todo el desarrollo ingenieril del producto, certificando que todos los procesos y acciones han sido hechas y establecidas en plena ejecución y conocimiento por el cliente. Estas preguntas fueron el resultado del análisis correspondiente a el área realizado por los integrantes del grupo 4.13.3. Pruebas de rendimiento.

En esta prueba se puede apreciar el tiempo de respuesta después del llenado de cada una de las preguntas que componen el formulario seguido de presionar clic en finalizar, llevándonos al formulario de resultado

72


Nombre:

ETAPA 6: PRUEBA DE RENDIMIENTO: Gestión de la Configuración.





TIEMPOS


5,00 sg 5,25 sg 5,15 sg 5,50 sg 5,20 sg



Promedio: 5,22sg

En esta prueba se procedió a acceder al aplicativo durante 5 momentos distintos para comprobar el tiempo que tarda el sistema en Ingresar a la página de Check List seleccionada (Gestión de la Configuración).

73

5. PRESENTACIÓN DE ANÁLISIS DE RESULTADOS Después de haber desarrollado todas las actividades en el proceso de creación de esta plataforma se presenta un análisis de cada uno de los elementos trabajados.

5.1. RESULTADO INGENIERIL Después de haber investigado sobre cuáles áreas de proceso de CMMI eran mejor para implementar en pequeñas y medianas empresas en Colombia, se procedió a realizar la recolección de la información mediante la realización de las encuestas entre los desarrolladores de las empresas, se continuo con la elaboración de los Check List de cada una de las áreas de CMMI que tendría el aplicativo. Seguido de esto se realizaron los diferentes casos de uso identificando los actores, escenarios y todos los requerimientos que harían parte de la aplicación. Se procedió a seleccionar el lenguaje en el cual se desarrollaría la aplicación, para esto se tuvo en cuenta el lenguaje en el cual se tenía conocimiento que fue php (Hipertexto Pre-processor) y el tipo de editor Web es Dreamweaver ya que es en el que mayor tiempo se ha trabajado.

5.2. RESULTADOS DE ENCUESTAS 1. ¿Cree usted que para el buen desarrollo de software, hay que implementar

un estándar de calidad que certifique su buen desarrollo, SI, NO y porque?

Figura 31. Resultados Encuesta – Pregunta 1.

Ver punto 4.2.1. Para análisis de resultados.

74

2. ¿Conoce de algún estándar para certificar que se esta desarrollando software de alta calidad, SI, NO? Si la respuesta es SI, diga cual o cuales conoce.

3. ¿De los estándares de calidad que existen, cuál cree que es el mejor, por que?

Figura 32. Resultados Encuesta – Preguntas 2, 3.

Ver punto 4.2.1. Para análisis de resultados. 4. ¿Nombre de la empresa donde trabaja? 5. ¿Qué cargo ocupa dentro de la empresa? Figura 33. Resultados Encuesta – Preguntas 4, 5.


75

6. ¿Conoce si en su Empresa se maneja algún tipo de estándar para la certificación de software de alta calidad, cual?

7. ¿Cree viable la elaboración de una herramienta de software para el control

del desarrollo de software? 8. ¿Le gustaría que en su empresa se implementara una herramienta para el

control de calidad de software? Figura 34. Resultados Encuesta – Preguntas 6, 7, 8.


5.3. RETROALIMENTACI ÓN. • Hubiese sido interesante que el proyecto se orientara hacia la parte

estadística (manejo de indicadores) del área de desarrollo. • El resultado de la evaluación debería mostrarse también de manera gráfica

para su posible análisis permitiendo poder ver las falencias de acuerdo a las fases que se evalúan.

• Se hizo una retroalimentación de los check List con los ingenieros Carlos

Peña, Fabián Ávila (Informática Siglo 21), Mario Pastas (id2production) y Luis Jiménez (Qvision), los cuales son Ingenieros de Sistemas en el área de desarrollo y calidad, para ver la factibilidad del producto evaluando los Check List diseñados y en los 4 casos hubo una favorable respuesta hacia la complejidad y viabilidad de los chequeos a realizar.

76

6. CONCLUSIONES 1. El estándar de calidad CMMI en su nivel 2, o nivel administrativo da la

opción de realizar una comprobada certificación de los procesos gestionados en toda la vida del proyecto.

2. El nivel 2 del estándar de calidad CMMI, posee las seis (6) etapas de

desarrollo del software necesarias para ser implementadas y puestas en marcha para la certificación de calidad.

3. En base a las seis (6) etapas de proceso de certificación del modelo CMMI

nivel 2, se concluyo que en cada etapa existe una serie de requisitos fundamentales para verificar que se estén cumpliendo con las gestiones esperadas.

4. La creación de los Check List están sujetas a comprobación de cada etapa

en el estándar de calidad CMMI en el nivel 2 para verificar su cumplimiento y posterior aprobación.

5. Los requisitos funcionales permitirán definir el comportamiento interno del

sistema y alguna funcionalidad especifica de la herramienta para ser llevada a su práctica.

6. Los requisitos no funcionales permitirán suplir las necesidades que el

sistema pida para su buen funcionamiento. 7. Los lenguajes PHP, HTML y XHTML permitirán que la aplicación sea lo

suficientemente práctica en su creación y fácil uso. 8. El motor de desarrollo Dreamweaver y su excelente conexión con Mysql son

herramientas fundamentales para la fácil creación, modificación y administración de este prototipo para la certificación de calidad.

9. Las pruebas funcionales y de rendimiento permiten asegurar la calidad de

cada uno de los módulos del aplicativo y establecer los tiempos de respuesta.

10. Las pruebas de modelamiento permiten tener la certeza que cada etapa

realiza lo que se ha esperado como resultado final. 11. En cuanto a la experiencia con el prototipo un inconveniente fue el

determinar cuál era el perfil de usuario que podría acceder a la herramienta ya que no en todas las empresas existe un auditor de sistemas y el nombre que el usuario tendría en la base de datos, en cuanto al desarrollo del prototipo la primera versión en un principio no era agradable para el usuario

77

final, determinar la cantidad adecuada de preguntas para cada una de las áreas sin olvidar los aspectos importantes de estas.

12. El prototipo propone un sistema muy sencillo, donde se deja abierto para su

posterior modificación y adaptación según las necesidades de la compañía donde se instalé. La escalabilidad a otros niveles se podrá realizar adicionando las áreas que pertenezcan a cada nivel para el contexto Colombiano junto con el estudio para poder realizar los Check List y la posible modificación de la base de datos.

78

7. RECOMENDACIONES Para que esta herramienta de calidad de Software se materialice y tenga los resultados esperados se recomienda: 1. Las acciones y ejecuciones que se han realizado siempre se han efectuado

en Navegador Explorer, por tal razón se recomienda este navegador para su ejecución.

2. Usar la Metodología Entrega por Etapas, ya que dicha metodología generó

buenos resultados y se acomodó al desarrollo del aplicativo. 3. Ejecutar correctamente los Chequeos para que así mismo los resultados

sean satisfactorios. 4. Al momento de implementar dicha aplicación en el servidor Web de la

compañía, se recomienda generar una IP privada para que solo tenga acceso la persona que se encargue de auditar el proceso del desarrollo del software.

79

BIBLIOGRAFÍA

• ACHA ITURMENDI, Juan. José. Auditoria Informática en la empresa. 2004.

• ALONSO, Enrique. Medición y métricas del software. 2005.

• ARENDS, Alvil. Auditoria, un enfoque integral. 1996. • BAÑERES, Juan Palacio. Sinopsis de los modelos SW-CMM y CMMI.

Compendio de Ingeniería del Software II. 2006.

• BLANCO LUNA, Yanel. Manual de Auditoria y de Revisión Fiscal. 1998.

• CLEMENTS, Richard. Guía completa de normas ISO. 2002.

• INFORMÁTICA SIGLO 21. Estándares para calidad. 2008.

• INFORMÁTICA SIGLO 21. Manuales de calidad de Software. 2008.

• SOFTWARE ENGINEERING INSTITUTE. Capability Maturity Model Integration. 2002.

• LATORRE, J. Planificación Estratégica de la Calidad. 2006.

• MÉNDEZ, C. Introducción al modelo CMMI. 2006.

• PEÑARE SALCEDO, Cristian Rafael. Métricas de Software que

determina la calidad de dos plataformas. 2006.

• QUIÑONES, E. Modelos de Calidad de Software. 2005.

80

WEBGRAFIA

• http://www.lsi.us.es/docencia/pagina_asignatura.php?id=48 pagina 11

• http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?SGNUMBER=21208&ISG1=35&ISG2=80&ISG3 pagina 12

• http://es.wikipedia.org/wiki/Software_Engineering_Institute pagina 12 • http://www.aciem.org/bancoconocimiento/C/Cartilla/CARTILLA%20PYM

ES%20ACIEM.pdf pagina 13

• http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF pagina 16

• http://gidis.ing.unlpam.edu.ar/downloads/pdfs/Calidad_software.PDF

pagina 17

• http://www.ingenierosoftware.com/.../cmm-cmmi-nivel-2.php pagina 20

81

GLOSARIO CALIDAD DE SOFTWARE: Consecuencia de un proceso que es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI,...) CMMI: Capability Maturity Model Integration, Modelo para la mejora y evaluación de procesos en el desarrollo de Software, empleado para guiar las mejoras en procesos durante el desarrollo de Software. PHP: Lenguaje de programación interpretado, diseñado para la creación de paginas Web dinámicas, utilizado principalmente desde una interfaz de comandos para la creación de tipos de programas de aplicación Web. WEB: Sistema de documentos de hipertexto y/o híper medios enlazados y accesibles a través de Internet. XML: eXtensible Markup Language, no es un lenguaje en particular, sino una manera de definir lenguajes para diferentes tipos de necesidades. Se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. XHTML: Lenguaje extensible de marcado de hipertexto, es el lenguaje de marcado pensado para sustituir a HTML, es la versión XML de HTML, por lo que tiene, básicamente, las mismas funcionalidades, pero cumple las especificaciones, más estrictas de XML.

82

ANEXO 1. Encuesta CALIDAD DE SOFTWARE

1. ¿Cree usted que para el buen desarrollo de software, hay que implementar un estándar de

calidad que certifique su buen desarrollo, SI, NO y por que? 2. ¿Conoce de algún estándar para certificar que se esta desarrollando software de alta

calidad, SI, NO? Si la respuesta es SI, diga cual o cuales conoce. 3. ¿De los estándares de calidad que existen, cuál cree que es el mejor, por que? 4. ¿Nombre de la empresa donde trabaja? 5. ¿Qué Función cumple dentro de la empresa? 6. ¿Conoce si en su Empresa se maneja algún tipo de estándar para la certificación de

software de alta calidad, cual? 7. ¿Cree viable la elaboración de una herramienta de software para el control del desarrollo

de software? 8. ¿Le gustaría que en su empresa se implementara una herramienta para el control de

calidad de software? ¿porque?

83

ANEXO 2. Ficha técnica y resultados encuestas.

Ficha técnica de la encuesta para el diseño y modelo de herramienta de software que permita realizar una auditoría interna a medianas empresas desarrolladoras de software, que permita evaluar si el producto elaborado posee alto grado de calidad. 1. Realizada por: Javier Mauricio Aguilera Martínez, Jorge Máximo

Hernández Soto. 2. Universo: Bogotá D.C. 3. Unidad de Muestreo: Personas. 4. Fecha: Febrero y Marzo de 2009. 5. Área de Cobertura: Ingenieros de Sistemas de empresas desarrolladoras

de software de Bogotá D.C. (Informática Siglo 21, QVisión y id2production). 6. Tipo de Muestreo: No Probabilístico – Muestreo accidental. 7. Técnica de Recolección de Datos: Encuesta. 8. Tamaño de la Muestra: 50 (Cincuenta) Personas. 9. Objeto de le Encuesta: Identificar la importancia de desarrollar una

herramienta que permita verificar la calidad del software con sus respectivos servicios para las empresas desarrolladoras de software.

10. Criterio de Selección: El criterio para realizar las encuestas se tomo por

parte de los dos (2) integrantes del grupo de trabajo, después de visitas de investigación en FEDESOFT y PARQUESOFT, los cuales son organizaciones sin ánimo de lucro que guían a jóvenes emprendedores a comenzar en el mundo del comercio, en nuestro caso la informática. En las 2 visitas que se hicieron a estas organizaciones se pudo crear un ciclo de vida del proyecto, donde se pudo enfocar esta primer parte de la investigación (recolección de información), enfocarse principalmente en 2 casos. • Primero: Las empresas a las cuales se le debería hacer las encuestas

deben producir software a la medida, con amplio desempeño y liderazgo en la actualidad.

• Segundo: Las personas a las cuales se le debería realizar las encuestas deben ser ingenieros de sistemas, especialmente en los cargos de desarrollo de software, mantenimiento, documentación, plantación y administrativos.

84

11. Número de Preguntas Formuladas: 8 (Ocho) Preguntas.

85

ANEXO 3. Marco Legal

Modelo de calidad de software. Cmmi (Capability Maturity Model Integration), modelo de aseguramiento de la calidad, buscando la mejora continua de los procesos que se realizan en los diferentes procesos que permiten el desarrollo de software. Regulatorio.

• Artículo 18 de la Ley 788 de 2002: Adiciona el artículo 207-2 del Estatuto

Tributario el cual consagra la exención y establece los parámetros generales para acreditarse como beneficiario de la misma. por lo tanto el software, elaborado en Colombia y amparado con nuevas patentes registradas ante la autoridad competente, siempre y cuando tengan un alto contenido de investigación científica y tecnológica nacional, será certificado por COLCIENCIAS o quien haga sus veces, por un término de diez (10) años a partir de la vigencia de la presente ley.

• Artículos 15, 16, 17 y 18 del Decreto 2755 de 2003: Reglamenta el artículo 207-2 del Estatuto Tributario y establece el procedimiento y los requisitos para obtener el beneficio, este decreto con sus artículos nos informa de los tipos de beneficios que se obtienen cuando de desarrolla un software en Colombia y qué se puede hacer para obtener estos beneficios.

Artículo 15

Renta exenta en la producción de software. Las rentas de fuente nacional y/o extranjera originadas en la producción de software elaborado en Colombia se consideran exentas del impuesto sobre la renta, por un término de diez (10) años comprendidos entre el primero (1°) de enero de 2003 y el treinta y uno (31) de diciembre de 2012, siempre y cuando cumplan con los requisitos contenidos en el artículo 207-2 del Estatuto Tributario y en este decreto. Parágrafo. La renta originada por la producción de software elaborado en Colombia comprende la explotación del mismo a través de actividades como la elaboración, enajenación, comercialización o licenciamiento del software certificado.

86

Artículo 16

Definición de software. Para efectos de lo dispuesto en el numeral 8 del artículo 207-2 del Estatuto Tributario, se entiende por software la definición contenida en el Decreto 1360 de 1989 y demás normas que lo modifiquen o adicionen.

Artículo 17

Requisitos para la obtención del beneficio. Para efectos de acceder al beneficio por concepto de producción de software elaborado en Colombia, el contribuyente deberá acreditar el cumplimiento de los siguientes requisitos cuando la Dirección de Impuestos y Aduanas Nacionales, DIAN, los exija:

• Que el nuevo software haya sido producido y/o elaborado con posterioridad a la fecha de entrada en vigencia de la Ley 788 de 2002.

• Que el nuevo software haya sido producido y/o elaborado en Colombia. Se entiende que el software ha sido elaborado en Colombia cuando dicha elaboración y/o producción se realice dentro de los límites del territorio nacional.

• Que el nuevo software se registre ante la Oficina de Registro de la Dirección Nacional de Derechos de Autor del Ministerio del Interior y de Justicia.

• Que en el nuevo software se haya incorporado un alto contenido de investigación científica y/o tecnológica nacional, lo cual deberá ser certificado por Colciencias o la entidad que haga sus veces.

• Que el nuevo software sea el resultado de un proyecto de investigación, de conformidad con lo dispuesto en el Decreto 2076 de 1992.

Artículo 18

Solicitud de certificación a Colciencias sobre nuevo software. Para efectos de la certificación que debe expedir Colciencias o la entidad que haga sus veces, el solicitante deberá presentar:

• El soporte lógico junto con sus manuales e instructivos. • Certificación sobre existencia y representación legal de la empresa

solicitante expedida por la Cámara de Comercio del domicilio; • Copia del certificado expedido por la Oficina de Registro de la Dirección

Nacional de Derechos de Autor del Ministerio del Interior y de Justicia;

87

• Certificación expedida por el Representante Legal y el Revisor Fiscal y/o Contador Público, según el caso, de la empresa interesada, en la cual se declare que el software fue elaborado en Colombia;

• Los documentos necesarios que acrediten un alto contenido de investigación científica y/o tecnología nacional en la producción del software correspondiente.

Decreto 1360 de 1989.

Reglamenta la inscripción del software en el Registro Nacional del Derecho de Autor. Este decreto es necesario ya que describe lo que es protegido por los derechos de autor al desarrollar un software y para el caso del anteproyecto es realmente útil ya que nos muestra que tipo de software y documentación son protegidos por los derechos de autor.

Artículo 1o. De conformidad con lo previsto en la Ley 23 de 1982 sobre Derechos de Autor, el soporte lógico (software) se considera como una creación propia del dominio literario.

Artículo 2o. El soporte lógico (software) comprende uno o varios de los siguientes elementos: el programa de computador, la descripción de programa y el material auxiliar. Artículo 3o. Para los efectos del artículo anterior se entiende por:

• "Programa de computador": La expresión de un conjunto organizado de instrucciones, en lenguaje natural o codificado, independientemente del medio en que se encuentre almacenado, cuyo fin es el de hacer que una máquina capaz de procesar información, indique, realice u obtenga una función, una tarea o un resultado específico.

• "Descripción de Programa": Una presentación completa de procedimientos en forma idónea, lo suficientemente detallada para determinar un conjunto de instrucciones que constituya el programa de computador correspondiente.

• "Material auxiliar": todo material, distinto de un programa de computador o de una descripción de programa creado para facilitar su comprensión o aplicación, como por ejemplo, descripción de problemas e instrucciones para el usuario.

• Continuación del Decreto "Por el cual se reglamenta la inscripción del soporte lógico (software) en el Registro Nacional del Derecho de Autor".

Artículo 4o. El soporte lógico (software), será considerado como obra inédita, salvo manifestación en contrario hecha por el titular de los derechos de autor.

88

Artículo 5o. Para la inscripción del soporte lógico (software) en el Registro Nacional del Derecho de Autor, deberá diligenciarse una solicitud por escrito que contenga la siguiente información:

• Nombre, identificación y domicilio del solicitante, debiendo manifestar si habla a nombre propio o como representante de otro en cuyo caso deberá acompañar la prueba de su representación.

• Nombre e identificación del autor o autores. • Nombre del productor. • Título de la obra, año de creación, país de origen, breve descripción de sus

funciones, y en general, cualquier otra característica que permita diferenciarla de otra obra de su misma naturaleza.

• Declaración acerca de si se trata de obra original o si por el contrario, es obra derivada.

• Declaración acerca de si la obra es individual, en colaboración, colectiva, anónima, seudónima o póstuma.

Artículo 6o. A la solicitud de que trata el artículo anterior, deberá acompañarse por lo menos uno de los siguientes elementos: el programa de computador, la descripción de programa y/o el material auxiliar. Artículo 7o. La protección que otorga el derecho de autor al soporte lógico (software) no excluye otras formas de protección por el derecho común. Artículo 8o. Este Decreto rige a partir de la fecha de su publicación.

89

ANEXO 4. Check List creados

GESTION DE REQUISITOS

1. ¿Existe un equipo de ingeniería de software? 2. ¿El equipo cuenta con un líder de proyecto? 3. ¿El equipo de ingeniería de software esta capacitado para llevar a cabo las

actividades de administración de requerimientos? 4. ¿Se ha establecido a una sola persona para agregar, eliminar o modificar

los requerimientos del proyecto? 5. ¿El equipo de ingeniería de software se encarga de asegurar que los

cambios en los requerimientos estén documentados y planeados que hayan sido comunicados a los afectados y de darle un seguimiento hasta su culminación?

6. ¿El equipo de ingeniería de software se encarga de ubicar los

requerimientos en el área que le corresponde después de analizarlos? 7. ¿Hay alguien encargado de mantener distintas versiones del proyecto cada

vez que se realiza un cambio en los requerimientos? 8. ¿Se están utilizando métricas para determinar el estado de las actividades

realizadas para administrar los requerimientos? 9. ¿Las actividades para la administración de requerimientos son avaluadas

regularmente por un administrador de primera línea y por el líder del proyecto?

10. ¿El equipo de ingeniería de software sigue un proceso documentado para la

administración de requerimientos? 11. ¿Hay una revisión formal de los requerimientos tanto por el equipo de

software como por parte del cliente? 12. ¿Están documentados, aprobados y firmados las fechas de entrega,

términos de contrato y condiciones? 13. ¿Existió revisión formal del plan de requerimientos? 14. ¿Se sigue un proceso documentado para realizar cambios en los

requerimientos?

90

15. ¿La revisión formal hecha por el equipo y el cliente esta documentada y

aceptada por todos?

91

PLANEACION DEL PROYECTO 1. ¿Existe gente encargada de realizar estimados para posteriormente realizar

el plan de desarrollo del producto? 2. ¿Se están utilizando métricas para determinar el estado de las actividades

realizadas para la plantación del proyecto? 3. ¿Las actividades para el plan de desarrollo de software son verificadas

regularmente por el líder del proyecto? 4. ¿El plan de desarrollo de software ha sido creado en base a otro documento

realizado anteriormente? 5. ¿Se han hecho estimaciones de esfuerzo y costo del proyecto? 6. ¿Se distribuyeron los costos y esfuerzos del proyecto a través del ciclo de

vida del proyecto? 7. ¿Han sido identificados valorados y documentados los riesgos técnicos y de

programación? 8. ¿Por cada proyecto existe un plan de desarrollo de software documentado y

aprobado? 9. ¿Los requerimientos de software son la base para la creación del plan? 10. ¿Se llevan a cabo procesos de plantación en forma frecuente a lo largo del

ciclo de vida por parte del equipo de ingeniería de software? 11. ¿Ha sido identificado un ciclo de vida apropiado al proyecto? 12. ¿Se genero un plan de riesgo en base al análisis hecho? 13. ¿Todas las personas en el proyecto aceptaron los acuerdos relacionados a

este? 14. ¿El equipo encargado revisa periódicamente las actividades, avances y el

plan de desarrollo? 15. ¿El plan de desarrollo incluye las actividades a realizar y los acuerdos

alcanzados para el proyecto?

92

MONITORIZACIÓN Y CONTROL DE PROYECTOS 1. ¿Existe un equipo o gente encargada de llevar a cabo las actividades de

seguimiento y corrección del plan de desarrollo? 2. ¿El líder del proyecto ha asignado responsables para dar seguimiento al

producto de software? 3. ¿El líder del proyecto ha asignado responsables para dar seguimiento al

esfuerzo, costo, fechas de entrega y presupuesto? 4. ¿Las actividades de seguimiento del plan de desarrollo son verificadas

regularmente por el líder del proyecto? 5. ¿La revisión del plan de desarrollo esta bajo un proceso documentado y se

lleva a cabo con una frecuencia especifica o periódicamente? 6. ¿Han sido realizadas y documentadas revisiones formales de actividades

cumplidas en los diferentes puntos del proyecto? 7. ¿Han sido asignados los recursos necesarios para las actividades de

seguimiento? 8. ¿La administración del plan de desarrollo sigue una política organizacional

escrita? 9. ¿Los cambios en los acuerdos de software han sido comunicados y

aceptados por las personas involucradas? 10. ¿El plan de desarrollo ha sido documentado? 11. ¿Han sido guardadas y documentadas las métricas de desempeño y los

datos usados para los cambios de la planeación? 12. ¿El plan de desarrollo fue utilizado para definir las actividades de

seguimiento? 13. ¿El equipo de ingeniería de software esta llevando a cabo revisiones

internas en el plan de desarrollo para dar seguimiento al proceso técnico? 14. ¿El equipo de ingeniería de software esta llevando a cabo revisiones

internas en el plan de desarrollo para dar seguimiento al desempeño y actividades?

15. ¿Existen actividades de seguimiento para las actividades de ingeniería de

software y se llevan a cabo acciones correctivas cuando hay problemas?

93

MEDICIÓN Y ANÁLISIS 1. ¿Existen definidos procesos para realizar el seguimiento, medición, análisis

y mejora? 2. ¿Se están empleando técnicas estadísticas? 3. ¿Existe definida una metodología adecuada para el análisis de la

satisfacción del cliente? 4. ¿Existen registros conformes a la metodología definida? 5. ¿Se emprenden acciones a partir del análisis de satisfacción? 6. ¿Se encuentra definida la frecuencia y planificación de las auditorías? 7. ¿La auditoría interna comprende todos los procesos del sistema de gestión

de la calidad y la norma CMMI nivel 2? 8. ¿Son objetivos e imparciales los auditores internos? 9. ¿Se encuentran definidos y se cumplen los requisitos que deben cumplir los

auditores internos para la realización de las auditorías internas? 10. ¿Existe un procedimiento documentado para las auditorías internas? 11. ¿Existen registros de las auditorías internas? 12. ¿El responsable de área toma las decisiones sobre las correcciones a

realizar después de la auditoría? 13. ¿Existen indicadores adecuados para cada uno de los procesos del sistema

de gestión de la calidad? 14. ¿Está definida la responsabilidad y la frecuencia para la realización del

seguimiento de los indicadores? 15. ¿Existe procedimiento documentado para las acciones correctivas? 16. ¿Existen registros conformes a este procedimiento? 17. ¿Existe análisis de causas? 18. ¿Se verifica el cierre y la eficacia de las acciones? 19. ¿Existe procedimiento documentado para las acciones preventivas?

94

20. ¿Existen registros conformes a este procedimiento?

95

ASEGURAMIENTO DE LA CALIDAD 1. ¿Existe un equipo o gente encargada de llevar a cabo las actividades de

aseguramiento de calidad de software? 2. ¿Se están utilizando métricas para determinar el costo y las fechas

importantes de las actividades de aseguramiento de la calidad de software? 3. ¿Las inconformidades son guardadas y verificadas en el nivel administrativo

apropiado y revisadas hasta ser resueltas? 4. ¿El plan de actividades de aseguramiento de calidad sigue una política

organizacional escrita? 5. ¿Las inconformidades encontradas en las revisiones y auditorias son

resueltas de acuerdo a un procedimiento establecido y llevadas hasta su cierre?

6. ¿Existe un proceso documentado para la elección del nivel administrativo

para evaluar las inconformidades? 7. ¿Las actividades realizadas por el equipo de aseguramiento de calidad de

software son verificadas por expertos independientes del equipo? 8. ¿El equipo de aseguramiento de calidad revisa actividades de desarrollo de

software para ver su completa realización? 9. ¿El equipo de aseguramiento de calidad participa en la preparación del plan

de desarrollo? 10. ¿El equipo de aseguramiento de calidad participa en la creación de

estándares y procedimientos? 11. ¿El equipo de aseguramiento de calidad audita los productos de trabajo de

Software para ver su completa realización y apego a los estándares establecidos para el proyecto?

12. ¿El equipo de aseguramiento de calidad tiene juntas regalares con el

equipo de ingeniería de software para informarle de los resultados de las evaluaciones?

13. ¿El equipo de aseguramiento de calidad revisa regularmente sus

actividades y resultados? 14. ¿El plan de aseguramiento de calidad de software fue realizado en fases

tempranas del proyecto y en paralelo con el plan de desarrollo?

96

15. ¿El plan de actividades de aseguramiento de calidad de software es

preparado a través de un proceso documentado?

97

ADMINISTRACION DE LA CONFIGURACION 1. ¿Existe un equipo o gente encargada de llevar a cabo las actividades de

administración de la configuración de software? 2. ¿Los integrantes del equipo de administración de la configuración de

software tienen preparación suficiente en los objetivos, procedimientos y métodos para realizar actividades asignadas?

3. ¿Ha sido asignado un responsable para llevar a cabo las actividades de

administración de la configuración? 4. ¿El plan de actividades de administración de la configuración de software es

planeado y a través de un proceso documentado? 5. ¿Se realizan auditorias a los documentos o productos que se encuentran en

línea base de proyectos de acuerdo a un proceso documentado? 6. ¿Los cambios solicitados y reportes de problemas para todos los elementos

de configuración son iniciados, guardados, aprobados y seguidos de acuerdo a un proceso documentado?

7. ¿Las actividades de administración de la configuración de software fueron

revisadas por las personas afectadas? 8. ¿Las actividades de administración de la configuración de software son

realizadas en base al plan de aseguramiento de calidad de software? 9. ¿El equipo de administración de la configuración de software realiza

auditorias de los documentos en línea base para verificar que están conforme a la documentación que los define?

10. ¿Los cambios en los documentos en línea base son realizados de acuerdo

a un proceso documentado? 11. ¿Las actividades de administración de la configuración de software fueron

realizadas en fases tempranas del proyecto y en paralelo con el plan de desarrollo de software?

12. ¿El equipo de administración de la configuración de software puso al

alcance de las personas y grupos afectados los reportes que documentan sus actividades y cambios en los documentos en línea base?

13. ¿Han sido asignados los recursos y fondos necesarios para las actividades

de administración de la configuración de software?

98

14. ¿El equipo de aseguramiento de la calidad de software revisa periódicamente las actividades y resultados de las actividades?

15. ¿Se están utilizando métricas para determinar el estado de las actividades

de administración de la configuración de software?

99

MANUAL DE USUARIO PROTOTIPO DE GESTION DE CALIDAD

Elaborado por: Javier M. Aguilera

Jorge M. Hernández

Versión: 001

Bogotá D.C. Junio de 2010

100

TABLA DE CONTENIDO

1. TABLA DE CONTENIDO--------------------------------------------------------------- 100

2. INTRODUCCIÓN------------------------------------------------------------------------- 101

3. GESTIÓN DE CALIDAD---------------------------------------------------------------- 101

4. DESCRIPCIÓN GENERAL ------------------------------------------------------------ 101

5. INGRESO AL APLICATIVO ----------------------------------------------------------- 102

6. VALIDACIÓN DEL USUARIO--------------------------------------------------------- 104

7. GESTIÓN DE LA CALIDAD ----------------------------------------------------------- 106

8. PLANIFICACIÓN DEL PROYECTO------------------------------------------------- 107

9. MONITORIZACIÓN Y CONTROL DEL PROYECTO--------------------------- 108

10. MEDICIÓN Y ANÁLISIS---------------------------------------------------------------- 109

11. ASEGURAMIENTO DE LA CALIDAD ---------------------------------------------- 110

12. GESTOR DE LA CONFIGURACIÓN ----------------------------------------------- 111

13. RESULTADOS FAVORABLES------------------------------------------------------- 112

14. RESULTADOS NO FAVORABLES ------------------------------------------------- 112

101

INTRODUCCIÓN Este manual esta elaborado para el buen funcionamiento del gestor de calidad, implementado para validar que todas las áreas y acciones que realiza cada una de ellas estén haciendo las operaciones con métricas establecidas, para que el producto que se realice, de cómo resultado final un optimo paquete con un alto nivel de calidad. En este documento encontrara como realizar toda la operación de este producto y se modelara su desempeño, para que el usuario lo conozca y le genere el mayor desempeño a este producto.

GESTIÓN DE CALIDAD La gestión de calidad es la herramienta más útil en el desarrollo de software, ya que ayuda a controlar todas las instancias del desarrollo de una aplicación. Por tal razón esta herramienta que ponemos a su disposición ayudara a controlar todas las instancias de verificación, control y aplicación de todos los pasos que se deben seguir en el momento de desarrollo de un Software. Esta herramienta le ayudara a diagnosticar si su grupo de trabajo si cumple con las normas básicas para el desarrollo de software de alta calidad y controlar todos los pasos que se deben seguir.

DESCRIPCIÓN GENERAL Esta herramienta le servirá para validar todas las áreas del proceso de calidad de su compañía, el aplicativo cuenta con un numero de Check List a llenar, para que compruebe si el proyecto que esta trabajando lo esta realizando con todos los estándares de calidad que se necesitan. Usted deberá ingresar al portal abriendo un explorador de Internet e ingresando la URL para ir a la pagina donde esta guardada la aplicación, una vez allí deberá validar si tiene usuario y contraseña validas para ingresar al sistema. Una vez validado su usuario será redirigido a la página principal del aplicativo y allí encontrara todas las opciones para validar su información, deberá escoger área por área para realizar un seguimiento minucioso del proyecto. Cada área cuenta con 15 preguntas de comprobación directa que usted deberá verificar si se cumplen o no e ingresar a la pagina su respuesta correspondiente, al finalizar cada área encontrara 2 opciones, una se seguir a la próxima área o una de finalizar, estas 2 opciones se podrán realizar sin ningún problema según su elección.

102

Una vez realizada las 15 preguntas del área podrá darle clic en finalizar para que el aplicativo le muestre un resultado global de la ejecución. A continuación se muestra como se deberá ejecutar dicha acciones.

INGRESO AL APLICATIVO

Deberá ir a “INICIO” y dar clic en el botón de INTERNET EXPLORER, donde se le abrirá una pagina en blanco de Internet y en la barra para ingresar las direcciones le da la ubicación o URL designado al portal, en este caso como se esta trabando en una maquina local, será: http://localhost/sitios/tesis/index.

Una vez ingresado esta dirección nos enviara a la página principal del aplicativo.

104

VALIDACIÓN DEL USUARIO

Una vez estando en esta página principal, el usuario deberá validar sus datos en las casillas de “Usuario” y “Clave”, si no es correcto el usuario o la clave, saldrá un mensaje de error:

De lo contrario será direccionado a la página de las áreas a seleccionar y trabajar:

105

El usuario en esta página a la parte izquierda encontrara todas las áreas a trabajar en cada proyecto, en la mitad saldrá el Check List seleccionado y en la parte derecha un botón para finalizar la sesión de trabajo. Para comenzar su trabajo deberá seleccionar una por una de las áreas.

106

GESTIÓN DE LA CALIDAD

El usuario dando clic en GESTION DE REQUISITOS, se le desplegara el chequeo a realizar en la mitad de la pantalla, deberá corroborar cada pregunta con lo trabajado en el proyecto y verificar si se cumple o no dicha acción, e ir llenando las casillas una por una, una vez finalizadas todas las 15 preguntas el usuario podrá ir al siguiente área o finalizar y ver el resultado de ella:

Si da clic en finalizar el sistema validara las acciones y según como encuentre el proyecto arrojara un resultado favorable o no favorable con su respectivo informe.

107

PLANIFICACIÓN DEL PROYECTO

El usuario dando clic en PLANIFICACION DEL PROYECTO, se le desplegara el chequeo a realizar en la mitad de la pantalla, deberá corroborar cada pregunta con lo trabajado en el proyecto y verificar si se cumple o no dicha acción, e ir llenando las casillas una por una, una vez finalizadas todas las 15 preguntas el usuario podrá ir al siguiente área o finalizar y ver el resultado de ella:


108

MONITORIZACIÓN Y CONTROL DEL PROYECTO

El usuario dando clic en MONITORIZACION Y CONTROL DEL PROYECTO, se le desplegara el chequeo a realizar en la mitad de la pantalla, deberá corroborar cada pregunta con lo trabajado en el proyecto y verificar si se cumple o no dicha acción, e ir llenando las casillas una por una, una vez finalizadas todas las 15 preguntas el usuario podrá ir al siguiente área o finalizar y ver el resultado de ella:


109

MEDICIÓN Y ANÁLISIS

El usuario dando clic en MEDICION Y ANALISIS, se le desplegara el chequeo a realizar en la mitad de la pantalla, deberá corroborar cada pregunta con lo trabajado en el proyecto y verificar si se cumple o no dicha acción, e ir llenando las casillas una por una, una vez finalizadas todas las 15 preguntas el usuario podrá ir al siguiente área o finalizar y ver el resultado de ella:


110

ASEGURAMIENTO DE LA CALIDAD

El usuario dando clic en ASEGURAMIENTO DE LA CALIDAD, se le desplegara el chequeo a realizar en la mitad de la pantalla, deberá corroborar cada pregunta con lo trabajado en el proyecto y verificar si se cumple o no dicha acción, e ir llenando las casillas una por una, una vez finalizadas todas las 15 preguntas el usuario podrá ir al siguiente área o finalizar y ver el resultado de ella:


111

GESTOR DE LA CONFIGURACIÓN

El usuario dando clic en GESTOR DE LA CONFIGURACIÓN, se le desplegara el chequeo a realizar en la mitad de la pantalla, deberá corroborar cada pregunta con lo trabajado en el proyecto y verificar si se cumple o no dicha acción, e ir llenando las casillas una por una, una vez finalizadas todas las 15 preguntas el usuario podrá ir al siguiente área o finalizar y ver el resultado de ella:

Si da clic en finalizar el sistema validara las acciones y según como encuentre el proyecto arrojara un resultado favorable o no favorable con su respectivo informe. Una vez terminada cada una de las etapas del seguimiento que se le deberá hacer a cada proyecto, el usuario deberá dar clic en el botón “FINALIZAR”, para ir a la página de resultados.

112

RESULTADOS FAVORABLES

Una vez evaluada cada una de las etapas, al dar clic en el botón “FINALIZAR”, el sistema entra a procesar los datos seleccionados y arroja una respuesta, si el numero de “SI” es mayor a 10, el sistema dará como favorable el análisis, de lo contrario lo dará como no favorable, en este caso el resultado es favorable.

RESULTADOS NO FAVORABLES

Una vez evaluada cada una de las etapas, al dar clic en el botón “FINALIZAR”, el sistema entra a procesar los datos seleccionados y arroja una respuesta, si el numero de “SI” es mayor a 10, el sistema dará como favorable el análisis, de lo contrario lo dará como no favorable, en este caso el resultado es no favorable.

113

Una vez obtenido los resultados y guardados en la base de datos, el usuario podrá finalizar sesión y terminar con su trabajo.

114

FECHA 02-06-2010 NÚMERO RAE

PROGRAMA INGENIERÍA DE SISTEMAS

AUTOR (ES)

AGUILERA JAVIER MAURICIO; HERNÁNDEZ JORGE MAXÍMO

TÍTULO DISEÑO DE UNA HERRAMIENTA AUDITORA PARA VALIDAR LA CALIDAD DE SOFTWARE BASADA EN EL MODELO CMMI NIVEL 2

PALABRAS CLAVES CMMI: Capability Maturity Model Integration, Modelo para la

mejora y evaluación de procesos en el desarrollo de

Software, empleado para guiar las mejoras en procesos durante el desarrollo de Software. PHP: Lenguaje de programación interpretado, diseñado para la creación de páginas Web dinámicas, utilizado principalmente desde una interfaz de comandos para la creación de tipos de programas de aplicación Web.

WEB: Sistema de documentos de hipertexto y/o híper medios enlazados y accesibles a través de Internet.

DESCRIPCIÓN Prototipo de software que realiza auditoria a nivel de procesos para las pequeñas y

medianas empresas desarrolladoras de software en Colombia basado en el modelo de calidad de software CMMI, mediante un portal web al cual se accede y en donde se responden cierto número de preguntas relacionadas con cada unas de las aéreas con las cuales el desarrollo de software se encuentra ligado.

FUENTES BIBLIOGRÁFICAS

• ACHA ITURMENDI, Juan. José. Auditoria Informática en la empresa. 2004.

• ALONSO, Enrique. Medición y métricas del software. 2005. • ARENDS, Alvil. Auditoria, un enfoque integral. 1996. • BAÑERES, Juan Palacio. Sinopsis de los modelos SW-CMM

y CMMI. Compendio de Ingeniería del Software II. 2006. • BLANCO LUNA, Yanel. Manual de Auditoria y de Revisión

Fiscal. 1998. • CLEMENTS, Richard. Guía completa de normas ISO. 2002. • INFORMÁTICA SIGLO 21. Estándares para calidad. 2008. • INFORMÁTICA SIGLO 21. Manuales de calidad de

Software. 2008. • SOFTWARE ENGINEERING INSTITUTE. Capability

Maturity Model Integration. 2002. • LATORRE, J. Planificación Estratégica de la Calidad. 2006. • MÉNDEZ, C. Introducción al modelo CMMI. 2006. • PEÑARE SALCEDO, Cristian Rafael. Métricas de Software

115

que determina la calidad de dos plataformas. 2006. • QUIÑONES, E. Modelos de Calidad de Software. 2005.

NÚMERO RAE PROGRAMA INGENIERÍA DE SISTEMAS CONTENIDOS

OBJETIVOS

Objetivo General. Diseñar una herramienta que permita realizar una auditoría a medianas empresas desarrolladoras de software según el estándar de calidad del nivel 2 de CMMI, bajo el criterio de comprobación por Check List.

Objetivos Específicos.

• Determinar las características fundamentales de aseguramiento de calidad del modelo CMMI aplicables al contexto nacional. Nivel 2.

• Diseñar los Check List a implementar en la herramienta según las características determinadas en el modelo de calidad CMMI nivel 2.

• Determinar los requerimientos funcionales y no funcionales para el desarrollo de la herramienta de aseguramiento de calidad.

• Diseñar un prototipo funcional de la herramienta de auditoría diseñada.

• Realizar las pruebas de modelamiento de datos para

verificar usabilidad y veracidad de los resultados

Alcances. El producto final debe ser un diseño funcional del software que verifique mediante chequeos de lista y métricas establecidas, que la compañía a la que se le realice esta prueba, cumpla con lo requerido en el modelo CMMI Nivel 2 para la buena elaboración y desarrollo de software de alta calidad.

Marco de Referencia El desarrollo de un software auditor es el objetivo final para el control de procesos y supervisión, capaz de estar ejerciendo un control continuo de las operaciones del área de procesamiento y de desarrollo de software. Para lo que se

tiene en cuenta la manera correcta para cumplir con las necesidades del cliente de una manera óptima.

NÚMERO RAE PROGRAMA INGENIERÍA DE SISTEMAS

116

METODOLOGÍA LÍNEA DE INVESTIGACIÓN

Línea Institucional. Tecnologías actuales y sociedad. Sub. Línea de la facultad de ingeniería. Sistemas de información y comunicación. Campo de investigación. Auditoría Informática. METODOLOGIA DEL PROYECTO La metodología utilizada durante el desarrollo de la aplicación es la denominada “Entrega por Etapas”, debido a que esta metodología, además de reducir los riesgos implícitos en la construcción del producto de software, también mejora la visibilidad del progreso del producto. • Levantamiento de información. Para llevar a cabo el proceso de

levantamiento de información se seleccionaron diferentes Ingenieros de Sistemas de empresas desarrolladores de software de Bogotá D.C. Al azar. A cada uno de ellos se le realizó una encuesta de tipo no probabilístico con muestreo accidental.

• Descripción del Sistema. La herramienta es accesible a través de un portal Web que se deberá montar en el Servidor Web interno de la compañía, al cual debe dársele una dirección interna y que solo tenga acceso el personal escogido para esta labor.

• Requerimientos Funcionales. Autenticación e identificación del servidor. Validaciones de campos de los Check List. Consulta de resultados obtenidos después de realizado el chequeo por cada área de la aplicación.

• Requerimientos no Funcionales disponibilidad debe ser equivalente a la del servidor, el tiempo de respuesta debe ser menor a 20 segundos

Entrega por etapas. La entrega por etapas es un modelo del ciclo de vida clásico en el que el software se desarrolla en etapas sucesivas, desarrollando normalmente las capacidades más importantes. Además esta metodología mejora más la planificación percibida que la planificación real. Análisis de requerimientos. En el análisis de requerimientos se busca comprender los requisitos del sistema logrando la estructuración de una solución, se contesta la pregunta del “que” del sistema. Objetivo del Nivel 2 de CMMI. El objetivo principal del nivel 2 de CMM-CMMI es que en los proyectos de la organización exista una gestión de los requisitos y que los procesos (formas de hacer las cosas) estén planeados, ejecutados, medidos y controlados.

CONCLUSIONES El estándar de calidad CMMI en su nivel 2, o nivel administrativo da la opción

de realizar una comprobada certificación de los procesos gestionados en toda la vida del proyecto. El nivel 2 del estándar de calidad CMMI, posee las seis (6) etapas de desarrollo del software necesarias para ser implementadas y puestas en marcha para la certificación de calidad.

117

En base a las seis (6) etapas de proceso de certificación del modelo CMMI nivel 2, se concluyo que en cada etapa existe una serie de requisitos fundamentales para verificar que se estén cumpliendo con las gestiones esperadas. La creación de los Check List están sujetas a comprobación de cada etapa en el estándar de calidad CMMI en el nivel 2 para verificar su cumplimiento y posterior aprobación. Los requisitos funcionales permitirán definir el comportamiento interno del sistema y alguna funcionalidad especifica de la herramienta para ser llevada a su práctica. Los requisitos no funcionales permitirán suplir las necesidades que el sistema pida para su buen funcionamiento. Los lenguajes PHP, HTML y XHTML permitirán que la aplicación sea lo suficientemente práctica en su creación y fácil uso. El motor de desarrollo Dreamweaver y su excelente conexión con MySQL son herramientas fundamentales para la fácil creación, modificación y administración de este prototipo para la certificación de calidad. Las pruebas funcionales y de rendimiento permiten asegurar la calidad de cada uno de los módulos del aplicativo y establecer los tiempos de respuesta. Las pruebas de modelamiento permiten tener la certeza que cada etapa realiza lo que se ha esperado como resultado final. En cuanto a la experiencia con el prototipo un inconveniente fue el determinar cuál era el perfil de usuario que podría acceder a la herramienta ya que no en todas las empresas existe un auditor de sistemas y el nombre que el usuario tendría en la base de datos, en cuanto al desarrollo del prototipo la primera versión en un principio no era agradable para el usuario final, determinar la cantidad adecuada de preguntas para cada una de las áreas sin olvidar los aspectos importantes de estas. El prototipo propone un sistema muy sencillo, donde se deja abierto para su posterior modificación y adaptación según las necesidades de la compañía donde se instalé. La escalabilidad a otros niveles se podrá realizar adicionando las áreas que pertenezcan a cada nivel para el contexto Colombiano junto con el estudio para poder realizar los Check List y la posible modificación de la base de datos.

dise o de una herramienta auditora para validar la calidad...

Documents