EVALUACIÓN DE MOPROSOFT COMO ALTERNATIVA...

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA DE SISTEMAS DEPARTAMENTO DE INVESTIGACIÓN DE OPERACIONES

EVALUACIÓN DE MOPROSOFT COMO ALTERNATIVA METODOLÓGICA DE ORGANIZACIÓN DE EMPRESAS

DE DESARROLLO Y MANTENIMIENTO DE SOFTWARE

Autor Yimy René Corredor Aranguren

Tutor Prof. Oswaldo Terán

Jurado Prof. Jose Aguilar

Prof. Hebert Hoeger

TRABAJO DE GRADO Presentado ante la

UNIVERSIDAD DE LOS ANDES En cumplimiento parcial de los requisitos

para optar al título de INGENIERO DE SISTEMAS

Mérida, Venezuela 2006

i

RESUMEN

La creciente dimensión de los proyectos relacionados con los sistemas de información

hace que sea imprescindible acometerlos con la mayor solidez metodológica. CMM

v1.0 es publicado en 1991 a modo de combatir la crisis del software de finales de los

años 80, como un modelo que sugiere la incorporación de un conjunto de

herramientas que conducen a la optimización de principios y prácticas de procesos de

software. Atacando los proyectos por mas grandes que fueran con calidad, un mínimo

de errores, reduciendo los costes y el tiempo de entrega de los productos.

SW-CMM, ISO 15504, CMMI son algunos de los modelos más importantes que

certifican a las empresas que logran aplicar con éxito sus respectivas prácticas. El

Modelo de Proceso para la Industria del Software (MoProSoft) creado en México,

esta basado en las prácticas más importantes de cada uno de estos modelos, con la

ventaja de que puede ser adaptado con más facilidad a cooperativas y Pymes, ya que

los primeros son muy costosos y complicados en su aplicación. Razones por la cual

se propone a MoProSoft como alternativa metodológica, tomando como caso de

estudio la aplicación de este modelo en la Unidad de Informática de FUNDACITE-

MÉRIDA, programando 3 evaluaciones con la finalidad de analizar la evolución del

proceso, diseñando una herramienta que permite estimar el nivel de capacidad de los

procesos evaluados.

En los resultados obtenidos de la evaluación, se observó la evolución de algunos de

los procesos sugeridos por MoProSoft, en sus diferentes categorías como son: Alta

Dirección, Gerencia y Operación. Se determinó el nivel de capacidad de los procesos

de la Unidad de Informática demostrando las bondades de MoProSoft con miras a la

creación de un modelo propio adaptado a las necesidades tecnológicas de Venezuela.

ii

A Yimy Alejandro…

iii

ÍNDICE

CAPÍTULO I. INTRODUCCIÓN............................................................................. 1

1.1 Antecedentes ............................................................................................... 1

1.2 Definición del Problema.............................................................................. 2

CAPÍTULO II. DESCRIPCIÓN DE LA EMPRESA.............................................. 4

2.1 Unidad de Informática................................................................................. 6

2.2 Fabrica de Software Libre (FSL) ................................................................ 8

2.3 Academia de Software Libre....................................................................... 9

CAPÍTULO III. MARCO TEÓRICO .................................................................... 10

3.1 Ingeniería del Software ............................................................................. 10

3.2 MoProSoft ................................................................................................. 10

3.2.1 Categoría de Procesos................................................................. 11

3.2.1.1 Categoría de Alta Dirección (DIR).............................. 11

3.2.1.2 Categoría de Gestión (GES) ........................................ 12

3.2.1.3 Categoría de Operación (OPE) .................................... 12

3.2.2 Procesos...................................................................................... 13

3.2.2.1 DIR.1 Gestión de Negocios ......................................... 13

3.2.2.2 GES.1 Gestión de Procesos ......................................... 13

3.2.2.3 GES.2 Gestión de Proyectos........................................ 13

3.2.2.4 GES.3 Gestión de Recursos......................................... 13

3.2.2.5 GES.3.1 Recursos Humanos y Ambiente de Trabajo..14

3.2.2.6 GES.3.2 Bienes, Servicio e Infraestructura ................. 14

3.2.2.7 GES.3.3 Conocimiento de la Organización................. 14

iv

3.2.2.8 OPE.1 Administración de Proyectos Específicos........ 14

3.2.2.9 OPE.2 Desarrollo y Mantenimiento de Software ........ 14

3.3 Otros Modelos ........................................................................................... 15

3.3.1 CMM .......................................................................................... 15

3.3.1.1 Inicial ........................................................................... 16

3.3.1.2 Repetible ...................................................................... 16

3.3.1.3 Definido ....................................................................... 16

3.3.1.4 Gestionado ................................................................... 17

3.3.1.5 Optimizado .................................................................. 17

3.3.2 ISO 15504.................................................................................. 18

3.3.2.1 Nivel 0: Proceso Incompleto ....................................... 18

3.3.2.2 Nivel 1: Proceso Desarrollado ................................... 18

3.3.2.3 Nivel 2: Proceso Gestionado ....................................... 18

3.3.2.4 Nivel 3: Proceso Establecido ....................................... 19

3.3.2.5 Nivel 4: Proceso Predecible........................................ 19

3.3.2.6 Nivel 5: Proceso en Optimización ............................... 19

3.3.3 ISO 9000:2000............................................................................ 19

3.4 Organización Madura................................................................................ 21

3.5 Software Libre........................................................................................... 22

3.6 Metodología Ágil ...................................................................................... 22

3.7 Programación Extrema.............................................................................. 23

CAPITULO IV. ELABORACIÓN DE LA HERRAMIENTA DE

EVALUACIÓN ......................................................................................................... 25

4.1 Alcance...................................................................................................... 25

v

4.2 Bases Conceptuales ................................................................................... 26

4.2.1 EvalProSoft................................................................................. 26

4.2.2 ISO 19011................................................................................... 27

4.3 Descripción de la Herramienta de Evaluación .......................................... 27

CAPITULO V. EVALUACIÓN DE LA ORGANIZACIÓN Y RESULTADOS 32

5.1 Evaluación 1.............................................................................................. 32

5.2 Evaluación 2.............................................................................................. 35

5.3 Evaluación 3.............................................................................................. 37

5.4 Discusión................................................................................................... 38

CAPITULO VI. CONCLUSIONES Y RECOMENDACIONES. ........................ 41

6.1 Conclusiones ............................................................................................. 41

6.2 Sugerencias................................................................................................ 43

REFERENCIAS BIBLIOGRÁFICAS.................................................................... 45

REFERENCIAS ELECTRÓNICAS ....................................................................... 46

ANEXOS .................................................................................................................... 48

EVALUACIÓN 1 ...................................................................................................... 49

EVALUACIÓN 2 ...................................................................................................... 64

EVALUACIÓN 3 ...................................................................................................... 79

EJEMPLO DE DOCUMENTACIÓN USADA PARA LA EVALUACIÓN....... 94

Documento desarrollado por la Coordinación de Informática en Diciembre de

2005, para uso interno del personal de la Unidad de Informática. ...................... 94

EJEMPLO DE PLANTILLA PARA DEFINICIÓN DE REQUISITOS. ......... 107

vi

ÍNDICE DE FIGURAS

1. Estructura Organizacional de Fundacite-Mérida 5

2. Esquema Organizativo de la Unidad de Informática 6

3. Categoría de Procesos 12

4. Relaciones entre Procesos 15

5. Niveles inclusivos de CMM 17

6. Evolución en el tiempo de los modelos ISO, SEI 21

7. Tabla comparativa de Procesos Maduros e Inmaduros 22

8. Tabla de procesos con sus respectivas Claves 28

9. Ejemplo de de Proceso Codificado y nombre del Producto de Trabajo 29

10. La Herramienta de Evaluación 31

11. Gráfico. Producto de Trabajo vs. % Ítems Completados 32

12. Tabla de Resultados de la Evaluación 1 34

13. Gráfico Comparativo entre Evaluación 1 y Evaluación 2 35


15. Gráfico Comparativo entre las 3 Evaluaciones 37


17. Gráfico de Porcentaje por Proceso 39

1

CAPÍTULO I. INTRODUCCIÓN

1.1 Antecedentes

“Luego de décadas de promesas no cumplidas sobre productividad y mejoras de

calidad por utilizar nuevas metodologías y tecnologías de software, industria y

organizaciones gubernamentales toman cuenta de que su problema fundamental es la

incapacidad de administrar el proceso de software.”

― Report of the Defense Science Board Task Force on Military software,

Washington, D.C., September 1987. La creciente dimensión de los proyectos relacionados con los sistemas de información

hace que sea imprescindible acometerlos con la mayor solidez metodológica. Al final

de la década de los 80 y principios de los 90 las compañías de software se

encontraron con que la mayoría de sus proyectos fallaban y no cumplían con los

objetivos acordados con sus clientes, consecuencia de esto se tradujo en la cantidad

de dinero que les costó a las empresas la cancelación de los proyectos y las múltiples

demandas que debían afrontar.

Es por estos motivos que el gobierno de los Estados Unidos de América a través del

Instituto de Ingeniería de Software (SEI) en conjunto con la empresa privada y

experiencias anteriores en procesos de calidad como las de Philip Crosby, crearon el

Modelo de Madurez de la Capacidad (CMM) cuya versión 1.0 se publicó en el año de

1.991.

2

CMM demostró a través de los años los beneficios de su aplicación en grandes

proyectos, con la incorporación de un conjunto de herramientas que conducen a la

optimización de principios y prácticas de procesos de software maduros. Sentando

precedentes para que proyectos por muy grandes que fueran, pudieran satisfacer las

expectativas con un producto de calidad, con un mínimo de imperfecciones,

reduciendo los tiempos de finalización del producto y reducción de costes, como

condición indispensable para salir previamente al mercado, manteniendo al mismo

tiempo estándares de calidad.

1.2 Definición del Problema

Según las características de la industria del software en Venezuela, que en su gran

mayoría está constituida por cooperativas, medianas y pequeñas empresas, el Modelo

de Madurez de las Capacidad del software es difícil de aplicar, muestra de ello es la

cantidad de empresas certificadas bajo este modelo que es mínima en el país. Es

preciso destacar la importancia que tiene para una empresa contar con una

certificación que ofrezca al cliente la confianza de que el producto de software que

adquiere, con seguridad va satisfacer todas sus necesidades y a su vez da a la

empresa certificada la opción de colocar sus productos en mercados internacionales

compitiendo en igualdad de condiciones a sus similares extranjeras.

Con todas las bondades de CMM, siendo bien conocido que es un marco de trabajo

para mejoramiento de los procesos de software con una alta tasa de confiabilidad, no

es menos cierto que el proceso de certificación para pasar del nivel 1 al nivel 2 tiene

una duración estimada entre 23 y 39 meses (Software Engineering Institute). Esto

3

último resulta desmotivante para una empresa que desea ver resultados a corto plazo

(en la vida de un proyecto), sin tener que invertir grandes cantidades de recursos en el

esfuerzo que realiza, lamentablemente los métodos de mejoramiento de procesos SW-

CMM y su versión actualizada más reciente CMMI, son procesos que dan resultados

positivos pero luego de un nivel de inversión de varios órdenes de magnitud mayor,

comparado con otras metodologías. Esto afecta en mayor medida a las pequeñas y

medianas empresas, que como hemos dicho representan mayormente al universo de la

industria existente en Venezuela y de igual forma en Mérida.

Ante la definición del problema planteado el propósito del presente estudio es

establecer alternativa que conlleve a las empresas a optimizar tiempo, costos y

recursos. Para los efecto se tomará como modelo la metodología utilizada por

MOPROSOFT, que de acuerdo a lo señalado por H. Oktaba (Ob. citada) y otros, “se

fundamenta en ofrecer a la pequeña y mediana empresa un modelo basado en las

mejores prácticas internacionales con características como: fácil de entender, fácil de

aplicar, no costoso en su adopción y ser la base para alcanzar evaluaciones exitosas

con otros modelos y normas tales como ISO 9000:2000 y CMM”. En ese sentido, se

puede ajustar fácilmente a necesidades de cooperativas, plataformas desarrolladas en

estándares libres y organizaciones que ya tienen establecidos los procesos. Además es

prioridad del estado venezolano el mejoramiento de este tipo de organizaciones con

miras a mejorar el bienestar general de la población y el desarrollo endógeno,

haciendo de este un problema no solo de índole económica sino también social.

4

CAPÍTULO II. DESCRIPCIÓN DE LA EMPRESA

La Fundación para el desarrollo de la Ciencia y la Tecnología en el Estado Mérida

(FUNDACITE – MÉRIDA) es una institución pública adscrita al ministerio de

Ciencia y Tecnología que tiene por misión: “Promover y orientar el desarrollo del

Sistema Científico y Tecnológico del Estado Mérida, en función de dar soporte

al desarrollo social y económico de esta Región”.

Fundada en el año de 1989, es pionera en la coordinación y promoción de las

actividades Científicas y Tecnológicas de la región. Transitó en el contexto histórico

que promovió cambios importantes en el escenario mundial, nacional y local que

obligaban a una revisión de lo roles tradicionales de las instituciones dedicadas al

servicio público y a una adaptación planificada al nuevo entorno social, con sus

particulares exigencias.

Es por eso que FUNDACITE – MÉRIDA tiene por visión: “Ser el ente rector en

Ciencia, Tecnología e Innovación en el Estado Mérida”. Para ello tiene como

objetivos:

Consolidar a FUNDACITE MÉRIDA como el ente coordinador y vinculador del

Sector de Ciencia y Tecnología del Estado Mérida.

Fomentar y estimular una cultura en Ciencia y Tecnología.

Identificar las necesidades de los distintos sectores de la región en Ciencia y

Tecnología.

5

En la actualidad FUNDACITE MÉRIDA está estructurada de manera general en

tres partes, ellas son: Dirección, Servicios Operativos y Servicios de Apoyo.

Como lo muestra la figura 1:

Figura 1. Estructura Organizacional de Fundacite Mérida.

Consultoría Jurídica

Dirección Ejecutiva

Gerencia de Gestión Interna

Presidencia

Junta Directiva

Consejo General

Contraloría Interna

DIRECCIÓN

Unidad de Gestión en C y T

Tecnología y Sistemas

Informática

Promoción y Divulgación

SERVICIOS OPERATIVOS

Presupuesto

Finanzas y contabilidad

Servicios Generales

Grupo Secretarial

SERVICIOS DE APOYO

6

Destacando dentro de la Dirección Ejecutiva la Unidad de Informática departamento

donde se desarrolla el presente trabajo.

2.1 Unidad de Informática.

La Unidad de Informática es una dependencia de la Dirección Ejecutiva que está

compuesta por los departamentos de software interno, software externo,

administración de servicios y telecomunicaciones.

Figura 2. Esquema Organizativo de la Unidad de Informática.

La Unidad de Informática posee basta experiencia en desarrollar e implementar

proyectos en el área de tecnología de la información, comunicaciones e informática

en plataformas basadas en licencias libres como el sistema operativo LINUX por

Esquema Organizativo

Software internoSoftware externo

Presidencia

Administración de Servidores

Telecomunicaciones

Gerencia de Planificación

Asistente

Analista de Proyecto Apoyo UGCyT

P-L P-L P-L E T E T E T

7

ejemplo y herramientas de desarrollo como Perl, PHP, Html, C++, etc., según las

necesidades del proyecto. También se caracteriza por aplicar metodologías de

avanzada en el desarrollo de software libre como la programación extrema la cual

hace de la relación usuario-desarrollador una ventaja que se traduce en beneficios

para el cumplimiento de los objetivos del proyecto.

Por disposición del ejecutivo nacional según decreto 3.390, articulo primero, el cual

expresa:

“La Administración Pública Nacional empleará prioritariamente Software Libre

desarrollado con Estándares Abiertos, en sus sistemas, proyectos y servicios

informáticos. A tales fines, todos los órganos y entes de la Administración Pública

Nacional iniciarán los procesos de migración gradual y progresiva de éstos hacia el

Software Libre desarrollado con Estándares Abiertos.” Fundacite - Mérida a través

de la Unidad de Informática, actúa como parte facilitadota en el proceso de migración

hacia el Software Libre de las distintas instituciones gubernamentales. De igual

forma, implementando mecanismos de concertación y convenios, detecta y aporta

soluciones en la parte informática a sectores que hacen vida en el estado, como el

turístico, agrícola y hospitalario. Muestra de su capacidad, ha generado proyectos

tales como El Centro Nacional de Seguridad Informática, La Red Teleinformática de

Ciencia, Tecnología e Innovación del Estado Mérida, Sistemas Automatizados para la

gestión Turística, Agrícola, Hospitalaria, entre otros.

Así la Unidad de Informática, con el aporte de sus diferentes actividades, cumple con

los objetivos, lineamientos y parámetros que Fundacite - Mérida ha establecido como

razón de ser y cumple con gran labor social prestando soporte educacional y de

8

entrenamiento de las herramientas informáticas a personas e instituciones que así lo

requieran.

2.2 Fabrica de Software Libre (FSL)

La coordinación de informática de Fundacite Mérida cuenta con la fábrica de

software libre (FSL) la misma esta integrada por un equipo de desarrolladores cuyo

propósito es analizar y desarrollar sistemas de información bajo plataforma web para

instituciones gubernamentales a nivel regional y nacional.

Esta iniciativa surge en el segundo trimestre del año 2004 en el marco de varios

proyectos que se dirigen hacia la promoción del desarrollo de software de calidad en

la región.

Entre los servicios que ofrece:

Análisis y diseño de sistemas.

Desarrollo del software.

Diseño gráfico del portal web.

Documentación del sistema.

Biblioteca de software (Es la zona de descarga de aplicaciones culminadas.)

La FSL cuenta con 15 estaciones de trabajo bajo distribuciones Linux

Fedora/Debian/Ubuntu y programas de aplicación de software libre que son

ejecutables en esta plataforma.

9

2.3 Academia de Software Libre

La Academia de Software Libre, ASL, creada por Fundacite Mérida con el apoyo del

Ministerio de Ciencias y Tecnología, contribuye con el fortalecimiento de la

infocultura del Estado venezolano, creando y manteniendo espacios de capacitación

para increpar la calidad del software libre en el país y mejorar la eficiencia en el

desarrollo de sistemas.

La FSL promueve la educación, capacitación y certificación de desarrolladores y

empresas de software, fortaleciendo de esta manera las actividades de migración que

se derivan del decreto 3390, emanado de la Presidencia de la República, que establece

la preferencia en el uso de software libre en la Administración Pública

10

CAPÍTULO III. MARCO TEÓRICO

En este capitulo se quiere mostrar una visión más amplia y detallada del soporte

teórico que sustenta este trabajo. Se desarrollarán algunos conceptos y definiciones

así como se describirán las categorías de los procesos establecidos en MoProSoft,

eje fundamental en la estructura de esta tesis. También se analizarán otros modelos

importantes dentro de la industria con algunas de sus ventajas y desventajas.

3.1 Ingeniería del Software

La Ingeniería de software es la rama de la ingeniería que crea y mantiene las

aplicaciones de software aplicando tecnologías y prácticas de las ciencias

computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros

campos. La Ingeniería del Software, término utilizado por primera vez por Fritz

Bauer en la primera conferencia sobre desarrollo de software patrocinada por el

Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de

1968, 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 un coste razonable, de software que satisfaga las necesidades de los usuarios".

3.2 MoProSoft

Es un Modelo de Procesos para la Industria del Software (MoProSoft) que fomenta la

estandarización de su operación a través de las mejores prácticas en gestión de la

Ingeniería de Software, la adopción de este modelo permitirá elevar la capacidad de

11

las organizaciones para ofrecer servicios de calidad y alcanzar niveles

internacionales de competitividad.

Dentro de las características más resaltantes se pueden nombrar:

Fácil de entender.

Fácil de aplicar.

No costoso en su adopción.

Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales

como ISO 9000:2000 o CMM.

El Modelo que propone MoProSoft esta enfocado en los procesos, es decir, su

filosofía dice que si el proceso es de alta calidad el producto asociado a ese proceso

también lo es, y considera los tres niveles básicos de la estructura de una organización

que son: Alta Dirección, Gestión y Operación. El modelo pretende apoyar a las

organizaciones en la estandarización de sus prácticas, en la evaluación de su

efectividad y en la integración de la mejora continua.

3.2.1 Categoría de Procesos

3.2.1.1 Categoría de Alta Dirección (DIR)

Categoría de procesos que aborda las prácticas de Alta Dirección relacionadas con la

gestión del negocio. Proporciona los lineamientos a los procesos de la Categoría de

Gestión y se retroalimenta con la información generada por ellos.

12

3.2.1.2 Categoría de Gestión (GES)

Categoría de procesos que aborda las prácticas de gestión de procesos, proyectos y

recursos en función de los lineamientos establecidos en la Categoría de Alta

Dirección. Proporciona los elementos para el funcionamiento de los procesos de la

Categoría de Operación, recibe y evalúa la información generada por éstos y

comunica los resultados a la Categoría de Alta Dirección.

3.2.1.3 Categoría de Operación (OPE)

Categoría de procesos que aborda las prácticas de los proyectos de desarrollo y

mantenimiento de software. Esta categoría realiza las actividades de acuerdo a los

elementos proporcionados por la Categoría de Gestión y entrega a ésta la información

y productos generados.

El esquema de las categorías de procesos está presentado en la figura 3.

Figura 3.Categorías de procesos

13

3.2.2 Procesos

3.2.2.1 DIR.1 Gestión de Negocios

El propósito de Gestión de Negocio es establecer la razón de ser de la organización,

sus objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las

necesidades de los clientes, así como evaluar los resultados para poder proponer

cambios que permitan la mejora continua.

Adicionalmente habilita a la organización para responder a un ambiente de cambio y a

sus miembros para trabajar en función de los objetivos establecidos.

3.2.2.2 GES.1 Gestión de Procesos

El propósito de Gestión de Procesos es establecer los procesos de la organización, en

función de los procesos requeridos identificados en el plan estratégico. Así como

definir, planear, e implantar las actividades de mejora en los mismos.

3.2.2.3 GES.2 Gestión de Proyectos

El propósito de la Gestión de Proyectos es asegurar que los proyectos contribuyan al

cumplimiento de los objetivos y estrategias de la organización.

3.2.2.4 GES.3 Gestión de Recursos

El propósito de Gestión de Recursos es conseguir y dotar a la organización de los

recursos humanos, infraestructura, ambiente de trabajo y proveedores, así como crear

y mantener la base de conocimiento de la organización. La finalidad es apoyar el

cumplimiento de los objetivos del plan estratégico de la organización.

14

3.2.2.5 GES.3.1 Recursos Humanos y Ambiente de Trabajo

El propósito de Recursos Humanos y Ambiente de Trabajo es proporcionar los

recursos humanos adecuados para cumplir las responsabilidades asignadas a los roles

dentro de la organización, así como la evaluación del ambiente de trabajo.

3.2.2.6 GES.3.2 Bienes, Servicio e Infraestructura

El propósito de Bienes, Servicios e Infraestructura es proporcionar proveedores de

bienes, servicios e infraestructura que satisfagan los requisitos de adquisición de los

procesos y proyectos.

3.2.2.7 GES.3.3 Conocimiento de la Organización

El propósito de Conocimiento de la Organización es mantener disponible y

administrar la base de conocimiento que contiene la información y los productos

generados por la organización.

3.2.2.8 OPE.1 Administración de Proyectos Específicos

El propósito de la Administración de Proyectos Específicos es establecer y llevar a

cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un

proyecto en tiempo y costo esperados.

3.2.2.9 OPE.2 Desarrollo y Mantenimiento de Software

El propósito de Desarrollo y Mantenimiento de Software es la realización sistemática

de las actividades de análisis, diseño, construcción, integración y pruebas de

15

productos de software nuevos o modificados cumpliendo con los requerimientos

especificados.

La relación entre los diferentes procesos viene dada como lo indica la figura 4

3.3 Otros Modelos

3.3.1 CMM

En el Modelo de Madurez de la Capacidad del Software del SEI (Software

Capability Maturity Model, SW-CMM) se definen un conjunto de áreas clave del

proceso, que describen las funciones de Ingeniería de Software que deben llevarse a

cabo para el desarrollo de una buena práctica, agrupadas en cinco niveles inclusivos.

Figura 4.Relación entre procesos

16

Estos niveles sirven de referencia para el conocimiento del estado de la madurez del

proceso del software en la organización. Mediante un amplio conjunto de métricas se

determina la calidad de cada una de las áreas clave, obteniéndose una visión precisa

del rigor, la eficacia y la eficiencia de la metodología de desarrollo de una

organización productora de software.

3.3.1.1 Inicial

Está caracterizado por una aproximación intuitiva al proceso de desarrollo del

software. El éxito depende del esfuerzo individual. No se han definido procesos

metodológicos, o se han definido pero no se siguen. Es necesario realizar medidas de

línea base, es decir, medidas que servirán para estimar y planificar en el futuro.

Asimismo, es el momento de hacer un esfuerzo de estructuración y control en el

proceso.

3.3.1.2 Repetible

La madurez metodológica de la organización permite estimar fiablemente el tamaño

funcional o físico del sistema, así como recursos, esfuerzo, costes y calendario. Se

han sentado las bases para repetir éxitos anteriores en proyectos con aplicaciones

similares.

3.3.1.3 Definido

Se conoce la forma de construcción del sistema. El proceso de software de las

actividades de gestión e ingeniería se documenta y se estandarizan. Las actividades

intermedias están bien definidas, y por tanto se pueden examinar y medir.

17

3.3.1.4 Gestionado

Se añade la gestión a un proceso definido. Se usa realimentación desde las primeras

actividades del proyecto para seleccionar prioridades en las actividades actuales y

conocer cómo se emplean los recursos. Los efectos de los cambios en una actividad

se pueden seguir en otras. Se recopilan medidas detalladas del proceso del software y

de la calidad del producto. En definitiva, se evalúa la efectividad de las actividades

del proceso.

3.3.1.5 Optimizado

Existe una mejora continua de los procesos. Las medidas de actividades se usan para

mejorar el proceso, eliminando y añadiendo actividades y reorganizando su estructura

como respuesta a los resultados de las medidas.

Como se ha mencionado al principio de este apartado los niveles en los que se

agrupan las áreas claves de proceso son inclusivos: para alcanzar uno es necesario

haber alcanzado (y mantener) todos los anteriores:

.

Figura 5. Niveles inclusivos de CMM

18

3.3.2 ISO 15504

ISO/IEC 15504 es un emergente estándar internacional de evaluación y

determinación de la capacidad y mejora continua de procesos de ingeniería del

software, con la filosofía de desarrollar un conjunto de medidas de capacidad

estructuradas para todos los procesos del ciclo de vida y para todos los participantes.

Es el resultado de un esfuerzo internacional de trabajo y colaboración y tiene la

innovación, en comparación con otros modelos, del proceso paralelo de evaluación

empírica del resultado.

Este modelo se caracteriza por tener seis (6) niveles de madurez de procesos que a

continuación describimos:

3.3.2.1 Nivel 0: Proceso Incompleto

El proceso no ha sido implementado o falla en la consecución de su propósito.

3.3.2.2 Nivel 1: Proceso Desarrollado

El proceso implementado alcanza sus objetivos.

3.3.2.3 Nivel 2: Proceso Gestionado

El proceso anteriormente descrito como proceso desarrollado se implementa ahora de

un modo gestionado (planificado, supervisado y ajustado) y sus productos de trabajo

se establecen, controlan y mantienen de forma apropiada.

19

3.3.2.4 Nivel 3: Proceso Establecido

Un proceso anteriormente descrito como un proceso gestionado se implementa ahora

utilizando un procedimiento definido que es capaz de conseguir resultados.

3.3.2.5 Nivel 4: Proceso Predecible

El proceso anteriormente definido como proceso establecido ahora operaría dentro de

unos límites definidos para conseguir sus resultados.

3.3.2.6 Nivel 5: Proceso en Optimización

El proceso anteriormente definido como proceso predecible se mejora continuamente

para cumplir objetivos de negocio relevantes actuales y futuros.

3.3.3 ISO 9000:2000

ISO 9000 es un conjunto de estándares internacionales para sistemas de calidad.

Diseñado para la gestión y aseguramiento de la calidad, especifica los requisitos

básicos para el desarrollo, producción, instalación y servicio a nivel de sistema y a

nivel de producto.

La familia de estándares es la siguiente:

ISO 9000, Fundamentos y vocabulario.

ISO 9001, Requisitos para aseguramiento de la calidad.

ISO 9004, Directrices para la mejora del rendimiento.

20

ISO 9011, Directrices para la auditoria de los sistemas de gestión de la calidad y/o

ambiental.

ISO 9001 e ISO 9004 se han desarrollado como un par coherente de normas,

complementándose. Mientras ISO 9001 se centra en la eficacia del sistema de gestión

de la calidad para dar cumplimiento a los requisitos del cliente, ISO 9004 se

recomienda para organizaciones que persiguen la mejora continua, sin afán

certificador.

El estándar se basa en un conjunto de Principios de Gestión de la Calidad:

Enfoque al cliente, Liderazgo, Implicación de todo el personal, Enfoque a procesos,

Enfoque del sistema hacia la gestión, Mejora continua, Enfoque objetivo hacia la

toma de decisiones y Relaciones mutuamente beneficiosas con los proveedores.

Las cinco secciones en que se divide ISO 9001:2000 son:

QMS Sistema de Gestión de la Calidad (Requisitos generales y Requisitos de la

documentación).

Responsabilidad de la Gestión (Compromiso de la dirección, Enfoque al cliente,

Política de la calidad, Planificación,…).

Gestión de los Recursos (Provisión de recursos, Recursos humanos,

Infraestructura, Ambiente de trabajo).

Realización del Producto (Planificación de la realización del producto, Procesos

relacionados con los clientes, Diseño y desarrollo, Compras, Prestación del

servicio,…).

Medición, Análisis y Mejora (Generalidades, Supervisión y Medición, Control de

servicio no-conforme, Análisis de datos, Mejora).

21

SW- CMM 1993

ISO/IEC15504-2:2003

ISO

SEI

ISO 9000:1994

ISO/IEC 12207:1995

ISO 9000:2000

ISO/IEC TR 15504:1998

CMMI 2002

ISO/IEC 12207 ENMIENDA 1 :2002

Figura 6. Evolución en el tiempo de los modelos ISO, SEI

3.4 Organización Madura

Aquella que posee la potencialidad para desarrollar y administrar sus proyectos de

software en forma consistente y proactiva, así como también la capacidad de

mantener y mejorar sus procesos. Una organización madura se caracteriza por

mantener procesos consistentes a través de sus distintos proyectos.

Curtís y Paulk en 1993 realizaron un comparativo entre los procesos maduros e

inmaduros, con el fin de comparar los extremos y crear un marco de referencia, y es

el siguiente:

Proceso Inmaduro Proceso Maduro

Proceso improvisado Trabajo consistente, definido, documentado y continuamente novedoso

Procedimientos no realizados Los esfuerzos son apoyados claramente por todos los involucrados.

Dependencia en individuos La organización es más importante y no

22

dependiente

La funcionalidad y calidad del producto pueden afectarse con el objetivo de cumplir fechas límite

Mediciones de productos y procesos

El uso de nueva tecnología es riesgoso Uso disciplinado de la tecnología

La calidad es difícil de predecir El proceso realizado es controlado y auditado.

Figura 7. Tabla comparativa de procesos maduros e inmaduros

3.5 Software Libre

Programa de computación cuya licencia garantiza al usuario acceso al código fuente

del programa y lo autoriza a ejecutarlo con cualquier propósito, modificarlo y

redistribuir tanto el programa original como sus modificaciones en las mismas

condiciones de licenciamiento acordadas al programa original, sin tener que pagar

regalías a los desarrolladores previos.

3.6 Metodología Ágil

Las metodologías ágiles (como por ejemplo XP, SCRUM, DSDM, Crystal, etc.)

forman parte del movimiento de desarrollo ágil de software, que se basan en la

adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de

éxito de un proyecto.

De forma que una metodología ágil es la que tiene como principios que:

23

Los individuos y sus interacciones son más importantes que los procesos y las

herramientas.

El software que funciona es más importante que la documentación exhaustiva.

La colaboración con el cliente en lugar de la negociación de contratos.

La respuesta delante del cambio en lugar de seguir un plan cerrado.

Se puede decir que, este movimiento empezó a existir a partir de febrero de 2001,

cuando se reunieron los representantes de cada una de estas metodologías y

terminaron poniendo en común sus ideas en una declaración conjunta.

3.7 Programación Extrema

La programación extrema es una metodología de desarrollo ligera (o ágil) basada en

una serie de valores y de prácticas de buenas maneras que persigue el objetivo de

aumentar la productividad a la hora de desarrollar programas. Este modelo de

programación se basa en una serie de metodologías de desarrollo de software en la

que se da prioridad a los trabajos que dan un resultado directo y que reducen la

burocracia que hay al rededor de la programación.

Una de las características principales de este método de programación, es que sus

ingredientes son conocidos desde el principio de la informática. Los autores de XP

han seleccionado aquellos que han considerado mejores y han profundizado en sus

relaciones y en como se refuerzan los unos con los otros. El resultado de esta

selección ha sido esta metodología única y compacta. Por esto, aunque no está basada

24

en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de

software.

El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda

de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el

sentido común.

25

CAPITULO IV. ELABORACIÓN DE LA HERRAMIENTA DE

EVALUACIÓN

El propósito de la herramienta de evaluación es definir un método para obtener el

grado de madurez de los procesos evaluados por cada nivel de capacidad basado en

los criterios utilizados por MoProSoft en sus diferentes apartados.

4.1 Alcance

La herramienta de evaluación puede ser aplicada en empresas, o departamentos de

informática dentro de diferentes empresas, dedicadas al desarrollo de software. Dado

que MoProSoft está basado en las normas ISO, la herramienta podría ser aplicada a

cualquier tipo de procesos utilizando y variando el patrón de procesos original

sugerido por MoProSoft.

El patrón de procesos de MoProSoft es un esquema de elementos que servirá para la

documentación de los procesos. Está constituido por tres partes: Definición general

del proceso, Prácticas y Guías de ajuste. En la Definición general del proceso se

identifica su nombre, categoría a la que pertenece, propósito, descripción general de

sus actividades, objetivos, indicadores, metas cuantitativas, responsabilidad y

autoridad, subprocesos en caso de tenerlos, procesos relacionados, entradas, salidas,

productos internos y referencias bibliográficas.

En las Prácticas se identifican los roles involucrados en el proceso y la capacitación

requerida, se describen las actividades en detalle, asociándolas a los objetivos del

proceso, se presenta un diagrama de flujo de trabajo, se describen las verificaciones y

26

validaciones requeridas, se listan los productos que se incorporan a la base de

conocimiento, se identifican los recursos de infraestructura necesarios para apoyar las

actividades, se establecen las mediciones del proceso, así como las prácticas para la

capacitación, manejo de situaciones excepcionales y uso de lecciones aprendidas.

En las Guías de ajuste se sugieren modificaciones al proceso que no deben afectar los

objetivos del mismo.

4.2 Bases Conceptuales

La Herramienta de evaluación se ha creado por la necesidad de contar con un

instrumento evaluador, debido a que, al momento de iniciar este trabajo, no se

encontraba a disposición ninguna herramienta que se pudiera utilizar. Tomando como

soporte EvalProSoft y la norma ISO 19011:2002 “Directrices para la auditoria de los

sistemas de gestión de la calidad y/o ambiental”, estos documentos especializados en

evaluar y auditar, son la base teórica que fundamentan a la Herramienta de

Evaluación y que a continuación se describirán:

4.2.1 EvalProSoft

El propósito del método de evaluación de procesos EvalProSoft para la industria de

software es otorgar a la organización solicitante un perfil del nivel de capacidad de

los procesos implantados en la organización y un nivel de madurez de capacidades de

la organización, tomando como referencia o modelo MoProSoft, el cual fue descrito

en el capitulo anterior.

27

4.2.2 ISO 19011

Proporciona orientación relativa a las auditorias a sistemas de gestión de la calidad y

de gestión ambiental. Proporciona las directrices para los fundamentos y realización

de las auditorias así como para la gestión de los programas de auditoria y la

calificación de los auditores. Se refiere tanto a los Sistemas de Gestión de la Calidad

como a los de Gestión Ambiental. Se aplica en auditorias internas y externas.

4.3 Descripción de la Herramienta de Evaluación

La Herramienta de Evaluación es una encuesta que valora a los procesos desde el

punto de vista de cada una de las categorías de proceso y según el nivel de capacidad

de la organización. La encuesta esta estructurada por ítems o puntos del proceso que

se quieren evaluar, para cada uno de los procesos. Esta Herramienta es usada como si

se tratara de una auditoria, de modo que mientras se ejecuta se solicitan para la

verificación la documentación digital escrita que respalde el punto del proceso que se

esta evaluando. Como la Herramienta de Evaluación esta basada en MoProSoft los

nombres de los procesos están tomados de este modelo.

Los diferentes procesos de MoProSoft y sus respectivas claves se utilizan para

identificar a los productos de trabajo, que son las instancias que proporcionan el

contenido mínimo que debe cubrirse por proceso en cualquier nivel de capacidad y

madurez.

28

Los procesos considerados por MoProSoft y sus correspondientes claves son:

Clave Proceso

GN Gestión de Negocios

GPR Gestión de Procesos

GPY Gestión de Proyectos

GR Gestión de Recursos

RHAT Recursos Humanos y Ambiente de Trabajo

BSI Bienes, Servicios e Infraestructura

CO Conocimiento de la Organización

APE Administración de proyectos Específicos

DMS Desarrollo y Mantenimiento de Software

Figura 8. Tabla de procesos con sus respectivas claves

Se ha utilizado para identificar a los productos de trabajo la siguiente nomenclatura:

Pr.An.PTm donde:

Pr es la Clave del Proceso.

An es la Actividad número n del proceso.

PTm es el Producto de Trabajo número m.

Siendo m y n números progresivos.

29

Un ejemplo de la notación sería el siguiente:

GN.A1.PT1 lo cual traduce que es el producto de trabajo 1, de la actividad 1 del

proceso de Gestión de Negocios.

Una vez identificado el proceso y codificado se da el nombre al producto de trabajo

como indica en la figura 9.

Evaluación de productos y prácticas requeridos para el primer nivel de capacidad de proceso.

Proceso: Gestión de Negocios. Fecha: 25-04-06

GN.A1.PT1 Plan Estratégico

Figura 9. Ejemplo de proceso codificado y nombre del producto de trabajo

La Herramienta de Evaluación cuenta con cinco columnas con características que se

describirán a continuación.

Primera columna: de numeración, indica cada punto dentro del producto de

trabajo y facilita de gran manera el manejo de la auditoria a la hora de evaluar.

Segunda columna: nombre del ítem o punto de evaluación. Es una descripción

breve dentro del proceso que el producto de trabajo quiere evaluar.

30

Tercera columna: casilla de evaluación, arroja como salida dos posibles valores:

a) SI, en caso de ser satisfactoria la evaluación y se presenta la documentación

requerida, o, b) NO cuando existe inconformidades o no se cumple lo anterior.

Cuarta columna: observaciones, en esta columna el auditor coloca las diferentes

percepciones y todos los detalles que sirvan para apoyar su evaluación final.

Quinta columna: porcentaje de ítem, esta columna representa el porcentaje del

punto evaluado cuando la salida de la tercera columna es NO. Es decir, el proceso

se realiza pero no de manera completa. Esta columna no fue tomada en cuenta

para la conclusión, pero da una idea de los correctivos a la empresa auditada.

La manera en la que la Herramienta de Evaluación quedó distribuida la muestra la

figura 10.

31

Evaluación de productos y prácticas requeridos para el primer nivel de capacidad de proceso.



1 Misión.

2 Visión

3 Valores

4 Objetivos

5 Estrategias de procesos, recursos y proyectos

6 Procesos Requeridos

7 Cartera de Proyectos

8 Estructura de la Organización

9 Estrategias de Recursos

10 Presupuesto

11 Periodicidad de Valoración

12 Plan de comunicación con el cliente Figura 10. La Herramienta de Evaluación

32

Evaluación 1

0,00

20,00

40,00

60,00

80,00

100,00

120,00

GN

.A1.

PT1

GPR

.A1P

T1

GPY

.A1.

PT1

GPY

.A1.

PT3

GPY

.A1.

PT5

GPY

.A2.

PT2

GPY

.A2.

PT4

GR.

A1.

PT2

RHA

T.A

2.PT

1

BSI.A

1.PT

2

CO.A

1.PT

1

CO.A

2.PT

2

APE

.A1.

PT2

DM

S.A

2.PT

1

DM

S.A

4.PT

1

DM

S.A

5.PT

1

Productos de Trabajo

% Ít

ems C

ompl

etad

os

Evaluación 1

CAPITULO V. EVALUACIÓN DE LA ORGANIZACIÓN Y

RESULTADOS

La evaluación como ya se ha dicho se realizó a la Unidad de Informática de

Fundacite-Mérida en forma de encuesta utilizando la Herramienta de evaluación

antes señalada. Con el objeto de analizar la evolución de los procesos planteados por

MoProSoft se planificó hacer 3 evaluaciones donde se pudieran constatar el estado

inicial de la Unidad, un etapa intermedia y comprobar el estado final producto del

trabajo realizado.

5.1 Evaluación 1

Los resultados obtenidos de la primera evaluación a la Unidad de Informática de

FUNDACITE-Mérida (UI) son presentados, de manera resumida, en el siguiente

gráfico:

Figura 11. Gráfico Productos de Trabajo vs. % Ítems Completados en la

Evaluación 1

33

En términos generales podemos decir que las principales fallas de los procesos de la

UI están en la documentación requerida, la cual resultó ser casi nula (ver Figuras 11 y

12). Una de las razones de la carencia de documentación es la aplicación de

metodologías como la programación extrema, la cual trata de suprimir la mayoría de

trámites “burocráticos” en función de generar a la brevedad versiones de los

programas, para aprovechar la rápida interacción con el usuario final. Se observa que

17 de 32 productos de trabajos tienen valor en porcentaje igual a cero (0) lo que

indica, según los parámetros de MoProSoft, que existen no conformidades. Una no

conformidad se presenta cuando el evaluador o auditor no encuentra respuesta

efectiva al evaluar cualquier ítem o punto dentro de cualquier Producto de Trabajo

(PT). Las no conformidades más reiterativas son la falta de documentación y la no

existencia del PT. Dentro de los procesos que presentan porcentaje cero en todos sus

PT están: Gerencia de Proceso, Conocimiento de la Organización y Recursos

Humanos y Ambiente de Trabajo. Otros procesos que tienen PT en porcentaje cero

son: Gerencia de Proyecto, que tiene 5 de 9 PT, y Desarrollo y Mantenimiento de

Software, que tiene 3 de 4 PT en este valor, entre otros. Por otro lado están los PT

que rondan hasta los 60 puntos porcentuales ubicados dentro de los procesos de

Gestión de Negocios, Gestión de Procesos, Gestión de Proyectos, Solicitud de Bienes

y Servicios y Administración de proyectos Específicos. Sobre los 60 puntos

porcentuales encontramos 6 PT destacando el proceso de Desarrollo y Mantenimiento

de Software con 3 de 4 PT en el 100 por ciento del valor porcentual.

34

En el siguiente cuadro se presentan los resultados obtenidos a partir de la primera

evaluación.

Producto de Trabajo Cod. Nº

ítems Conforme Porcentaje

1 Plan Estratégico GN.A1.PT1 12.00 3.00 25.002 Plan de Adquisiciones y Capacitación GN.A1.PT2 4.00 3.00 75.003 Plan de Proceso GPR.A1PT1 5.00 1.00 20.004 Documentación del Proceso GPR.A2.PT1 19.00 3.00 15.795 Plan de Adquisiciones y Capacitación GPY.A1.PT1 8.00 6.00 75.006 Plan de Gestión de Proyectos GPY.A1.PT2 2.00 1.00 50.007 Plan de Concertación GPY.A1.PT3 5.00 0.00 0.008 Plan de Proyectos GPY.A1.PT4 1.00 0.00 0.009 Alternativas de realización de proyectos internos GPY.A1.PT5 2.00 0.00 0.0010 Contrato GPY.A2.PT1 1.00 0.00 0.0011 Registro de Proyecto GPY.A2.PT2 4.00 2.00 50.0012 Descripción del Proyecto GPY.A2.PT3 8.00 4.00 50.0013 Responsable de Administración de Proyecto Específico GPY.A2.PT4 1.00 0.00 0.0014 Plan Operativo de Recursos Humanos y Ambiente de Trabajo GR.A1.PT1 3.00 0.00 0.0015 Plan de Adquisiciones y Capacitación GR.A1.PT2 5.00 0.00 0.0016 Plan de Capacitación RHAT.A1.PT1 5.00 0.00 0.0017 Registro de Recursos Humanos RHAT.A2.PT1 6.00 0.00 0.0018 Plan de Mantenimiento BSI.A1.PT1 3.00 0.00 0.0019 Solicitud de Bienes y Servicios BSI.A1.PT2 5.00 5.00 100.0020 Registro de Bienes y servicios BSI.A2.PT1 3.00 2.00 66.6721 Plan de Administración de la base de Conocimiento CO.A1.PT1 6.00 0.00 0.0022 Diseño de la Base de Conocimiento CO.A2.PT1 6.00 0.00 0.0023 Base de Conocimiento CO.A2.PT2 8.00 0.00 0.0024 Plan de Desarrollo APE.A1.PT1 3.00 0.00 0.0025 Plan de Proyecto APE.A1.PT2 8.00 4.00 50.0026 Documentación de Aceptación APE.A4.PT1 1.00 0.00 0.0027 Especificación de Requisitos DMS.A2.PT1 12.00 0.00 0.0028 Análisis y Diseño DMS.A3.PT1 2.00 0.00 0.0029 Componente DMS.A4.PT1 1.00 0.00 0.0030 Software DMS.A4.PT1 1.00 1.00 100.0031 Manual de Usuario DMS.A5.PT1 1.00 1.00 100.0032 Manual de Operaciones DMS.A5.PT2 1.00 1.00 100.00

Figura 12. Tabla de resultados Evaluación 1

35

Gráfico comparativo

0,0020,0040,0060,0080,00

100,00120,00

GN.A1.P

T1

GPR.A

2.PT1

GPY.A

1.PT3

GPY.A

2.PT1

GPY.A

2.PT4

RHAT.A1.P

T1

BSI.A1.P

T2

CO.A2.P

T1

APE.A

1.PT2

DMS.A3.P

T1

DMS.A5.P

T1

Productos de trabajo

% Ít

ems c

omle

t

Evaluación 1Evaluación 2

5.2 Evaluación 2

Para la segunda evaluación se encontró que algunos PT que fueron nulos en la

primera evaluación ya se hallaban presentando cierto tipo de avance, lográndose, en

particular, que 4 PT más que en la primera evaluación lleguen al máximo de cien

puntos porcentuales. A la par de éste trabajo también se comenzó en Fundacite

Mérida el desarrollo y aplicación de una metodología donde se toman ideas de los

métodos ágiles como la programación extrema, y de otros métodos o modelos de

referencia con algo más de formalidad como RUP y Watch, y el mismo MoProSoft.

Esta herramienta ha contribuido junto al presente trabajo a los cambios realizados en

la UI. Se espera que la aplicación conjunta de métodos de evaluación, como el

seguido en este trabajo, y metodologías como la que se está desarrollando, continúe

dando frutos en un futuro no muy lejano.

En la figura 13 se comparan la primera y la segunda evaluación.

Figura 13. Gráfico comparativo entre Evaluación 1 y Evaluación 2

36

En la segunda evaluación se observa una mejora en los procesos de gestión de

negocios y gestión de procesos, así como de manera particular en la gestión de

proyectos al ubicar 2 de sus 8 PT en el máximo del puntaje porcentual y mejorar en

otros dos respecto de la primera evaluación.

La figura 14 muestra los resultados completos obtenidos en la evaluación.

Producto de Trabajo Cod. Nº ítems Conforme % 1 Plan Estratégico GN.A1.PT1 12.00 3.00 25.002 Plan de Adquisiciones y Capacitación GN.A1.PT2 4.00 3.00 75.003 Plan de Proceso GPR.A1PT1 5.00 3.00 60.004 Documentación del Proceso GPR.A2.PT1 19.00 9.00 47.375 Plan de Adquisiciones y Capacitación GPY.A1.PT1 8.00 6.00 75.006 Plan de Gestión de Proyectos GPY.A1.PT2 2.00 1.00 50.007 Plan de Concertación GPY.A1.PT3 5.00 0.00 0.008 Plan de Proyectos GPY.A1.PT4 1.00 1.00 100.009 Alternativas de realización de proyectos internos GPY.A1.PT5 2.00 0.00 0.00

10 Contrato GPY.A2.PT1 1.00 1.00 100.0011 Registro de Proyecto GPY.A2.PT2 4.00 3.00 75.0012 Descripción del Proyecto GPY.A2.PT3 8.00 7.00 87.5013 Responsable de Administración de Proyecto Específico GPT.A2.PT4 1.00 0.00 0.0014 Plan Operativo de Recursos Humanos y Ambiente de Trabajo GR.A1.PT1 3.00 0.00 0.0015 Plan de Adquisiciones y Capacitación GR.A1.PT2 5.00 0.00 0.0016 Plan de Capacitación RHAT.A1.PT1 5.00 0.00 0.0017 Registro de Recursos Humanos RHAT.A2.PT1 6.00 6.00 100.0018 Plan de Mantenimiento BSI.A1.PT1 3.00 0.00 0.0019 Solicitud de Bienes y Servicios BSI.A1.PT2 5.00 5.00 100.0020 Registro de Bienes y servicios BSI.A2.PT1 3.00 2.00 66.6721 Plan de Administración de la base de Conocimiento CO.A1.PT1 6.00 0.00 0.0022 Diseño de la Base de Conocimiento CO.A2.PT1 6.00 0.00 0.0023 Base de Conocimiento CO.A2.PT2 8.00 0.00 0.0024 Plan de Desarrollo APE.A1.PT1 3.00 3.00 100.0025 Plan de Proyecto APE.A1.PT2 8.00 5.00 62.5026 Documentación de Aceptación APE.A4.PT1 1.00 0.00 0.0027 Especificación de Requisitos DMS.A2.PT1 12.00 5.00 41.6728 Análisis y Diseño DMS.A3.PT1 2.00 0.00 0.0029 Componente DMS.A4.PT1 1.00 0.00 0.0030 Software DMS.A4.PT1 1.00 1.00 100.0031 Manual de Usuario DMS.A5.PT1 1.00 1.00 100.0032 Manual de Operaciones DMS.A5.PT2 1.00 1.00 100.00

Figura 14. Tabla de resultados de la Evaluación 2

37

Gráfico Comparativo

0,00

20,00

40,00

60,00

80,00

100,00

120,00

GN.A1.PT1

GPR.A1PT1

GPY.A1.P

T1

GPY.A1.P

T3

GPY.A1.P

T5

GPY.A2.P

T2

GPY.A2.P

T4

GR.A1.PT2

RHAT.A2.PT1

BSI.A1.P

T2

CO.A1.PT1

CO.A2.PT2

APE.A1.PT2

DMS.A2.PT1

DMS.A4.PT1

DMS.A5.PT1

Productos de Trabajo

% Ít

ems

Com

plet

.

Evaluación 1

Evaluación 2

Evaluación 3

5.3 Evaluación 3

La tercera evaluación muestra resultados muy interesantes dado que 16 de los 32

Productos de Trabajo se encuentran en el máximo valor de porcentaje (100%). Esto

quiere decir que todos los ítems o puntos de estos 16 productos de trabajo están

conforme con lo que pide el modelo. También llama la atención el proceso

Conocimiento de la Organización, el cual no tuvo en ninguna de las evaluaciones

puntos porcentuales (0%). El gráfico que reúne las 3 evaluaciones donde se nota la

evolución en un tiempo menor de 5 meses se presenta en la figura 15:

Figura 15. Gráfico comparativo entre las 3 Evaluaciones

38

Los datos completos de la tercera evaluación se presentan en la Figura 16.

Producto de Trabajo Cod. Nº ítems conforme %

1 Plan Estratégico GN.A1.PT1 12.00 12.00 100.002 Plan de Adquisiciones y Capacitación GN.A1.PT2 4.00 3.00 75.003 Plan de Proceso GPR.A1PT1 5.00 5.00 100.004 Documentación del Proceso GPR.A2.PT1 19.00 12.00 63.165 Plan de Adquisiciones y Capacitación GPY.A1.PT1 8.00 7.00 87.506 Plan de Gestión de Proyectos GPY.A1.PT2 2.00 2.00 100.007 Plan de Concertación GPY.A1.PT3 5.00 5.00 100.008 Plan de Proyectos GPY.A1.PT4 1.00 1.00 100.009 Alternativas de realización de proyectos internos GPY.A1.PT5 2.00 2.00 100.0010 Contrato GPY.A2.PT1 1.00 1.00 100.0011 Registro de Proyecto GPY.A2.PT2 4.00 3.00 75.0012 Descripción del Proyecto GPY.A2.PT3 8.00 7.00 87.5013 Responsable de Administración de Proyecto Específico GPY.A2.PT4 1.00 1.00 100.0014 Plan Operativo de Recursos Humanos y Ambiente de Trabajo GR.A1.PT1 3.00 0.00 0.0015 Plan de Adquisiciones y Capacitación GR.A1.PT2 5.00 2.00 40.0016 Plan de Capacitación RHAT.A1.PT1 5.00 0.00 0.0017 Registro de Recursos Humanos RHAT.A2.PT1 6.00 6.00 100.0018 Plan de Mantenimiento BSI.A1.PT1 3.00 1.00 33.3319 Solicitud de Bienes y Servicios BSI.A1.PT2 5.00 5.00 100.0020 Registro de Bienes y servicios BSI.A2.PT1 3.00 2.00 66.6721 Plan de Administración de la base de Conocimiento CO.A1.PT1 6.00 0.00 0.0022 Diseño de la Base de Conocimiento CO.A2.PT1 6.00 0.00 0.0023 Base de Conocimiento CO.A2.PT2 8.00 0.00 0.0024 Plan de Desarrollo APE.A1.PT1 3.00 3.00 100.0025 Plan de Proyecto APE.A1.PT2 8.00 5.00 62.5026 Documentación de Aceptación APE.A4.PT1 1.00 1.00 100.0027 Especificación de Requisitos DMS.A2.PT1 12.00 8.00 66.6728 Análisis y Diseño DMS.A3.PT1 2.00 0.00 0.0029 Componente DMS.A4.PT1 1.00 1.00 100.0030 Software DMS.A4.PT1 1.00 1.00 100.0031 Manual de Usuario DMS.A5.PT1 1.00 1.00 100.0032 Manual de Operaciones DMS.A5.PT2 1.00 1.00 100.00

Figura 16. Tabla de resultados de la evaluación 3

5.4 Discusión

Al final, al realizar la tercera evaluación, muchos de los procesos de la UI están

bastante adelantados pero ninguno está completo. Cinco de los procesos están por

39

encima del 80%, ellos son: Gestión de Negocios, Gestión de Procesos, Gestión de

Proyectos, Administración de Proyectos Específicos y Desarrollo y Mantenimiento de

Software como se aprecia en la figura 17. Sobre el 50% están los procesos:

Recursos Humanos y Ambiente de Trabajo y Bienes, Servicios e Infraestructura. Con

20% o menos los procesos de Gestión de Recursos y Conocimiento de la

Organización. Llama poderosa mente la atención, la evolución de la Unidad de

Informática en tan corto tiempo, solo podríamos suponer que de haber continuado con

el desarrollo de este trabajo seguramente se habría alcanzado no solo el primer nivel

de capacidad de proceso, también mucho más.

Grafico de los Procesos

0.00 20.00 40.00 60.00 80.00 100.00

Proc

esos

% Completado

DMSAPECOBSIRHATGRGPYGPRGN

Figura 17. Gráfico de porcentaje por proceso.

40

Urge entonces mejorar los procesos de Conocimiento de la Organización y Gestión

de Recursos para alcanzar el objetivo de cumplir con los requerimientos del nivel 1

de capacidad de procesos en MoProSoft.

El proceso de Conocimiento de la Organización propone mantener disponible y

administrar la Base de Conocimiento que debería contener toda la información y los

productos generados por la organización. Para MoProSoft la base del conocimiento es

de fundamental importancia debido a que cuando funciona de manera eficiente trae

beneficios como por ejemplo: el manejo de la información de manera confiable,

oportuna y segura, también como biblioteca de reuso, entre otros beneficios. Por esto

resultaría importante concentrar esfuerzos para poner en marcha dicho proceso en el

menor tiempo posible.

41

CAPITULO VI. CONCLUSIONES Y RECOMENDACIONES.

6.1 Conclusiones

El hombre por su naturaleza es un ser que está en constante competencia, de

modo que para destacar requiere de preparación y dedicación para encontrar éxito

y reconocimiento en un mundo que cada vez se hace más exigente. De igual

manera pasa con las empresas y en especial aquellas que están dedicadas al

desarrollo de software, donde los cambios ocurren de manera tan rápida que solo

las que estén mejor preparadas sobrevivirán en un mercado tan difícil. Una de las

formas más efectivas de destacarse en el mercado es a través de la certificación.

En este trabajo se propone un modelo que otorga grandes beneficios, MoProSoft

que aunque no sea una certificación en Venezuela es una base para conseguir

cualquier otra certificación, como ISO, CMMI, etc.

Al hacer el estudio inicial y determinar las bondades del modelo se realizó un

gran esfuerzo por encontrar un mecanismo de evaluación para aplicar MoProSoft.

La búsqueda de EvalProSoft se hizo difícil debido a que se convirtió en una

norma mexicana, de tal manera que en función de tiempo y esfuerzo resultó

complicado. La llegada de EvalProSoft no fue lo esperado debido a que no es

explicita a la hora de afrontar la evaluación y en ese sentido prácticamente no

aporta nada, solo dicta algunas directrices de cómo enfrentar el proceso de

evaluación. Motivo por el cual nos vimos obligados a crear nuestra propia

Herramienta de Evaluación.

42

La “Herramienta de Evaluación” es un instrumento para estimar el nivel de

capacidad de los procesos implantados en una organización que desarrolla

software, así como también el grado de madurez de las capacidades a través de los

procesos propuestos por MoProSoft.

Esta herramienta también tiene un carácter social, pues es de fácil aplicación lo

que favorecerá a las Cooperativas y Pymes que deseen aplicar éste modelo,

recordando siempre la función social que MoProSoft tiene, debido a que es a ese

tipo de empresas a quien el modelo esta dirigido.

La empresa auditada: Unidad de Informática de Fundacite Mérida, carece para los

actuales momentos de los requerimientos mínimos para acreditarse el nivel 1 de

capacidad de proceso de MoProSoft, por presentar no conformidades en varios de

sus procesos, como por ejemplo: Gestión de Recursos, Conocimiento de la

Organización y Desarrollo y Mantenimiento de Software. Pero se reconoce que

tiene gran parte del trayecto recorrido. En cuanto a la madurez de la empresa los

resultados de la evaluación indica que hay inmadurez en procedimientos como la

documentación, por nombrar alguno, motivado a los grandes cambios

organizacionales y de metodologías que se están aplicando. También es cierto

que el trabajo en la UI es consistente y definido, así como todos los esfuerzos son

apoyados claramente por todos los involucrados, características de madurez. Sin

duda la organización está en vías de alcanzar la madurez en sus procesos.

La combinación de un modelo de gestión de calidad con un método de desarrollo

de software de manera adecuada puede traer grandes beneficios, debido a que uno

43

es el complemento del otro. El modelo sugiere el estado ideal de cómo un proceso

debe funcionar, pero no dice cómo lograr éste estado. Por otro lado un método de

desarrollo indica paso a paso cómo hacer software a través de una serie de etapas,

que normalmente se llaman fases o disciplinas, pero no las establece en términos

de una organización con sus diferentes niveles (lo que si hace el modelo

MoProSoft), como por ejemplo, alta dirección, gestión y operación. Es de vital

importancia la elección de modelos y métodos para optimizar el proceso de

desarrollo de software.

6.2 Sugerencias

Para apreciar los primeros resultados de la aplicación de un modelo, los diferentes

autores refieren que, en términos generales, para alcanzar el primer nivel deben

transcurrir en promedio de 12 a 18 meses, por lo tanto es importante destacar el

esfuerzo que se ha realizado en la Unidad de Informática de Fundacite Mérida,

para que en tan poco tiempo se hayan modificado los procesos requeridos de una

manera considerablemente positiva. Es por eso que sugerimos a Fundacite Mérida

seguir en el esfuerzo de mejorar los procesos y así en el mediano o largo plazo

optar por una certificación de características internacionales y como es su misión

podría prestar asesoría a las diferentes empresas públicas o privadas en materia de

modelos de gestión de calidad.

MoProSoft puede ser el primer paso para la creación de un certificado a nivel

local, nacional e incluso a nivel Latinoamericano debido a lo parecido del

44

universo de empresas y mercado que existe en la región – así iríamos hacia la

Integración Latinoamericana a través de la tecnología.

En base a la experiencia de hacer el presente trabajo en Fundacite-Mérida, la

vivencia de compartir con quienes trabajan normalmente en la institución y

además trabajan en función de los modelos de gestión de calidad se comprobó que

sus cargas de trabajo se duplican pues al estar pendiente de dos actividades fuertes

el trabajo se acumula o el modelo se retraza. Se sugiere crear equipos de trabajo

para las actividades específicas de los modelos.

Este trabajo puede ser el inicio de una serie de nuevos esfuerzos que continúen y

mejoren los resultados, lo que generaría gran interés y beneficio para la

comunidad que desarrolla software en la región.

45

REFERENCIAS BIBLIOGRÁFICAS

Paulk M., Weber C., Curtis B. y M. Beth, “The Capability Maturity

Model: Guidelines for improving the software process”, Addison

Wesley, 1995.

Oktaba H., Esquivel C., Ramos A., Martínez A., Quintanilla G.

Modelo de Procesos para la Industria del Software, México, 2003.

López Pérez C.,” Modelo de Madurez de la Capacidad del Software”,

Revista de Ingeniería Informática del CIIRM. InforMas N°1, España,

2005.

Process Maturity Profile of the Software Community 2002Mid-Year

Update, Software Engineering Institute, Carnegie Mellon University,

2002.

Hammersley V., “Metodología de Implantación de Mejores Prácticas en el

Proceso de Desarrollo de software para que perduren en la

organización.”, Universidad Técnica Federico Santa María, Chile, 2003.

ISO 9000:2000 Sistema de gestión de la calidad, Fondonorma, 2000.

ISO/IEC TR 15504-2:1998 (E) Information Technology, ISO/IEC, 1998.

COVENIN-ISO 19011:2002, Directrices para la Auditoría de los

sistemas de gestión de la calidad y/o ambiental, Fondonorma, 2002.

Maller P., Ochoa C., “Agilizando el Proceso de Producción de Software

en la Organización”, Generalitat Valenciana, España, 2001.

46

REFERENCIAS ELECTRÓNICAS

www.google.co.ve

www.wikipedia.com

www.sei.cmu.edu

www.rup.unicauca.edu.co

www.BiografiaBillCrosby.htm

www.funmrd.gov.ve

http://mx.groups.yahoo.com/group/moprosoft

48

ANEXOS

49

EVALUACIÓN 1

50

Evaluación de productos y prácticas requeridos para el primer nivel de

capacidad de proceso.

Proceso: Gestión de Negocios. Fecha:


2 VisiónNO

S/D

1 Misión.NO

SIN DOCUMENTACION

(S/D)

4 ObjetivosNO

S/D

3 ValoresNO

S/D

6 Procesos RequeridosNO

S/D

5 Estrategias de procesos, recursos y

proyectosNO

S/D

8 Estructura de la OrganizaciónNO

S/D

7 Cartera de ProyectosSI

10 PresupuestoSI

9 Estrategias de RecursosNO

S/D

12 Plan de comunicación con el clienteSI

11 Periodicidad de ValoraciónNO

S/D

51



Proceso: Gestión de Negocios. Fecha:

GN.A1.PT2 Plan de Adquisiciones y capacitación1 Personal Capacitado

SI

3 InfraestructuraSI

2 ProveedoresSI

Proceso: Gestión de Proceso

GPR.A1.PT1 Plan de Proceso

4 Requisitos de CapacitaciónNO

S/D

2 CalendarioSI

1 Definición de Elementos de ProcesosNO

S/D

4 Plan de EvaluaciónNO

NO EXISTE

3 Plan de adquisiciones y

CapacitacionesNO

NO EXISTE

5 Plan de Manejo de RiesgosNO

NO EXISTE

52



Proceso: Gestión de Proceso Fecha:

GPR.A2.PT1 Documentación del Proceso1 Nombre del proceso

SI

3 ObjetivosNO

S/D

2 DescripciónNO

S/D

5 Metas cuantitativasNO

S/D

4 IndicadoresNO

S/D

7 Procesos relacionados (a roles)NO

S/D

6 Responsabilidad y autoridadSI

9 SalidasNO

S/D

8 EntradasNO

S/D

11 Roles involucrados y capacitación

requeridaNO

S/D

10 Productos internosNO

S/D

13 Verificación y validaciónNO

S/D

12 ActividadesNO

S/D

14 Incorporación a la base del

conocimientoNO

no se realiza

53



Proceso: Gestión de Proceso Fecha:

16 MedicionesNO

MUY POCAS

15 Recurso de infraestructuraSI

18 Lecciones aprendidasNO

no se realiza

17 Situaciones excepcionalesNO

no se realiza

Proceso: Gestión de Proyectos

GPY.A1.PT1 Plan de Adquisición y Capacitación

19 Guías de ajusteNO

no se realiza

2 Cantidad de recursosSI

1 Perfil de recursos requeridosSI

4 Requisitos de capacitaciónNO

S/D

3 Fecha de incorporación a los

proyectosSI

6 Recursos tecnológicos requeridosSI

5 Recursos de infraestructura requeridosNO

S/D

8 Recursos materiales requeridosSI

7 Recursos financieros requeridosSI

54



Proceso: Gestión de Proyecto Fecha:

GPY.A1.PT2 Plan de Gestión de Proyectos

2 Plan de ProyectosSI

1 Plan de concertaciónNO

S/D

GPY.A1.PT3 Plan de Concertación1 Objetivos de Servicios

NOS/D

3 Recursos necesarios para prestar los

serviciosNO

S/D

2 Alcance de los ServiciosNO

S/D

5 Plan de trabajo de serviciosNO

S/D

4 Acciones de serviciosNO

S/D

GPY.A1.PT4 Plan de Proyectos1 Actividades para gestionar proyectos

internos y externos NO

S/D

GPY.A1.PT5 Alternativas de realización de proyectos internos1 Opciones

NO

2 Decisión tomadaNO

55




GPY.A2.PT1 Contrato

NOSI se hacen contratos pero

S/D

NOS/D

GPY.A2.PT2 Registro de Proyecto1 Nombre del Proyecto

SI

NO

3 Fecha de inicio y terminaciónSI

2 Responsable

GPY.A2.PT3 Descripción del Proyecto1 Propósito

SI

4 Requisitos de Capacitación

3 ObjetivosSI

2 ProductosSI

5 EntregablesNO

S/D

4 AlcanceSI

7 Supuestos y premisasNO

S/D

6 Necesidad de negocioNO

S/D

8 RestriccionesNO

S/D

56




GPY.A2.PT4 Responsable de Administración del Proyecto Específico

NO

Proceso: Gestión de RecursosGR.A1.PT1 Plan Operativo de Recursos Humanos y Ambiente de Trabajo

1 Elementos a considerar en la selección, asignación, aceptación capacitación,

evaluación y desempeño de los recursos humanos, así como el ambiente de trabajo

NO

3 Elementos a considerar en el diseño, operación y mantenimiento de la Base de

Conocimiento de la organizaciónNO

2 Elementos a considerar en la adquisición de bienes y servicios, así como en la evaluación

de proveedoresNO

GR.A1.PT2 Plan de Adquisición y Capacitación1 Personal capacitado

NO

3 InfraestructuraNO

2 ProveedoresNO


4 HerramientasNO

57

NO

Proceso: Recursos Humanos Y Ambiente de Trabajo Fecha:

Plan de Capacitación

NO

2 TalleresNO

1 Cursos

NO

4 InstructoresNO

3 Calendario

RHAT.A2.PT1 Registro de Recursos Humanos1 Datos Personales

NO

5 Logística

3 ExperienciaNO

2 FormaciónNO

5 CapacitaciónNO

4 Roles AsignadosNO

6 ExperienciaNO

RHAT.A1.PT1



58



Proceso: Bienes Servicios e Infraestructura Fecha:

BSI.A1.PT1 Plan de Mantenimiento1 Calendario

NO

3 ProveedoresNO

2 ResponsableNO

BSI.A1.PT2 Solicitud de Bienes y Servicios1 Características del bien o servicio

SI

3 Fecha de solicitudSI

2 SolicitanteSI

5 Fecha de recepciónSI

4 Fecha de entregaSI

BSI.A2.PT1 Registro de Bienes o Servicios1 Datos generales

SI

3 Evaluación de satisfacción dentro de

la organizaciónNO

2 Bienes o serviciosSI

59



Proceso: Conocimiento de la organización Fecha:

CO.A1.PT1 Plan de Administración de la Base de Conocimiento

2 Usuarios de cada proceso NO

1 Modelo conceptual NO

No existe Base de

Conocimiento

4 Mecanismos de operación NO

3 Requisitos de usuario NO

6 Mecanismos de validaciónNO

5 Mecanismos de verificación NO

CO.A2.PT1 Diseño de la base de Conocimiento1 Modelo de la base conceptual,

inclusive meta modeladoNO

3 Definición de mecanismos de consultaNO

2 Definición de mecanismos de

alimentaciónNO


mantenimientosNO

4 Definición de mecanismos de control

de accesosNO

6 Definición de mecanismos de respaldoNO

60



Proceso: Conocimiento de la organización Fecha:

CO.A2.PT2 Base de Conocimiento1 Repositorio de negocio

NO

3 Repositorio de ProyectosNO

2 Repositorio de ProcesosNO

5 Repositorio de RecursosNO

4 Repositorio de Desarrollo y

MantenimientoNO

7 Repositorio de Bienes Adquiridos y

ProveedoresNO

6 Repositorio de Recursos HumanosNO

Proceso: Administración de Proyectos Específicos

APE.A1.PT1 Plan de Desarrollo

8 Repositorio de Documentación de la

Base de ConocimientoNO

2 Equipo de trabajo

1 Descripción del producto y

entregables

3 Calendario

61



Proceso: Administración de Proyectos Específicos Fecha:

APE.A1.PT2 Plan de Proyecto1 Ciclos y actividades

SI

3 Plan de Adquisiciones y CapacitaciónNO

2 Tiempo estimadoSI

5 Costo estimadoSI

4 Equipo de trabajoNO

7 Plan de manejo de riesgosNO

6 CalendarioSI

APE.A4.PT2 Documento de aceptación

NO

8 Protocolo de entregaNO

62

Evaluación de productos y prácticas requeridos para el primer nivel

de capacidad de proceso.

Proceso: Desarrollo y Mantenimiento de Software Fecha:

DMS.A2.PT1 Especificación de Requisitos

2 FuncionalesNO

1 IntroducciónNO

4 Interfaz con otro software y

hardwareNO

3 Interfaz con usuarioNO

6 EficienciaNO

5 confiabilidadNO


7 MantenimientoNO

10 ReusabilidadNO

9 InteroperatividadNO

12 Legales y reglamentariosNO

11 Restricción de diseños y

construcciónNO

DMS.A3.PT1 Análisis y Diseño1 Descripción Arquitectónica

NO

2 Descripción Detallada NO

63



Proceso: Desarrollo y Mantenimiento de Software Fecha:

Componente

NO

SI

DMS.A5.PT1 Manual de Usuario

SI

DMS.A5.PT2 Manual de Operaciones

DMS.A4.PT1 Software

NO

DMS.A4.PT1

64

EVALUACIÓN 2

65

GN.A1.PT11 Misión.

SI

SI



4 ObjetivosSI

3 ValoresNO

6 Procesos RequeridosNO


proyectosNO

8 Estructura de la OrganizaciónNO

7 Cartera de ProyectosNO

10 PresupuestoNO

75

9 Estrategias de RecursosNO

12 Plan de comunicación con el clienteNO

11 Periodicidad de ValoraciónNO

Proceso: Gestión de Negocios.

Plan Estratégico

Visión2

Fecha: 25-04-06

66




SI

Proceso: Gestión de Negocios.

2

InfraestructuraSI

3

4

Fecha:25-04-06

Requisitos de CapacitaciónNO

ProveedoresSI



SI

2

SI1 Definición de Elementos de Procesos

NO

CalendarioSI

4 Plan de EvaluaciónNO

3 Plan de adquisiciones y Capacitaciones

5 Plan de Manejo de Riesgos

67



SI1 Nombre del proceso

GPR.A2.PT1 Documentación del Proceso

Proceso: Gestión de Proceso Fecha

9 SalidasSI

2 DescripciónSI

3 ObjetivosNO

existen como actividades no

como objetivos4 Indicadores

NO



Referente a modulos, instalaciones,

descargas, nºde usuarios?

8 EntradasSI

7 Procesos relacionados (a roles)SI

10 Productos internosNO

Definisos pero no

documentados

75

12 ActividadesSI


requeridaSI

14 Incorporación a la base del conocimientoNO

13 Verificación y validaciónSI

68

Por proyecto



Proceso: Gestión de Proceso Fecha



16 MedicionesNO







Por proyecto


Se debe hacer un plan

3 Fecha de incorporación a los proyectosSI

Por proyecto

6 Recursos tecnológicos requeridosNO

5 Recursos de infraestructura requeridosSI


Por proyecto


Por proyecto

69

2 Decisión tomadaNO

GPY.A1.PT5 Alternativas de realización de proyectos internos1 Opciones

NO


internos y externosSI

Existen pero no hay plan

5 Plan de trabajo de serviciosNO

4 Acciones de serviciosNO


serviciosNO

2 Alcance de los ServiciosNO

que Moprosoft no desarrolla


NONota: por ser un ente pertenecienete al

estado la concertación es un punto



Proceso: Gestión de Proyecto Fecha



se hacen proyectos por cada

desarrollo

1 Plan de concertaciónNO

Debe hacerse el plan

70

2 ProductosSI

SI


SI


Se definen perfiles pero luego si no se consige

personal no se prevee tiempo para capacitarlo


2 ResponsableSI

GPY.A2.PT1 Contrato


SI




4 AlcanceSI

3 Objetivos


5 EntregablesSI

Se deben mejorar como parte del

documento del negocio

8 RestriccionesSI

7 Supuestos y premisasSI

71


4 HerramientasNO

3 InfraestructuraNO

2 ProveedoresNO


NOExiste en general para la institución

no para la unidad

3 Elementos a considerar en el diseño, operación y mantenimiento de la Base de Conocimiento de la

organizaciónNO

2 Elementos a considerar en la adquisición de bienes y servicios, así como en la evaluación de

proveedoresNO

Proceso: Gestión de RecursosGR.A1.PT1 Plan Operativo de Recursos Humanos y Ambiente de TrabajoElementos a considerar en la selección, asignación, aceptación capacitación, evaluación y desempeño de los recursos humanos, así como el ambiente de

trabajo

1

NO





72

6 ExperienciaSI

5 CapacitaciónSI

4 Roles AsignadosSI

3 ExperienciaSI

1 Datos PersonalesSI

FormaciónSI

RHAT.A2.PT1 Registro de Recursos Humanos

5 LogísticaNO

2

4 InstructoresNO

3 CalendarioNO

2 TalleresNO

1 CursosNO



Proceso: Recursos Humanos Y Ambiente de Tra Fecha

RHAT.A1.PT1 Plan de Capacitación

73

3 Evaluación de satisfacción dentro de la

organizaciónNO

Se hacen solo con servicios


Solo bienes


SI




2 SolicitanteSI


SI

3 ProveedoresNO

2 ResponsableNO

1 CalendarioNO

Proceso: Bienes Servicios e Infraestructura Fecha

BSI.A1.PT1 Plan de Mantenimiento



74



mantenimientosNO

4 Definición de mecanismos de control de

accesosNO


2 Definición de mecanismos de alimentaciónNO

CO.A2.PT1 Diseño de la base de Conocimiento1 Modelo de la base conceptual, inclusive

meta modeladoNO

no existe la base de conocimiento


5 Mecanismos de verificaciónNO

4 Mecanismos de operaciónNO

3 Requisitos de usuarioNO

2 Usuarios de cada procesoNO

1 Modelo conceptualNO

no existe base de conocimiento



Proceso: Conocimiento de la organización Fecha


75


3 CalendarioSI

2 Equipo de trabajoSI

APE.A1.PT1 Plan de Desarrollo1 Descripción del producto y entregables

SI

8 Repositorio de Documentación de la Base

de ConocimientoNO


ProveedoresNO




MantenimientoNO



1 Repositorio de negocioNO

no existe la base de conocimiento

CO.A2.PT2 Base de Conocimiento



Proceso: Conocimiento de la organización Fecha

76


NO S/D



S/D

6 CalendarioSI

5 Costo estimadoSI



Solo adquisiciones y no capacitación

2 Tiempo estimadoSI

1 Ciclos y actividadesSI

APE.A1.PT2 Plan de Proyecto

Proceso: Administración de Proyectos Específicos Fecha:



77

Plan de pruebas


7 MantenimientoNO

6 EficienciaNO

5 confiabilidadNO

Plan de pruebas

4 Interfaz con otro software y hardwareSI

3 Interfaz con usuarioSI

2 FuncionalesSI

1 IntroducciónSI



Proceso: Desarrollo y Mantenimiento de Software fecha



10 ReusabilidadSI

12 Legales y reglamentariosSI

11 Restricción de diseños y construcciónNO

no se documenta

DMS.A3.PT1 Análisis y Diseño1 Descripción Arquitectónica NO S/D


78



Proceso: Desarrollo y Mantenimiento de Software fecha

DMS.A4.PT1 Componente

NO

S/D

DMS.A4.PT1 Software

SI


SI


SI

79

EVALUACIÓN 3

80





2 VisiónSI

1 Misión.SI

4 ObjetivosSI

3 ValoresSI

6 Procesos RequeridosSI


proyectosSI

8 Estructura de la OrganizaciónSI

7 Cartera de ProyectosSI

10 PresupuestoSI

9 Estrategias de RecursosSI

12 Plan de comunicación con el clienteSI

11 Periodicidad de ValoraciónSI

81





SI

3 InfraestructuraSI

2 ProveedoresSI




2 CalendarioSI

1 Definición de Elementos de ProcesosSI

4 Plan de EvaluaciónSI

3 Plan de adquisiciones y

CapacitacionesSI

5 Plan de Manejo de RiesgosSI

82



Proceso: Gestión de Proceso Fecha: 20-06-06

GPR.A2.PT1 Documentación del Proceso1 Nombre del proceso

SI

3 ObjetivosSI

2 DescripciónSI


4 IndicadoresNO

7 Procesos relacionados (a roles)SI


9 SalidasSI

8 EntradasSI


requeridaSI

10 Productos internosSI

13 Verificación y validaciónSI

12 ActividadesSI

14 Incorporación a la base del

conocimientoNO

83



Proceso: Gestión de Proceso Fecha: 20-06-06

16 MedicionesNO










3 Fecha de incorporación a los

proyectosSI

6 Recursos tecnológicos requeridosSI

5 Recursos de infraestructura requeridosSI



84



Proceso: Gestión de Proyecto Fecha: 20-06-06



1 Plan de concertaciónSI


SI


serviciosSI

2 Alcance de los ServiciosSI

5 Plan de trabajo de serviciosSI

4 Acciones de serviciosSI


internos y externosSI

GPY.A1.PT5 Alternativas de realización de proyectos internos1 Opciones SI

2 Decisión tomadaSI

85




GPY.A2.PT1 Contrato

SI

SI


SI

NO


2 Responsable


SI

4 Requisitos de Capacitación

3 ObjetivosSI

2 ProductosSI

5 EntregablesSI

4 AlcanceSI

7 Supuestos y premisasSI


8 RestriccionesSI

86





SI

Proceso: Gestión de RecursosGR.A1.PT1 Plan Operativo de Recursos Humanos y Ambiente de Trabajo

1 Elementos a considerar en la selección, asignación, aceptación capacitación,

evaluación y desempeño de los recursos humanos, así como el ambiente de trabajo

NO

3 Elementos a considerar en el diseño, operación y mantenimiento de la Base de

Conocimiento de la organizaciónNO

2 Elementos a considerar en la adquisición de bienes y servicios, así como en la evaluación

de proveedoresNO


SI

3 InfraestructuraSI

2 ProveedoresNO


4 HerramientasNO

87

NO



Proceso: Recursos Humanos Y Ambiente de Trabajo Fecha: 20-06-06

RHAT.A1.PT1 Plan de Capacitación

NO

2 TalleresNO

1 Cursos

NO

4 InstructoresNO

3 Calendario

RHAT.A2.PT1 Registro de Recursos Humanos1 Datos Personales

SI

5 Logística

3 ExperienciaSI

2 FormaciónSI

5 CapacitaciónSI

4 Roles AsignadosSI

6 ExperienciaSI

88



Proceso: Bienes Servicios e Infraestructura Fecha: 20-06-06

BSI.A1.PT1 Plan de Mantenimiento1 Calendario

NO

3 ProveedoresNO

2 ResponsableSI


SI


2 SolicitanteSI




SI

3 Evaluación de satisfacción dentro de

la organizaciónNO


89



Proceso: Conocimiento de la organización Fecha: 20-06-06


2 Usuarios de cada procesoNO

1 Modelo conceptualNO

4 Mecanismos de operaciónNO

3 Requisitos de usuarioNO


5 Mecanismos de verificaciónNO

CO.A2.PT1 Diseño de la base de Conocimiento1 Modelo de la base conceptual,

inclusive meta modeladoNO



alimentaciónNO


mantenimientosNO

4 Definición de mecanismos de control

de accesosNO


90



Proceso: Conocimiento de la organización Fecha: 20-06-06

CO.A2.PT2 Base de Conocimiento1 Repositorio de negocio

NO





MantenimientoNO


ProveedoresNO



APE.A1.PT1 Plan de Desarrollo

8 Repositorio de Documentación de la

Base de ConocimientoNO


1 Descripción del producto y

entregablesSI

3 CalendarioSI

91



Proceso: Administración de Proyectos Específicos Fecha: 20-06-06

APE.A1.PT2 Plan de Proyecto1 Ciclos y actividades

SI


Solo adquisiciones y no

capacitación

2 Tiempo estimadoSI

5 Costo estimadoSI



6 CalendarioSI


SI


92



Proceso: Desarrollo y Mantenimiento de Software Fecha: 20-06-06


2 FuncionalesSI

1 IntroducciónSI

4 Interfaz con otro software y hardwareSI

3 Interfaz con usuarioNO

6 EficienciaSI

5 confiabilidadSI

8 Protocolo de entregaSI

7 MantenimientoNO

10 ReusabilidadSI


12 Legales y reglamentariosSI

11 Restricción de diseños y construcciónNO

DMS.A3.PT1 Análisis y Diseño1 Descripción Arquitectónica

NO


93



Proceso: Desarrollo y Mantenimiento de Software Fecha: 20-06-06

DMS.A4.PT1 Componente

SI

DMS.A4.PT1 Software

SI


SI


SI

94

EJEMPLO DE DOCUMENTACIÓN USADA PARA LA EVALUACIÓN

Documento desarrollado por la Coordinación de Informática en Diciembre de

2005, para uso interno del personal de la Unidad de Informática.

95

Fundación para el Desarrollo de la Ciencia y la

Tecnología del Estado Mérida

FUNDACITE – MÉRIDA

Coordinación Informática

96

Diciembre, 2005

ROLES Y PERFILES

Todo el personal de Informática debe ser idealmente de comprobada confianza y alta dedicación y orientación al logro y cumplimiento de metas.

Cargo: Sistemas Internos Perfil: Ing. De Sistemas o carrera afín con experiencia en manejo de proyectos de Software Libre, experiencia en programación. Dominio de grupo, facilidad de expresión, apto para trabajo bajo presión, capacidad de respuesta. Responsabilidades:

- Definición de nuevos proyectos - Presentación y Gestión de proyectos Internos - Coordina actividades de proyectos Internos - Coordina manejo y asignación de recursos Internos - Seguimiento del plan de trabajo por proyecto Interno - Planificación de actividades por proyecto Interno - Canaliza solicitudes de entrenamiento del personal a su cargo - Supervisa y avala logros de cada proyecto Interno - Supervisa recursos humanos, equipos y financieros

relacionados con los proyectos Internos - Apoya en la generación del plan estratégico y operativo - Genera solicitudes de personal según proyectos. - Apoyo a seguimiento de proyectos de software. - Cierre de proyectos - Concertación con actores externos para trabajo en conjunto. - Asiste a reuniones y presentaciones. - Hace seguimiento de convenios relacionados con Informática.

Cargo: Coordinador Sistemas Internos

Perfil: Ing. De Sistemas o carrera afín con experiencia en manejo de proyectos de Software Libre, experiencia en programación. Dominio de grupo, facilidad de expresión, apto para trabajo bajo presión, capacidad de respuesta. Responsabilidades:

- Definición de nuevos proyectos - Presentación y Gestión de proyectos - Coordina actividades de proyectos - Coordina manejo y asignación de recursos - Seguimiento del plan de trabajo por proyecto

97

- Planificación de actividades por proyecto - Canaliza solicitudes de entrenamiento - Supervisa y avala logros de cada proyecto - Supervisa recursos humanos, equipos y financieros

relacionados con los proyectos. - Apoya en la generación del plan estratégico y operativo - Genera solicitudes de personal según proyectos. - Apoyo a seguimiento de proyectos de software. - Cierre de proyectos - Concertación con actores externos para trabajo en conjunto. - Asiste a reuniones y presentaciones. - Hace seguimiento de convenios relacionados con Informática.

Cargo: Responsable Administración de Servidores

Perfil: Ing. De Sistemas, Telecomunicaciones, Electrónica o carrera afín con experiencia en manejo de proyectos, administración de servidores, redes, telecomunicaciones. Dominio de grupo, facilidad de expresión, apto para trabajo bajo presión, capacidad de respuesta. Responsabilidades:

- Mantenimiento e instalación de servidores - Mantenimiento y supervisión de enrutamiento de la red. - Instalacion y mantenimiento de la seguridad de la red - Supervisión y seguimiento de proyectos relacionados con

video-conferencias, politicas de seguridad, direccionamiento IP, etc.

- Definición de necesidades de hardware relacionado con servidores.

Cargo: Responsable de Instalaciones Inalámbricas.

Perfil: Ing. De Sistemas, Telecomunicaciones, Electrónica o carrera afín con experiencia en manejo de proyectos, administración de servidores, redes, telecomunicaciones. Dominio de grupo, facilidad de expresión, apto para trabajo bajo presión, capacidad de respuesta. Responsabilidades:

- Instalación y Mantenimiento de conexiones ultima milla. - Supervisión de rendimiento de la red inalámbrica - Supervisión y seguimiento de proyectos relacionados con

interconexiones. - Supervisión de rendimiento de conexiones a clientes de la red. - Definición de necesidades de hardware relacionado con las

98

telecomunicaciones

Cargo: Apoyo a proyectos. Perfil: TSU o Lic. en administración, contabilidad o carrera afín con amplia experiencia en control de procesos administrativos, proactivo, facilidad de redacción y relación con el publico. Responsabilidades:

- Manejo de correspondencia interna y externa - Apoyo a la coordinación del seguimiento de actividades - Apoyo al manejo de solicitudes de viáticos, pasajes, compra

y contratación de bienes y servicios. - Apoyo en el manejo de presupuesto y recursos asignados a

los diferentes proyectos de la unidad. - Atención al publico (Instituciones y comunidad) - Canaliza reclamos, sugerencias y fallas de los servicios que

presta la unidad.

Cargo: Líder de Proyecto Perfil: : Ing. de Sistemas o carrera afín con experiencia en redes LAN, administración de servidores, seguridad informática o programación con software libre (según el proyecto). Experiencia en manejo de grupos de trabajo, control de cronograma de actividades. Responsabilidades:

- Supervisa Actividades del grupo de programadores según cronograma del proyecto.

- Programa y maneja a la totalidad el desarrollo y de bases de datos.

- Introduce nuevas versiones al servidor. - Genera necesidades de entrenamiento del grupo - Presenta avances y situación del proyecto en distintos

escenarios - Lideriza el proceso de levantamiento de información, análisis

y diseño del sistema. - Lideriza el proceso de pruebas del sistema. - Cierre de sistemas y proyectos conjuntamente con el

Coordinador de Informática. - Garantiza documentación del código (comentarios). - Garantiza documentación del sistema (Manuales)

99

Cargo: Programador I Salario Actual: 1.000.000. Perfil: TSU en Informática, Ing. de Sistemas o carrera afín con experiencia en administración de servidores, seguridad informática o programación con software libre (según el proyecto). Responsabilidades:

- Construcción de programas y módulos asignados - Sólo usa base de datos, modifica solo bajo autorización del

lider del proyecto. - Responde por sus actividades al Líder del Proyecto en el

que esté involucrado - Asume el rol de líder del proyecto en ausencia del mismo. - Apoya en diseño del sistema y bases de datos. - Dirige entrenamientos.

Cargo: Programador II Salario Actual: 800.000. Perfil: TSU en Informática, Ing. de Sistemas o carrera afín con experiencia en administración de servidores, seguridad informática o programación con software libre (según el proyecto). Responsabilidades:

- Construcción de programas y módulos asignados - Sólo usa base de datos, no los modifica ni las crea - Responde por sus actividades al Líder del Proyecto en el

que esté involucrado - Dirige entrenamientos.

100

Propuesta Informática

1. Alta Dirección: a. Presidencia b. Gerencia de Planificación c. Coordinación de Software Externo.

2. Gestión de Recursos a. Gerencia de Gestión Interna b. Presupuesto c. Finanzas d. Asesoria Legal e. Coordinación de Informática.

3. Gestión de Proyectos a. Alta Dirección b. Coordinación de Informática c. Analista de Proyecto

4. Gestión de Procesos: El propósito es establecer los procesos de la organización, en función de los procesos requeridos identificados en el plan estratégico. Así como definir, planificar, e implantar las actividades de mejoras de los mismos.

a. Coordinación Informática b. Responsable de Administración de Servidores. c. Responsable de Telecomunicaciones

5. Administración de Desarrollo a. Coordinación de Informática b. Lideres de Proyectos

101

ESQUEMA ORGANIZATIVO PROPUESTO

P-L : Programadores y Lideres de Proyecto. E T : Especialista en Telecomunicaciones y Adm. Serv

Software Interno

Administracion de Servidores

P - L

Asistente Analista de Proyecto Apoyo UGCyT

P - L P - L P - L E T E T E T E T

Gerencia Planificacion

Presidencia

Telecomunicaciones Software Externo

102

ESQUEMA ORGANIZATIVO UNIDAD DE PRODUCCION

SOFTWARE EXTERNO (FABRICA DE SOFTWARE LIBRE)

P - L

Asistente Analista de Proyecto Apoyo UGCyT

P - L P - L P - L E T

Gerencia Planificacion

Presidencia

Software Externo

Administracion Alta Direccion

Gestion

Operativo

103

APOYO DE UNIDADES EXTERNAS A INFORMATICA

PRESIDENCIA: - Evalúa y supervisa todas las actividades de la Unidad de

Informática. - Planifica proyectos y actividades a corto, mediano y largo plazo

junto a la Gerencia de Planificación y la Coordinación de Informática.

- Autoriza y avala convenios interinstitucionales. - Representa a la Fundación en espacios nacionales e

internacionales SECRETARIA PRESIDENCIA

- Apoya en la firma de convenios - Apoya en la concertación de reuniones con Presidencia.

ASISTENTE A PRESIDENCIA:

- Apoya a Presidencia en el control y seguimiento de actividades. - Controla la ejecución de actividades del punto de cuenta. - Apoya como enlace entre Fundacite e Instituciones con las

cuales se generan convenios interinstitucionales - Controla el uso de vehículos.

GERENCIA DE GESTIÓN INTERNA:

- Seguimiento de contratos de personal - Supervisión de concursos de selección de personal - Supervisión la ejecución presupuestaria

DIRECCION EJECUTIVA:

- Avala y apoya en elaboración de planes de acción. - Avala y apoya en elaboración de POA y PEI - Apoyo en concertaciones con actores externos. - Apoyo en planificación prospectiva de la unidad.

PROMOCION Y DIVULGACION:

- Apoya en la divulgación de la información relacionada con proyectos de la Unidad de Informática.

- Responsable de la información que se publica en la Pag. Web de la Fundación.

- Planifica junto a la Unidad e Informática la actualización permanente de la Pág. Web de la Fundación.

- Apoya en la elaboración e instalación de stand y material audiovisual.

ASESORIA LEGAL:

- Realización de convenio y contratos - Asesoría legal a los proyectos.

ANALISTA DE PROYECTOS:

- Define y presenta requerimientos de proyectos según necesidades diagnosticadas

104

- Apoyo en definición de entrenamientos de software u otro según proyecto (planificación)

- Convocatoria de actores internos y externos - Organización de reuniones para fortalecer proyectos - Seguimiento a proyectos

COORDINACION DE PRESUPUESTO:

- Maneja disponibilidad presupuestaria de proyectos - Realiza formulación presupuestaria de los proyectos y de la

Unidad de Informática. COORDINACIÓN DE CONTABILIDAD Y FINANZAS:

- Manejo de recursos financieros - Pagos y cobros asociados a proyectos

SERVICIOS GENERALES:

- Manejo de proceso de compras - Solicitud de presupuesto - Recepción de bienes y equipos - Control de bienes - Manejo de inventario automatizado - Apoyo en eventos y actividades con actores externos

APOYO SECRETARIAL:

- Apoya en la solicitud de boletos aéreos. - Apoya en la entrega de material para la junta directiva - Apoya en el envío de material e información a instituciones

externas.

105

PROCEDIMIENTOS DE LA UNIDAD DE INFORMATICA DESARROLLO DE SOFTWARE: PROCESO: Desarrollo de Software SUB-PROCESO: Levantamiento de Información

ENTRADA (Insumos) ACTIVIDAD SALIDA

(Productos) • Requerimiento Inicial de

Software • Información

relacionada con procesos a automatizar

• Expectativas de los usuarios del sistema

• Definir responsable del proyecto. • Definir equipo de trabajo • Definir cronograma de actividades contentivo de:

• Fechas de entrega de cada modulo (Avances) • Fechas de prueba • Fechas de reuniones de seguimiento. • Posibles fechas de entrenamiento de uso

• Definición de recursos necesarios.

• Documento de gestión del desarrollo del sistema.

PROCESO: Desarrollo de Software SUB-PROCESO: Análisis del Sistema


(Productos) • Documento de gestión del

desarrollo del sistema. • Definir plataforma de desarrollo. • Diseño de base de datos (Si existe) • Diseño modular del sistema (Usando UML) • Diseño de casos de prueba

• Documentación del Sistema

PROCESO: Desarrollo de Software SUB-PROCESO: Desarrollo


(Productos)

106

• Documentación del Sistema

• Establecer cronograma de desarrollo con el equipo de desarrollo.

• Programación modular. • Desarrollar manuales de uso

• Módulos para prueba

PROCESO: Desarrollo de Software SUB-PROCESO: Pruebas


(Productos) • Módulos para prueba • Pruebas internas

• Corrección de fallas. (Se inicia ciclo si hace falta.)

• Módulos en producción.

PROCESO: Desarrollo de Software SUB-PROCESO: IMPLANTACION


(Productos) • •

107

EJEMPLO DE PLANTILLA PARA DEFINICIÓN DE REQUISITOS.

Realizada para FUNDACITE-MÉRIDA Unidad de Informática

Por: Ing. Johanna Álvarez.

108

<Nombre del Proyecto> Definición de Requisitos

Versión<#>

Proceso: Subproceso: Tipo de documento:

Responsable: Fecha de elaboración:

Tipo de revisión

Aprobado por:

Fecha de aprobación:

Desarrollo de Aplicaciones de Software

Levantamiento y Análisis de Requisitos

Definición de Requisitos

109

Definición de Requisitos

1. Problemas de Información del Dominio de la Aplicación: [Se listan los problemas de información que pueda tener el dominio de la

aplicación a desarrollar en la tabla siguiente:]

Problemas de información del dominio de la aplicación Problema # 1: [Se coloca el problema de información definido por el cliente] . . . Problema # n:

2. Requisitos Funcionales:

[Se colocan en la tabla todos los módulos a desarrollar, para cada un de ellos se

definen requisitos funcionales]

Módulos Requisitos Funcionales por Modulo Requisito # 1: [Se coloca el requisito funcional para el modulo en particular] . . .

<Nombre del Modulo>

Requisito # n: [Se coloca el requisito funcional para el componente en particular] Requisito # 1: [Se coloca el requisito funcional para el modulo en particular] . . .

<Nombre del Modulo>

Requisito # n: [Se coloca el requisito funcional para el modulo en particular] Requisito # 1: [Se coloca el requisito funcional para el modulo en particular]

<Nombre del Modulo>

.

110

.

.

Requisito # n: [Se coloca el requisito funcional para el modulo en particular]

3. Requisitos No-Funcionales:

[Se listan todos los requisitos no funcionales que debe cubrir la aplicación a

desarrollar en la tabla siguiente:]

Requisitos no

Funcionales

Variables Valor Cuantitativa

Valor Cualitativo

Tolerancia a fallas

*

Madurez (frecuencia de fallas por errores de software)

*

Confiabilidad

Recuperabilidad

*

Tiempo de respuesta *

Cantidad de recursos

Eficiencia

Duración del uso

Estabilidad

*

Analizabilidad *

Mantenibilidad

Cambiabilidad *

Adaptabilidad

*

Adecuación

Portabilidad

Reemplazabilidad

*

Entendibilidad

* Usabilidad

Aprendibilidad *

111

Operabilidad

*

Agrado a su uso *

Otro Tipo de Requisitos Funcionales Fondo de pantallas

Tipos de fuentes

Color de la fuente

Interfaz con usuario

POR FAVOR COLOCAR LAS QUE FALTEN

Restricciones de diseño y construcción

Restricciones de diseño y de construcción

Legales y reglamentarias

Interfaces externas

4. Otro Tipo de Requisitos

Requisitos

[Se coloca el requisito sugerido por el cliente]




EVALUACIÓN DE MOPROSOFT COMO ALTERNATIVA...

Documents

Transcript of EVALUACIÓN DE MOPROSOFT COMO ALTERNATIVA...