MPS.BR - Mejora de Proceso del Software Brasileño …a_de... · con la versión 2008 de la norma ISO/IEC 12207 y actualizó el contenido referente a las normas de calidad de producto

MPS.BR - Mejora de Proceso del Software Brasileño

Guía de Adquisición

Esta guía describe un proceso de adquisición de software y servicios asociados, basado en la Norma Internacional ISO/IEC 12207: 2008.

Octubre de 2011

Copyright © 2011 - SOFTEX Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN 978-85-99334-63-8

MPS.BR – Guía de Adquisición:2011 2/95

Índice

1 Prefacio ......................................................................................................4

2 Introducción ..............................................................................................6

3 Objetivo .....................................................................................................7

4 Descripción del proceso de adquisición ................................................8

4.1 Visión general ...................................................................................................8

4.2 Preparación de la adquisición ...........................................................................9

4.3 Selección del proveedor .................................................................................. 15

4.4 Supervisión del contrato .................................................................................. 19

4.5 Aceptación por el cliente ................................................................................. 25

Anexo A – Plan de adquisición............................................................................... 31

Anexo B – Solicitud de propuestas ........................................................................ 39

Anexo C – Propuesta de los proveedores ............................................................. 41

Anexo D – Contrato ................................................................................................. 43

Anexo E – Registro de revisiones .......................................................................... 47

Anexo F – Aspectos relevantes en la adquisición de S&SC ................................ 49

F.1 Visión general ...................................................................................................... 49

F.2 Problemas comunes en la adquisición ................................................................ 49

F.3 Adquisición de software libre/código abierto (SL/CA) .......................................... 53

F.4 Adquisición y la Ingeniería de Software basada en componentes....................... 54

Anexo G – Funciones en el proyecto de adquisición ........................................... 58

G.1 Visión general ..................................................................................................... 58

G.2 Funciones del promotor ...................................................................................... 59

G.3 Funciones de gestión .......................................................................................... 59

G.4 Funciones de asistencia o soporte ...................................................................... 60

G.5 Funciones ejecutivas .......................................................................................... 62

Anexo H – Normas ISO/IEC para evaluación de producto de software .............. 64

H.1 Descripción general ............................................................................................ 64

H.2 Evaluación utilizando la ISO/IEC 25051 .............................................................. 64

H.3 Evaluación con las series ISO/IEC 9126 y 14598 ............................................... 65

H.4 La serie de normas SQuaRE .............................................................................. 68

Anexo I – Procesos de adquisición de la ISO/IEC 12207 e IEEE STD 1062:1998 ................................................................................................. 72

I.1 Proceso de la ISO/IEC 12207 ............................................................................... 72

I.2 Proceso de la IEEE STD 1062:1998 ..................................................................... 74


Anexo J – Habilitación de consultores de adquisición MPS ............................... 78

J.1 Habilitación de consultores de adquisición .......................................................... 78

Anexo K – Iniciativas de utilización de procesos de adquisición en el área pública ..................................................................................................... 79

K.1 Personalización de proceso de adquisición ........................................................ 79

K.2 Personalización de proceso de adquisición para organizaciones públicas ......... 80

Referencias bibliográficas ...................................................................................... 86

Lista de colaboradores de la Guía de Adquisición:2011 ...................................... 91

Lista de colaboradores de la Guía de Adquisición:2009 ...................................... 92

Lista de colaboradores de la Guía de Adquisición versión 1.2 ........................... 93




1 Prefacio

El MPS.BR1 es un programa movilizador, de largo plazo, creado en diciembre de 2003, es coordinado por la Asociación para Promoción de la Excelencia del Software Brasileño (SOFTEX), y cuenta con el apoyo del Ministerio de Ciencia y Tecnología (MCT), de la Financiera de Estudios y Proyectos (FINEP), del Servicio Brasileño de Apoyo a las Micro y Pequeñas Empresas (SEBRAE) y del Banco Interamericano de Desarrollo (BID).

El objetivo del programa MPS.BR (acrónimo) es la Mejora de Proceso del Software Brasileño, para lograr dos metas a mediano y largo plazos:

a) meta técnica, teniendo como objetivo la creación y perfeccionamiento del modelo MPS, con resultados esperados tales como: (i) guías del modelo MPS; (ii) Instituciones Implementadoras (II) acreditadas para prestar servicios de consultoría de implementación del modelo de referencia MR-MPS; (iii) Instituciones Evaluadoras (IA) acreditadas para prestar servicios de evaluación siguiendo el método de evaluación MA-MPS; (iv) Consultores de Adquisición (CA) habilitados e Instituciones de Consultoría de Adquisición (ICA) acreditadas para prestar servicios de consultoría de adquisición de software y servicios asociados;

b) meta de mercado, teniendo como objetivo la diseminación y adopción del modelo MPS, en todas las regiones del país, en un intervalo de tiempo justo, a un costo razonable, tanto en PYME (foco principal) así como en grandes organizaciones públicas y privadas, con resultados esperados tales como: (i) creación y perfeccionamiento del modelo de negocio MN-MPS; (ii) cursos, pruebas y workshops; (iii) organizaciones que implementaron el modelo MPS; (iv) organizaciones con evaluación MPS publicada (vigencia de tres años).

El programa MPS.BR cuenta con dos estructuras de apoyo al desarrollo de sus actividades, el Foro de Acreditación y Control (FCC) y el Equipo Técnico del Modelo (ETM). Por medio de estas estructuras, el MPS.BR obtiene la participación de representantes de universidades, instituciones gubernamentales, centros de investigación y de organizaciones privadas, las cuales contribuyen con sus visiones complementarias que agregan calidad al emprendimiento.

Cabe al FCC: (i) emitir parecer para auxiliar las decisiones de la SOFTEX sobre la acreditación de Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA); (ii) supervisar los resultados de las Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA), emitiendo parecer proponiendo a la SOFTEX su desacreditación en caso de comprometimiento de la credibilidad del modelo MPS.

Cabe al ETM apoyar a la SOFTEX sobre los aspectos técnicos relacionados al Modelo de Referencia (MR-MPS) y Método de Evaluación (MA-MPS), para: (i) creación y perfeccionamiento continuo del MR-MPS, MA-MPS y sus guías específicas; (ii) capacitación de personas por medio de cursos, pruebas y workshops.

1 MPS.BR, MR-MPS, MA-MPS y MN-MPS son marcas de la SOFTEX. La sigla MPS.BR está asociada

al programa MPS.BR – Mejora del Proceso de Software Brasileño y la sigla MPS está asociada al modelo MPS – Mejora del Proceso de Software.


La creación y el perfeccionamiento de esta Guía de Adquisición son también atribuciones del ETM, siendo que esta guía forma parte del siguiente conjunto de documentos del modelo MPS:

• Guía General:2011 [SOFTEX, 2011a];

• Guía de Evaluación:2011 [SOFTEX, 2011b];

• Guía de Adquisición:2011;

• Guía de Implementación – Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS:2011 [SOFTEX, 2011c];

• Guía de Implementación – Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS:2011 [SOFTEX, 2011d];

• Guía de Implementación – Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS:2011 [SOFTEX, 2011e];

• Guía de Implementación – Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS:2011 [SOFTEX, 2011f];

• Guía de Implementación – Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS:2011 [SOFTEX, 2011g];

• Guía de Implementación – Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS:2011 [SOFTEX, 2011h]; y

• Guía de Implementación – Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS:2011 [SOFTEX, 2011i];

• Guía de Implementación – Parte 8: Implementación del MR-MPS:2011 (Niveles G a A) en organizaciones que adquieren software [SOFTEX, 2011j];

• Guía de Implementación – Parte 9: Implementación del MR-MPS:2011 (Niveles G a A) en organizaciones del tipo Fábrica de Software [SOFTEX, 2011k];

• Guía de Implementación – Parte 10: Implementación del MR-MPS:2011 (Niveles G a A) en organizaciones del tipo Fábrica de Teste [SOFTEX, 2011l]; y

• Guía de Implementación – Parte 11: Implementación y Evaluación del MR-MPS (Niveles G a A) en conjunto con el CMMI-DEV [SOFTEX, 2011m].

Esta Guía de Adquisición tiene como referencia el Proceso de Adquisición de la Norma Internacional ISO/IEC 12207: 2008. La norma IEEE STD 1062:1998 se puede utilizar para complementar y detallar las actividades del proceso de adquisición.

La versión 2009 de esta Guía de Adquisición compatibilizó el proceso de adquisición con la versión 2008 de la norma ISO/IEC 12207 y actualizó el contenido referente a las normas de calidad de producto de software, ajustándolo a las normas ya publicadas de la serie ISO/IEC 25000 y correspondientes normas brasileñas. Además de eso, el alcance del documento quedó delimitado específicamente como una guía de orientación a organizaciones que pretenden conducir proyectos de adquisición, evidenciando que no trata de la preparación de estas organizaciones a ser evaluadas con respecto a los niveles de madurez. En este sentido, las referencias específicas a los procesos y niveles de capacidad abordadas en la Guía General fueron excluidas de la Guía de Adquisición.


La versión 2011 de esta Guía de Adquisición actualizó la situación de las normas de la serie ISO/IEC 25000, además de incluir el anexo K que aborda iniciativas de utilización de proceso de adquisición para organizaciones públicas.

2 Introducción

El MPS.BR tiene como foco, aunque no exclusivo, atender a micro, pequeñas y medianas empresas de software latinoamericanas, con pocos recursos y que deseen obtener mejoras significativas en sus procesos de software.

Se busca que el modelo MPS sea adecuado al perfil de empresas con diferentes tamaños y características, públicas y privadas, sea compatible con los estándares de calidad aceptados internacionalmente y que tenga como presupuesto el aprovechamiento de toda la competencia existente en los estándares y modelos de mejora de proceso ya disponibles.

De esa forma, el modelo MPS tiene como base los requisitos de procesos definidos en los modelos de mejora de proceso y busca atender la necesidad de implantar los principios de Ingeniería de Software de forma adecuada al contexto de las empresas latinoamericanas, estando en consonancia con los principales abordajes internacionales para definición, evaluación y mejora de procesos de software.

La introducción de la adquisición de S&SC como parte del MPS.BR tiene como finalidad orientar a las organizaciones que adquieren S&SC, por medio de un proceso de adquisición donde son descritas las actividades y tareas fundamentales para la garantía de la calidad del contrato y respectivos productos y servicios a ser entregados por el proveedor. Esta guía será también un importante elemento inductor de mejoras de procesos de organizaciones proveedoras, contribuyendo como un documento orientador a ser usado para atender a las necesidades y requisitos de los clientes, conforme definido en el plan de adquisición y respectivo contrato.

La adquisición de S&SC es un proceso complejo, principalmente en lo que respecta a la caracterización de los requisitos necesarios al S&SC y a las condiciones involucradas en la contratación como, por ejemplo, calidad esperada, forma de aceptación, gestión de cambios, artefactos2 esperados, entre otros. Este entorno presenta riesgos para las partes involucradas y, como consecuencia, es común la ocurrencia de serios conflictos en la relación entre proveedores y adquiridores de software.

Ante este escenario, fueron emprendidas varias iniciativas internacionales con vistas a tornar este proceso más previsible y con mejores resultados para los involucrados, resultando, como consecuencia, desde estándares específicos para grandes organizaciones compradoras de software, hasta normas internacionales que buscan orientar relaciones técnicas y comerciales.

La elaboración de la Guía de Adquisición llevó en cuenta los documentos resultantes de estos trabajos, además de considerar relaciones del proceso de adquisición con aspectos definidos por el MR-MPS.

2 Cualquier parte tangible de información que sea creada, alterada, y utilizada por el proyectista durante

el proceso de desarrollo de software. De acuerdo con esta definición, un artefacto de software puede ser un documento de especificación de requisitos, arquitectura, programa, partes de programa, proyecto, modelo, o cualquier otro documento asociado al software.


Como la implementación del MR-MPS está relacionada a los procesos de la norma ISO/IEC 12207, la Guía de Adquisición, también está basado en el proceso de adquisición de aquella Norma Internacional, adoptando como base los procesos de nivel inferior (descomposición del proceso de adquisición en procesos más detallados) del proceso de adquisición, conforme consta en el anexo B de la norma ISO/IEC 12207. La Guía de Adquisición proporciona informaciones complementarias a la norma ISO/IEC 12207, identificando la relación entre los procesos de esta norma y de la IEEE STD 1062:1998.

3 Objetivo

Este documento describe un proceso de adquisición de S&SC basado en la Norma Internacional ISO/IEC 12207:2008, complementado por la norma IEEE STD 1062:1998. La organización de este documento busca servir como una guía para empresas que adquieren S&SC, detallando las actividades y tareas para ello, describiendo los productos de trabajo y proporcionando ejemplos de cómo llenar los principales documentos. Obsérvese que el objetivo de esta guía no es servir como Guía de Implementación para un proceso de adquisición que sea evaluado utilizando el MA-MPS, pues este es el propósito de otras guías del modelo MPS.

En el contexto de la adquisición de S&SC se considera el producto de software propiamente dicho, además de servicios típicamente relacionados al desarrollo, implantación, soporte a la operación y mantenimiento del software, tales como entrenamiento, configuración del software y del entorno operativo, mantenimientos correctivos, evolutivos y adaptativos, entre otros.

El proceso descrito en la Guía de Adquisición se ajusta perfectamente para adquisiciones de productos comercialmente disponibles (paquete de software), de productos de software personalizados o de un dominio específico, tanto por instituciones privadas como por instituciones públicas. En el caso de instituciones públicas, se debe considerar la legislación que regula las adquisiciones, de acuerdo con las diferentes modalidades de licitación establecidas. En el caso de contrataciones de alcance abierto, que engloban servicios de desarrollo de software, es necesario que el proceso sea personalizado, principalmente para contemplar la eventual inexistencia de requisitos específicos para los productos que se desarrollarán en un proceso de contratación. De este modo, el proceso deberá trabajar con requisitos generales a ser considerados para todos los productos de software que se vengan a desarrollar a lo largo del contrato a ser firmado entre las partes. Además de eso, como el proceso presupone tareas planificadas y resultados contratados y evaluados, la modalidad de contratación de mano de obra está fuera del tema de esta guía.

El proceso de adquisición está descrito en la sección 4, donde están detalladas las actividades y sus tareas, así como los respectivos productos requeridos y productos generados. Los Anexos de A hasta E presentan sugerencias de modelos de documentos que se pueden utilizar y personalizar por las organizaciones compradoras. El Anexo F aborda algunos aspectos importantes que se deben considerar en la adquisición de S&SC, tales como problemas enfrentados, software libre/código abierto e Ingeniería de Software basada en componentes. El Anexo G indica posibles funciones involucradas en procesos de adquisición. El Anexo H presenta un conjunto de normas que se pueden utilizar en la evaluación de producto de software durante el proceso de adquisición. El Anexo I presenta una breve descripción de los procesos definidos en las normas internacionales ISO/IEC 12207 e IEEE STD 1062:1998, así


como un mapeo de sus relaciones. El Anexo J describe cómo los profesionales deben proceder para ser habilitados como Consultores de Adquisición MPS.BR, cual es la calificación profesional y académica deseada para esa certificación, además de los requisitos de entrenamiento, evaluación y elaboración de un Plan de Adquisición de Software. Finalmente, el Anexo K identifica algunas iniciativas que vienen siendo adoptadas en el Brasil personalizando un proceso de adquisición de S&SC para organizaciones públicas.

Este documento está dirigido, pero no se limita, a instituciones interesadas en adquisición de S&SC. Se destina también, como una referencia, a instituciones productoras de software que pretendan prepararse para participar de procesos de selección en conformidad con lo establecido en esta guía.

4 Descripción del proceso de adquisición

4.1 Visión general

El propósito del proceso de adquisición es obtener S&SC que satisfagan la necesidad expresada por el cliente. Este proceso se inicia con la identificación de la necesidad del cliente y se concluye con la aceptación del producto o servicio.

Como resultado de la implementación exitosa del proceso de adquisición:

1. las necesidades de adquisición, las metas, los criterios de aceptación del S&SC y las estrategias de adquisición son definidos;

2. un contrato que exprese claramente la expectativa, las responsabilidades y las obligaciones de ambos (cliente y proveedor) es elaborado;

3. uno o más proveedores son seleccionados;

4. S&SC que satisfacen la necesidad expresada por el cliente son adquiridos;

5. la adquisición es supervisada de modo que las condiciones especificadas se cumplan, tales como: costo, cronograma y calidad;

6. los productos y servicios entregados por el proveedor son aceptados; y

7. cualquier pendencia identificada tiene una conclusión satisfactoria, conforme lo acordado entre el cliente y el proveedor.

A seguir, este proceso será descrito por sus 4 (cuatro) actividades (Figura 1):

� Preparación de la adquisición (ver 4.2)

� Selección del proveedor (ver 4.3)

� Supervisión del contrato (ver 4.4)

� Aceptación por el cliente (ver 4.5)


Figura 1 – Actividades de adquisición

Cada una de las actividades está detallada por los siguientes elementos:

� Objetivo: describe los objetivos que se deben lograr con la realización de la actividad y proporciona orientaciones generales;

� Tareas previstas: identifica y describe las tareas necesarias para lograr los objetivos y obtener los resultados previstos de la actividad; y

� Productos requeridos y generados: relaciona los insumos necesarios para ejecutar cada tarea prevista en la actividad, así como los productos de las tareas previstas en la actividad. Para algunos de estos productos hay referencias de modelos descritos en los anexos de A hasta E de esta guía;

4.2 Preparación de la adquisición

4.2.1 Objetivo

El propósito de la actividad de preparación de la adquisición es establecer las necesidades y los requisitos de la adquisición y comunicarlos a los proveedores en potencial.

La ejecución de esta actividad es fundamental para establecer la estrategia de conducción de todo el proceso de adquisición, llevándose en cuenta las necesidades y requisitos establecidos, así como las demás variables de contexto de la adquisición. Las tareas previstas comprenden:

Establecer la necesidad (ver Pre-t1);

Definir los requisitos (ver Pre-t2);

Preparación de la adquisición

1. Establecer la necesidad 2. Definir los requisitos 3. Revisar los requisitos 4. Desarrollar una estrategia de adquisición 5. Definir los criterios de selección de proveedores

Selección del proveedor

1. Evaluar la capacidad de los proveedores 2. Seleccionar el proveedor 3. Preparar y negociar un contrato

Supervisión del contrato

1. Establecer y mantener comunicaciones 2. Intercambiar información sobre el progreso técnico 3. Revisar el desempeño del proveedor 4. Supervisar la adquisición 5. Obtener acuerdo a respecto de los cambios 6. Acompañar problemas

Aceptación por el cliente

1. Preparar la aceptación 2. Evaluar el S&SC entregado 3. Mantener conformidad con el contrato 4. Aceptar el S&SC


Revisar requisitos (ver Pre-t3);

Desarrollar una estrategia de adquisición (ver Pre-t4); y

Definir los criterios de selección de proveedores (ver Pre-t5).

4.2.2 Tareas previstas

Id. Tarea

Pre-t1 Establecer la necesidad

Descripción:

Establecer las necesidades que se deberán atender por medio de la adquisición, desarrollo o mejora de un sistema, producto de software o servicio de software.

Durante esta tarea, se analizan las necesidades y los resultados que la organización pretende lograr con el proyecto de adquisición, evaluándose el alcance efectivo de las necesidades que se deben contemplar en la adquisición. Esta tarea es fundamental, pues indica la primera toma de decisión con respecto a la continuación del proyecto y cuáles son los resultados esperados por la organización después de efectuar la adquisición.

Productos requeridos:

Pre-p1 - Evaluación de la necesidad del S&SC

NOTA: Eventualmente este trabajo de evaluación de la necesidad es complementado en el propio proceso de adquisición, a medida en que algunos casos son apenas esbozadas las necesidades por la organización adquiriente.

Productos generados:

Pre-p2 - Resultado del análisis de la necesidad de la adquisición

NOTA: La tarea define, en este documento, el conjunto de necesidades que se deben contemplar por el sistema, producto de software o servicio de software.

Pre-t2 Definir los requisitos

Descripción:

Identificar los requisitos del cliente para un S&SC.

En caso de que sea necesario, las organizaciones podrán solicitar informaciones de proveedores o realizar averiguaciones e identificar las mejores prácticas de otras organizaciones, que adquirieron productos y servicios semejantes, con vistas a determinar los requisitos a partir de soluciones disponibles en el mercado.

Durante esta tarea se deben especificar los requisitos que se deben considerar en el proyecto de adquisición, incluyendo los siguientes:

• de los interesados (stakeholders): las necesidades se deben transformar en requisitos más específicos que


contemplen los diversos tipos de interesados (stakeholders), tales como: usuarios, planificadores, gestores, productores y beneficiarios del sistema;

• del sistema: requisitos envolviendo procesos, hardware, software, integraciones, entorno y personas que compondrán la solución que atenderá a las necesidades establecidas;

• del software: requisitos de lo(s) producto(s) de software que compondrá(n) lo(s) sistema(s) que se deben implementar. Se deben especificar los requisitos funcionales y requisitos de calidad;

• de proyecto: ciclo de vida que se debe adoptar, técnicas, metodologías, forma de gestión y de documentación del proyecto;

• de mantenimiento: requisitos relacionados al mantenimiento del software después de su entrega;

• de entrenamiento: características esperadas del entrenamiento relacionado al S&SC a ser entregado; y

• de implantación: descripción de los procedimientos necesarios para la implantación del software en el entorno operativo, como, por ejemplo, la carga de la base de datos, la implementación en una configuración distribuida, entre otros.

Además de estos requisitos, se pueden considerar otros requisitos y restricciones que afecten directamente al proyecto de adquisición como, por ejemplo: restricciones legales, financieras, de plazo del proyecto y de número de usuarios del sistema en operación.

El adquiridor podrá definir y analizar los requisitos con su propio equipo o contratar un proveedor para ejecutar estas actividades. En este caso, el adquiridor deberá mantener la responsabilidad por la aprobación del resultado del análisis de los requisitos.



Pre-p3 - Informe de análisis de mercado

NOTA: Este documento es, en general, elaborado como parte del proceso de análisis de viabilidad de iniciar el proyecto de adquisición, evaluándose el problema de la organización y las alternativas posibles de solución que el mercado ofrece.


Pre-p2 - Resultado del análisis de la necesidad de la adquisición revisado

NOTA: Esta tarea puede causar la revisión del alcance de las necesidades que se deben atender en función de las características de los requisitos que se deben contemplar para atender a las necesidades, que pueden causar impactos en costo y plazo.


Pre-p4 - Especificación de requisitos

Pre-t3 Revisar los requisitos

Descripción:

Analizar y validar los requisitos definidos en relación a las necesidades de la adquisición, para reducir los riesgos de la falta de entendimiento por parte de los proveedores en potencial.

La revisión de los requisitos establecidos debe considerar elementos como:

• Evaluar si todos los interesados (stakeholders) están siendo considerados en los requisitos, o si las ausencias son justificadas;

• Verificar eventuales situaciones de conflictos e inconsistencias entre requisitos;

• Verificar la existencia de requisitos incompletos, ambiguos o no verificables;

• Verificar si los requisitos del software contemplan aspectos funcionales y de calidad;

• Evaluar la relación entre costo y beneficio de los requisitos, apuntando situaciones críticas.



Pre-p4 - Especificación de requisitos


Pre-p4 - Especificación de requisitos revisada

Pre-p5 - Registro de la revisión de los requisitos

Pre-t4 Desarrollar una estrategia de adquisición

Descripción:

Desarrollar una estrategia para la adquisición del S&SC compatible con las necesidades que se deben atender en la adquisición.

El Adquiridor debe considerar opciones viables para la adquisición, analizando criterios que lleven en cuenta riesgos, costos y beneficios de cada opción. Se debe considerar opciones como:

• Comprar un producto de software comercializado que cumpla los requisitos;

• Desarrollar el producto de software u obtener el servicio de software internamente en la organización;

• Desarrollar el producto de software u obtener el servicio de software por medio de un contrato;

• Realizar una combinación de los tres elementos anteriores;


• Perfeccionar un producto o servicio de software existente.

Esta tarea es responsable por orientar la conducción de las tareas de las demás actividades de adquisición, llevando en cuenta las necesidades y requisitos establecidos y los contextos de la organización adquiriente y del mercado proveedor. La representación de la estrategia se materializa por medio del plan de adquisición, que es insumo para la elaboración de la solicitud de propuestas y contempla elementos como: los términos contractuales, los términos financieros, los términos técnicos, la lista de productos y servicios a ser suministrados, los mecanismos de control del proyecto de adquisición, normas y modelos a ser seguidos por el proveedor, riesgos identificados en el proyecto, criterios de aceptación del producto y servicios y las responsabilidades de las organizaciones involucradas en el proyecto.


Pre-p2 - Resultado del análisis de la necesidad de la adquisición revisado

Pre-p3 - Informe del análisis de mercado



Pre-p6 - Plan de adquisición

Pre-p7 - Plan de prueba del S&SC para su aceptación

NOTA: Visión inicial del plan de pruebas obtenida a partir de la estrategia de definición y de los criterios de aceptación. Los criterios de aceptación definen los aspectos que deben cumplirse para que el S&SC sean aceptados.

Pre-p8 - Solicitud de propuestas

Pre-t5 Definir los criterios de selección de proveedores

Descripción:

Establecer y acordar los criterios de selección de proveedores, así como la forma de evaluación que se aplicará.

Como factores que pueden influenciar en la elección del proveedor, se pueden citar: localización geográfica del proveedor; registro de desempeño en trabajos semejantes; equipo e infraestructura disponibles para el desarrollo del producto deseado; tiempo de mercado; experiencia en el dominio del problema; nivel de calidad de sus procesos utilizados; y certificaciones exigidas.


Pre-p3 - Informe del análisis de mercado







NOTA: Incluyendo los criterios de selección de proveedores.


NOTA: Incluyendo los criterios de selección de proveedores.

4.2.3 Productos requeridos y generados

Id. Productos Descripción

Pre-p1 Evaluación de la necesidad del S&SC

Documento que contiene la necesidad del S&SC y alineamiento de la adquisición a los objetivos de la organización. Descripción de los objetivos que se pretende lograr con la adquisición.

Pre-p2 Resultado del análisis de la necesidad de la adquisición

Documento que detalla los criterios y resultados obtenidos durante el análisis de definición de las necesidades y requisitos del S&SC a adquirir. El resultado principal de este documento es la definición del alcance de las necesidades y requisitos que se deben contemplar en el proyecto de adquisición.

Pre-p3 Informe del análisis de mercado

Documento conteniendo las alternativas que el mercado ofrece con relación al S&SC deseado, con sus respectivas ventajas y desventajas. Este documento proporciona, a la organización adquiriente, una referencia para la elaboración de los requisitos del S&SC deseado.

Pre-p4 Especificación de requisitos Documento que define los requisitos y restricciones definidas por el cliente, incluyendo requisitos de los interesados (stakeholders), del sistema (cuando sea el caso), del software, de proyecto, de mantenimiento, de entrenamiento y de implantación, restricciones legales, financieras, de plazo y de número de usuarios.

Pre-p5 Registro de la revisión de los requisitos

Documento que registra los resultados del proceso utilizado para revisión de los requisitos especificados como, por ejemplo, relación de los interesados (stakeholders) que participaron en la revisión, problemas identificados y como


fueron tratados, además de la aprobación, cuando sea pertinente.

Pre-p6 Plan de adquisición

(ver anexo A)

Documento que define los objetivos específicos que se deben lograr con la adquisición, los riesgos involucrados y un plan de proyecto, contemplando elementos como: plazos, costos, requisitos y restricciones, criterios de selección de proveedores, productos y servicios a entregar, criterios de aceptación del S&SC, responsabilidades de las organizaciones involucradas en la adquisición, riesgos envueltos y mecanismos de control (cómo los productos generados y los procesos utilizados por el proveedor serán supervisados).

Pre-p7 Plan de prueba del S&SC para su aceptación

Documento que define las condiciones, tareas y responsabilidades por la ejecución de las pruebas necesarias para la aceptación del S&SC a ser adquirido. Para la elaboración de este documento, se deben llevar en cuenta los requisitos deseados del S&SC, así como los criterios establecidos para la aceptación. Este documento de orientación será actualizado y detallado a medida que sean especificadas las funciones del software a lo largo de la ejecución del contrato.

Pre-p8 Solicitud de propuestas

(ver anexo B)

Documento que caracteriza el S&SC requerido y las condiciones de entrega, además de las condiciones generales esperadas de la adquisición, plazos y valores envueltos, criterios de selección de proveedores, criterios de aceptación del S&SC y otras cuestiones formales que se deberán seguir. La solicitud de propuestas debe estar alineada al plan de adquisición. Puede ser una composición de los documentos especificación de requisitos y plan de adquisición.

4.3 Selección del proveedor

4.3.1 Objetivo

El propósito de la actividad de selección del proveedor es escoger la organización que será responsable por el desarrollo y entrega del S&SC en conformidad con los requisitos establecidos.


La ejecución de esta actividad busca identificar el proveedor adecuado para los requisitos establecidos, llevándose en cuenta una combinación armoniosa entre los resultados a ser obtenidos, plazos, recursos y riesgos envueltos. Como consecuencia, será escogido el proveedor que prestará el servicio hasta el final del contrato. Las tareas previstas comprenden:

Evaluar la capacidad de los proveedores (ver Sel-t1);

Seleccionar el proveedor (ver Sel-t2); y

Preparar y negociar un contrato (ver Sel-t3).


Id. Tarea

Sel-t1 Evaluar la capacidad de los proveedores

Descripción:

Evaluar la capacidad de los proveedores potenciales mediante los requisitos definidos y de acuerdo con los criterios de selección de proveedores.

Esta tarea es importante principalmente cuando se pretende hacer una selección previa de proveedores, llevando en cuenta los criterios de selección establecidos por el adquiriente. Hay situaciones en que organizaciones adquirientes utilizan una base de posibles proveedores, seleccionados a partir de criterios generales. En este caso, la selección para una adquisición específica es hecha a partir de la aplicación de los criterios de selección establecidos para esta adquisición en los proveedores potenciales registrados en la base existente en la organización.


Sel-p1 - Informe de auditoría o de evaluación de los proveedores

Sel-p2 - Especificación de requisitos

Sel-p3 - Solicitud de propuestas

NOTA: Con foco en los criterios de selección de proveedores. Productos generados:

Sel-p4 - Registro de proveedores preferenciales

Sel-p5 - Registro de contactos ocurridos

Sel-t2 Seleccionar el proveedor

Descripción:

Seleccionar el proveedor a partir de la evaluación de las propuestas recibidas.

En esta tarea se confrontan las características del proveedor y sus soluciones técnicas presentadas con los requisitos y criterios de selección definidos. Dependiendo de lo definido en los criterios de selección, esta tarea podrá requerir una evaluación de los procesos de software de los proveedores o evaluación de la calidad de productos de software (principalmente cuando es para la selección


de algún producto específico).


Sel-p4 - Registro de proveedores preferenciales


Sel-p6 - Propuesta del proveedor



Sel-p7 - Informe de evaluación de las propuestas de los proveedores

Sel-p8 - Resultado del análisis de la evaluación de los proveedores


Sel-p9 - Registro de apoyo a reuniones

NOTA: Documento donde son registradas las reuniones y los materiales presentados por los proveedores durante la exposición de su propuesta.

Sel-t3 Preparar y negociar un contrato

Negociar un contrato3 con el proveedor seleccionado, expresando las expectativas del adquiriente y las responsabilidades y derechos de las partes involucradas (adquiriente y proveedor).

Definido el proveedor y la propuesta técnica a implementar, esta tarea deberá contemplar una revisión del plan de adquisición en los tópicos de supervisión de la capacidad del proveedor y de los riesgos y mecanismos de mitigación, considerando la necesidad de inclusión o complementación de estos aspectos en el contrato a ser firmado entre las partes.

Productos Requeridos


Sel-p6 - Propuesta del proveedor



NOTA: Normalmente incluida en la solicitud de propuestas.

Sel-p10 - Plan de adquisición

NOTA: Principalmente los aspectos de supervisión del proveedor y de riesgos.


Sel-p11 - Contrato.

Sel-p12 - Registro de revisión de contrato


3 En el caso de instituciones públicas, el contrato es elaborado antes de la actividad “Selección del

proveedor” con base en el plan de adquisición elaborado y en la legislación relacionada. No habiendo, por lo tanto, posibilidad de revisión del plan de adquisición o complementación del contrato.


NOTA: Documento donde son registradas las reuniones realizadas durante la negociación del contrato con el proveedor seleccionado.



Id. Productos /tareas Descripción

Sel-p1 Informe de auditoría o de evaluación de los proveedores

Documento que contiene la evaluación de los proveedores según los criterios de selección definidos.

Sel-p2 Especificación de requisitos Documento que especifica los requisitos y restricciones definidas por el cliente, incluyendo requisitos de los interesados (stakeholders), del sistema (cuando sea el caso), del software, de proyecto, de mantenimiento, de entrenamiento y de implantación, restricciones legales, financieras, de plazo y de número de usuarios.

Sel-p3 Solicitud de propuestas

(ver anexo B)

Documento que caracteriza el S&SC y las condiciones de entrega, además de las condiciones generales esperadas de la adquisición, plazos y valores envueltos, criterios de selección y otras cuestiones formales que se deben seguir.

Sel-p4 Registro de proveedores preferenciales

Documento que registra los proveedores potenciales (preferenciales) según el informe de evaluación de proveedores.

Sel-p5 Registro de contactos ocurridos

Documento que registra todas las comunicaciones formales ocurridas entre las partes (por ejemplo, por teléfono, carta, fax, e-mail, entre otras).

Sel-p6 Propuesta del proveedor

(ver anexo C)

Documento que describe el entendimiento del problema por el proveedor, su abordaje y sus sugerencias de solución técnica, además del plan de entrega del S&SC y las condiciones financieras de la propuesta.

Sel-p7 Informe de evaluación de las propuestas de los proveedores

Documento que registra la evaluación de la capacidad del proveedor y de sus respectivas propuestas, considerando la solución técnica propuesta y su costo.

Sel-p8 Resultado del análisis de la evaluación de los proveedores

Documento que registra el resultado de la selección del proveedor teniendo como base el informe de evaluación de las


propuestas recibidas.

Sel-p9 Registro de apoyo a reuniones

Acta de las reuniones ocurridas abordando aspectos como objetivo de la reunión, participantes, local y fecha, asuntos tratados, elementos identificados, cuestiones que permanecieron pendientes y agenda de la próxima reunión.

Sel-p10 Plan de adquisición

(ver anexo A)

Documento que define los objetivos específicos que se deben lograr con la adquisición, los riesgos envueltos y un plan de proyecto, contemplando elementos como: plazos, costos, requisitos y restricciones, criterios de selección de proveedores, productos y servicios a entregar, criterios de aceptación del S&SC, responsabilidades de las organizaciones involucradas en la adquisición, riesgos envueltos y mecanismos de control (cómo los productos generados y los procesos utilizados por el proveedor serán supervisados).

Sel-p11 Contrato

(ver anexo D)

Documento donde son establecidos los aspectos financieros, técnicos y legales referentes a la contratación del S&SC, así como las expectativas y responsabilidades de las partes involucradas.

Sel-p12 Registro de revisión de contrato

Documento donde son registrados los cambios o modificaciones del contrato requeridos por cualquiera de las partes.

4.4 Supervisión del contrato

4.4.1 Objetivo

El propósito de la actividad de supervisión del contrato es acompañar y asegurar el desempeño del proveedor mediante los términos del contrato.

La ejecución de este actividad es fundamental para supervisar el desarrollo del S&SC y de la relación adquiridor-proveedor durante todo el período del contrato establecido. Las evaluaciones realizadas durante el desarrollo del contrato permiten identificar problemas, tomar decisiones de gerenciales, proyectar la calidad final esperada del S&SC y minimizar los riesgos. Dependiendo del abordaje adoptado, los resultados de evaluaciones intermedias se podrán utilizar en las tareas de la actividad de aceptación. Las tareas previstas comprenden:

Establecer y mantener comunicaciones (ver Mon-t1);

Intercambiar información sobre el progreso técnico (ver Mon-t2);

Revisar el desempeño del proveedor (ver Mon-t3);


Supervisar la adquisición (ver Mon-t4);

Obtener acuerdo con respecto a los cambios (ver Mon-t5); y

Acompañar problemas (ver Mon-t6).


Id. Tarea

Mon-t1 Establecer y mantener comunicaciones

Descripción:

Establecer y mantener un canal de comunicación entre el proveedor y el adquiriente.

Esta tarea es fundamental, pues define la forma de comunicación entre las partes (por ejemplo, cronograma, representantes, documentos utilizados, reuniones, revisiones conjuntas) a adoptar durante todo el período vigente del contrato. Esta comunicación establecida, así como los productos requeridos y generados, se debe considerar en todas las demás tareas de esta actividad.


Mon-p1 - Contrato

NOTA: Las cláusulas contractuales forman la base para definición de la forma de supervisión de las tareas ejecutadas.

Mon-p2 - Propuesta del proveedor

NOTA: La propuesta del proveedor podrá contener detalles complementarios al contrato y que se deben llevar en cuenta en la supervisión.

Mon-p3 - Registro de apoyo a reuniones.

NOTA: Es imprescindible el registro de discusiones y definiciones ocurridas en reuniones conjuntas.


Mon-p3 - Registros de apoyo a reuniones

Mon-p4 - Registro del status del progreso.

Mon-p5 - Registro de contactos ocurridos.

Mon-t2 Intercambio de informaciones sobre el progreso técnico

Descripción:

Utilizar el canal de comunicación para intercambio de informaciones sobre el progreso técnico del proveedor, además de aspectos de costos y la identificación de posibles riesgos.

Este intercambio de informaciones podrá ocurrir durante las tareas típicas de desarrollo del proyecto (por ejemplo, en la obtención de requisitos, aprobación de artefactos, reuniones de aclaraciones, entre otros) pudiendo, sin embargo, suministrar informaciones importantes sobre la evolución


técnica del proyecto.


Mon-p1 - Contrato


Mon-p3 - Registro de apoyo a reuniones



Mon-p4 - Registro del status del progreso

Mon-p5 - Registro de contactos ocurridos

Mon-p6 - Registro de revisiones

NOTA: Es importante el registro de las revisiones conjuntas ocurridas para posibles aclaraciones futuras y para el histórico del proyecto.

Mon-t3 Revisar el desempeño del proveedor

Descripción:

Revisar, regularmente, aspectos del desarrollo con el proveedor, teniendo como base los términos del contrato. Los aspectos incluyen cuestiones técnicas, de calidad, costos y plazos.

La revisión es un evento formal que ocurre en hitos (marcos) del proyecto. Se deberá planificar con anticipación y ocurrir en puntos bien definidos que puedan traer el mejor retorno con relación al andamiento del proyecto. Como puede envolver un volumen expresivo de recursos, la cantidad de revisiones deberá ser proporcional a la criticidad del proyecto. En general, deberá valerse de medidas recolectadas durante las tareas del proyecto, sin embargo podrá demandar mediciones específicas sobre los artefactos producidos en el proyecto. Esta tarea se podrá ejecutar por el propio adquiriente o, dependiendo de su complejidad, podrá requerir la utilización de recursos de tercera parte.


Mon-p1- Contrato

NOTA: Si el contrato no contempla las reglas que hayan sido definidas para la supervisión, se pueden requerir otros documentos complementarios.



Mon-p7 - Conformidad con los requisitos del contrato

NOTA: El contrato deberá reflejar eventuales cambios que puedan ocurrir conforme referido en la tarea Mon-t5.

Mon-p13 – S&SC






Mon-p8 - Resultado del análisis del desempeño del proveedor

Mon-p9 - Registro de aceptación del desempeño del proveedor

NOTA: La aceptación de los productos entregados en la revisión debe estar vinculada al contenido del resultado del análisis del desempeño del proveedor.

Mon-t4

Supervisar la adquisición

Descripción:

Supervisar la adquisición, teniendo como base el contrato, para que el progreso se pueda evaluar asegurando que aspectos como costo, calidad y plazo sean cumplidos.

La supervisión del proyecto es una tarea ejecutada por medio del análisis de medidas obtenidas en el proceso ejecutado. Durante la supervisión, también se deben considerar los resultados de la revisión del desempeño del proveedor (Mon-t3). El análisis de estas medidas permite la obtención de indicadores de desempeño del proyecto en la situación en que fueron obtenidas las medidas, además de la proyección de la situación futura del proyecto. La supervisión debe envolver aspectos que caracterizan el progreso del proyecto, tales como cumplimiento de los requisitos, costos y plazos, los riesgos envueltos, nivel de problemas que están siendo enfrentados y adherencia al proceso que fue contratado. La supervisión es la base para la toma de acciones de gestión, tales como revisión de plazos y requisitos, designación de recursos, interrupción de actividades, aceptación (o no) de artefactos, aplicación de penalidades, solicitud de la participación de interesados (stakeholders) o inclusive la interrupción del contrato.


Mon-p1 - Contrato

NOTA: Si el contrato no contempla las reglas que hayan sido definidas para supervisión, se puede requerir otros documentos complementarios.




NOTA: El contrato deberá reflejar eventuales cambios que puedan ocurrir conforme referido en la tarea Mon-t5.


NOTA: Los resultados obtenidos en Mon-t3 sirven como insumo en la tarea de supervisión.


Mon-p13 - S&SC






NOTA: Esta tarea también produce resultados del análisis del desempeño del proveedor.

Mon-p9 - Registro de aceptación del desempeño del proveedor

NOTA: La aceptación de los productos entregados en la supervisión debe estar vinculada al contenido del resultado del análisis del desempeño del proveedor.

Mon-t5 Obtener acuerdo con respecto a los cambios

Descripción:

Los cambios propuestos por cualquiera de las partes se deben negociar y sus resultados se deben documentar en el contrato.

El contrato debe estar preparado para la necesidad de implementar cambios con relación a los requisitos u otras condiciones inicialmente establecidas. Estos cambios pueden significar nuevas responsabilidades para las partes además de poder influenciar los plazos, costos, calidad y beneficios envueltos. Conviene que el mecanismo utilizado para control de cambios considere los papeles y responsabilidades involucradas, el nivel de formalidad necesario y la forma de comunicación para los interesados (stakeholders) afectados.


Mon-p1 - Contrato


Mon-p3 - Registro de apoyo a reuniones


NOTA: La situación de los requisitos establecidos o actualizados en cambios anteriores será la base para cualquier nueva solicitud.

Mon-p10 - Pedidos de cambios por el adquiriente

NOTA: Este registro es muy importante para sustentar el acuerdo firmado en el contrato y analizar sus posibles enmiendas.





NOTA: Eventuales cambios introducidos deberán ser aprobados por los interesados (stakeholders) y reflejados en el contrato entre las


partes.

Mon-t6 Acompañar problemas

Descripción:

Los problemas que surjan durante la ejecución del contrato se deben registrar y acompañar hasta su solución por las partes.

La adopción de una solución de acompañamiento de problemas permite que los problemas identificados sean declarados y designados para los respectivos responsables hasta su solución definitiva o creación de soluciones provisionales aceptables. Acciones de gestión sobre los datos obtenidos podrán evitar la reincidencia de problemas, mejorando la calidad del proceso adoptado.


Mon-p11 - Sistema de acompañamiento de problemas

NOTA: Este sistema puede ser manual o automatizado y facilitará la gestión del proyecto.


Mon-p12 - Registros en el sistema de acompañamiento de problemas.



Mon-p1 Contrato

(ver anexo D)


Mon-p2 Propuesta del proveedor

(ver anexo C)

Documento que describe el entendimiento del problema por el proveedor, su abordaje y sus sugerencias de solución técnica.

Mon-p3 Registros de apoyo a reuniones


Mon-p4 Registro del status del progreso

Documento que registra, en una determinada fecha, la situación del proyecto de adquisición en lo referente a costo, plazo y requisitos atendidos.

Mon-p5 Registro de contactos ocurridos

Documento que registra todas las comunicaciones formales ocurridas entre las partes (por ejemplo, por teléfono, carta,


fax, e-mail, entre otras).

Mon-p6 Registro de revisiones

(ver anexo E)

Documento que registra fecha, producto o proceso revisado, método de revisión utilizado, el responsable por la revisión y el resultado (bueno, necesita mejorar, malo). El registro de revisiones también contiene informaciones de gestión del proyecto y los riesgos identificados durante la revisión.

Mon-p7 Conformidad con los requisitos del contrato

Documento que registra la concordancia de los interesados (stakeholders) relevantes con los requisitos del contrato y los compromisos establecidos para las partes.

Mon-p8 Resultado del análisis del desempeño del proveedor

Documento que registra el desempeño del proveedor, si está o no respondiendo a las expectativas esperadas y cumpliendo el acuerdo realizado o si es el caso de aplicar penalidades, cancelar el contrato u otra solución.

Mon-p9 Registro de aceptación del desempeño del proveedor

Documento que registra la aceptación del S&SC entregados y del desempeño del proveedor, dando continuidad al contrato.

Mon-p10 Pedidos de cambios por el adquiriente

Documento donde son registrados los pedidos del adquiriente como cambio de requisitos o inclusión de nuevos.

Mon-p11 Sistema de acompañamiento de problemas

Sistemática que permita registrar y acompañar las tareas necesarias para la solución de los problemas identificados.

Mon-p12 Registros en el sistema de acompañamiento de problemas

Registros que permiten acompañar el status de los problemas pendientes y solucionados.

Mon-p13 S&SC Artefactos del S&SC que estarán sujetos a las tareas relacionadas a la actividad de monitoreo del contrato.

4.5 Aceptación por el cliente

4.5.1 Objetivo

El propósito de la actividad de aceptación por el cliente es aprobar S&SC entregados por el proveedor cuando todos los criterios de aceptación se cumplan.

En esta actividad, se refinan los criterios de aceptación definidos en el plan de proyecto e incorporados en la solicitud de propuestas y en el contrato. Las evaluaciones se pueden conducir durante la vigencia del contrato, por un abordaje envolviendo múltiples iteraciones y entregas de productos, o por medio de una entrega única. Los S&SC


entregados son analizados para identificar la conformidad a los criterios establecidos. Las tareas de evaluación son concebidas de modo que se reduzcan las intervenciones en las evaluaciones ejecutadas por el proveedor y la duplicación de esfuerzos de evaluación.

No habiendo aprobación del S&SC, y dependiendo de las cláusulas contractuales, se puede planificar e implementar ajustes para que el producto sea sometido a una nueva evaluación. Este ciclo ocurre mientras el producto no sea aprobado, o hasta que sea definitivamente rechazado. Las tareas previstas comprenden:

Definir criterios de aceptación (ver Ace-t1);

Evaluar el producto entregado (ver Ace-t2);

Mantener la conformidad con el contrato (ver Ace-t3); y

Aceptar el S&SC (ver Ace-t4).


Id. Tarea

Ace-t1 Preparar la aceptación

Descripción:

Preparar la aceptación del S&SC llevando en cuenta los criterios de aceptación del S&SC, así como la forma de evaluación que se aplicará.

En esta tarea deberán hacerse las adaptaciones finales en los criterios de aceptación y en el plan de pruebas elaborados durante la actividad de preparación de la adquisición, incluyendo los casos de pruebas, datos de pruebas, procedimientos de pruebas y entorno de pruebas. En este momento deben considerarse no apenas los requisitos establecidos pero también sus formas de implementación a través de las diversas funciones del software. Esta tarea requiere el establecimiento de una correlación entre los requisitos especificados y las funciones del software que fueron implementadas. Los requisitos abordados por los criterios de aceptación se deberán desdoblar en casos de prueba de las funciones del software que permitan constatar el cumplimiento de las medidas establecidas.


Ace-p1 - Contrato

Ace-p2 - Plan de prueba del S&SC para su aceptación

NOTA: versión elaborada en la actividad de preparación de la adquisición.

Ace-p3 - Plan de adquisición

Ace-p4 - Propuesta del proveedor

NOTA: La propuesta del proveedor puede incluir elementos que suplementan los requisitos inicialmente establecidos.

Ace-p5 - S&SC




NOTA: Plan de prueba actualizado, considerando la forma de implementación de los requisitos especificados.

Ace-t2 Evaluar el S&SC entregado

Descripción:

Evaluar el S&SC con base en los criterios de aceptación definidos.

En esta tarea, son complementadas las pruebas necesarias para confirmar el cumplimiento de los criterios de aceptación definidos. Dependiendo del abordaje utilizado para desarrollo del S&SC, se podrá ejecutar parte de las tareas de evaluación durante el proyecto.




NOTA: El Plan de adquisición se puede utilizar en esta tarea, pues incluye la definición de los criterios de aceptación establecidos en la actividad de preparación de la adquisición.


Ace-p5 - S&SC

Ace-p6 - Especificación de requisitos


Ace-p7 - Informe de resultados de pruebas

Ace-t3 Mantener conformidad con el contrato

Descripción:

Resolver cualquier aspecto relacionado a la aceptación, de acuerdo con los procedimientos establecidos en el contrato.

Esta tarea apenas asegura que el contrato sea utilizado como referencia para dirimir cuestiones que puedan surgir en el proceso de aceptación y para asegurar que el S&SC entregados están de acuerdo con el contrato.


Ace-p1 - Contrato


Ace-p8 - Registro de apoyo a reuniones


Ace-t4 Aceptar el S&SC

Descripción:

Aceptar el S&SC y comunicar su aceptación al proveedor.

Esta tarea representa el rito de pasaje del S&SC de su estado de suministro al recibimiento por el cliente. Deberá estar completamente respaldada por los informes producidos en el proceso de evaluación y por la observación de todos los criterios de aceptación definidos anteriormente. Además de los criterios de evaluación del producto de software entregado, también se debe considerar los criterios relacionados a los servicios asociados, por ejemplo, al proceso de implantación del software y al cumplimiento de las condiciones para que este entre en proceso de mantenimiento.


Ace-p1 - Contrato



Ace-p5 - S&SC

Ace-p6 - Especificación de requisitos

Ace-p7 - Informe de resultados de pruebas


Ace-p8 - Informe de aceptación del S&SC



Ace-p1 Contrato

(ver anexo D)


Ace-p2 Plan de prueba del S&SC para su aceptación

Documento que define las condiciones, tareas y responsabilidades por la ejecución de las pruebas necesarias para la aceptación del S&SC a ser adquirido. Para la elaboración de este documento, se debe llevar en cuenta los requisitos deseados del S&SC, así como los criterios establecidos para la aceptación. Este documento de orientación será actualizado y detallado a medida que sean especificadas las funciones del software durante la ejecución del contrato.


Ace-p3 Plan de adquisición

(ver anexo A)

Documento que define los objetivos específicos que se deben lograr con la adquisición, los riesgos envueltos y un plan de proyecto, contemplando elementos como: plazos, costos, requisitos y restricciones, criterios de selección de proveedores, productos y servicios que serán entregados, criterios de aceptación del S&SC, responsabilidades de las organizaciones involucradas en la adquisición, riesgos envueltos y mecanismos de control (cómo los productos generados y los procesos utilizados por el proveedor serán supervisados).

Ace-p4 Propuesta del proveedor

(ver Anexo C)

Documento que describe el entendimiento del problema por el proveedor, su abordaje y sus sugerencias de solución técnica.

Ace-p5 S&SC Conjunto de programas de computadora, procedimientos y posible documentación y datos asociados que se deben entregar al cliente, así como servicios correlacionados con el software entregado, tales como mantenimiento, entrenamiento, integración con otros sistemas, implantación, entre otros.

Ace-p6 Especificación de requisitos Documento que especifica los requisitos y las restricciones definidas por el cliente, incluyendo requisitos de los interesados (stakeholders), del sistema (cuando sea el caso), del software, de proyecto, de mantenimiento, de entrenamiento y de implantación, restricciones legales, financieras, de plazo y de número de usuarios.

Ace-p7 Informe de resultados de pruebas

Documento que presenta los resultados de las pruebas del software, sean parciales, pruebas de integración de las partes del producto, prueba final del producto y prueba en operación realizada en el entorno del cliente.

Ace-p8 Informe de aceptación del S&SC

Documento que presenta la memoria de los resultados de los procedimientos utilizados que llevaron a la aceptación o rechazo del S&SC.


Ace-p8 Registro de apoyo a reuniones



Anexo A – Plan de adquisición

PLAN DE ADQUISICIÓN – < S&SC >

Este documento tiene como objetivo orientar la adquisición de S&SC

para < objetivo esperado del S&SC> de la < nombre de la empresa >.

1. Objetivo de la adquisición:

(Descripción de los objetivos que se deberán atender con la adquisición del S&SC).

Ejemplo: Se pretende, con la adquisición del S&SC, controlar las finanzas de la institución, de modo que se agilicen los procesos administrativos, aliviando la alta carga de trabajo de la tesorería, mejorando y haciendo dinámicas las rutinas administrativas y los controles financieros; y mejorar la calidad de las informaciones para gestión.

2. Requisitos

2.1 Requisitos de los interesados (stakeholders)

(Lista de necesidades de los interesados (stakeholders) en la utilización del software a ser adquirido. Se deben considerar los diversos interesados y contextos de uso del software. La definición de prioridades puede ser importante para establecer criterios de aceptación y plan de versiones del software. Eventualmente, esta relación de requisitos se puede constituir en un documento anexo al plan de adquisición).

Ejemplos:

Agilizar los procesos administrativos.

Amenizar la alta carga de trabajo de la tesorería.

Permitir el control de las cuentas a recibir.

2.2 Requisitos del sistema

(Descripción del contexto general en el cual se incluirá el software a ser adquirido, pudiendo contemplar el entorno tecnológico, de procesos o hasta de personas involucradas).

Ejemplo: El software debe trabajar en red de microcomputadoras y ambiente Windows, de modo que se aproveche la infraestructura existente, utilizando la base de datos FireBird, que es el banco de datos corporativo de la organización. El software será uno de los componentes del proceso de adquisición de insumos de la empresa, contemplando las actividades “a”, “b” y “c”.

2.3 Requisitos del software

(Es la derivación de los requisitos de los interesados (stakeholders) que fueron ubicados a través de los sistemas. Los requisitos del software se dividen en Requisitos Funcionales que describe las funciones a ser realizadas por el software a


ser adquirido y Requisitos de Calidad que describen las características de calidad consideradas importantes en el software).

Ejemplos de requisitos funcionales:

El software deberá permitir registrar al usuario con su grado de confidencialidad.

El software deberá permitir redactar documento.

El software deberá permitir visualizar documento.

Ejemplos de requisitos de calidad:

Usabilidad: estilo o principios de diálogo que son aplicables; tipo de documentación a entregar (online, manuales de usuario);

Portabilidad: Reglas de portabilidad que se deberán adoptar (tanto para la parte de servidores como para el acceso vía estaciones de trabajo);

Interoperabilidad: integración de las aplicaciones nuevas con las bases de datos y aplicaciones legadas;

Mantenibilidad: tipos y características de los artefactos generados, de modo que se permita el mantenimiento por parte del contratado, así como para facilitar eventuales repases de conocimiento.

2.4 Requisitos de proyecto

(Establecer el ciclo de vida de desarrollo a ser adoptado, técnicas, herramientas, tecnologías, métodos, forma de gestión y de documentación).

Ejemplo: El software a ser adquirido se deberá desarrollar según el abordaje del Proceso Unificado, generando artefactos según la notación la UML y con la tecnología J2EE.

2.5 Requisitos de mantenimiento

(Establecimiento de la forma como será conducido el mantenimiento del software a ser adquirido. Definir el costo y el canal de comunicación entre el proveedor y el cliente para el tratamiento de posibles problemas).

Ejemplo: La corrección de problemas considerados críticos se deberá suministrar hasta en 24 horas después de su identificación por el usuario, o, no siendo viable, se deberá establecer una solución provisional; Cada 2 años se deberá promover una actualización tecnológica del software considerando las evoluciones que puedan ocurrir en su entorno operativo.

2.6 Requisitos de entrenamiento

(Establecimiento de un plan de entrenamiento para la operación del software a ser adquirido. Definir las personas que participarán en el entrenamiento, el número de presentaciones/aulas que serán necesarias así como el material y el entorno a ser utilizado).

Ejemplo: La organización proveedora deberá ofrecer 3 presentaciones/aulas a los usuarios del software. Deberá ser parte del material de entrenamiento el


manual del usuario. El entrenamiento será realizado en las dependencias de la organización del cliente.

2.7 Requisitos de implantación

(Establecimiento de la forma de cómo será conducida la implantación del software a ser adquirido. Definir el entorno y los equipamientos necesarios).

Ejemplo: La implantación del software será realizada en 3 días. La organización proveedora deberá acompañar las instalaciones de los nuevos equipamientos y del nuevo software. Al implantarse el software, la base de datos deberá estar rellenado con los datos reales.

3. Términos contractuales

(Descripción de aspectos relacionados al contrato).

3.1 Tipo de contrato a emplear

(Tipo de contrato a utilizar)

Ejemplo: Contrato de precio fijo, contrato de costos reembolsables o contrato de precio unitario por punto de función.

3.2 Multas y penalidades

(Valor y las condiciones de ocurrencia de multas para ambas partes).

Ejemplo: La contratada, salvo los casos fortuitos o de fuerza mayor, debidamente comprobadas, y asegurada su defensa previa en el respectivo proceso de apuración de los hechos, estará sujeta a las siguientes penalidades:

a. advertencia, por escrito, en la primera falta cometida;

b. multas, por el valor de hasta 20% del valor total establecido;

c. suspensión temporaria de participación en licitación e impedimento de contratar con el cliente, por un plazo de hasta (02) años.

3.3 Derechos de distribución, uso y propiedad del software

(Establecimiento de los derechos de distribución, uso y propiedad del software, como por ejemplo, el número de copias a distribuir y la propiedad del código fuente, entre otros).

Ejemplo: El software desarrollado estará bajo una licencia de uso restringida al contratante, protegidos por derechos autorales y de propiedad. La copia, redistribución, ingeniería reversa y modificaciones del software propietario son prohibidas. Los programas de software serán de uso propietario de la organización cliente, inclusive sus códigos fuente y documentación. La organización proveedora no tendrá derecho, disponibilidad o cualquier otro tipo de participación en ninguno de estos programas o en cualquier copia, modificación o parte agregada de cualquiera de estos programas.


3.4 Garantía del S&SC

(Garantía del S&SC describiendo el plazo de vigencia, el alcance (por ejemplo, errores en el software, problemas en la instalación, documentación, integración con otros sistemas) y los procedimientos para su uso).

Ejemplo: Durante el plazo de garantía, de seis meses, la contratada deberá prestar servicios de mantenimiento, aclarando dudas y corrigiendo eventuales fallas que imposibiliten el uso normal del software.

4. Términos financieros

(Descripción de cuestiones financieras relacionadas a la adquisición).

4.1 Presupuesto del proyecto

(Valor monetario disponible para el proyecto de adquisición).

Ejemplo: El valor disponible para la adquisición del software es de RS $ 1.000.000,00 (Un millón de reales).

4.2 Fuente de recursos para la adquisición

(Descripción del origen de la verba designada para la adquisición).

Ejemplo: La verba para el proyecto de adquisición es fruto de una alianza con organizaciones afines.

4.3 Formas de pago de la adquisición

(Descripción de los períodos de pago al proveedor, el número de cuotas y el valor de cada cuota).

Ejemplo: El pago referente a la adquisición será realizado en cuatro cuotas en el valor de R$ 250.000,00 (doscientos y cincuenta mil reales) cada, en un período de un año.

5. Términos técnicos

(Descripción de aspectos técnicos considerados importantes para la adquisición).

5.1 Procedimientos de confidencialidad

(Establecimiento del tratamiento que se debe dar a las informaciones confidenciales confiadas al proveedor, así como las condiciones de acceso a las instalaciones del adquiriente, identificación de los participantes del proyecto, entre otros).

Ejemplo: Es de responsabilidad del proveedor proteger y devolver toda y cualquier documentación confidencial prestada por la organización cliente durante la elaboración del S&SC. El proveedor deberá elegir un responsable por


el pedido, guardia y devolución de los documentos necesarios durante la adquisición.

5.2 Especificación del canal de comunicación

(Establecimiento de un mecanismo de comunicación entre los participantes del proyecto de adquisición y el proveedor: vía e-mail, personalmente o por teléfono, siempre que haya necesidad).

Ejemplo: Siempre que haya necesidad, se podrá realizar el intercambio de informaciones entre la organización cliente y el proveedor, vía e-mail y/o personalmente. Tanto los e-mails intercambiados, como las reuniones presenciales se deben registrar y almacenar.

5.3 Procedimientos para cambios

(Establecimiento de cómo, cuándo y por quien serán ejecutados los cambios en los requisitos y en el contrato).

Ejemplo: Tanto la organización cliente así como la organización proveedora deberán elegir un responsable por la gestión de pedidos de cambios de requisitos y de contrato. Siempre que haya la necesidad de algún cambio, los representantes responsables deberán reunirse y llegar a un acuerdo sobre la realización o no del cambio en cuestión.

5.4 Procedimientos para tratamiento de problemas

(Procedimientos a adoptar para registro, acompañamiento y solución de problemas).

Ejemplo: A medida que sean identificados problemas que puedan afectar los resultados del proyecto para el adquiriente, se deberán registrar, analizar sus impactos y definir los cauces de solución, incluyendo los responsables por las acciones que se tomarán, los plazos involucrados y la fecha de la solución efectiva.

Problemas en el ámbito técnico específico de los proyectos y que no afecten los resultados para el adquiriente ser deberán tratar por medio de los procedimientos internos de tratamiento de problemas del proveedor.

6. Lista de S&SC a entregar

(Lista de los S&SC que se deben entregar al proveedor al finalizar el contrato. Entre estos, se debe considerar los servicios de soporte esperados del proveedor).

Ejemplo: Los productos a ser entregados al final del contrato son:

(i) el software instalado en su entorno operativo;

(ii) los manuales del usuario, de instalación y del sistema; y

(iii) los códigos fuente


7. Puntos de control

(Descripción de los hitos (marcos) de control del proyecto, definidos por medio de los productos de trabajo y de los procesos del proveedor que serán evaluados por el adquiriente durante el proceso de adquisición, y el método de evaluación, por ejemplo: validación, auditoria y revisión conjunta, entre otros).

Nombre del Producto/Proceso

Método de la Evaluación

Módulo 1 – mantenimiento de los datos del BD

Pruebas

Manual del usuario Revisión Conjunta

8. Plazos establecidos

(Especificación del cronograma para el ciclo de vida escogido y sus hitos (marcos)).

Ejemplo: El software a ser adquirido deberá estar compuesto por cuatro módulos. El primer módulo (xxxx) deberá ser entregado, para pruebas del cliente, al final de dos meses, a partir de la fecha de la firma del contrato. El segundo módulo (yyyy) deberá ser entregado tres meses después de la entrega del primero. El tercer módulo (zzzz) deberá ser entregado tres meses después de la entrega del segundo módulo y el cuarto y último módulo (wwww) deberá ser entregado cuatro meses después de la entrega del tercer módulo.

9. Criterios de selección del proveedor

(Descripción de los criterios de evaluación para juzgar la capacidad del proveedor para cumplir el contrato pretendido).

Ejemplo: Los criterios para la selección del proveedor son:

(i) Situarse en la ciudad de Río de Janeiro;

(ii) Tener más de cinco años de mercado;

(iii) Tener experiencia en el dominio del problema; y

(iv) Tener evaluación oficial MA-MPS nivel F

10. Criterios de aceptación del S&SC

(Descripción de aspectos que se deben satisfacer para que el S&SC sean aceptados. Teóricamente todos los requisitos tendrían que ser evaluados, lo que no siempre es práctico. Estos son criterios que serán evaluados para apoyar al proceso de aceptación. La garantía puede asegurar que los demás requisitos tienen que ser cumplidos durante su plazo de vigencia).

10.1 Requisitos funcionales del software

(Descripción de las funciones del software que serán evaluadas para la definición de su aceptación).


Ejemplo: El software solamente se aceptará después de su validación con éxito de las funciones de registro, cálculo y consultas gerenciales.

10.2 Requisitos de calidad del software

(Descripción de las características de calidad que serán evaluadas para la definición de la aceptación del software).

Ejemplo: El software solo se aceptará después de una evaluación con éxito de los requisitos referentes a las siguientes características de calidad:

(i) seguridad de acceso;

(ii) usabilidad;

(iii) comportamiento con respecto al tiempo; y

(iv) portabilidad

10.3 Documentación disponible

(Especificación de los documentos que serán evaluados como condición de aceptación del S&SC, como: manual del usuario y de instalación, entre otros).

Ejemplo: El software a ser adquirido se deberá entregar junto con el manual del usuario, el manual del sistema y el manual de instalación.

11. Normas y modelos

(Descripción de normas, modelos, leyes, estándares, prácticas y convenciones que deben ser seguidos por el proveedor).

Ejemplo: La organización proveedora deberá seguir el modelo MPS.BR para el desarrollo de software y las normas adoptadas por la organización cliente con relación a la estandarización de la nomenclatura de variables de los programas de software.

12. Responsabilidades del proyecto

(Definición de las tareas que se desempeñaran en el proyecto, considerando el adquiriente, el proveedor y, cuando hubiera, la tercera parte).

Ejemplo: El equipo del proyecto de adquisición de la organización cliente deberá suministrar, siempre que sea necesario, informaciones y documentos que serán utilizados por la organización proveedora. Queda también bajo la responsabilidad del equipo del proyecto de adquisición de la organización cliente la actividad de suministrar las informaciones necesarias para rellenar la base de datos. Además de las tareas típicas del proveedor, previstas en el plan de proyecto, deberá ejecutar funciones de gerente de proyecto, que actuará de forma global en el proyecto, asegurando que las acciones sean tomadas de forma adecuada y a tiempo para atender las necesidades de proyecto;

13. Riesgos y eventos

(Descripción de riesgos o eventos que pueden ocurrir durante la adquisición y cómo se deben tratar).


13.1 – Identificación del riesgo

(Descripción del tipo de riesgo, por ejemplo: atraso en el cronograma, falta de recursos financieros y humanos y falla en la interpretación de los requisitos del software, entre otros).

Ejemplo: Un riesgo que puede ocurrir durante la ejecución del proyecto es la complejidad de los requisitos.

13.2 – Probabilidad de ocurrencia

(Descripción de la probabilidad de que ocurra el riesgo, por ejemplo: alta, mediana o baja).

Ejemplo: La probabilidad de ocurrencia del riesgo identificado en el elemento 13.1 es alta.

13.3 – Impacto en el proyecto

(Descripción de los aspectos relevantes que pueden afectar al proyecto caso de que el riesgo ocurra, por ejemplo: parar el proyecto y falta de verbas para otras tareas, entre otros).

Ejemplo: Los impactos en el proyecto como consecuencia del riesgo identificado en la sección 13.1 son: el alto índice de cambio de los requisitos y cronograma ultrapasado.

13.4 – Mitigación de los riesgos

(Descripción de los procedimientos para amenizar o eliminar la ocurrencia del riesgo).

Ejemplo: Para mitigar el riesgo identificado en el elemento 13.1 será consultado un especialista con dominio del problema para aclarar dudas y orientar la actividad para obtención de requisitos del software.

13.5 - Plan de contingencia

(Descripción de los procedimientos a ser tomados en caso de que se concretice el riesgo).

Ejemplo: Caso de que el riesgo identificado en el elemento 13.1 se concretice, se puede necesitar considerar un nuevo abordaje para complementar los requisitos y para desarrollar el software, pudiendo adoptar, por ejemplo, la aplicación de prototipos.


Anexo B – Solicitud de propuestas

Solicitud de propuestas – < Software >

Este documento busca auxiliar la elaboración de propuesta de suministro de software para < aplicación del software > de la < nombre de la empresa >.

1. Descripción de la organización cliente

(Descripción del tipo, de la estructura, de los objetivos y metas de la organización cliente).

Ejemplo: El Colegio ABC, una institución de enseñanza que cubre desde del jardín de infancia hasta la conclusión del segundo grado, hoy cuenta con un sistema informatizado de control escolar de las actividades de la secretaria. Sin embargo, en el sector de tesorería los controles todavía son efectuados de forma manual, lo que es considerado crítico por los mantenedores.

Ese control manual de las actividades de la tesorería acarrea, entre otros problemas, sobrecarga de trabajo para algunos funcionarios, acumulación de papeles, dificultad para controlar los gastos y recetas por sector de la escuela, dificultad en el tratamiento de informaciones gerenciales y una pérdida de calidad en la atención a los alumnos y sus padres, debido a la morosidad de las informaciones.

La mantenedora demostró la intención de, después de mejorar el desempeño de la tesorería, sustituir el software de control de la secretaria e integrarlo al software de control financiero.

También hay planes de, con la reforma del edificio administrativo, se haga disponible, para los alumnos y padres, un terminal de consulta de su situación escolar, inclusive financiera.

(El contenido de los elementos 2 a 14 es semejante a los elementos correspondientes del plan de adquisición. A veces es necesaria alguna adaptación con relación a las informaciones establecidas en el plan de adquisición que son de carácter reservado de la organización adquiriente. Algunos aspectos específicos son comentados a seguir).

2. Objetivo de la adquisición

3. Requisitos

3.1 Requisitos de los interesados (stakeholders)

3.2 Requisitos del sistema

3.3 Requisitos del software

3.4 Requisitos de proyecto

3.5 Requisitos de mantenimiento

3.6 Requisitos de entrenamiento

3.7 Requisitos de implantación

4. Términos contractuales

4.1 Tipo de contrato a emplear

4.2 Multas y penalidades

4.3 Derechos de distribución, uso y propiedad del software


4.4 Garantía del S&SC

5. Términos financieros

(Dependiendo de la organización, solo será necesario establecer apartado 5.3, explicitando las formas de pago).

5.1 Presupuesto financiero del proyecto

5.2 Fuente de recursos para la adquisición

5.3 Formas de pago de la adquisición

6. Términos técnicos

6.1 Procedimientos de confidencialidad

6.2 Especificación del canal de comunicación

6.3 Procedimientos para cambios

6.4 Procedimientos para tratamiento de problemas

7. Lista de S&SC a entregar

8. Puntos de control

9. Plazos establecidos

10. Criterios de selección del proveedor

(En la solicitud de propuestas puede que sea conveniente orientar al proponente con respecto a la forma de presentación de la comprobación del cumplimiento de los elementos que serán adoptados para selección del proveedor como, por ejemplo, los tipos de certificados que serán obtenidos para comprobación de experiencia del proveedor, certificados de calificación técnica de los técnicos, forma de explicitar lo que se refiere al cumplimiento de elementos obligatorios, entre otros).

11. Criterios de aceptación del S&SC

11.1 Requisitos funcionales del software

11.2 Requisitos de calidad del software

11.3 Documentación disponible

12. Normas y modelos

13. Responsabilidades del proyecto

14. Riesgos y eventos

(El adquiriente deberá evaluar la conveniencia de incluir este tópico. Deberá explicitarlo en la solicitud de propuestas apenas si los riesgos pueden influenciar las condiciones a ser propuestas por el proveedor).

14.1 - Identificación del riesgo

14.2 - Probabilidad de ocurrencia

14.3 - Impacto en el proyecto

14.4 - Mitigación de los riesgos

14.5 - Plan de contingencia


Anexo C – Propuesta de los proveedores 1. Propuestas

(Identificación, descripción de la empresa, de las capacidades, estimativas y otras características de cada proveedor).

1.1 Identificación del proveedor

1.2 Descripción de la empresa y su histórico

(Descripción de las principales características de la empresa y su tiempo de mercado).

1.3 Clientes actuales y pasados

(Nombre y contacto de los clientes actuales y pasados y los respectivos trabajos realizados).

1.4 Posición financiera

(Descripción de los bienes patrimoniales y monetarios de la empresa).

1.5 Descripción del entendimiento del problema

(Descripción de cómo el proveedor entendió el problema).

1.6 Abordaje técnico

(Descripción de las técnicas a ser utilizadas por el proveedor para resolver el problema).

1.7 Sugerencias de soluciones

(Descripción de las soluciones, propuestas por el proveedor, para resolver el problema).

1.8 Prácticas de calidad

Descripción de las prácticas de calidad empleadas por el proveedor, por ejemplo: seguir procesos definidos, verificación y validación de productos.

1.9 Recursos de equipamiento, herramientas y otros

(Descripción del hardware y software usados, por el proveedor, para resolver el problema).

1.10 Experiencia en la técnica y en el dominio

(Descripción de las experiencias anteriores en el dominio del problema y en las técnicas usadas para resolverlo).

1.11 Experiencia del equipo

(Descripción de la formación y experiencia de cada miembro del equipo).

1.12 Estimativas de precio y plazo

(Establecimiento del precio y plazo para la realización de los servicios).

1.13 Compatibilidad con normas nacionales e internacionales

(Descripción de las normas, estándares y modelos usados por el proveedor).


1.14 Formas de pago

(Descripción de la forma de pago, por ejemplo: número de parcelas, valor de cada parcela, entre otras).

1.15 Aspectos legales, como garantía y licencias

(Descripción de como el proveedor tratará los requisitos establecidos con respecto a la garantía del producto, sus licencias y distribuciones).

1.16 Matriz de cumplimiento de los requisitos

(Relación de los requisitos solicitados e identificación del cumplimiento de cada uno de ellos, con las informaciones adicionales consideradas relevantes. Esta matriz se podrá utilizar para responder a los criterios de selección formulados en la solicitud de propuestas, indicando el nivel de criterio que se está cumpliendo con vistas a obtener la respectiva puntuación).

1.17 Contactos

(Teléfono y e-mail de personas para contacto).


Anexo D – Contrato

CONTRATO DE PRESTACIÓN DE SERVICIO Nº <9999 / 09>

(El Contrato de prestación de servicios muchas veces es elaborado incluyendo apenas cláusulas generales y determinando que la solicitud de propuestas y la propuesta del proveedor pasen a formar parte integrante del contrato. Esta situación es típica para compras públicas, donde los términos del contrato son publicados juntamente con la solicitud de propuestas. Por otro lado, en las organizaciones en que hay mayor flexibilidad para el tratamiento de esta cuestión, el contrato puede ser elaborado a partir de la conciliación entre la solicitud de propuestas y la propuesta del proveedor, introduciendo algunos ajustes posibles a partir del establecimiento de la solución técnica y de gestión a ser adoptada para atender al problema. El modelo a seguir retrata la primera situación, donde la solicitud de propuestas y la propuesta del proveedor servirán como base complementaria de los términos generales relacionados, principalmente por medio de las informaciones relacionadas a seguir).

Informaciones de la solicitud de propuestas:

Requisitos

Términos contractuales

Tipo de contrato a ser empleado

Multas y penalidades

Derechos de distribución, uso y propiedad del software

Garantía del S&SC

Términos Técnicos

Procedimientos de confidencialidad

Especificación del canal de comunicación

Procedimientos para cambios

Procedimientos para tratamiento de problemas

Lista de S&SC a ser entregados

Puntos de control

Plazos establecidos

Criterios de aceptación del S&SC

Requisitos funcionales del software

Requisitos de calidad del software

Documentación disponible

Normas y modelos

Responsabilidades del proyecto

Riesgos y eventos

Identificación del riesgo

Probabilidad de ocurrencia

Impacto en el proyecto


Mitigación de los riesgos

Plan de contingencia

Informaciones de la propuesta del proveedor:

Descripción del entendimiento del problema

Abordaje técnico

Sugerencias de soluciones

Prácticas de calidad

Recursos de equipamiento, herramientas y otros

Experiencia en la técnica y en el dominio

Experiencia del equipo

Estimativas de precio y plazo

Compatibilidad con normas nacionales e internacionales

Formas de pago

Aspectos legales, como garantía y licencias

Matriz de cumplimiento de los requisitos

Términos generales que componen el contrato

Las partes:

La < nombre de la empresa > con sede en la < dirección >, en el municipio de < nombre de la ciudad >, estado de < nombre del estado >, inscrita en el CNPJ bajo el nº <número del CNPJ > e Inscripción Estatal nº < número de la inscripción estatal >, por su representante legal abajo firmado, en adelante designada "CONTRATANTE"; y

La < nombre de la empresa > con sede en < dirección >, en el municipio de < nombre de la ciudad >, estado de < nombre del estado >, inscrita en el CNPJ bajo el nº < número de CNPJ > e Inscripción Estatal nº < número de la inscripción estatal >, por su representante legal abajo firmado, en adelante designada "CONTRATADA".

CONSIDERANDO que la CONTRATANTE y la CONTRATADA firmaron, en < fecha del contrato >, un Contrato de Prestación de Servicios – Desarrollo de Software, RESUELVEN firmar el presente instrumento particular que se regirá por las siguientes cláusulas y condiciones:

1. Vigencia

1.1. El presente Contrato de Prestación de Servicio entra en vigor en < fecha inicio > y termina con la conclusión del objeto definido en la cláusula 2.

2. Objeto

2.1. < Desarrollar o Adaptar > un software para < función del software> y entrenar las personas indicadas por la CONTRATANTE en su utilización.

3. Obligaciones de la contratante

3.1. La CONTRATANTE suministrará a la CONTRATADA, siempre que solicitada, las aclaraciones necesarias al desarrollo del objeto de este contrato.


3.2. La CONTRATANTE asegurará el libre acceso de los técnicos de la CONTRATADA, desde que debidamente identificados, a sus dependencias y a los equipamientos, para los fines de este contrato.

4. Obligaciones de la contratada

4.1. La CONTRATADA se obliga a prestar todos los servicios descritos en la cláusula 2 del presente contrato.

4.2. La CONTRATADA se obliga a proveer, juntamente con el software, su manual de utilización.

4.3. La CONTRATADA se obliga a reparar, sin encargos, a la CONTRATANTE por un período de tres meses a partir de la fecha de la implantación, cualquier problema que el software venga a presentar, en hasta 24 horas después de la notificación de la anormalidad.

4.4. La CONTRATADA se obliga, bajo las penas de la ley, a no revelar por cualesquiera formas de divulgación cualesquiera informaciones, datos, materiales, documentos, especificaciones técnicas o comerciales, innovaciones y perfeccionamientos recibidos de la CONTRATANTE como consecuencia de este contrato, aun después de terminado, obligándose a utilizar tales informaciones única y exclusivamente con el propósito de realizar los servicios objetos de este contrato y solamente con las personas indicadas o de conocimiento de la CONTRATANTE.

4.5. La CONTRATADA cumplirá rigurosamente todas las reglas de seguridad y normas internas vigentes en los establecimientos de la CONTRATANTE durante la ejecución de los servicios.

4.6. La CONTRATADA utilizará adecuadamente todos los bienes que se le hagan disponibles por la CONTRATANTE para la ejecución de los servicios.

4.7. La CONTRATADA deberá garantizar a la CONTRATANTE por medio de un contrato de mantenimiento, el soporte del producto después de su implantación, así como hacerle disponible sus nuevas versiones.

5. Remuneración de la contratada

5.1. La CONTRATANTE pagará a la CONTRATADA el valor correspondiente a cada fase del proyecto de desarrollo del software, mediante la presentación por parte de la CONTRATADA, de los productos generados en cada fase, conforme detallado abajo.

< Fase1 – Proyecto Lógico del nuevo sistema >

Productos:

1....

2....

3....

Valor de esta cuota R$ 9,999.00

< Fase2 –...... >

Productos:

1....


2....

3....

Valor de esta cuota R$ 9,999.00

5.2. Forma de pago. El pago previsto en la cláusula 5.1 del presente contrato, será efectuado mediante la presentación por la CONTRATADA de la correspondiente Nota Fiscal, después la validación por parte de la CONTRATANTE del producto entregado.

6 Consideraciones generales

6.1. Los eventuales viáticos y otros costos originados por actividades pertinentes a los servicios serán de responsabilidad y pagados por la CONTRATANTE.

6.2. Además de las cláusulas ya relacionadas, son partes integrantes de este contrato los términos establecidos en los documentos “Solicitud de propuestas” y “Propuesta del proveedor”.

Y por estar así, justas y contratadas, firman la presente Descripción del Proyecto en dos copias idénticas, y para un único efecto, en la presencia de los testigos abajo.

< Ciudad, XX/XX/XXXX >.


Anexo E – Registro de revisiones

1. Evaluación de procesos y software

(Relación conteniendo los productos de trabajo y los procesos del proveedor evaluados por el adquiriente durante el proceso de adquisición; la fecha de la evaluación; el método de evaluación utilizado, por ejemplo: validación, auditoria, revisión conjunta, entre otros; el responsable por la evaluación; y su resultado como: correcto, parcialmente correcto e incorrecto).

Nombre del producto /Proceso

Fecha de la Evaluación

Método de la Evaluación Responsable Resultado

2. Evaluación de los aspectos de gestión

(Descripción de la evaluación de los aspectos de gestión del contrato)

2.1 Situación actual del presupuesto

(Descripción de cuánto ya fue gastado y cuánto todavía se tiene disponible para el proyecto).

2.2 Situación del cronograma

(Descripción del tiempo gastado hasta el momento y del plazo del proyecto).

2.3 Dependencias críticas

(Descripción de aspectos que se necesitan analizar, por ejemplo: nuevos requisitos, cambios de requisitos, tarifas extras, entre otros).

2.4 Riesgos identificados (para cada riesgo)

(Descripción de los riesgos y sus consecuencias).

2.4.1 – Identificación del riesgo

(Descripción del tipo de riesgo, por ejemplo: atraso en el cronograma, falta de recursos financieros y humanos, falla de interpretación de los requisitos del software, entre otros).

2.4.2 – Fecha de la constatación del riesgo

(Descripción del día, mes y año en que el riesgo fue constatado).

2.4.3 – Probabilidad de ocurrencia

(Descripción de la probabilidad que ocurra el riesgo, por ejemplo: alta, mediana o baja).


2.4.4 - Impacto en el proyecto

(Descripción de los aspectos relevantes que pueden afectar al proyecto caso de que el riesgo ocurra, por ejemplo: parar el proyecto, falta de verbas para otras actividades, entre otros).

2.4.5 – Mitigación de los riesgos

(Descripción de los procedimientos para amenizar o eliminar la ocurrencia del riesgo).

2.4.6 - Plan de contingencia

(Descripción de los procedimientos que se deberán tomar en el caso de que el riesgo se realice).

2.5 Problemas encontrados

(Descripción de situaciones indeseables, por ejemplo: problemas de relacionamiento entre los integrantes del equipo).

3. Acciones correctivas

(Descripción de las acciones correctivas como consecuencia de discrepancias encontradas en las evaluaciones de los productos, de los procesos y de los aspectos gerenciales).

Descripción del Problema

Fecha de la Identificación

Solución Propuesta


Anexo F – Aspectos relevantes en la adquisición de S&SC

F.1 Visión general

El principal objetivo de esta guía es que las organizaciones que pretendan obtener mejoras significativas en sus adquisiciones de S&SC, puedan definir un proceso que se pueda implementar. La parte central de este documento, principalmente la sección 4, está orientada hacia este propósito. Por otro lado, se entiende que las organizaciones podrán tener dificultades para transitar de un proceso existente, a veces sin una estructura definida, para un modelo más formal y organizado. En este sentido, este anexo pretende ofrecer algunas orientaciones para adquiridores de S&SC que puedan ser útiles durante el estado actual de estas organizaciones, durante el período de transición y después la implementación del nuevo proceso.

F.2 Problemas comunes en la adquisición

Prácticas de gestión ineficaces son las principales causas de problemas en las adquisiciones de S&SC. Los problemas son caracterizados por la frecuente incidencia de fallas en la adquisición de grandes sistemas de software y por el crecimiento de los esfuerzos para mantener el costo, el plazo, y para lograr los objetivos definidos. Una organización inmadura en sus procesos de adquisición de S&SC puede llevar el proyecto al fracaso, lo mismo puede ocurrir por la contratación de una organización con proceso de desarrollo de software inmaduro.

Es importante resaltar que la extensión de los problemas es proporcional a los riesgos que representan la no conclusión del proyecto, la operación del sistema no conforme con los requisitos establecidos, los riesgos representados para vidas humanas debido a su funcionamiento inadecuado y las pérdidas financieras debido a fallas en su implementación.

Los problemas apuntados como los más comunes durante el proceso de adquisición de S&SC, compilados en [ALVES, 2004] son:

• Costo del desarrollo mayor que el presupuesto previsto;

• Atraso en el plazo de entrega;

• Resultados insatisfactorios con relación a las expectativas del usuario;

• No intervencionismo: el cliente no es una parte activa del proyecto después de la firma del contrato;

• Burocracia: exceso de burocracia administrativa para supervisar el contrato y poco enfoque en los aspectos técnicos del proyecto;

• Alcance volátil: el cliente adiciona y cambia el alcance y la funcionalidad del proyecto con el trabajo en curso y con plazos y recursos limitados;

• Fragmentación: miembros de los equipos del cliente y del Contratado son retirados de los proyectos aleatoriamente;

• Preciosismo: requisitos e imposición de soluciones complejas en lugar de soluciones técnicamente simples;

• Ingeniería: el cliente dice al proveedor CÓMO hacer su trabajo, y no CUÁL es el trabajo;

• Indicadores: las medidas de progreso y de desempeño son cualitativas, y no cuantitativas. Los indicadores de niveles de desempeño son pobres;


• Comando: con muchos jefes, las decisiones no son tomadas a tiempo;

• No envolvimiento del usuario final: el punto de vista del usuario final no es incorporado en la funcionalidad4 y usabilidad5 del producto;

• Requisitos pobres: el cliente proporciona al Contratado un conjunto de requisitos incompleto y sin validación;

• Adquisición incompetente: fallas en el entendimiento de las necesidades particulares de la adquisición de software;

• Falsas promesas: el personal de marketing del proveedor hace promesas, al cliente, que el equipo técnico no puede cumplir;

• Falta de disciplina: proceso de desarrollo ad hoc, cuando el plazo de entrega del producto está próximo;

• Expectativas no realistas: cronogramas impracticables y desconsideración de las limitaciones de las tecnologías usadas;

• Recurso inadecuado con respecto a suministro financiero, equipo, herramientas y equipamientos;

• Ausencia de apoyo de la alta gerencia de la empresa;

• Ausencia de objetivos claros, conduciendo a los miembros del proyecto para direcciones no uniformes (no alineamiento de objetivos);

• Comunicación ineficiente: ausencia de un canal de comunicación efectivo, haciendo que las informaciones no lleguen hasta las personas a tiempo hábil para toma de alguna medida;

• Incompetencia: ausencia de perfil técnico y de liderazgo apropiados; y

• Atritos, comprometiendo la cooperación de una de las partes involucradas.

Por otro lado, algunos autores, compilados en [ALVES, 2004], presentan una lista de problemas que son considerados clásicos durante el proceso de adquisición de S&SC. Obsérvese que algunos de estos problemas son los mismos citados anteriormente.

Los problemas considerados clásicos son:

• Costo mayor que lo previsto;

• Alto costo de mantenimiento;

• Descumplimiento de cronograma;

• Relación pobre entre cliente y proveedor;

• Productos inexequibles;

• No atendimiento de las necesidades del usuario;

• No atendimiento de las expectativas del usuario;

• No cumplimiento de los requisitos especificados;

4 Capacidad del producto de software de proveer funciones que atiendan necesidades explícitas e

implícitas, cuando el software esté siendo utilizado bajo condiciones especificadas. [ISO/IEC 9126-1]. 5 Capacidad del producto de software de ser comprendido, aprendido, operado y atractivo para el usuario,

cuando usado bajo condiciones especificadas. [ISO/IEC 9126-1].


• Dificultades de personalización del software;

• Pérdida de control del proyecto;

• Falta de acompañamiento del proyecto;

• Falta de visibilidad de los procesos de Subcontratado;

• Ciclo de desarrollo muy largo;

• Exceso de re-trabajo;

• Falta de habilidad para previsión de problemas;

• Dificultad en la prevención de defectos;

• Baja disponibilidad de recursos humanos; y

• Alta rotación del personal.

Para mitigar los problemas apuntados arriba, se proponen las siguientes acciones que deben estar asociadas al proceso de adquisición definido en esta guía:

• Definir y comunicar el objetivo y la visión del proyecto a todos los involucrados;

• Designar al Gerente de Adquisición que, en última instancia, tiene la responsabilidad por el éxito del proceso de adquisición;

• Tener clara la función del Promotor del proyecto que es colaborar para su andamiento, definir los límites del proyecto, proveer el presupuesto adecuado y estable y conducir el proyecto de forma positiva o, si es necesario, proveer su cancelación;

• Adaptar y personalizar los abordajes de adquisición y estrategias de acuerdo con las características del proyecto;

• Evitar el exceso de trabajo administrativo, asegurando, sin embargo, los siguientes elementos: requisitos y compromisos debidamente registrados; documentación de las decisiones importantes; documentación de las causas y motivos de las decisiones tomadas; mediciones cuantitativas del progreso del proyecto, de la calidad y de los cambios en los requisitos;

• Definir, claramente, el objetivo a ser logrado. Obtener requisitos válidos, estables, completos y viables, siempre que sea posible. Es importante, también, definir el alcance, para que tanto el cliente como el contratado sepan cuando los objetivos fueron logrados y cuando el contrato necesita de modificaciones y renegociaciones;

• Definir, para cada requisito, como será la evaluación para la certificación de su implementación;

• Asegurar que el usuario final sea involucrado en la definición de los requisitos y en la evaluación del producto;

• Informar al Contratado LO QUÉ está siendo Contratado, y no CÓMO implementar el objeto de la contratación. Efectuar una revisión conjunta de los requisitos antes del inicio del desarrollo, con la finalidad de eliminar ambigüedades y mal entendidos;

• Seleccionar el Contratado cuidadosamente. El Contratado que ofrezca el menor precio y la programación de plazo más optimista no siempre es la mejor opción.


Ninguna práctica de gestión puede mejorar el desempeño mediocre de una contratación equivocada;

• Crear una cultura de relación amigable con el Contratado, basada en la confianza, respeto y siempre buscando el beneficio mutuo. Las dos o más partes involucradas deben estar conscientes de que el éxito del proyecto es de responsabilidad de todos los asociados participantes. Las partes deben trabajar como un equipo, resolver los problemas conjuntamente y evitar la dinámica de mutua atribución de culpas;

• Establecer un canal efectivo de comunicación y tentar derrumbar las barreras existentes entre las personas y los departamentos de las organizaciones involucradas en el proyecto. Asegurar el entendimiento mutuo;

• Evitar buscar siempre obtener ventajas del Contratado. Crear una situación de ganancias mutuas. Cuidar para que el contrato sea benéfico y traiga ventajas para todas las partes involucradas, de modo que la firma y el comprometimiento sean confortables para todas las partes;

• Esperar siempre lo mejor, pero actuar de forma proactiva y prepararse para las eventualidades. Discutir, en conjunto con lo(s) Contratado(s), los riesgos posibles y modos de mitigación;

• Escoger siempre las personas más competentes posibles, entrenarlas y organizar su plan de trabajo. Suministrar la asistencia y los recursos necesarios;

• Planificar el mantenimiento esperado del software, identificar la forma de soporte y mantenimiento, antes de la elaboración de la solicitud de propuestas;

• Evaluar los resultados del desarrollo del software lo antes posible y con frecuencia compatible con su porte, antes de la evaluación final para aceptación del producto. Esas medidas minimizan la posibilidad de obtener un software que no atienda las expectativas del usuario;

• Efectuar verificaciones periódicas. Tomar las providencias necesarias, en el caso de que alguna de las siguientes cuestiones no sea respondida de forma satisfactoria:

� El software que está siendo adquirido es el más apropiado?

� El software ESTÁ siendo adquirido de la forma apropiada?

� El contratado está desarrollando el SOFTWARE APROPIADO?

� El contratado está desarrollando el software DE FORMA APROPIADA?

• Ser realista y evaluar nuevamente las expectativas, a medida que el aprendizaje sobre el dominio del problema y su viabilidad técnica sea ampliada con el progreso del proyecto. Las primeras estimaciones y especificaciones de los cuatro parámetros citados abajo, cambiarán, en algún grado, durante el proyecto:

� Plazo de entrega;

� Costo del desarrollo;

� Alcance del software; y

� Calidad del software.


Observando cuidadosamente los posibles problemas apuntados arriba y las acciones recomendadas para sus respectivas soluciones, aumentan las posibilidades de que el proyecto de adquisición sea finalizado en el plazo establecido, con los costos previstos y con la implementación de las funcionalidades especificadas en los requisitos.

F.3 Adquisición de software libre/código abierto (SL/CA)

La dinámica del SL/CA es el fenómeno más reciente en el escenario de la informática, y que ultrapasa sus límites técnicos, generando un nivel de interés semejante al de los primeros momentos de la Internet comercial. El concepto de software libre surgió en 1983 y los más de 20 años de evolución permitieron al SL/CA avanzar en diversos aspectos: técnico, político-estratégico, de adecuación a las necesidades de los usuarios, calidad, seguridad, entre otros. Esta evolución se debe a un esfuerzo colectivo internacional involucrando profesionales, usuarios e interesados que se dedican al perfeccionamiento, discusión, desarrollo, compartición e integración de SL/CA. Esta dinámica envuelve el desarrollo de software, la acción de difusión, estímulo y apoyo al uso de SL/CA llegando hasta una visión y acción empresarial marcadamente distinta de la actualmente adoptada por las empresas hegemónicas del sector de software.

De forma resumida, se entiende por SL/CA todo software que ofrece al usuario, por medio de su esquema de licenciamiento6, la libertad para uso, reproducción, modificación y redistribución de sus códigos fuente. También es importante destacar que el modelo de desarrollo y el de disponibilidad del software son específicos del SL/CA.

Dos denominaciones conviven con esta definición básica: la de software libre y la de software de código abierto. Los términos son la traducción directa de los utilizados en ingles: "free software" y "open source software". Estas denominaciones, que se pueden atribuir al software, contienen semejanzas y diferencias. Ambas significan cambios de paradigmas en la informática, sea del punto de vista del usuario final, del productor de software o de otros agentes directa o indirectamente relacionados.

La principal diferencia entre estas denominaciones está en el enfoque que sus proponentes y defensores dan al concepto de software libre/código abierto. Mientras que las ideas de software libre están más vinculadas a las cuestiones de garantía y perpetuación de las libertades citadas, las de código abierto están más ligadas a cuestiones prácticas de producción y negocio, como la agilización del desarrollo del software por las comunidades abiertas.

En estudios realizados, se percibió que el modelo de disponibilidad del SL/CA puede servir de base para la generación de negocios. Sin embargo, en función de las propias características del SL/CA y, en especial, de su modelo de disponibilidad, la "comercialización" de este no es idéntica a la de un software propietario.

En función de este modelo, al realizar negocios con SL/CA el cliente/usuario desembolsará valores que están vinculados directamente al trabajo prestado y no al número de licencias adquiridas7. Además de esto, la libertad para escoger el proveedor

6 Legalmente, la forma como un usuario puede "relacionarse" con un software es definida a través de

una licencia de uso, que es escrita/definida/escogida por el productor del software, y que debe ser aceptada y respetada por el usuario. La legislación brasileña trata de este asunto a través de la ley nº 9.609, de 19/02/1998, artículos 9º e 10º.

7 U otra variante de licenciamiento de software propietario, comentada en nota anterior.


de los servicios también es una característica apreciada por los usuarios, puesto que el usuario posee su copia del código fuente del software y puede contratar cualquier proveedor de los servicios para los trabajos deseados.

Se percibe entonces que también es incorrecta la percepción de que SL/CA es software gratis, sin costos. Los costos existen, sin embargo están asociados intrínsecamente a los servicios y no al producto. En otras palabras, los "proveedores de SL/CA" son prestadores de servicios que, como resultado de sus esfuerzos (de programación, adaptación, integración, evaluación de opciones, entre otros) presentan un sistema libre, listo para uso por los contratantes o realizan todavía tareas satélites (pero no menos importantes) que permitirán al contratante (o a los beneficiarios) usufructuar del sistema.

Con estas características, se evalúa que el SL/CA permite crear modelos de negocio diferenciados de los que se practican actualmente en la industria de software, lo que puede representar la generación de nuevas oportunidades de negocio y la abertura de nuevos mercados, con la repercusión directa en el mercado de trabajo. Algunas empresas centradas en SL/CA adoptan estrategias múltiples para obtener el retorno necesario para sus actividades. Entre estas estrategias están los ya citados contratos de soporte y mantenimiento, consultoría y cursos de entrenamiento y también formas más sofisticadas (aplicables en algunos casos) como contratos de alianzas, venta de utilidades accesorias, equipamientos y también literatura asociada.

Aunque el fenómeno SL/CA sea reciente y esté en la fase de construcción tecnológica, con varios atores involucrados en el proceso contribuyendo para que ocurra tal conclusión, se puede observar que algunas características ya están suficientemente delineadas.

Ya es posible observar que existe un abordaje del SL/CA del punto de vista de producto, que nos permite comprender los conceptos fundamentales relacionados al software en sí, del punto de vista de proyecto de SL/CA que es una organización virtual dedicada al mantenimiento de un producto de SL/CA y del punto de vista de Proceso de Desarrollo, con prácticas y conceptos establecidos.

Considerando aunque existan modelos de negocio ya establecidos para la relación cliente y proveedor de SL/CA, se puede concluir que ya existe oferta y demanda por S&SC en SL/CA.

Ante el escenario expuesto, es importante que las organizaciones al considerar la adquisición o suministro de S&SC en un modelo de SL/CA, se preocupen por realizar las debidas adaptaciones y cambios en sus procesos de adquisición, de modo que estos puedan acomodar las características particulares de esta nueva forma de suministro y adquisición.

Para más informaciones sobre las cuestiones relacionadas al SL/CA, se puede averiguar en la Open Source Initiative (OSI), disponible en http://www.opensource.org, Free Software Foundation (FSF), disponible en http://www.fsf.org y en Brasil en http://www.softwarelivre.org.

F.4 Adquisición y la Ingeniería de Software basada en componentes

Un posible abordaje para adquisición de software está relacionado a la utilización de componentes. Aún que sea posible personalizar el proceso descrito en esta guía, con el objetivo de adquirir componentes de software, es importante que se lleven en cuenta las siguientes consideraciones:


De acuerdo con [SAMETINGER, 1997], el componente de software debe: ser autosuficiente, ser identificable, tener funcionalidad (describir y/o desempeñar funciones específicas), tener interfaces, tener documentación (indispensable para su reutilización) y tener status de reutilización definido.

Otra definición, que auxilia al entendimiento del componente como un producto, en una visión comercial, siendo desarrollado por productores (proveedores) y adquirido por consumidores (productores), como un artefacto para composición de otros sistemas, es colocada por [D’Souza, 1998]: “un componente (código) es un paquete coherente de implementación que se puede desarrollar y distribuir independientemente, provee interfaces explícitas y bien especificadas, define las interfaces que necesita de otros componentes, y puede combinarse con otros componentes por la configuración de sus propiedades, sin la necesidad de cambios”.

Un nuevo desafío para el desarrollo basado en componentes es el llamado “problema de la confianza en el componente”. El problema está en la dificultad de saber si el componente hace lo que realmente debería hacer. Un consumidor muchas veces necesita decidir entre varios componentes, de proveedores distintos, por aquel adecuado a la composición del nuevo sistema.

El proveedor de un componente puede medir las características de calidad de un componente como una unidad, pero no puede prever todos sus futuros contextos de reutilización y asegurar su adecuación. Esta cuestión es especialmente más difícil mientras se trata de componentes desarrollados por terceros o de componentes comercializados (COTS - Commercial Off-The-Shelf), los cuales normalmente son distribuidos sin el código fuente. Todavía, esta cuestión también está presente para componentes desarrollados en la propia organización, donde la falta de documentación y la dificultad de comunicación de los equipos de desarrollo pueden producir un efecto semejante.

La garantía de éxito del desarrollo basado en componentes depende de la calidad de los componentes de software. Los productores necesitan saber si el componente es confiable y adecuado al sistema [VOAS, 1998]. Muchos componentes de software son ofrecidos como “cajas negras”, como objetos ejecutables, cuyas licencias no permiten el acceso a los códigos fuente (o licenciados a precios prohibitivos). Entonces, como saber si un determinado componente es adecuado para integrar un sistema basado en componentes? Como prever si realizará la función necesaria al encajarse en la arquitectura? O, más aún, si reúne los requisitos deseados con la calidad adecuada?

Si consideramos componentes como paquetes de software, es posible utilizar los conceptos contenidos en la ISO/IEC 121198 que trata de sus requisitos de calidad y prueba. Estos conceptos pueden ser de gran valor para los consumidores de componentes o paquetes de software. Tratan de aspectos importantes que se pueden abordar durante su adquisición. Por lo tanto, al adquirir un componente o paquete de software el consumidor debe verificar:

1 - Descripción del producto: un documento que contiene las propiedades y el principal propósito del paquete de software o componente, auxiliando al comprador en la evaluación de su adecuación antes de adquirirlo. Esta descripción deberá contener:

8 Esta norma fue actualizada por la norma internacional ISO/IEC 25051, sin embargo, los conceptos relacionados en esta sección son semejantes y fueron mantenidos para mantener la compatibilidad con el texto relacionado a las referencias bibliográficas citadas.


• Identificación única del documento, por ejemplo: Descripción Funcional o Informaciones del Producto;

• Identificación del producto conteniendo por lo menos el nombre y su versión o fecha;

• El nombre y la dirección de por lo menos uno de los proveedores;

• Tareas que pueden realizarse con el producto;

• Requisitos del sistema, como: unidad de procesamiento, tamaño de la memoria principal, tipos y tamaños de almacenamientos periféricos, equipamientos de entrada y salida, entorno de red, software del sistema operativo y otros tipos de software;

• Interfaces con otros productos;

• Elementos a ser entregados;

• Información de instalación (si puede o no ser llevada a cabo por el comprador);

• Información de soporte (si habrá o no soporte para la operación del producto);

• Información de mantenimiento (si habrá o no mantenimiento del producto y lo que será incluido);

• Visión general de las funcionalidades del producto, los datos necesarios y las facilidades ofrecidas;

• Valores limites soportados por el producto;

• Informaciones de seguridad para prevenir acceso no autorizado a programas o datos;

• Informaciones de fiabilidad, como: verificar si las entradas son plausibles, protección contra errores de usuarios y recuperación de errores;

• Informaciones de usabilidad, como el tipo de interfaz usada con el usuario, conocimiento requerido para el uso del producto, si el producto puede ser adaptado por el usuario y en qué condiciones, y procedimientos usados para la protección contra copias;

• Informaciones con respecto de la eficiencia del producto, como tiempo de respuesta;

• Informaciones con respecto a la mantenibilidad9; y

• Informaciones con respecto a la portabilidad10.

2 - Documentación del usuario: un documento conteniendo las informaciones necesarias para el uso del producto. Todas las funciones

9 Capacidad del producto de software de ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptaciones del software debido a mudanzas del entorno e de sus requisitos o especificaciones funcionales. [ISO/IEC 9126-1]. 10 Capacidad del producto de software de ser transferido de un ambiente para otro [ISO/IEC 9126-1].


citadas en la descripción del producto y sus formas de accionamiento por el usuario deben estar descritas en este documento. Este documento debe ser completo, correcto, consistente e inteligible.

3 – Informaciones relativas a programas y datos: si la instalación se pudiera realizar por el comprador, entonces es necesario un manual de instalación. Los programas y los datos deben corresponder y no presentar contradicciones con la descripción del producto y la documentación del usuario.

4 – Instrucciones para prueba: estas instrucciones describen cómo se debe probar un producto en relación a los requisitos de calidad. Estas pruebas incluyen tanto la prueba de las propiedades requeridas como la prueba de las propiedades prometidas por la descripción del producto. Incluyen la prueba de inspección de los documentos que son parte del producto como: descripción del producto, documentación del usuario, programas y datos, así como las pruebas de caja negra para evaluar el comportamiento de sus programas y datos.

La calidad de componentes de software es fundamental para el éxito de aplicaciones basadas en componentes.

Según [SIMÃO, 2002], las características y subcaracterísticas de calidad abordadas por la ISO/IEC 9126-1 también se pueden utilizar como metas a ser logradas en el desarrollo, en la selección y en la adquisición de componentes.

Es importante resaltar, para aquellos que desean adquirir componentes para desarrollar software con reutilización, la existencia de la IEEE Std 1517:1999 como una norma específica del desarrollo para reutilización y que es una extensión de la ISO/IEC 12207.


Anexo G – Funciones en el proyecto de adquisición

G.1 Visión general

Un buen equipo compuesto por personas con experiencia y eficientes es la clave para el éxito de un proyecto. Los proyectos de adquisición de software poseen diferentes características. Algunos proyectos son pequeños, de rápida finalización y de fácil comprensión, mientras que otros tienen características opuestas. Cada organización debe desarrollar su propia manera de trabajar, y cada proyecto debe considerar sus propias metodologías, llevando en cuenta la cultura, la posición, el grado crítico y la tecnología disponible.

Para conseguir un proceso de adquisición efectivo, que presente buenos resultados, es necesario que se emplee un nivel adecuado de formalidad de los procesos, de acuerdo con las características del proyecto en cuestión.

Cada proyecto, dependiendo de sus características, presenta un flujo que se debe gestionar por el proceso de gestión de la adquisición de S&SC. Ese flujo representa la arquitectura que se deberá implementar cuando el proyecto de adquisición entre en operación.

Para la implementación de esta arquitectura, es necesario que algunas funciones sean ejecutadas y que personas sean designadas para cada una de ellas dependiendo del porte del proyecto y de su complejidad. En este anexo será presentada una posible clasificación de los diferentes tipos de funciones necesarias para el éxito de un proyecto de adquisición de S&SC. Nótese que una persona puede ejecutar más de una función.

Las funciones se pueden dividir en categorías, en verdad cuatro categorías, siendo: funciones del promotor, funciones de gestión, funciones de asistencia o soporte y funciones ejecutivas, dependiendo de sus características conforme definidas abajo:

• Funciones del promotor son responsables por la obtención de suministro financiero para el proyecto y tiene poder para decidir sobre su prosecución o cancelación. Las funciones del promotor, en este contexto, son: promoción, colaboración con el cliente y gestión de producto;

• Funciones de gestión son funciones de planificación, gestión, acompañamiento y administración del proyecto. Las funciones de gestión son: gestión de la adquisición, gestión técnica, gestión de contrato y administración;

• Funciones de asistencia o soporte son ejecutadas por diferentes especialistas; son responsables por orientaciones específicas y soporte al contratado durante la evolución del proyecto. Las funciones de asistencia o soporte son: especialista en adquisición, especialista técnico, especialista en el dominio del producto, especialista en asuntos legales, traductor, usuario final, equipo de mantenimiento y soporte, verificación y validación independiente, ingeniería de sistemas y asistencia técnica;

• Funciones ejecutivas son las funciones ejercidas por parte del contratado. Las funciones ejecutivas son: contratado, colaborador contratado, subcontratado y proveedor complementario;


G.2 Funciones del promotor

Las funciones del promotor son ejecutadas por personas que representan a la organización y tienen poder para iniciar y cancelar el proyecto de adquisición. Las funciones del tipo promotor son: promotor, cliente colaborador y gerente de producto.

G.2.1 Promotor

Inicia y acompaña el proyecto de adquisición con entusiasmo. Tiene poder de cancelar el proyecto, caso de que su costo sea mayor que el beneficio que agregará a la organización después de su finalización. Las responsabilidades del promotor del proyecto son: definir y comunicar los objetivos y la visión del proyecto; proveer un presupuesto adecuado y colocar los límites financieros y otros para el proyecto; y escoger un gerente que tenga responsabilidad por el éxito del proyecto. El promotor debe ser muy cuidadoso y no intervenir en la forma como el gerente escogido ejecuta la gestión del proyecto.

G.2.2 Cliente colaborador

Un proyecto de adquisición puede ser un proyecto de varios proveedores o co-proveedores, con un gran número de organizaciones-cliente involucradas. El cliente colaborador es el promotor de otro proyecto cuya colaboración necesita ser coordinada con los otros promotores.

G.2.3 Gerente de producto

En algunos casos, el software es parte de un grande sistema en adquisición, donde el gerente de producto ejecuta la función de promotor ante el sistema.

G.3 Funciones de gestión

El acompañamiento y la administración de los procedimientos del proyecto de adquisición de software son funciones ejecutadas por personas del cliente, responsabilizadas por la gestión. Los diferentes tipos de funciones de gestión son: gerente de adquisición, gerente técnico, gerente de contrato y administrador.

G.3.1 Gerente de adquisición

Es indicado por el promotor y es responsable por el éxito del proyecto. El gerente de adquisición tiene la palabra final sobre la ejecución del proyecto. Sus tareas y responsabilidades son: adaptar y personalizar la estrategia de adquisición de acuerdo con las características del proyecto; planificar el proyecto y ejecutar conforme lo planificado; rehacer el planificación durante el progreso del proyecto; gestionar los riesgos y resolver los problemas; contratar y organizar las personas del equipo de adquisición; ejecutar las actividades de entrenamiento y formación de equipo; motivar e incentivar personas, tornar el camino de cada elemento más fácil y apoyar al equipo; seleccionar y prestar soporte a los proveedores; negociar y firmar acuerdos con el contratado y con los contratados de soporte; gestionar la relación entre el contratado y la organización, tomando como referencia valores tales como moral, confianza, comunicación y colaboración; dejar claro al proveedor cual es la extensión del software, de modo que se asegure que tanto el proveedor como el gerente puedan identificar cuando es logrado; gestionar el presupuesto del proyecto dentro del límite impuesto por el promotor; coordinar el trabajo para el acompañamiento del progreso del proyecto; tornar el promotor consciente de esos resultados; y ejecutar verificaciones periódicas. Deberá también ejecutar las acciones necesarias en caso de que las respuestas no sean satisfactorias: El software correcto está siendo adquirido? El software está siendo adquirido en la forma correcta? El proveedor está desarrollando el software de forma


correcta? Debe, todavía, hacer el balance entre el plazo de entrega, el costo total, el alcance del producto, la calidad del producto, para verificar los desvíos con relación a las estimativas y a las especificaciones, cuando ocurran; coordinar el trabajo de evaluación y aceptación del producto; y preparar el soporte posterior al contrato y el mantenimiento del producto.

G.3.2 Gerente técnico

Para grandes proyectos donde existe demanda de alta calidad y técnicas complejas, por ejemplo, software de misión crítica, el gerente de adquisición puede delegar las responsabilidades por los requisitos y calidad al gerente técnico.

G.3.3 Gerente de contrato

Para proyectos con muchas organizaciones involucradas, o proyectos donde la administración del contrato es grande, el gerente de adquisición puede delegar las responsabilidades por la gestión del contrato al gerente de contrato.

G.3.4 Administrador

El límite del administrador depende del tamaño y del tipo del proyecto. Se debe tomar cuidado para asegurar una buena administración, y no burocratizar innecesariamente las funciones administrativas. Un miembro del equipo de adquisición ejecuta la función de administración, pero en algunos proyectos debe responsabilizar una persona específica por la función. Las responsabilidades de la función del administrador incluyen el mantenimiento de la configuración y gestión de cambios en los documentos del proyecto, como el contrato, la especificación de requisitos, planificación del proyecto, lista de riesgos y otros; documentar y archivar las correspondencias, tiempo de reunión y decisiones; administrar el pago y dar soporte al contratado; y documentar y archivar las medidas de progreso, calidad y cambios de requisitos.

G.4 Funciones de asistencia o soporte

La función de asistencia es ejecutada por diferentes especialistas y contratados de soporte, que pueden asistir y orientar la gestión, la dirección y las funciones ejecutivas. Las funciones son: especialista en adquisición, especialista técnico, especialista de dominio, especialista legal, traductor, usuario final, equipo de mantenimiento y soporte, verificación y validación independiente, ingeniería de sistemas y asistencia técnica.

G.4.1 Especialista en adquisición

Un especialista en adquisición puede ser empleado para orientar cómo planificar y ejecutar un proyecto de adquisición, definir el vehículo contractual, seleccionar y entrenar el equipo en gestión de adquisición de software.

G.4.2 Especialista técnico

Un especialista técnico puede ser usado para evaluar los requisitos y hacer una estimativa independiente de costo y plazo. El especialista técnico puede ser usado para revisar los documentos técnicos y auditar el conocimiento técnico y la capacidad del contratado. El contratado puede emplear al especialista técnico para áreas en las cuales no tenga competencia establecida.

G.4.3 Especialista de dominio

El especialista de dominio no es, necesariamente, un especialista técnico, pero conoce profundamente el campo en el cual el software será usado. El especialista de dominio puede ser empleado para desarrollar y validar los requisitos del software. Otra tarea


para ese especialista puede ser desarrollar el entrenamiento para el usuario del software.

G.4.4 Especialista legal

El especialista legal es esencial para aconsejar cómo el contrato se debe escribir e informar cuales son las leyes y reglamentos vigentes y otros asuntos concernientes al proyecto, como derecho de propiedad intelectual, patentes, licencias, garantías, derecho de reproducción y otros. El especialista legal puede, también, auxiliar durante una disputa y rompimiento con el contratado. El empleo de un especialista legal con conocimiento específico en el área de software, especialmente en proyectos internacionales, es fundamental para el proyecto de adquisición.

G.4.5 Traductor

El traductor es una función que puede ser ejecutada por una persona capaz de traducir términos técnicos en términos legales, y viceversa. Esta función se puede utilizar en la especificación de requisitos y transferencia de requisitos al equipo técnico del contratado. La persona debe tener el perfil para traducir las necesidades del cliente en algo que el contratado pueda usar para construir el sistema.

G.4.6 Usuario final

El usuario final es la razón de la existencia del software, excepto si el software no interactúa directamente con usuarios humanos. De esa forma, es imperativo envolver al usuario final en la especificación de los requisitos del software, en la evaluación de la interfaz con el usuario y en la evaluación de las funcionalidades del producto de software.

G.4.7 Equipo de mantenimiento y soporte

Tiene como tarea principal mantener el software en ejecución, hacer evoluciones, corregir defectos y adicionar nuevas facilidades, así como suministrar soporte técnico al usuario final. Es importante solicitar las sugerencias de los equipos de mantenimiento y soporte sobre los requisitos necesarios al software, para que sea de fácil mantenimiento y verificación de defectos. También se deben involucrar en la evaluación de las capacidades de mantenimiento, verificación y resolución de defectos del software y en la revisión de la documentación, para verificar si contienen todas las informaciones necesarias para su trabajo. Lo antes posible, se debe involucrar al equipo de mantenimiento y soporte en el proyecto, para promover y facilitar la discusión de cómo la organización de mantenimiento y soporte se puede organizar, para proporcionar una transición suave del software, en el momento de su entrega para mantenimiento y soporte, con el respectivo mantenimiento de la gestión de configuración. Esta función puede ser ejecutada por la propia organización o puede ser realizada por terceros.

G.4.8 Verificación y validación independiente

Función que el cliente puede contratar para la ejecución de una evaluación técnica profunda del software entregado. Se recomienda este expediente cuando el software afecta la salud pública o la vida de personas, o cuando se tiene un gran volumen de dinero envuelto y se puede perder por el funcionamiento inadecuado del producto. La verificación y validación independiente pueden aumentar el costo del proyecto significativamente.


G.4.9 Ingeniería de sistemas y asistencia técnica

Cuando el cliente o el proveedor no poseen el recurso adecuado para una determinada especialidad, es necesaria una contratación suplementar para suplir esa deficiencia. De esa forma, la empresa contrata la ingeniería de sistemas y asistencia técnica. Este servicio puede comprender desde la planificación del proyecto hasta la prueba, mediciones y aseguramiento de la calidad. Debe considerarse el empleo de contratados para las siguientes áreas: riesgos técnicos, pruebas independientes, gestión de soporte e integración.

G.5 Funciones ejecutivas

Estas funciones son ejecutadas por representantes del contratado, o sea, quien está desarrollando el producto de software en cuestión. Ellas son: contratado, colaborador contratado, subcontratado y proveedor.

G.5.1 Contratado

El contratado puede ser único o el primero contratado, en el caso de uso del trabajo de colaboración de varios contratados. Se debe escoger cuidadosamente al contratado, pues, no siempre es la mejor opción, el contratado con la oferta de precios más baja y las programaciones más optimistas de plazo y costos. Ninguna práctica de gestión puede compensar el perjuicio de un contratado inadecuado. Una vez seleccionado, se debe ver al contratado como un miembro del equipo, y no como un adversario. Las responsabilidades del contratado son:

• Desarrollar y entregar el producto de software requerido. Cuando el proyecto es cancelado, debe entregarse al cliente el producto del desarrollo hasta el momento de la cancelación;

• Demostrar que las capacidades técnicas y de gestión son adecuadas para el desarrollo del software. En caso de que sean utilizados subcontratados o contratados de soporte, es obligatorio que también estos demuestren sus competencias y capacidades;

• Presentar un plan de trabajo y una estructura de trabajo, WBS11, viables y con estimativas realistas de costos y plazos para el proyecto.

• Mostrar al cliente, regularmente, el progreso del desarrollo y la distancia hasta su finalización;

• Certificarse de que los requisitos fueron correctamente entendidos; • Incentivar el desarrollo de una cultura efectiva, funcional y cooperativa en el

relacionamiento con el cliente, y que sea construida con base en la confianza y el respeto. Las partes deben comprender que son mutuamente responsables por el éxito del proyecto y deben abstenerse de las tentativas de obtener ventajas, una sobre la otra. Las partes involucradas deben trabajar como un equipo, resolver los problemas conjuntamente y evitar la dinámica de imputación de culpas mutuas;

• Avisar al cliente, con prontitud y transparencia, sobre problemas no previstos anteriormente y cambios en los plazos;

• Discutir, revisar y mitigar los riesgos conjuntamente.

11 Work Breakdown Structure


G.5.2 Colaborador contratado

En la existencia de más de un contratado, se debe coordinar la colaboración entre ellos. Una forma es elegir uno de los contratados como primero contratado, con la responsabilidad de coordinar el trabajo de los colaboradores contratados.

G.5.3 Subcontratado

El contratado puede usar subcontratados para entregar partes de un software. La competencia y la capacidad del subcontratado se deben evaluar, y el cliente tiene el derecho de escoger el más adecuado. En caso de que el contratado emplee subcontratados, se debe asegurar que ellos sean involucrados lo antes posible en el proyecto.

G.5.4 Proveedor complementario

Puede ser necesario contratar proveedores de COTS y hardware durante el proyecto.


Anexo H – Normas ISO/IEC para evaluación de producto de software

H.1 Descripción general

El proceso de adquisición de software incluye la evaluación del producto antes de su aceptación. El Brasil viene actuando en la producción de normas brasileñas para evaluación de la calidad de producto de software, basadas en las normas de la ISO/IEC. Como consecuencia, ya están disponibles y en uso en el país diversas normas internacionales de apoyo a este proceso, conforme relacionadas a seguir.

H.2 Evaluación utilizando la ISO/IEC 25051

La ISO/IEC 25051 establece cómo un producto de software comercializado (COTS) debe presentar sus requisitos de calidad y proporciona instrucciones de cómo probar estos productos de software en relación a los requisitos definidos. Adicionalmente, proporciona instrucciones para la evaluación de conformidad de producto de software comercializado (COTS). Su alcance se refiere al paquete de software, en la forma ofrecida al mercado y no a los procesos de desarrollo y suministro de software.

El paquete de software se puede probar o tener su calidad evaluada con relación a:

Descripción del producto

Un documento que proporciona la descripción general del producto, así como establece declaraciones relacionadas a las características de calidad del producto de software y de calidad en uso, con el propósito de orientar a los potenciales compradores en la evaluación de la adecuación del producto antes de comprarlo. En caso de que el producto de software no disponga de una descripción de producto, se considera que es una no-conformidad mayor.

Documentación del usuario

El conjunto completo de documentos, disponible en forma impresa o no, que es suministrado para la aplicación del producto de software y también como parte integral del producto. Esta documentación debe seguir una serie de recomendaciones que aseguren su calidad.

Requisitos de calidad del software

Requisitos esperados del producto de software que estén en conformidad con lo establecido en la descripción del producto, en la documentación del usuario y con algunos requisitos típicos para productos de software comercializados (COTS).

La Figura 2 muestra la estructura básica del contenido de la norma, indicando los requisitos de calidad de las partes de un paquete de software y también las actividades de prueba para un paquete de software.


Figura 2 – Estructura de la norma ISO/IEC 12119

Esta norma es bastante utilizada internacionalmente, principalmente en Europa, siendo también referencia en diversas evaluaciones efectuadas en el Brasil, por medio de métodos de evaluación como, por ejemplo, el MEDE-PROS – Método de Evaluación de Calidad de Producto de Software [COLOMBO, 2004].

H.3 Evaluación con las series ISO/IEC 9126 y 1459812

Las series de normas ISO/IEC 9126 y 14598 son dedicadas a la evaluación de la calidad de cualquier tipo de producto de software. Las normas de estas series definen un modelo de calidad para productos de software y un proceso de evaluación de la calidad de software. A seguir, son presentados, resumidamente, estos conjuntos de normas.

Modelo de calidad

ISO/IEC 9126-1

La norma ISO/IEC 9126-1 define un Modelo de Calidad, que es utilizado como referencia del proceso de evaluación de la calidad de producto de software, y está subdividido en dos partes: Modelo de Calidad para características externas e internas; y Modelo de Calidad para calidad en uso.

El Modelo de Calidad para características externas e internas clasifica los atributos de calidad de software en seis características (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad) las cuales son, a su vez, desdobladas en subcaracterísticas. Las subcaracterísticas se pueden desdoblar en más niveles, que caracterizan los atributos de calidad.

12 La ISO/IEC está revisando estas normas referentes a la evaluación de producto de software, constituyendo el modelo denominado SQuaRE (Software Quality Requirements and Evaluation), que presenta una evolución de los conceptos representados en la serie de normas que están siendo reemplazadas. Algunas de estas normas ya están publicadas por la ISO y el modelo general del SQuaRE puede ser encontrado en la norma ISO/IEC 25000:2005 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE.


En el Modelo de Calidad para calidad en uso, los atributos son clasificados en cuatro características: eficacia, productividad, seguridad y satisfacción. La calidad en uso es “la capacidad del producto de software de permitir que usuarios específicos logren alcanzar sus metas especificadas con eficacia, productividad, seguridad y satisfacción en un contexto de uso especificado”.

Ejemplos de métricas

La ISO/IEC desarrolló tres informes técnicos internacionales, como documentos de apoyo al proceso de definición de requisitos y evaluación de la calidad de producto de software.

ISO/IEC TR 9126-2

Este informe técnico define el concepto de métricas externas13 y presenta un conjunto de métricas que se pueden utilizar para la definición y evaluación de calidad de producto de software.

En la parte común a los tres documentos de métricas, son identificadas propiedades deseables para la selección de una métrica para producto de software.

ISO/IEC TR 9126-3

Este informe técnico tiene su formato semejante al de la ISO/IEC 9126-2, proporcionando un conjunto de métricas internas14.

ISO/IEC TR 9126-4

Este informe técnico tiene partes comunes a las dos anteriores, proporcionando un conjunto de métricas de calidad en uso, además de presentar un ejemplo de proceso de evaluación de la calidad en uso.

Evaluación de la calidad de producto de software

ISO/IEC 14598-1

Esta norma presenta toda la estructura de funcionamiento de la serie de normas para evaluación de la calidad de los productos de software, además de definir los términos técnicos utilizados en ese modelo. Proporciona también los conceptos y el funcionamiento del proceso de evaluación de la calidad de cualquier tipo de software, para ser utilizado por productores (incluyendo gerentes, analistas de requisitos, proyectistas de software, implementadores y equipo de aseguramiento de la calidad), por compradores y por evaluadores de software independientes. En general, puede ser utilizada por personas involucradas en el desarrollo, estandarización y uso de tecnología de evaluación.

ISO/IEC 14598-2

Esta norma presenta requisitos, recomendaciones y orientaciones para una función de soporte al proceso de evaluación de los productos de software. El soporte está relacionado a la planificación y gestión de un proceso de evaluación de software y la tecnología necesaria, incluyendo: desarrollo, adquisición, estandarización, control,

13 Métricas relacionadas al comportamiento del sistema que incluye el software. 14 Métricas relacionadas a las propiedades estáticas del software como, por ejemplo, documentación,

código fuente, lista de requisitos, entre otras.


transferencia y realimentación del uso de tecnologías de evaluación en el entorno de la organización.

ISO/IEC 14598-3

Esta norma se destina al uso durante el proceso de desarrollo y mantenimiento de software, enfocando la selección y registro de indicadores que puedan ser medidos y evaluados a partir de los productos intermediarios, obtenidos en las fases del desarrollo de sistemas, con el objetivo de prever la calidad del producto final que será desarrollado, de modo que oriente la toma de decisiones técnicas y de gestión durante del proceso de desarrollo.

ISO/IEC 14598-4

Esta norma es dirigida a adquiridores de software y establece un proceso sistemático para evaluación de: productos de software comerciales, productos de software bajo encomienda o, inclusive, modificaciones en productos ya existentes. El propósito de la evaluación puede ser la comparación entre diversas alternativas de productos existentes en el mercado, o la tentativa de asegurar que un producto desarrollado o modificado bajo encomienda cumpla los requisitos inicialmente especificados. La norma considera el Modelo de Calidad de la ISO/IEC 9126-1 y utiliza el proceso de evaluación definido genéricamente en la ISO/IEC 14598-1.

ISO/IEC 14598-5

Esta norma proporciona orientaciones para la implementación práctica de evaluación de producto de software, cuando diversas partes necesitan entender, aceptar y confiar en resultados de evaluación. Normalmente es utilizada considerando el Modelo de Calidad descrito en la norma ISO/IEC 9126-1. El proceso descrito define las actividades necesarias para analizar los requisitos de evaluación de modo que se especifiquen, proyecten y ejecuten las actividades de evaluación y para obtener una conclusión sobre la evaluación de cualquier tipo de producto de software.

ISO/IEC 14598-6

Esta norma define la estructura y el contenido de la documentación a ser usada en la descripción de los Módulos de Evaluación. Explica cómo desarrollar módulos de evaluación y cómo validarlos. Un Módulo de Evaluación es un conjunto de instrucciones y datos usados para evaluación. Especifica los métodos de evaluación aplicables para evaluar las características de calidad. Define también los procedimientos elementales de evaluación y el formato del informe de presentación de los resultados de las mediciones resultantes de las aplicaciones de las técnicas. El uso de módulos de evaluación producidos y validados, conforme la norma, debe asegurar que las evaluaciones de software se puedan repetir, reproducir y que sean imparciales.

En resumen, las Normas de las series 9126 y 14598 se pueden utilizar como complemento una de la otra y de acuerdo con el objetivo de la evaluación. La Norma ISO/IEC 9126-1 establece un Modelo de Calidad, mientras que los informes técnicos ISO/IEC 9126-2, ISO/IEC 9126-3 e ISO/IEC 9126-4, proporcionan ejemplos de métricas de calidad de software. La Norma ISO/IEC 14598-1 contiene conceptos de cómo evaluar la calidad de software y define un modelo de proceso de evaluación genérico. Las normas ISO/IEC 14598-2 e ISO/IEC 14598-6, establecen elementos necesarios del soporte a la evaluación y las normas ISO/IEC 14598-3, ISO/IEC 14598-4 e ISO/IEC 14598-5 establecen procesos de evaluación específicos para productores, adquiridores y evaluadores de software, respectivamente. En la Figura 3 se pueden observar las relaciones entre ellas.


Figura 3 – Relación entre las series 9126 y 14598

H.4 La serie de normas SQuaRE

El grupo de trabajo WG6, del Subcomité de Sistemas y Software (SC7) de la ISO/IEC, que es el responsable por la elaboración de normas internacionales que tratan de la especificación, medición y evaluación de la calidad de productos de software, viene desarrollando un trabajo de revisión de las normas de las series ISO/IEC 9126 y ISO/IEC 14598, de especificación y evaluación de la calidad de producto de software, resultando en un nuevo modelo denominado SQuaRE, que es un acrónimo de Software Quality Requirements and Evaluation. La definición de la arquitectura de normas SQuaRE tuvo inicio en 1999 y viene orientando la revisión de las normas ya publicadas por la ISO, así como la creación de nuevas normas que atiendan los requisitos del mercado y la evolución de la Ingeniería de Software. El núcleo principal del SQuaRE está compuesto de cuatro divisiones de normas y una secuencia prevista para extensión del modelo:

• ISO/IEC 2500n – División Gestión de la Calidad, • ISO/IEC 2501n – División Modelo de Calidad, • ISO/IEC 2502n – División Medición de la Calidad, • ISO/IEC 2503n – División Requisitos de Calidad, • ISO/IEC 2504n – División Evaluación de la Calidad, y • ISO/IEC 2505n – ISO/IEC 25099 – Extensión del SQuaRE.

Esas divisiones se componen de normas, harmónicamente integradas, que detallan los tópicos relacionados a la especificación y evaluación de la calidad de productos de software, conforme breve descripción a seguir.

División Gestión de la Calidad

ISO/IEC 25000 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE

Métricas de calidad

en uso

Métricas externas

Métricas internas

Proceso de

evaluación

Soporte a la

evaluación

14598-1

9126-4 9126-2 9126-3 14598-5

14598-4

14598-3 9126-1

14598-6

14598-2

Recursos y

Entorno

Efectos del

Producto Software

Proceso de

Evaluación

Producto Software


Esta norma proporciona orientaciones sobre el uso de la serie de normas SQuaRE, proporcionando una visión general del contenido del SQuaRE, de sus modelos de referencia y definiciones, así como de las relaciones entre los documentos de la serie.

ISO/IEC 25001 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Planning and management (publicada por la ISO)

Esta norma proporciona requisitos y recomendaciones para una organización responsable por implementar y gestionar la especificación de requisitos de calidad del producto de software y por las actividades de evaluación de la calidad de software, suministrando tecnología, herramientas, experiencias y habilidades de gestión.

División Modelo de Calidad

ISO/IEC 25010 - Systems and software engineering — Software product Quality Requirements and Evaluation (SQuaRE) – Quality models for software product quality and systems quality in use (publicada por la ISO)

Esta norma define un modelo de calidad de producto de software, compuesto de características y subcaracterísticas que se manifiestan externamente cuando el software es utilizado como parte de un sistema y son resultados de atributos estáticos que se pueden obtener por medio de medidas internas de software. Presenta también un modelo de calidad en uso de sistemas, compuesto por características y subcaracterísticas que se pueden medir cuando un producto de software es utilizado en un contexto de uso real.

ISO/IEC 25012 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) – Data quality model (publicada por la ISO)

Esta norma define un modelo general de calidad de datos utilizados de forma estructurada en un sistema computacional. El modelo define características de calidad de datos que se pueden utilizar por personas o sistemas.

División Medición de la Calidad

ISO/IEC 25020 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Measurement reference model and guide (publicada por la ISO)

Esta norma presenta una introducción a los elementos de medida de calidad, medidas de calidad interna, externa y de calidad en uso y un modelo de referencia. Además de eso, proporciona orientaciones a los usuarios para seleccionar o desarrollar y aplicar medidas de calidad de producto de software.

ISO/IEC TR 25021 - Systems and software engineering: Software product Quality Requirements and Evaluation (SQuaRE) - Quality measure elements (en revisión por la ISO)

Este informe técnico proporciona un conjunto inicial de elementos de medidas de calidad, para auxiliar a los usuarios de las demás normas en la selección de medidas de calidad de software, las cuales son obtenidas a partir de la combinación de elementos de medidas de calidad.

ISO/IEC 25022 - Systems and software engineering: Systems and Software product Quality Requirements and Evaluation (SQuaRE) – Measurement of quality in use

Esta norma, cuyo trabajo fue iniciado recientemente por la ISO/IEC, pretende definir medidas de calidad en uso, según el modelo de calidad de la ISO/IEC 25010.


ISO/IEC 25023 - Systems and software engineering: Systems and Software product Quality Requirements and Evaluation (SQuaRE) – Measurement of systems and software product quality

Esta norma, cuyo trabajo fue iniciado recientemente por la ISO/IEC, pretende definir medidas de calidad de sistemas y de producto de software, según el modelo de calidad de la ISO/IEC 25010.

ISO/IEC 25024 - Systems and software engineering: Systems ans software product Quality Requirements and Evaluation (SQuaRE) – Measurement of data quality

Esta norma, cuyo trabajo fue iniciado recientemente por la ISOIEC, pretende definir medidas de calidad de datos, según el modelo de calidad de la ISO/IEC 25012.

División Requisitos de Calidad

ISO/IEC 25030 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements (publicada por la ISO)

Esta norma proporciona requisitos y recomendaciones para la especificación de requisitos de calidad de producto de software, pudiendo ser aplicada tanto por adquirentes, así como por proveedores de producto software.

División Evaluación de la Calidad

ISO/IEC 25040 - Systems and software engineering – Systems and software product Quality Requirements and Evaluation (SQuaRE) – Evaluation reference model and guide (publicada por la ISO)

Esta norma define requisitos generales para evaluación de la calidad de producto de software. Describe un proceso de evaluación, estableciendo los requisitos que se deben seguir en la aplicación de este proceso. El proceso se puede aplicar a la evaluación de productos de software pre desarrollados o, aún, para productos de software por encomienda. Esta nueva norma, diferentemente de la serie ISO/IEC 14598, define en un único documento las visiones de evaluación para desarrolladores, adquirentes o evaluación por tercera-parte.

ISO/IEC 25041 - Systems and software engineering – Systems and software product Quality Requirements and Evaluation (SQuaRE) – Evaluation guide for developers, acquirers and independent evaluators (en elaboración por la ISO)

Esta norma proporciona requisitos y orientaciones para evaluación de producto de software según la perspectiva de desarrolladores, adquirentes y evaluadores independientes.

ISO/IEC 25042 - Systems and software engineering – Systems and software product Quality Requirements and Evaluation (SQuaRE) – Evaluation modules

Esta norma, cuyo trabajo aun no fue iniciado por la ISO, pretende definir la estructura y el contenido de la documentación a ser utilizada para describir un módulo de evaluación.

ISO/IEC 25045 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Evaluation module for recoverability (publicada por la ISO)

Esta norma describe un módulo de evaluación que permite evaluar la capacidad con que un sistema trata de perturbaciones que le sean inducidas, el modo como ellas son detectadas y analizadas y cómo el sistema se ajusta y se recupera de estos eventos.


Extensión del SQuaRE

ISO/IEC 25051 - Software Engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing (publicada por la ISO)

Esta Norma establece requisitos de calidad para productos de software comercializados (COTS) y requisitos para la documentación de pruebas de COTS, incluyendo requisitos de prueba, casos de prueba e informe de prueba. Proporciona también instrucciones para la evaluación de conformidad de COTS, además de incluir recomendaciones para COTS críticos para negocios o para seguridad.

ISO/IEC TR 25060 - Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for Usability — General Framework for Usability-related Information (en elaboración por la ISO)

Este informe técnico define una visión general de un framework, utilizado para documentar la especificación de la evaluación de usabilidad de sistemas interactivos, llamados como Formatos Comunes de la Industria, describiendo su contenido esperado, las definiciones y relacionamientos entre los elementos del framework. Además de eso, define los usuarios esperados del framework, así como las situaciones en que es aplicable.

ISO/IEC 25062 - Software engineering: Software product Quality Requirements and Evaluation (SQuaRE) - Common Industry Format (CIF) for Usability Test Reports (publicada por la ISO)

Esta norma define cómo registrar las medidas obtenidas en pruebas de usabilidad, donde son evaluadas las características de eficacia, eficiencia y satisfacción en un contexto de uso especificado (estas características definen usabilidad conforme la norma ISO 9241-11).


Anexo I – Procesos de adquisición de la ISO/IEC 12207 e IEEE STD 1062:1998

I.1 Proceso de la ISO/IEC 12207

Manteniendo adherencia a las definiciones de proceso establecidas en el Modelo de Referencia MR-MPS, el proceso de adquisición está orientado por la norma ISO/IEC 12207:2008. En esta sección será descrito, de forma general, el proceso de la ISO/IEC 12207 para adquisición de S&SC y su relación con la IEEE STD 1062:1998, norma que podrá proporcionar informaciones complementarias útiles para organizaciones que pretendan adquirir software.

La ISO/IEC 12207 fue publicada, originalmente, en 1995 y tuvo una nueva versión publicada en 2008. Es una Norma Internacional y describe los procesos que componen el ciclo de vida, su interfaz con otros procesos y las relaciones de alto nivel que gobiernan estas interacciones. La norma cubre el ciclo de vida del software desde su concepción hasta el final de su vida útil. La norma es usada como referencia en diversos países, inclusive en el Brasil, para permitir que las empresas logren un escalón competitivo compatible con lo existente en las organizaciones internacionales. Tiene por objetivo auxiliar a los involucrados en la producción de software a definir sus papeles y, así, proporcionar a las organizaciones que la utilizan un mejor entendimiento de las tareas a ser ejecutadas en las operaciones que envuelven, de alguna forma, al software. La norma utiliza una terminología bien definida y está compuesta de procesos, actividades y tareas para adquisición, suministro, desarrollo, operación y mantenimiento del software. La norma establece una arquitectura de alto nivel para el ciclo de vida del software que abarca desde la concepción hasta su discontinuidad.

Cada proceso está definido en términos de sus propias actividades, y cada actividad está definida en términos de sus tareas.

La Tabla 1 presenta los procesos de contratación que tratan del asunto de adquisición, son ellos adquisición, propiamente dicho, y suministro. El proceso de adquisición es el objetivo específico de este documento, mientras que el proceso de suministro es una visión complementaria que orienta organizaciones que utilizan la norma ISO/IEC 12207 para cumplir los respectivos requisitos de adquisición.


Procesos de contratación Definen las actividades necesarias para el establecimiento de un contrato entre dos organizaciones.

Adquisición Define las actividades del adquiriente (organización que adquiere un S&SC). Se inicia con la definición de la necesidad de adquirir un sistema, un producto o un servicio de software y continúa con la preparación y la emisión de solicitud de propuestas, con la selección de un proveedor y, la supervisión del contrato hasta la aceptación del sistema, producto o servicio de software.

Suministro Define las actividades del proveedor (organización que suministra S&SC al adquiriente). El proceso puede ser iniciado tanto por la decisión de preparar una propuesta para atender una solicitud de un adquiriente, como por la firma y celebración de un contrato con el adquiriente para suministrar un sistema o S&SC. El proceso continúa con la diseminación de los procedimientos y recursos necesarios para gestionar y asegurar el proyecto, incluyendo el desarrollo y la ejecución de los planes del proyecto hasta la entrega del sistema o S&SC al adquiriente.

Tabla 1 – Descripción de los procesos de contratación relacionados a la adquisición [ROCHA, 2001]

La ISO/IEC 12207 es considerada de gran importancia para los procesos internacionales de adquisición de software. Es una norma adecuada para los procesos de adquisición porque reconoce las distintas funciones existentes para los compradores y proveedores. Se tiene la intención de que esta norma sea usada por las partes cuando exista un acuerdo o contrato que defina el desarrollo, mantenimiento u operación de un sistema de software.

El proceso de adquisición, definido por la ISO/IEC 12207, tiene como propósito obtener un producto o servicio que satisfaga la necesidad expresada por el cliente. El proceso se inicia con la identificación de una necesidad del cliente y se concluye con la aceptación del producto o servicio. Este proceso está constituido por las siguientes actividades:

Preparación de la adquisición – tiene como propósito establecer las necesidades y los objetivos de la adquisición y comunicarlos a los proveedores en potencial.

Selección del proveedor – tiene como propósito escoger la organización que será responsable por el cumplimiento de los requisitos del proyecto.

Supervisión del contrato – tiene como propósito acompañar y evaluar el desempeño del proveedor en relación a los requisitos acordados.

Aceptación por el cliente – tiene como propósito aprobar los productos entregados por el proveedor cuando todos los criterios de aceptación se cumplen.


I.2 Proceso de la IEEE STD 1062:1998

Además de la norma ISO/IEC 12207, que es la principal referencia para este documento, también se debe considerar otros estándares creados por asociaciones de profesionales, como es el caso de la norma IEEE STD 1062:1998 [IEEE, 1998], que es específica para la adquisición de S&SC. Esta norma es conocida y utilizada internacionalmente, aunque en el Brasil no existen datos registrados del uso de este estándar. Hay, en los Estados Unidos, cinco organizaciones volteadas al desarrollo de la tecnología de procesos de desarrollo de software. Dos de ellas son específicas para la adquisición de productos y servicios de software: Outsourcing Center [OUTC, 2002] y COTS Group [COTS, 2002].

En Europa existe también esta preocupación y, como ejemplo, tenemos en la Unión Europea o EUROMethod, o European Procurement Handbook for Open Systems - EPHOS [EPHOS]. Hay grupos específicos para adquisición, entre ellos se destaca: The Procurement Forum’s Special Interest Groups [PROCURE].

La norma IEEE STD 1062:1998 - IEEE Recommended Practice for Software Acquisition, además de ser adherente a la Enmienda 1 de la norma ISO/IEC 12207, es considerada como un framework con la misma relevancia de la propia ISO/IEC 12207, del SW-CMM, SA-CMM, FAAiCMM, ISO 9000, ISO/IEC 15504, y Euromethod y se pueden utilizar para la adquisición de cualquier producto de software, para cualquier tipo de plataforma computacional, independiente del tamaño, complejidad y grado crítico del software, aunque sea más adecuada utilizarla para la adquisición de software pre-elaborado modificable (modified off the shelf software (MOTS)) y software por encomienda (partially to fully outsourced (FD)).

La clasificación adoptada por la IEEE STD 1062:1998 para los productos de software es definida conforme el grado de libertad que tiene el usuario en definir y especificar sus funcionalidades. Según la norma, hay tres tipos de productos de software: Commercial-off-the-shelf-software (COTS), Modified-off-the-shelf-software (MOTS) y Fully Developed Software (FD).

El software del tipo COTS está comercialmente disponible. Es normalmente bien definido y documentado y su uso en escala, por un gran número de usuarios demuestra su buen desempeño en uso. El proveedor no está disponible para modificar el software a las necesidades de un cliente específico ni para controlar el mantenimiento del software. El costo para adquirir el software es de bajo para mediano y la entrega del producto es inmediata.

En el software del tipo MOTS, software pre elaborado modificable, el cliente no tiene control con respecto de la calidad de sus características, es parecido con el software del tipo COTS, con la diferencia de que el proveedor está disponible para efectuar modificaciones de las funcionalidades del producto de software, según los requisitos del cliente. En aplicaciones semejantes utilizadas por otros clientes, se puede demostrar su buen desempeño en el uso. El cliente tiene un control relativo del mantenimiento del producto y de sus características de calidad en la parte personalizada. El tiempo de entrega varia de mediano a largo y el costo para el cliente de mediano a alto.

El tercer tipo FD, software por encomienda (fully developed software) es único, tiene un volumen bajo de aplicación y es desarrollado para atender completamente los requisitos de un cliente específico. Como el producto no tiene precedentes, su desempeño no se puede evaluar a priori, pero el cliente posee total control sobre sus características de calidad y mantenimiento. El costo de desarrollo para el cliente es alto


y el tiempo de entrega largo. Las características de estas clases de producto están resumidas en la Tabla 2.

Características COTS MOTS FD*

Alcance Fijo Parcialmente personalizado

Totalmente personalizado

Apropiación al uso Demostrado Demostrado en aplicaciones semejantes

Sin precedentes

Mantenimiento Sin control Control parcial Control total

Plazo de Entrega Inmediato Pequeño - Grande Grande

Costo de la adquisición Bajo - Mediano Mediano - Alto Alto

Calidad [ABNT, 2003a]

No controlada Parcialmente controlada Controlada en su mayor parte

(*) Parcialmente o completamente de terceros Tabla 2 – Características de las clases de producto según la IEEE STD 1062:1998

Según la norma, el ciclo de vida de la adquisición de software representa el período de tiempo que comienza con la decisión de adquirir un producto de software y termina cuando el producto tiene su uso discontinuado. Este ciclo de vida representa un marco de referencia (framework) para la adquisición. Los resultados, producción o salida de una fase son usados como entrada para la fase siguiente. La Tabla 3, presenta la ilustración de esas fases.

Fase Inicio de Fase Fin de Fase Paso en el Proceso de Adquisición de Software

Planificación Desarrollo de la idea

Llamada para propuesta actualizada

1. Planificación de la estrategia organizacional,

2. Implementación del proceso organizacional

3. Definición de los requisitos del software

Contratación Actualización de la llamada para propuesta

Contrato firmado

4. Identificación de los potenciales proveedores

5. Preparación de los requisitos del contrato

6. Evaluación de las propuestas y selección del proveedor

Implementación del software

Firma del contrato

Recepción del software 7. Gestión del desempeño del proveedor

Aceptación del software

Recibimiento del software

Aceptación del software 8. Aceptación del software

Seguimiento Aceptación del software

Retiro del software 9. Utilización del software

Tabla 3 – Fases del proceso de adquisición de software según la IEEE STD 1062:1998

La norma define nueve pasos que se deben seguir para asegurar que los productos con alto potencial de calidad sean debidamente puntuados, contemplados y


considerados en el proceso de adquisición. El resultado esperado es la obtención de un software de alta calidad y con documentación adecuada. Atributos como plazo de entrega y costos, son dejados a criterio del usuario de la norma. La Tabla 3 presenta las fases, hitos (marcos) e indica cuales acciones se deben ejecutar y cumplir en cada una de las fases. Los pasos tienen como foco la adquisición de software con un conjunto básico de funcionalidades con posibilidad de ser desarrolladas, o ser componentes de software acabados. Esos pasos son menos adecuados para software con necesidad de implementación rápida. Los pasos son:

1- Planificación de la estrategia organizacional: revisa los objetivos de la adquisición y desarrolla una estrategia para la adquisición del software.

2- Implementación del proceso organizacional: establece un proceso de adquisición de software que atiende a las necesidades de la organización en obtener un producto de calidad.

3- Definición de los requisitos de software: define el software a ser adquirido y prepara los planes con los requisitos de calidad y de mantenimiento para la aceptación del software.

4- Identificación de los potenciales proveedores: selecciona los candidatos potenciales que deberán presentar la documentación de su software, efectuar la demostración de los productos, y presentar las propuestas formales de abastecimiento. La no observación o desempeño mediocre en cualquiera de estas acciones es considerado como base o argumento suficiente para el rechazo del potencial proveedor.

5- Preparación de los requisitos del contrato: describe la calidad del trabajo a hacerse en términos de desempeño y criterios de aceptación y prepara las condiciones contractuales que establece la previsión de pago de acuerdo con la entrega del software.

6- Evaluación de las propuestas y selección del proveedor: las propuestas de los proveedores son evaluadas, es hecha la elección del proveedor cualificado y el contrato es negociado.

7- Gestión el desempeño del proveedor: el progreso del trabajo del proveedor es supervisado para asegurar el cumplimiento de los hitos (marcos) y para aprobación de las partes ejecutadas del trabajo. El comprador o adquiriente debe, en esta fase, suministrar todos los insumos al proveedor, cuando solicitado.

8- Aceptación del software: se deben ejecutar pruebas, conforme establece el proceso, para asegurar que todas las no-conformidades sean corregidas y que todos los criterios de aceptación sean satisfechos.

9- Utilización del software: son realizados acompañamiento y análisis del contrato de adquisición para evaluar las prácticas del contrato, registrar las lecciones aprendidas y evaluar la satisfacción del usuario con el producto. Los datos de desempeño del proveedor se deben almacenar.

Según la norma, el éxito en la adquisición de un software o servicio asociado de alta calidad se puede lograr si las siguientes acciones son ejecutadas:

a) identificación de las características de calidad necesarias para lograr los objetivos del comprador o adquiriente;

b) inclusión de consideraciones de calidad en las actividades de planificación, evaluación y aceptación del producto;


c) implementación de una estrategia de la organización para la adquisición de software;

d) implementación de un proceso de adquisición de software usando los nueve pasos sugeridos por la norma en el texto anterior; y

e) colocación del proceso en práctica.

La Figura 4 relaciona los pasos previstos en la norma IEEE STD 1062:1998 con las actividades establecidas en la ISO/IEC 12207:2008, indicando la posibilidad de complementar el proceso establecido en esta guía, que es compatible con esta norma de la ISO/IEC.

Figura 4 - Relación entre la ISO/IEC 12207:2008 y la IEEE STD 1062:1998

ISO/IEC 12207 IEEE STD 1062

Preparación de la adquisición

Preparar estrategia organizacional

Implementar proceso organizacional

Determinar requisitos de software

Selección del proveedor

Identificar proveedores potenciales

Preparar requisitos del contrato

Evaluar propuestas/selec. del proveedor

Supervisión del contrato

Gestionar el desempeño del proveedor

Aceptación por el cliente

Aceptar el software

Utilizar el software


Anexo J – Habilitación de consultores de adquisición MPS

J.1 Habilitación de consultores de adquisición

Así como en las demás áreas del MPS.BR, en el proceso de adquisición también hay una sistemática para formación y reconocimiento de profesionales. Los profesionales, para ser habilitados como Consultores de Adquisición MPS, deben presentar calificación profesional y académica, además de cumplir con los requisitos de entrenamiento, evaluación y elaboración de un Plan de Adquisición de Software, conforme detallados en el sitio www.softex.br/mpsbr y resumidos a seguir:

I. Participación en el curso de Proceso de Adquisición MPS (C4);

II. Aprobación en la prueba sobre el Proceso de Adquisición MPS (P4): esta prueba consiste en la solución de un caso en que se abordan algunos aspectos incluidos en un proyecto de adquisición. Para ser aprobado, el candidato necesita lograr, por lo menos, 70% del puntaje máximo;

III. Demostración, comprobada por medio de análisis curricular, que el candidato desarrolla o desarrolló actividades de ejecución o de gestión en proyectos de adquisición de software y servicios asociados o en definición y/o implantación de procesos de adquisición de software y servicios asociados. La experiencia demostrada deberá ser suficiente para asegurar la capacidad del candidato para actuar como Consultor de Adquisición (CA) con base en la Guía de Adquisición del MPS.BR. El resultado del juicio indicará si el candidato fue aprobado; y

IV. Habilitación: en el caso de que el candidato cumpla con los requisitos establecidos, su nombre será publicado, en la sección “Profesionales Habilitados” en “Acceso Rápido” del sitio www.softex.br/mpsbr, como Consultor de Adquisición MPS. La habilitación podrá ser cancelada, en cualquier tiempo, caso el Consultor de Adquisición MPS, por alguna acción u omisión, coloque en riesgo la credibilidad del MPS.BR.


Anexo K – Iniciativas de utilización de procesos de adquisición en el área pública

K.1 Personalización de proceso de adquisición

Para cualquier organización, la adopción de un proceso de adquisición en los moldes de lo que fue definido en esta Guía de Adquisición, exige una personalización del proceso general a las características peculiares de la organización y del contexto donde ella está inserida. En este sentido, la personalización del proceso de adquisición debe llevar en cuenta aspectos como los relacionados a seguir:

• Contexto de la organización: características de la organización que pueden afectar a los proyectos de adquisición de S&SC. Estos aspectos pueden definir requisitos y restricciones a ser considerados en los proyectos de adquisición. Entre ellos, pueden ser incluidos:

o Demás procesos de la organización que sean directamente relacionados al proceso de adquisición;

o Ambiente de hardware y software adoptado;

o Habilidades y calificaciones del personal involucrado en adquisiciones de S&SC;

o Política de formación de las personas que actúan en adquisiciones de S&SC;

o Políticas de contratación de productos y servicios de la organización;

o Definiciones establecidas en el plan estratégico de la organización que pueden influenciar las adquisiciones de S&SC;

o Directrices, proyectos y acciones estratégicas definidas en el Plan Director de Tecnología de la Información (TI);

o Procesos de gobernanza de TI que subsidian la adquisición como planificación estratégica, gestión de inversiones, gestión de portafolio de proyectos, gestión de riesgos, gestión de la contratación de servicios de TI y el de medición.

• Contexto regulador: leyes y reglamentos externos e internos que rigen el funcionamiento de la organización, principalmente a lo que se refiere a adquisición de S&SC. Estas informaciones deben estar organizadas en un repositorio que facilite el acceso, la comprensión y la aplicación de las reglas aplicables a cada proyecto de adquisición de S&SC;

• Contexto del mercado: aspectos referentes al mercado con el cual la organización se relaciona y que influencian sus proyectos de adquisición. Entre otros, se destacan los siguientes aspectos:

o Productos existentes con potencial de atender a las necesidades de la organización;

o Potenciales proveedores de S&SC y su histórico de prestación de servicios a la organización;

o Referencias de uso de productos y servicios de interés de la organización por otras organizaciones;

o Referencias técnicas y comerciales aplicables a los proyectos de adquisición de S&SC de la organización.


• Procesos de gobernanza y gestión de la organización: procesos adoptados en la organización para gestión de proyectos, contemplando gestión de requisitos, comunicaciones, costos, cambios, problemas, plazos y calidad y que pueden ser aplicables en proyectos de adquisición de S&SC;

• Instrumentos de apoyo: métodos, técnicas y herramientas que la organización utiliza en sus proyectos de adquisición de S&SC.

K.2 Personalización de proceso de adquisición para organizaciones públicas

La adopción de un proceso de adquisición de S&SC personalizado para la administración pública es de fundamental importancia, sea por las altas inversiones involucradas o, principalmente, por los beneficios que pueden ser obtenidos en favor de la sociedad brasileña a partir de un proyecto de adquisición que tenga éxito.

De acuerdo con la norma ABNT NBR ISO/IEC 38500:2009 [ABNT, 2009c], p. 6, actualmente la única norma que se refiere a gobernanza corporativa de TI en el Brasil, el principio de la adquisición es uno entre los seis que deben nortear la buena gobernanza de TI: “Las adquisiciones de TI son hechas por razones válidas, con base en análisis apropiada y continua, con toma de decisión clara y transparente. Existe un equilibrio apropiado entre beneficios, oportunidades, costos y riesgos, de corto y largo plazo”.

En la Administración Pública Federal (APF) la adquisición Es tratada como contratación de servicios de TI, con base principalmente en la Ley 8.666/1993. El Tribunal de Cuentas de la Unión (TCU) ha identificado frecuentes irregularidades e impropiedades en contrataciones de servicios de TI. Ante este contexto, en 2006 el TCU creó la Secretaria de Fiscalización de Tecnología de la Información, instituyo la investigación de gobernanza de TI en órganos públicos y recomendó la elaboración de un modelo de licitación y contratación de servicios de TI con procesos más maduros y su implantación en los órganos y entidades bajo la coordinación de la Secretaria de Logística y Tecnología de la Información del Ministerio de Planificación, Presupuesto y Gestión (SLTI/MP) [TCU, 2006, articulo 67 del Voto del Relator y artículo 9.4 del Acuerdo].

En seguida se observó un movimiento positivo de la SLTI/MP, que es el órgano central del Sistema de Administración de los Recursos de Información e Informática (SISP), en la implementación de directrices para contratación de servicios de TI por la APF directa, autárquica y fundacional, con resultados importantes, conforme identificados por Cruz, Andrade y Figueiredo [CRUZ, ANDRADE, FIGUEIREDO, 2011] presentados a seguir:

a) “En mayo de 2008, la elaboración y publicación de la Instrucción Normativa SLTI/MP04/2008 (IN-04/2008) [MPOG, 2008b]. Esta IN define las directrices y fases del proceso de contratación de servicio de TI y fue concebida tomando como base, entre otras fuentes, la legislación brasileña, los resultados preliminares de la investigación de [CRUZ, 2008] que resultaron en el Cuadro Referencial Normativo para contratación de servicios de TI, presentados en 19/12/2007, y en las experiencias de los gestores involucrados en el grupo de trabajo organizado por la SLTI para apoyar la construcción de esta IN;

b) En diciembre de 2008, la publicación de un instrumento balizador de las directrices estratégicas y metas de perfeccionamiento institucional del SISP, denominado Estrategia General de Tecnología de la Información (EGTI) [MPOG,


2011]. El objetivo de la EGTI fue establecer las bases para el cumplimiento de la IN-04/2008, para que los órganos del SISP elaboren sus Planes Directores de Tecnología de la Información (PDTI), buscando el mejora institucional y la madurez de la gobernanza de TI. La palabra síntesis fue transición;

c) En 2009, el gobierno creó la Gratificación Temporaria del Sistema de Administración de los Recursos de Información e Informática (GSISP), atrayendo funcionarios públicos para actuar en el área de gobernanza de TI, y creó el cargo de Analista en TI (ATI) con atribuciones volteadas hacia las actividades de planificación, supervisión y control de los recursos, con el intuito de reforzar las unidades de TI;

d) La SLTI también implantó un programa de desarrollo de gestores de TI, por medio de la Escuela Nacional de Administración Pública (ENAP), con cuatro módulos: i) elaboración del plan director de TI; ii) planificación de la contratación; iii) selección de proveedores; y iv) gestión de contratos;

e) Aún en 2009, la EGTI 2008 fue revisada y considerando el aumento de profesionales de TI, publicando-se la EGTI 2010 [MPOG, 2010a] cuya palabra síntesis fue agregación de valor;

f) En 2010, la IN 04/2008 fue revisada, mejorada y publicada como IN 04/2010 [MPOG, 2010a]. Esa revisión de la IN 04 ocurrió debido a las necesidades como: detallar las etapas y fases; aclarar las atribuciones de los actores; facilitar la involucración de las áreas requisitora de la solución y administrativa en la planificación de la contratación y en la gestión de contratos; aclarar las orientaciones para inclusión y gestión de las sanciones administrativas;

g) En seguida, fue publicada la EGTI 2011-2012 [MPOG, 2011], que tiene como misión promover la gestión de los recursos de TI en los órganos integrantes del sistema buscando apoyar el desarrollo social del País.”

El resultado de esa evolución jurídica claramente una preocupación con la mejora de la planificación de TI, planificación de la contratación, selección del proveedor y gestión de contratos en todos los procesos de la tecnología de la información, incluyendo los procesos de S&SC. Por lo tanto, es requerido normativamente que las organizaciones públicas definan e institucionalicen sus procesos de contratación de servicios de TI.

La Instrucción Normativa SLTI/MP 4/2010 ([MPOG, 2010a], más conocida por la sigla IN 04 define las directrices del proceso de Contratación de Soluciones de Tecnología de la Información por los órganos integrantes del Sistema de Administración de los Recursos de Información e Informática del Poder Ejecutivo Federal (SISP), establecido por el Decreto 1.048/1994 [BRASIL, 1994]. Las principales alteraciones de la IN 04 fueron: i) creación del equipo de planificación de la contratación (integrante demandante, integrante técnico e integrante administrativo); ii) definición de los papeles de integrantes del equipo de planificación de la contratación, gestor, cogestor y fiscales de contratación; iii) definición de los responsables en cada etapa de las fases en el proceso de contratación (planificación, selección de proveedores y gestión del contrato); iv) creación del documento oficialización de la demanda; v) más detalles en la fase de selección del proveedor y en la definición de las sanciones administrativas.


La IN-04 se compone de tres capítulos, conforme presenta la Figura 1 abajo:

Figura 1 - Estructura de la IN-04 - Fuente: [CRUZ, ANDRADE, FIGUEIREDO, 2011]

El capítulo I presenta las disposiciones generales sobre las directrices relacionadas a la Planificación de TI, que abarca la Estrategia General de Tecnología de la Información (EGTI) y el Plan Director de Tecnología de la Información (PDTI):

a) La (EGTI), elaborada por el SISP, es revisada anualmente y contiene orientaciones generales para perfeccionar la gestión de procesos de TI en los órganos del SISP, y una de las metas es adoptar un proceso de contrataciones de soluciones de TI, conforme las publicaciones de la IN-04/2010 y del Manual de Contrataciones de Soluciones de TI.

b) El PDTI es un documento obligatorio para cada órgano o entidad integrante del SISP. En este documento son presentados la evaluación y el diagnóstico de los recursos de TI, las necesidades de información identificadas por el órgano, además de la planificación de inversiones, recursos humanos y su capacitación, adquisición de equipamientos y contrataciones de servicios de TI.

El Capítulo II presenta el proceso de contratación de servicios de TI, constituido por las fases de planificación de la contratación (sección I), de selección del proveedor (sección II) y de gestión del contrato (sección III).

Todas las contrataciones de soluciones de tecnología de la información deberán ser precedidas de planificación de la contratación, independiente del tipo de contratación, como: licitación convencional (pregón, competencia, toma de precios, invitación o concurso), inexigibilidad e dispensa de licitación, sistema de registro de precios y contrataciones con recursos de convenios internacionales.

En la fase de PLANIFICACIÓN DE LA CONTRATACIÓN, se observan los cuidados con la definición de las responsabilidades de los involucrados, justificativas y resultados esperados y fuente de recursos. El resultado de esa fase es caracterizado por la producción do término de referencia o del proyecto básico, pero su inicio es marcado

Capítulo III

Disposiciones

Finales

EGTI

PDTI

Sección I

Planificación de la

Contratación

Sección II

Selección del

Proveedor

Sección III

Gestión del

Contrato

Capítulo I

Disposiciones

Generales

Capítulo II

Proceso de

Contratación


por el recibimiento del Documento de Oficialización de la Demanda, por el Área de Tecnología de la Información, oriundo del Área Requirente de la Solución, que contendrá por lo menos las siguientes secciones:

a) Necesidad de la contratación, considerando los objetivos estratégicos y las necesidades corporativas de la institución, bien como su alineamiento al PDTI;

b) Explicitación de la motivación y demostrativo de resultados a ser logrados;

c) Indicación de la fuente de los recursos para la contratación; e

d) Indicación del Integrante Requirente para composición del Equipo de Planificación de la Contratación.

Esa fase se constituye de las siguientes etapas:

a) Análisis de Viabilidad de la Contratación – abarca: la definición y especificación de los requisitos; identificación, evaluación y selección de soluciones; justificativa de la solución seleccionada; evaluación de la necesidad de adecuación de la solución; consolidación de las informaciones; y evaluación del análisis de viabilidad. En esa etapa es verificada también la posibilidad de subdividir la Solución de Tecnología de la Información (Art. 17, §2º) en cumplimiento de los arts. 15 y 23, §1º, de la Ley 8.666/1993 y al Acuerdo 786/2006-TCU-Plenário;

b) Elaboración del Plan de Sustentación – abarca: seguridad de la información; recursos materiales y humanos; transición contractual; continuidad del proveimiento de la solución de Tecnología; de la Información en eventual interrupción contractual; y estrategia de independencia; consolida informaciones y evalúa el plan de sustentabilidad. Es firmado por el Requirente de la Solución y Área de TI;

c) Elaboración de la Estrategia de la Contratación – abarca: la indicación de la solución de TI, términos contractuales, responsabilidades de contratación, elaboración de modelos de documentos y estimativa de impactos; define criterios para emisión de juicio; consolida informaciones y avalúa la estrategia de la contratación. Además de estas actividades, analiza la necesidad de licitaciones y contrataciones separadas para os elementos que, debido a su naturaleza, puedan ser objeto de recursos y que puedan paralizar la contratación de componentes de la Solución de Tecnología de la Información.

d) Análisis de Riesgos – abarca: la identificación de los principales riesgos que puedan comprometer el éxito del proceso de contratación y de modo que la solución contratada no atienda a las necesidades del órgano; niveles de probabilidad y severidad de cada riesgo; acciones para amenizar o eliminar las chances de ocurrencia; acciones de contingencia; responsables por las acciones de prevención o procedimientos de contingencia. Los responsables por la elaboración son los integrantes técnicos y demandantes, con el apoyo del área de TI.

e) Elaboración del Término de Referencia o Proyecto Básico – documento con la planificación completa de la contratación y sus respectivos anexos.

La fase SELECCIÓN DEL PROVEEDOR refuerza el uso rutinero del Pregón (es excepcional de otros tipos y modalidades de mecanismo de selección del proveedor) para las contrataciones de Solución de Tecnología de la Información. Esa fase se inicia con el encaminamiento del término de referencia (o proyecto básico) por el área de TI


al área de licitaciones, cabiendo a la última la responsabilidad por la fase y al área de TI apenas:

a) analizar las sugerencias hechas por las Áreas de Licitaciones y Jurídica para el Termino de Referencia o Proyecto Básico y demás documentos;

b) apoyar técnicamente el pregonero o la Comisión de Licitación en la respuesta a los cuestionamientos o a las impugnaciones de los licitantes; y

c) apoyar técnicamente al pregonero o a la Comisión de Licitación en el análisis y juicio de las propuestas y de los recursos presentados por los licitantes.

La fase Selección del Proveedor es encerrada con la firma del contrato y con la nombramiento de personas para ejercer los siguientes papeles:

a) Gestor del Contrato;

b) Fiscal Técnico del Contrato;

c) Fiscal Requirente del Contrato; y

d) Fiscal Administrativo del Contrato.

La fase de GESTIÓN DEL CONTRATO enfoca al seguimiento y en el aseguramiento apropiado de prestación de los servicios y del suministro de los bienes que componen la Solución de Tecnología de la Información durante todo el período de ejecución del contrato, con las etapas:

a) Inicio del contrato;

b) Presentación formal de órdenes de servicio o de suministro de bienes por el Gestor del Contrato al representante de la contratada;

c) Monitoreo de la ejecución;

d) Transición contractual, cuando aplicable, y cierre del contrato, que deberá observar el Plan de Sustentabilidad;

e) Ajustes contractuales, por medio del envío al Área Administrativa, de documentación que deja explícito el interés de aditamento contractual, basado en la documentación del histórico de gestión del contrato, en el mantenimiento de la necesidad, economicidad y oportunidad de la contratación.

Se enfatiza que, en los casos de contratación de desarrollo de software, los productos deberán ser catalogados por el contratante e, siempre que se aplicable, colocarlos a disponibilidad en el Portal del Software Público.

Juntamente con la publicación de la IN-04, fue publicado también el Manual de Contratación de Soluciones de Tecnología de la Información V. 2.0 [MPOG, 2010c], que describe los procesos, actividades y artefactos involucrados en la contratación, con el objetivo de apoyar a los profesionales en la realización del proceso de contratación de Soluciones de TI.

Otra iniciativa importante del Gobierno fue la llamada en 2010 para publicación de un libro sobre adquisiciones en TI por la Secretaria de Política de Informática del Ministerio de Ciencia, Tecnología e Innovación, por medio de la Serie de Libros del Programa Brasileño de Calidad y Productividad en Software (PBQP). El Libro “Proceso de Contratación de Servicios de Tecnología de la Información para Organizaciones Públicas” [CRUZ, ANDRADE, FIGUEIREDO, 2011] fue el vencedor de ese concurso.


Ese libro presenta un proceso de contratación de servicios de TI para órganos públicos descrito con base en la IN-04, en el proceso de adquisición del MPS.BR, en los modelos Cobit, objetivos de control enfocados en contratación de servicios: AI5 (Adquirir recursos de TI) y DS2 (Gestión de servicios de outsourcing), en el eSCM-CL (eSourcing Capability Model for Clients) y en el QRN (Cuadro Referencial Normativo). Por lo tanto, proceso descrito en el libro puede ser considerado un ejemplo de un proceso personalizado.


Referencias bibliográficas

[ABNT, 2001a] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 14598-1:2001 - Tecnologia de informação - Avaliação de produto de software – Parte 1: Visão geral. Rio de Janeiro: ABNT, 2001.

[ABNT, 2001b] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 14598-5:2001 - Tecnologia de informação - Avaliação de produto de software – Parte 5: Processo para avaliadores. Rio de Janeiro: ABNT, 2001.

[ABNT, 2003a] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 9126-1:2003 - Engenharia de software - Qualidade de produto - Parte 1: Modelo de qualidade. Rio de Janeiro: ABNT, 2003.

[ABNT, 2003b] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 14598-2:2003 - Engenharia de software - Avaliação de produto de software – Parte 2: Planejamento e gestão. Rio de Janeiro: ABNT, 2003.

[ABNT, 2003c] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 14598-3:2003 - Engenharia de software - Avaliação de produto de software – Parte 3: Processo para desenvolvedores. Rio de Janeiro: ABNT, 2003.

[ABNT, 2003d] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 14598-4:2003 - Engenharia de software - Avaliação de produto de software – Parte 4: Processo para adquirentes. Rio de Janeiro: ABNT, 2003.

[ABNT, 2004] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 14598-6:2004 - Engenharia de software - Avaliação de produto de software – Parte 6: Documentação de módulos de avaliação. Rio de Janeiro: ABNT, 2004.

[ABNT, 2008a] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 25000:2008 - Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE) - Guia do SQuaRE. Rio de Janeiro: ABNT, 2008.

[ABNT, 2008b] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 25030:2008 - Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Requisitos de qualidade. Rio de Janeiro: ABNT, 2008.

[ABNT, 2008c] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 25051:2008 - Engenharia de software - Requisitos e avaliação da qualidade de produto de software (SQuaRE) - Requisitos de qualidade de produto de software comercial de prateleira (COTS) e instruções para teste. Rio de Janeiro: ABNT, 2008.

[ABNT, 2009a] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 25001:2009 - Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE) – Planejamento e gestão. Rio de Janeiro: ABNT, 2009.

[ABNT, 2009b] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 25020:2009 - Engenharia de software - Requisitos e avaliação da qualidade de produtos de software (SQuaRE) – Guia e modelo de referência para medição. Rio de Janeiro: ABNT, 2009.


[ABNT, 2009c] - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/IEC 38500:2009 - Governança corporativa de tecnologia da informação. Rio de Janeiro: ABNT, 2009.

[ALVES, 2004] - ALVES, Ângela M; GUERRA, Ana. Aquisição de Produtos e Serviços de Software. Rio de Janeiro: Elsevier, 2004. 213p.

[BRASIL, 1994] – BRASIL. Decreto n° 1.048, de 21 de janeiro de 1994. Dispõe sobre o Sistema de Administração dos Recursos de Informação e Informática, da Administração Pública Federal, e dá outras providências. Brasília, 1994. Disponible en: <http://www.planalto.gov.br/ccivil_03/decreto/1990-1994/D1048.htm>. Acceso en: 26 fev. 2010.

[COLOMBO, 2004] - COLOMBO, Regina Maria Thienne. Processo de Avaliação da Qualidade de Pacotes de Software. Campinas, SP, 2004. 169pp. Orientadora Ana Cervigni Guerra. Trabalho Final de Mestrado Profissional. Universidade Estadual de Campinas, Faculdade de Engenharia Mecânica.

[CMMI, 2002] - SEI. SOFTWARE ENGINEERING INSTITUTE. Capability Maturity Model® Integration, Version 1.1. CMMI for Software Enginneering. Software Engineering Institute, August, 2002.

[COTS, 2002] - COTS group. Disponible en <www.cots.state.va.us>. Último acceso en 12 de abril 2002.

[CRUZ, 2008] - CRUZ, Cláudio Silva da. Governança de TI e conformidade legal no setor público: um quadro referencial normativo para a contratação de serviços de TI. Dissertação (Mestrado em Gestão do Conhecimento e da Tecnologia da Informação). Universidade Católica de Brasília, Brasília, 2008. Disponible en: <http://www.bdtd.ucb.br/tede/tde_arquivos/3/TDE-2008-11-25T123713Z-687/Publico/Texto Completo Cruz - 2008.pdf>. Acceso en: 26 fev. 2011.

[CRUZ, ANDRADE, FIGUEIREDO, 2011] - CRUZ, Cláudio Silva da; ANDRADE, Edméia Leonor Pereira de; FIGUEIREDO, Rejane Maria da Costa. PCSSCEG - Processo de contratação de serviços de tecnologia da informação para organizações públicas. Brasília: MCT/SEPIN, 2011. 109 p. il. Série Livros PBQP. Disponible en: http://mct.gov.br/index.php/content/view/331689.html

[D’Souza, 1998] – D’Souza, D.F. e Wills, A. C., 1998, Object, Components, and Frameworks with UML: The catalysis Approach, Addison-Weskey.

[EPHOS] - EPHOS - European Procurement Handbook for Open Systems Disponible en http://www.csi.map.es/csi/historico/pg5e20.htm . Ultimo acceso en 31.01.05.

[EURO] - Comissão Europeia, DG III, PPG, Julho, 1996. EURO-Eurométodo v1.0. Disponible en <http://projekte.fast.de/Euromethod>. Último acceso en 19 de maio de 2002.

[IEEE, 1998] - IEEE COMPUTER SOCIETY. IEEE - Software Engineering Standards Colletion. IEEE STD 1062 - IEEE Recommended Practice for Software Acquisition. New York, NY. 1998a. 43p.

[ISO/IEC, 2002a] - THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-2:2003 - Software engineering - Product quality - Part 2: External metrics. Geneve: ISO, 2002.


[ISO/IEC, 2002b] - THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-3:2003 - Software engineering - Product quality - Part 3: Internal metrics. Geneve: ISO, 2002.

[ISO/IEC, 2002c] - THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-4:2002 - Software engineering - Product quality - Part 4: Quality in Use. Geneve: ISO, 2002.

[ISO/IEC, 2006] - THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25062:2006 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for Usability Test Reports. Geneve: ISO, 2006.

[ISO/IEC, 2007] - THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25001:2007 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Planning and management. Geneve: ISO, 2007.

[ISO/IEC, 2008a] – THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 12207:2008 – Systems and software engineering – Software life cycle processes. Geneve: ISO, 2008.

[ISO/IEC, 2008b] - THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 25020:2008 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Measurement reference model and guide. Geneve: ISO, 2008.

[MPOG, 2008a] - Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Estratégia Geral de TI 2008. Versão 1.0. Brasília, 2008. Disponible en: <http://www.governoeletronico.gov.br/biblioteca/arquivos/portaria-no-11-de-30-de-dezembro-de-2008>. Acceso en: 19 jun. 2006.

[MPOG, 2008b] - Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Instrução Normativa SLTI n° 4, de 19 de maio de 2008. Dispõe sobre o processo de contratação de serviços de Tecnologia da Informação pela Administração Pública Federal direta, autárquica e fundacional. Brasília, 2008. Disponible en: <http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-04-2>. Acceso en: 26 feb. 2011.

[MPOG, 2010a] - Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Estratégia Geral de Tecnologia da Informação 2010. Brasília, SLTI/MP, 2010.


[MPOG, 2010b] - Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Instrução normativa nº 4, de 12 de novembro de 2010. Dispõe sobre o processo de contratação de Soluções de Tecnologia da Informação pelos órgãos integrantes do Sistema de Administração dos Recursos de Informação e Informática (Sisp) do Poder Executivo Federal. Brasília, 2010. Disponible en: <http://www.governoeletronico.gov.br/biblioteca/arquivos/instrucao-normativa-no-04-de-12-de-novembro-de-2010>. Acceso en: 26 feb. 2011.

[MPOG, 2010c] - Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Manual de contratação de soluções de tecnologia da informação. Versão 2.0. Brasília, 2010. Disponible en: <http://www.governoeletronico.gov.br/biblioteca/arquivos/manual-de-contratacao-de-solucoes-de-tecnologia-da-informacao>. Acceso en: 26 feb. 2011.

[MPOG, 2011] - Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Estratégia Geral de Tecnologia da Informação EGTI 2011-2012. Brasília, 2011. Disponible en: <http://www.governoeletronico.gov.br/biblioteca/arquivos/estrategia-geral-de-tecnologia-da-informacao-egti-2011-2012>. Acceso en: 26 feb. 2011.

[SOFTEX, 2011a] - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR - Guía General:2011, junio 2011. Disponible en: www.softex.br .

[SOFTEX, 2011b] - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR - Guía de Evaluación:2011, mayo 2011. Disponible en: www.softex.br .

[SOFTEX, 2011c] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS:2011, junio 2011. Disponible en: www.softex.br .

[SOFTEX, 2011d] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS:2011, junio 2011. Disponible en: www.softex.br .

[SOFTEX, 2011e] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS:2011, junio 2011. Disponible en: www.softex.br .

[SOFTEX, 2011f] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS:2011, junio 2011. Disponible en: www.softex.br .

[SOFTEX, 2011g] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS:2011, junio 2011. Disponible en: www.softex.br .


[SOFTEX, 2011h] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS:2011, junio 2011. Disponible en: www.softex.br .

[SOFTEX, 2011i] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011j] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 8: Implementação do MR-MPS:2011 em organizações que adquirem software, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011k] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 9: Implementação do MR-MPS:2011 em organizações do tipo Fábrica de Software, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011l] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 10: Implementação do MR-MPS:2011 em organizações do tipo Fábrica de Teste, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011m] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 11: Implementação e Avaliação do MR-MPS:2011 em Conjunto com o CMMI-DEV v1.2, mayo 2011. Disponible en: www.softex.br.

[PROCURE] - PROCURE - The Procurement Forum’s Special Interest Groups. Disponible en http://www.imakenews.com/procurementforum/index000005275.cfm Último acceso en 31.01.05.

[ROCHA, 2001] - ROCHA, Ana Regina. C.da, MALDONADO, José C.; WEBER, Kival C.. Qualidade de Software: Teoria e Prática. 1. ed. São Paulo: Prentice Hall, 2001. 303 p.

[SAMETINGER, 1997] - Sametinger, J., Software Engineering with Reusable Components, Springer, 1997.

[SIMÃO, 2002] - Simão, R.P.S., Características de Qualidade para Componentes de Software, Tese de Mestrado, UNIFOR, Fortaleza, Ceará, 2002.

[TCU, 2006] - Tribunal de Contas da União. Acórdão 786/2006-TCU-Plenário. Brasília, 2006. Disponible en: <http://contas.tcu.gov.br/portaltextual/MostraDocumento?lnk=(acordao+adj+786/2006+adj+plenario)[idtd][b001]>. Acceso en: 26 fev. 2011.

[VOAS, 1998] - Voas, J. M., Certifying Off-the-Shelf Software Components, IEEE Computer, 0018-9162/98, 1998, June, pp 53-59.


Lista de colaboradores de la Guía de Adquisición:2011

Editor:

Danilo Scalet CELEPAR

Edméia Leonor Pereira de Andrade EMBRAPA

Revisor:

João Condack PRIMEUP

Traducción al español:

Maria Teresa Villalobos IMA


Lista de colaboradores de la Guía de Adquisición:2009

Editor:


Revisores:

Ana Cervigni Guerra CTI

Ana Liddy Cenni de Castro Magalhães QualityFocus y Universidad FUMEC

Ana Regina C Rocha COPPE/UFRJ (Coordinadora de la ETM)

Edméia Leonor Pereira de Andrade EMBRAPA

Gleison dos Santos Souza COPPE/UFRJ

Lúcia Nigro Pereira Pinheiro CASNAV (Marina del Brasil)

Mariano Angel Montoni COPPE/UFRJ


Maria Teresa Villalobos IMA

Revisión de la traducción:

Andrés Rubinstein Liveware, Inc.


Lista de colaboradores de la Guía de Adquisición versión 1.2

Editor:


Colaboradores:

Ana Cervigni Guerra CenPRA

Edméia Leonor Pereira de Andrade MAPA


Regina Thienne Colombo CenPRA

Revisores:

Francisco Vasconcellos Marina del Brasil y COPPE/UFRJ

Kival Chaves Weber SOFTEX


Maria Teresa Villalobos CenPRA e IMA



Editor:


Colaboradores:


Ângela M. Alves CenPRA



Revisores:

Christiane Grese von Wangenheim UNIVALI

Clenio F. Salviano CenPRA

Cristina Ângela Filipak Machado CELEPAR

Fábio Nogueira de Lucena UFG (Instituto de Informática)

Francisco Vasconcellos Marina del Brasil

Kathia Marçal Oliveira UCB


Marcio Pecegueiro Amaral RIOSOFT


Maria Teresa Villalobos CenPRA



Editor:


Colaboradores:


Ângela M. Alves CenPRA




Revisores:

Ana Cristina Rouiller UFLA


Ana Regina C Rocha COPPE/UFRJ

André Villas-Boas CPqD


Cristina Ângela Filipak Machado CELEPAR

Eratóstenes Araújo SOFTEX

Kathia Marçal Oliveira UCB


Luiz Carlos de Almeida Oliveira CELEPAR

Marcio Pecegueiro Amaral RIOSOFT

Documents

MPS.BR - Mejora de Proceso del Software Brasileño …a_de... · con la versión 2008 de la norma ISO/IEC 12207 y actualizó el contenido referente a las normas de calidad de producto