TEMA1

TEMA 2
GESTION DE PROYECTOS
DE SOFTWARE
Dr. José Ignacio Peláez Sánchez

E.T.S.I. Informática de Sistemas. 3er Curso. Año 2004/2005
Introducción
Muchos de los problemas en el desarrollo de software: fechas límite,
decepción de los clientes, coste disparados, son el resultado de una
gestión débil.
La gestión de proyectos implica la planificación, supervisión y control
del personal, del proceso y los eventos que ocurren mientras
evoluciona el software desde la fase preliminar a la implementación
operacional.
¿Quién gestiona?. La respuesta es todos, pero adecuados a su
ámbito.
z Un ingeniero controla las actividades diaria, planificando, supervisando y
controlando las tareas técnicas. Los gestores expertos coordinando el
negocio y los profesionales del software, etc.
José Ignacio Peláez Sánchez

Universidad de Málaga 2 de 68
Departamento de Lenguajes y Ciencias de la Computación
Introducción
La importancia de esta tarea de gestión viene dada por la
cantidad de tareas y gente que es necesario coordinar en
un proyecto software.
Los pasos en las gestión tienen que cumplir las cuatro Ps:
z Personal, producto, proceso y proyecto.
z Este orden no es arbitrario.
9 Si el gestor olvida que la IS es un esfuerzo humano no tendrá éxito
en la gestión de proyectos.
9 Si el gestor no fomenta la comunicación con el cliente construirá un
software que no se ajuste a las necesidades.
9 El administrado que se olvida de los procesos no utilizará
herramientas que garantizan la calidad del producto.
9 Si el gestor no tiene un plan para el proyecto no alcanzará el
producto deseado.

Introducción
El producto que se obtiene en la Gestión es un plan donde
se define el proceso, las tareas a realizar, los mecanismos
para evaluar los riesgos, mecanismos de seguridad y
finalmente controlar el cambio y evaluar la calidad.
¿Cómo estoy seguro que esta correcto? Nunca se
esta seguro hasta que se ha entregado el producto. Sin
embargo un gestor de proyectos hace lo correcto cuando
estimula al personal para trabajar juntos como un equipo
efectivo, centrando su atención en las necesidades del
cliente y en la calidad del producto.

Componentes de la Gestión
Los componentes de la gestión de proyectos son las
cuatro Ps:
z Personal, Producto, Proceso y Proyecto.
Personal:
z La gestión del personal esta compuesto de varias áreas para
garantizar la elección adecuada:
9 Reclutamiento, Selección, Gestión de Rendimiento, Entrenamiento,
Retribución, Desarrollo de la Carrera, Diseño de la Organización y del
trabajo y desarrollo cultural y de espíritu de equipo.
9 Todas estas áreas son denominadas MODELO DE MADUREZ DE
GESTIÓN DE PERSONAL.
z Este es el componente más importante en la IS.

Producto
z Antes de planificar se deben realizar las siguientes
tareas:
9 Objetivos (sin saber como se alcanzarán) y ámbito del
producto (datos primarios y funciones y comportamientos que
caracterizan al producto); Soluciones alternativas; Identificar
soluciones técnicas y de gestión.
9 Estás acciones suelen ser parte del proceso de ingeniería o del
negocio.

Proceso
z Se establece la estructura desde donde detallar el plan de
desarrollo (tareas, hitos, productos, puntos de control para
garantía de calidad, etc). Además, en las fases genéricas se
selecciona el modelo de proceso (Incremental, DRA, etc).
z Modelo CMM para la Madurez de la Empresa en la utilización de
un proceso.
Proyecto
z En 1998 los datos de la industria del software indicaron que el
26% de los proyecto fallaron totalmente, del resto el 46%
tuvieron desbordamientos en la planificación y el coste.
z Para evitar el fracaso se debe aplicar el sentido común en la
planificación, supervisión y control del proyecto.

Participantes

Participantes
En la mayoría de los casos el desarrollo de un sistema de
información se lleva a cabo por un grupo de personas,
cada una de las cuales tiene un perfil. De la armonía que
exista entre todos los componentes del grupo de trabajo
depende el éxito o fracaso del proyecto.
Atendiendo a las características de complejidad y

magnitud del sistema que se esté desarrollando, los
perfiles de los participantes que intervienen deberán
adaptarse y dimensionarse en cada momento.

Perfiles de Participantes
Los perfiles establecidos son:
z Directivo.
z Jefe de Proyecto.
z Consultor.
z Analista.
z Programador.
Cada uno de estos perfiles tienen una serie de

características importantes a la hora de delimitar su
participación en el proyecto.

Perfil Directivo
Dentro de esta categoría se agrupan los siguientes
participantes:
z Comité Dirección.
z Comité de Seguimiento.
z Directores de Usuarios.
z Usuarios Expertos.
Intervienen en todos los procesos principales, siendo sus

principales responsabilidades y funciones similares.

Perfil Directivo
El perfil de este grupo de participantes es el siguiente:
z Alto nivel en la dirección de la organización.
z Conocimientos de los objetivos estratégicos y de negocio que se
persiguen.
z Autoridad para validar y aprobar cada uno de los procesos
realizados durante el desarrollo del sistema.
z Conocimiento del entorno y de la organización suficiente para
proporcionar, a lo largo de todo el proyecto, unos requisitos del
sistema adecuados, completos y suficientemente importantes
como para considerarse en el catálogo definitivo de requisitos.

Comité de Dirección
La responsabilidad del Comité de Dirección es la siguiente:

z Proveer los recursos necesarios para el cumplimiento de los
objetivos propuestos.
z Revisar y aprobar formalmente cada uno de los procesos.

Comité de Seguimiento y Control
La responsabilidad del Comité de Seguimiento y Control es
la siguiente:
z Resolver cualquier contingencia que pueda presentarse.
z Asegurar la disponibilidad de los recursos humanos con los perfiles
adecuados.
z Participación en aquellas actividades donde sea necesaria su
colaboración.

Directores de Usuarios
La responsabilidad de los Directores de Usuarios es:
z Aportar información sobre las necesidades planteadas.
z Validar los resultados con el fin de garantizar la identificación.
z Comprensión e incorporación de todos los requisitos con las
prioridades adecuadas.
Esta misma función la desempeñan con mayor nivel de

detalle los usuarios expertos de nivel directivo.

Perfil Jefe de Proyecto
Los participantes que se engloban dentro de este perfil
son los siguientes:
z Jefe de Proyecto.
z Responsable de Implantación.
z Responsable de Mantenimiento.
z Responsable de Operación.
z Responsable de Sistemas.
z Responsable de Seguridad.
z Responsable de Calidad.
Todos ellos ejercen labores de coordinación y dirección de
equipos humanos especializados en actividades propias.

Jefe de Proyecto
Es la figura principal.
Recibe el apoyo de los distintos responsables durante la
realización de procesos o determinadas actividades a lo
largo del proyecto.
Las tareas del Jefe de Proyecto son las siguientes:
z Estima el esfuerzo necesario para llevar a cabo el proyecto.
z Selecciona la estrategia de desarrollo.
z Determina la estructura de la estrategia seleccionando los
procesos principales.
z Establece la planificación del proyecto, fijando el calendario de
hitos y entregas.
z Realiza las labores de seguimiento y control del proyecto.

Jefe de Proyecto
Tareas del Jefe de Proyecto:
z Revisa la evaluación de resultados.
z Coordina el equipo de proyecto.
z Gestiona y resuelve las incidencias que puedan surgir durante la
realización del proyecto.
z Realiza la actualización de la planificación inicial.
z Realiza los informes de seguimiento.
z Archiva la documentación de gestión del proyecto una vez que
éste ha finalizado.

Otros Responsables
Los responsables de Implantación, Operación, Sistemas y
Mantenimiento, participan en los procesos principales del
desarrollo, ofreciendo su apoyo al Jefe de Proyecto.
Poseen mayor conocimiento de los aspecto organizativos

y de procedimientos habituales en la organización en sus
áreas de responsabilidad concretas.
Aseguran la disponibilidad de los recursos necesarios y la

participación activa del equipo humano que coordinan.

Otros Responsables
Los responsables de Seguridad y Calidad aportan
información relativa a las normas y procedimientos
habituales en la organización, completándolos en su caso
de acuerdo con los requerimientos particulares del
sistema en colaboración con el Jefe de Proyecto.
Ofrecen asesoramiento sobre todos los aspectos de
Seguridad y Calidad relativos tanto al producto como el
proceso seguido para su obtención, analizando los riesgos
y determinando las medidas de control oportunas.
Coordinan a los integrantes de los equipos de Seguridad y
Calidad.

Perfil Consultor
Los participantes que se engloban dentro de este perfil
son los siguientes:
z Consultor.
z Consultor Informático.
9 Consultor de las Tecnologías de la Información.
9 Consultor de Sistemas de Información.
z Especialista en Comunicaciones.
z Técnico de Sistemas.
z Técnico de Comunicaciones.

Perfil Consultor
La función de los consultores es asesorar en las
cuestiones sobre las que tienen conocimiento
especializado.
Dos tipos de consultores:
z Consultor: asesora en los aspectos relativos al negocio.
z Consultor Informático: aserora en temas informáticos.
En el ámbito de la consultoría informática se distingue
entre:
z Tecnologías de la Información.
z Sistemas de Información.

Tecnologías de la Información
Este consultor aporta:
z Conocimiento de las últimas tecnologías.
z Participa en la evaluación de las distintas alternativas
tecnológicas.
z Participa en la validación y selección de la solución más adecuada
para el sistema.

Sistemas de Información y Otros
Este consultor aporta:
z Opinión experta, pericia o conocimientos relativos a los requisitos
del negocio, técnicos y de usuario.
Los técnicos y especialistas en sistemas y comunicaciones

cuentan con una visión más precisa de la tecnología
existente en el momento.
Aportan también su experiencia práctica a la hora de
valorar alternativas tecnológicas y participan activamente
durante su implantación y puesta en producción.

Perfil Analista
Los participantes que se engloban dentro de este perfil son los
siguientes:
z Analista.
z Administrador de Bases de Datos.
z Equipo de Arquitectura.
z Equipo de Formación.
z Equipo de Implantación.
z Equipo de Operación.
z Equipo de Seguridad.
z Equipo de Soporte Técnico.
z Equipo de Proyecto.
z Grupo de Aseguramiento de la Calidad.

Perfil Analista
Los analistas son los encargados de elaborar un catálogo detallado de
requisitos que describan de forma precisa el sistema.
Este catálogo se obtiene mediante entrevistas y sesiones de trabajo
con los responsables de la organización y usuarios.
Son los interlocutores entre los usuarios y el equipo de proyecto en lo
que se refiere a requisitos.
Con el catálogo de requisitos los analistas elaboran los distintos
modelos que sirven de base para el diseño:
z Modelo de datos (análisis estructurado).
z Modelos de clases e interacción de objetos (análisis orientado a objetos).

Administrador de Base de Datos
Participa en las siguientes tareas:
z Diseño físico de datos, definiendo la estructura física de datos que
utilizará el sistema a partir del modelo lógico de datos normalizado
o del modelo de clases.
z Migración de datos, estimando los volúmenes de las estructuras
de datos implicadas.
z Carga inicial de datos.
z Gestión una vez el sistema está en producción.

Equipo de Proyecto
Participa a lo largo de todo el proceso de desarrollo y
mantenimiento del sistema de información.
Su composición puede ir variando en función de las
características del proyecto o del proceso que se esté
realizando.
Se puede diferenciar así los siguientes equipos:
z Implantación.
z Operación.
z Mantenimiento.
z Arquitectura.
z Soporte técnico.
z Seguridad.

Equipo de Formación
El equipo de formación es el encargado de preparar e
impartir la formación al equipo responsable de la
implantación y operación del sistema. Para ello tiene que
elaborar un plan de formación que incluye:
z Cursos de formación y contenidos.
z Recursos humanos.
z Infraestructura.
z Contenido de formación que deberá recibir el usuario.
z Seguimiento de dicha formación.

Grupo de Aseguramiento de la Calidad
Dirigido por el responsable de calidad, este grupo
desarrolla el plan de aseguramiento de calidad específico
para el proyecto, reflejando las actividades de calidad a
realizar.
Este grupo participa en la revisión de los productos
seleccionados, comprobando que se han llevado a cabo
las medidas de calidad establecidas.
Este grupo es completamente independiente del equipo
del proyecto.

Perfil Programador
Tanto la participación como funciones de los
programadores son concretas y limitadas en los procesos
de construcción y mantenimiento de los sistemas.
Los programadores son miembros del equipo de proyecto,

y su función es la de construir el código del producto en
base al diseño técnico realizado por el analista.
El programador es el encargado de realizar las pruebas

unitarias del código.

Paradigmas de
Organización
del Equipo de
Software

Paradigmas de Organización
La mejor estructura de equipo depende del estilo de
gestión de una organización, el número de personas que
compondrá el equipo, sus niveles de preparación y la
dificultad general del problema.
Existen diferentes organigramas de equipo según

diferentes autores, aunque cualquiera que sea la
organización del equipo, el objetivo para todos los
gestores de proyecto es colaborar para crear un equipo
que presente cohesión.

Paradigmas de Organización
A continuación mostramos dos paradigmas:
z M.Mantei. The Effect of Programing Team Structures on
Programming Task.
z L. Constantine. Work Organization: Paradigms for Project
Management and Organization.
Paradigmas de Mantei:
z Descentralizado Democrático (DD); Descentralizado Controlado
(DC); Centralizado Controlado (CC).
Paradigna de Cosntantine:
z Cerrado (C); Aleatorio (AL); Abierto (A); Sincronizado (S).

Paradigmas
Descentralizado Democrático (DD).
z El equipo de ingeniería no tiene un jefe permanente. Se nombran
coordinadores de tareas a corto plazo. Las decisiones se toman
por consenso. La comunicación del equipo es horizontal.
z Los equipos descentralizados producen más y mejores soluciones.
La estructura DD es buena para problemas difíciles. Este tipo de
organización es para grupos que permanecen mucho tiempo
juntos. Aumentan la moral.
z Necesitan mucha comunicación. El rendimiento es inversamente
proporcional a la cantidad de información. Problemas pequeños.
Problemas con baja modularidad. Producen más defectos en los
productos. Al ser un equipo descentralizado necesita más tiempo
para llevar a cabo una tarea.

Paradigmas
Descentralizado Controlado (DC).
z Este equipo de ingeniería del software tiene un jefe definido que
coordina tareas específicas y jefes secundarios que tienen
responsabilidades sobre subtareas. La resolución de problemas
sigue siendo una actividad del grupo, pero la implementación de
soluciones se reparte entre los subgrupos por el jefe de equipo. La
comunicación entre subgrupos e individuos es horizontal. También
hay comunicación vertical a lo largo de la jerarquía de control.
z Buenos para problemas complejos. Buenos para problemas
grandes. Buenos cuando hay una modularidad alta.

Paradigmas
Centralizado Controlado (CC).
z El jefe del equipo se encarga de la resolución de problemas a alto
nivel y la coordinación interna del equipo. La comunicación entre
el jefe y los miembros del equipo es vertical.
z Bueno para proyecto grandes. Bueno cuando hay alta
modularidad. Buenos cuando producen software similar.
z Son menos innovadores.

Paradigmas
Cerrado (C).
z Paradigma con jerarquía tradicional.
z Bueno para proyectos similares.
z Poca innovación.
Aleatorio (AL).
z Estructura al equipo libremente y depende de la iniciativa
individual de los miembros del equipo.
z Buenos cuando se requiere innovación y avances tecnológicos.
z No son buenos cuando se quiere un rendimiento ordenado.

Paradigmas
Abierto (A).
z Asigna unos controles al paradigma Aleatorio. El trabajo se
desarrolla en colaboración, con mucha comunicación y toma de
decisiones consensuadas.
z Buenos para problemas complejos.
z No son buenos cuando se quiere rendimiento.
Sincronizado (S).
z Se basa en la compartimentación natural de un problema y
organiza los miembros del equipo para trabajar en partes del
problema con poco comunicación activa entre ellos.

Nuestra propuesta
Nosotros proponemos que los diferentes paradigmas que
se han mostrado anteriormente, pueden ser utilizados de
forma híbrida, de la siguiente manera:
z Cuando entra alguien nuevo entraría en el modelo CC.

Posteriormente pasaría al modelo DC y finalmente podría pasar al
como DD.

Coordinación y
Comunicación

Coordinación y Comunicación
Motivos por los que los proyectos de software pueden
tener problemas.
z Escala; Incertidumbre; Interoperatividad (el software antiguo
debe comunicarse con el nuevo).
Para enfrentarse a estos problemas el equipo debe
disponer de métodos efectivos para coordinar a la gente,
es decir, son necesarios mecanismos de comunicación
formales e informales entre todos los miembros (p.e.
UML, realización de reuniones).

Coordinación y Comunicación
Formal. Enfoque Impersonal. Incluye documentos de IS y
entregas, memorandos técnicos, hitos del proyecto, planificaciones
del programa y herramientas de control.
Formal. Procedimientos Interpersonales. Se centra en las
actividades de garantía de calidad aplicada a los productos de IS.
Informal. Procedimientos Interpersonales. Reuniones de grupo
para la divulgación de información y resolución de problemas.
Comunicación Electrónica. Incluye correo electrónico, boletines de
noticias electrónicos y videoconferencias.
Red Interpersonal. Discusiones informales entre los miembros del
equipo y con personas que puedan aportar al proyecto aunque no
pertenezcan al proyecto.

Reglas para Conseguir un Equipo
Para conseguir un equipo de alto rendimiento:
z Los miembros del equipo deben confiar unos en otros.
z La distribución de habilidades debe adecuarse al problema.
z Para mantener la unión del equipo, los inconformistas tienen que
ser excluidos del mismo.
Cuando se habla de equipo no se habla de grupo de
personas, se habla de un grupo cuajado de personas tan
fuertemente cohesionado que el todo es mayor que la
suma de las partes.

Factores Tóxicos para un Equipo
Atmósfera de trabajo frenética en la que los miembros del
equipo gastan energía y se descentran de los objetivos del
trabajo a desarrollar.
Alta frustración causada por factores tecnológicos, del
negocio, o personales que provocan fricción entre los
miembros del equipo.
Procedimientos coordinados pobremente o fragmentados.
Definición confusa de los papeles a desempeñar
produciendo una falta de responsabilidad y la acusación
correspondiente.
Continua y repetida exposición al fallo, que conduce a la
perdida de confianza y a una caída de la moral.

Seguridad

Seguridad en un Sistema de
Información
¿Por qué?
¿Para qué?
¿Dónde (en el proyecto)?
¿Cómo?
¿Quiénes?

Seguridad. ¿Por qué?
El uso de los medios electrónicos, informáticos y telemáticos supone
unos beneficios evidentes para los ciudadanos; pero también da lugar
a ciertos riesgos que deben minimizarse con medidas de seguridad
que garanticen la autenticación, confidencialidad, integridad
y disponibilidad de los sistemas de información. Por tanto es
necesario el uso de una metodología bien definida y actualizada de
seguridad que mantenga nuestro sistema a salvo de los distintos
peligros que le acechan.
Es muy importante resaltar la importancia de la seguridad si nuestro
sistema maneja información personal reservada pues en el caso de
ser objeto de un ataque pasaríamos, como responsables del sistema,
de víctimas (del ataque) a inculpados (por violación de la LORTAD,
Ley Orgánica de Regulación del Tratamiento Automatizado de los
Datos de carácter personal, es decir, la confidencialidad de dichos
datos).

Seguridad. ¿Para qué?
Para proteger los denominados activos del sistema de posibles
ataques que den lugar a accesos no autorizados (que podrían derivar
en responsabilidades penales para los responsables del sistema) o a
comportamientos no deseados del sistema.
La lógica consecuencia de la materialización de estos ataques sería un
pérdida de la confianza en el sistema por parte del cliente que
descartaría su uso y rompería las relaciones con la organización de
desarrollo de software con la consiguiente pérdida de prestigio.
Además de las responsabilidades penales antes mencionadas en
relación con la LORTAD, los criterios de seguridad deben especificarse
en el contrato por lo que un mal funcionamiento de los mecanismos
de seguridad puede dar lugar a la cancelación del mismo permitiendo
al cliente eludir el pago.

Seguridad. ¿Para qué?
Por tanto es imprescindible integrar una metodología
enfocada a la seguridad del sistema en el desarrollo del
mismo.
La metodología recomendada es MAGERIT, desarrollada
por el Ministerio de Administraciones Públicas, que
permite un seguimiento exhaustivo de la seguridad del
sistema ajustándose a criterios como los de ITSEC o
Criterios Comunes de Evaluación de la Seguridad de los
Productos y Sistemas de Información, que permitan la
posterior homologación y certificación del sistema de
información desde el punto de vista de la seguridad.

Seguridad. ¿Dónde?
La seguridad debe ser un aspecto omnipresente en
cualquier proyecto de desarrollo software, no sólo en
cuanto al estudio de la seguridad requerida por el sistema
de información a desarrollar, sino también en los propios
procesos de desarrollo, pues la organización de desarrollo
de software debe estar sujeta también a una política de
seguridad tan fuerte y robusta como la situación lo
requiera. Más que realizarse en paralelo con el proyecto,
como se podría pensar, se integra en él estableciendo
criterios a los que debe estar sujeto cada actividad
realizada o cada producto generado dentro del proyecto.

A continuación se muestra un diagrama que muestra la
situación exacta de la metodología recomendada,
MAGERIT.

MAGERIT no abarca todo el espectro de la seguridad de
un sistema de información, se limita al análisis y gestión
de riesgos, sin embargo su documentación no está exenta
de sugerencias, explicaciones y referencias a textos más
completos sobre los demás aspectos de la seguridad.

Seguridad. ¿Cómo?
MAGERIT consta de cuatro fases:
1. Planificación del Proyecto de Riesgos: Estimaciones iniciales de los
riesgos que pueden afectar al sistema de información así como del tiempo y
los recursos que su tratamiento conllevará.
2. Análisis de Riesgos: Se estima el impacto que tendrán los riesgos en la
organización, cuestión muy importante, puesto que si bien la seguridad es
fundamental, su uso desproporcionado puede afectar gravemente al
rendimiento del sistema por lo que es necesario establecer un umbral de
riesgo deseable (tolerable) que debe superar un determinado riesgo para ser
objeto de tratamiento.
3. Gestión de riesgos: Se seleccionan posibles soluciones para cada riesgo, en
este apartado son fundamentales las prácticas de simulación.
4. Selección de salvaguardas: Se seleccionan los mecanismos que
implementarán las soluciones seleccionadas en la fase anterior.

Seguridad. ¿Cómo?

Seguridad. ¿Quiénes?
Todos los implicados tanto en el proyecto de desarrollo
como en el uso posterior del sistema de información.
Empezando por una primera labor del cliente que
determina los objetivos, la estrategia y la política de
seguridad, pasando por los responsables de la propia
organización de desarrollo, los desarrolladores, y,
finalmente, los usuarios finales que deben ser objeto de
un campaña de concienciación y de formación en
cuestiones de seguridad.
Será necesario definir (y hacer saber) de forma clara y
precisa las obligaciones y responsabilidades de todos los
implicados en el desarrollo y posterior uso del sistema.

Calidad

Calidad en un Sistema de Información
¿Por qué?
¿Para qué?
¿Dónde (en el proyecto?.
¿Cómo?
¿Quiénes?

Concepto de Calidad
Definición.
z “Totalidad de características de un producto o servicio relativas a
su capacidad para satisfacer unas necesidades dadas”
(ANSI/ASQC A3-1978).
z “La calidad del software es el grado con el que un sistema,
componente o proceso cumple los requerimientos especificados y
las necesidades o expectativas del cliente o usuario”. (IEEE, Std.
610-1990).
Gestión de la calidad:
z “Conjunto de acciones planificadas y sistemáticas que son
necesarias para proporcionar la confianza adecuada en que un
producto o servicio satisfará los requisitos dados sobre la calidad”
(AENOR 1992, UNE-66900: Vocabulario de calidad)

Calidad. ¿Por qué?
Es imprescindible transmitir al cliente confianza en que el
software desarrollado cumple y cumplirá los requisitos
especificados (y otros no especificados pero implícitos en
el propio producto). En definitiva, el cliente necesita saber
que está adquiriendo un buen producto que se ajusta
rigurosamente a sus necesidades, estos aspectos se
manejan con el concepto de calidad del software.
No es posible generar un producto de calidad sin seguir
una metodología, por lo tanto el concepto de calidad
estará referido no sólo al producto final, sino también al
proceso de desarrollo del mismo.

Calidad. ¿Por qué?

Calidad. ¿Para qué?
Es necesario convertir una apreciación subjetiva ‘un buen producto
que se ajusta a las necesidades del cliente’ en un análisis objetivo y
riguroso que demuestre fehacientemente:
z Que el producto cumple todos y cada uno de los requisitos especificados
por el cliente.
z Que el producto cumple todos y cada uno de los requisitos no
especificados por el cliente pero implícitos en el propio sistema.
z Que lo hace atendiendo a las normas y estándares a los que está sujeto.
z Que lo hace de forma correcta, fiable, eficiente e íntegra. Además será un
producto flexible, portable, capaz de interactuar con otros productos,
reutilizable, y fácil de usar, mantener y probar. Aspectos todos estos que
deben medirse siguiendo alguna métrica de aseguramiento de la calidad.

Calidad. ¿Para qué?

Calidad. ¿Dónde?
Fuera del proyecto, es decir, a nivel de organización se lleva a cabo
la gestión de la calidad, materializada en el sistema de calidad de la
organización (compuesto por personal y sus responsabilidades,
procedimientos y recursos de calidad).
Dentro de este marco se elabora el plan de aseguramiento de la
calidad para el proyecto concreto que se vaya a desarrollar tomando
aquellos elementos del sistema de calidad que se estimen necesarios.
El encargado de llevar a cabo dicho plan será el equipo de
aseguramiento de la calidad que será independiente del equipo de
desarrollo y realizará sus tareas correspondientes, a diferencia del
equipo de seguridad, en paralelo con las tareas de desarrollo, si bien
tendrán lugar las lógicas realimentaciones pues, por ejemplo, no es
posible validar un producto si el equipo de calidad no determina que
alcanza unos valores aceptables en términos de calidad.

Calidad. ¿Cómo?
A nivel organizativo se lleva a cabo la gestión de seguridad, separada
de la gestión de proyectos, cuyo cometido es el establecimiento de los
niveles de calidad requeridos, la definición de normas y estándares de
calidad (política de calidad) y la implicación y concienciación de todos
los miembros de la organización de la importancia de la calidad, pues
no hay que olvidar que si bien el equipo de calidad es el encargado de
evaluar la calidad de los productos, es el equipo de desarrollo el
encargado de alcanzar los parámetros de calidad establecidos.
Para llevar a cabo la gestión de la calidad es necesario contar con un
sistema de calidad que estará formado por los miembros de la
organización especializados en tareas de calidad, por la definición de
los procedimientos de calidad y por los recursos (por ejemplo,
herramientas, manual, estándares y normas) de calidad.

Calidad. ¿Cómo?
A nivel del proyecto se llevan a cabo el control y el
aseguramiento de la calidad. Cuando se define un nuevo
proyecto, de forma paralela se define un plan de calidad
para el mismo tomando aquellos elementos que se
estimen necesarios del sistema de calidad de la empresa.
El aseguramiento de la calidad consiste en la ejecución de
las tareas especificadas en el plan de calidad del proyecto,
mientras que el control de la calidad consiste en la
verificación del cumplimiento de los niveles de calidad
establecidos por la organización o por el plan de calidad
para las actividades y productos del proyecto.

Calidad. ¿Cómo?
Ésta es la visión de la infraestructura de calidad en una organización
durante la ejecución de un proyecto de desarrollo de software, sin
embargo, al plantear la pregunta ¿cómo? podemos referirnos en
realidad a la manera de establecer los niveles de calidad; la respuesta
es mediante la medición, es decir, la cuantificación de conceptos
normalmente cualitativos. No es posible tratar con rigor la calidad de
un producto o proceso sin llevar a cabo mediciones.

Calidad. ¿Quiénes?
El equipo de aseguramiento de la calidad opera de forma
independiente del de desarrollo, sin embargo, ambos
participan en el objetivo final, que el producto alcance un
nivel de calidad satisfactorio.
Si bien los primeros se encargan de la evaluación de los
distintos productos y procesos desde el punto de vista de
la calidad y pueden actuar como asesores realizando las
recomendaciones oportunas, los segundos son los
encargados de hacer que el producto final alcance esos
valores, así como de llevar a cabo los procesos de
desarrollo atendiendo a los parámetros de calidad
establecidos por la organización.


TEMA1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TEMA1

Cargado por

Copyright:

Formatos disponibles

TEMA 2

Dr. José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Atendiendo a las características de complejidad y

José Ignacio Peláez Sánchez

 Cada uno de estos perfiles tienen una serie de

José Ignacio Peláez Sánchez

 Intervienen en todos los procesos principales, siendo sus

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 La responsabilidad del Comité de Dirección es la siguiente:

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Esta misma función la desempeñan con mayor nivel de

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Poseen mayor conocimiento de los aspecto organizativos

 Aseguran la disponibilidad de los recursos necesarios y la

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Los técnicos y especialistas en sistemas y comunicaciones

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Los programadores son miembros del equipo de proyecto,

 El programador es el encargado de realizar las pruebas

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Existen diferentes organigramas de equipo según

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

z Cuando entra alguien nuevo entraría en el modelo CC.

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

¿Dónde (en el proyecto)?

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Atendiendo a las características de complejidad y

Cada uno de estos perfiles tienen una serie de

Intervienen en todos los procesos principales, siendo sus

La responsabilidad del Comité de Dirección es la siguiente:

Esta misma función la desempeñan con mayor nivel de

Poseen mayor conocimiento de los aspecto organizativos

Aseguran la disponibilidad de los recursos necesarios y la

Los técnicos y especialistas en sistemas y comunicaciones

Los programadores son miembros del equipo de proyecto,

El programador es el encargado de realizar las pruebas

Existen diferentes organigramas de equipo según

¿Dónde (en el proyecto)?

¿Dónde (en el proyecto?.