Garantía de la calidad del software

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

La gestión de la calidad

Gestión de la calidad: "Aspectos de la función de gestión que determinan y aplican la política de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificación de la calidad, el control de la calidad, la garantía de calidad y la mejora de la calidad". Dentro de la gestión de la calidad se observa:

• Gestión de la calidad de software (ISO 9000): Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificación de la calidad, el control de la calidad, el aseguramiento (garantía) de la calidad y la mejora de la calidad, en el marco del sistema de calidad

• Política de calidad (ISO 9000): Directrices y objetivos generales de una organización, relativos a la calidad, tal como se expresan formalmente por la alta dirección.

Principios de la gestión de la calidad según ISO 9000: 2000

Los ocho principios de la gestión de la calidad identificados para lograr los objetivos de la calidad, según "ISO 9000:2000 Sistemas de Gestión de la Calidad. Fundamentos y vocabulario." son:

1. Enfoque al cliente. Las organizaciones dependen de sus clientes y por la tanto deberían comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de los clientes.
2. Liderazgo. Los líderes establecen la unidad de propósito y la orientación de la organización. Ellos deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organización.
3. Participación del personal. El personal, a todos los niveles, es la esencia de una organización y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organización.
4. Enfoque basado en procesos. Un resultado deseado se alcanza más eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso.
5. Enfoque de sistema hacia la gestión. Identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos.
6. Mejora continua. La mejora continua del desempeño global de la organización debería ser un objetivo permanente de ésta.
7. Enfoque basado en hechos para la toma de decisiones. Las decisiones eficaces se basan en el análisis de los datos y la información.
8. Relación mutuamente beneficiosa con el proveedor. Una organización y sus proveedores son interdependientes, y una relación mutuamente beneficiosa aumenta la capacidad de ambos para crear valor.

Para entender bien la relación de estos aspectos, es preferible observar la siguiente gráfica:


 Ver màs informaciòn en: http://www.monografias.com/trabajos59/calidad-software/calidad-software2.shtml

Tabla de gestión de riesgos

Ej 2: Resolver Caso de Estudio Sky Light Tour aplicando las métricas

Agencia de Viajes Sky Light Tour en Nicaragua desea realizar una mercadotecnia defensiva de sus servicios de viajes de paquetes turísticos, para ello requiere de un Sitio Web que sea promocionado por los diversos medios de comunicación. El sitio web debe presentar mapa del pais, ciudades, hoteles por ciudad, clases y su respectiva descripción, recreación, restaurantes, alquiler vehicular y sus promociones por temporadas.

Entidades y atributos de los sub objetivos

Cliente (id_cliente, nombre, apellido, num_cedula, dirección, país, teléfono, sexo)

Reservación (id_reservación, id_cliente, id_vuelo, id_hotel, id_paquete, país_origen, país_destino, fecha_salida, fecha_regreso,hora_salida, hora_regreso)

Vuelo (id_vuelo, num_avión, aeropuerto, costo_boleto, num_asiento, tipo_clase)

Paquete (id_paquete, tipo_paquete, costo_paquete, duración_paquete)

Hotel ( id_hotel, id_vehiculo, nombre_hotel, país, dirección_hotel, telf._hotel, costo_habitación, personas_habitación,  serv.extras_hotel)

Vehiculo ( id_vehiculo, marca, placa, color, num_chasis, costo_dia)

Usuario (id_usuario, nombre_usuario, apellido_usuario, dirección_usuario, telf._usuario, país_usuario)

Pais_Destino ( id_paísdestino, id_hotel, ciudades, fotos, videos, mapa_pais, clima_pais)

Recolecta de datos y cálculos de indicadores

 

Análisis y Gestión de Riesgos

En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente con nuestras acciones del pasado. La pregunta es, podemos por tanto, cambiando nuestras acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinión, de acciones, de lugares... En tercer lugar, el riesgo implica elección y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte, es una de las pocas cosas inevitables de la vida.


El riesgo siempre implica dos características:

• Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad. 
• Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos. cliente y requisitos y su impacto en un proyecto de software.

Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz. verificación y de mantenimiento. Además. las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las "tecnologías punta" son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

Los riesgos del negocio amenazan la viabilidad del software a construir Los riesgos del negocio a menudo ponen en peligro ei proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado),

2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico),

3. Construir un producto que el departamento de ventas no sabe cómo vender,

4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección),

5. Perder presupuesto o personal asignado (riesgos de presupuesto).

 Ver más en: http://www.wikilearning.com/curso_gratis/gestion_de_riesgos_en_ingenieria_del_software-introduccion/3620-1

COCOMO

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado. 

La función básica que utilizan los tres modelos es:

E = a(Kl)^b * m(X) donde:

a y b son constantes con valores definidos en cada submodelo

Kl es la cantidad de líneas de código, en miles.

m(X) Es un multiplicador que depende de 15 atributos.

El resultado se da en unidades salario/mes y horas-hombre.

A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:

• Modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).

• Modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.

• Modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

Modelo básico: Se utiliza para obtener una primera aproximación rápida del esfuerzo, y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:

MODO	a	b	c	d
Orgánico	2.40	1.05	2.50	0.38
Semilibre	3.00	1.12	2.50	0.35
Rígido	3.60	1.20	2.50	0.32

Estos valores son para las fórmulas:

• Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Kl^b)

• Tiempo de desarrollo del proyecto (TDEV) = c*(MM^d)

• Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV

• Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal.

 Modelo intermedio: Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación. Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar. Los valores de las constantes a reemplazar en la fórmula son:

MODO	a	b
Orgánico	3.20	1.05
Semilibre	3.00	1.12
Rígido	2.80	1.20

Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.

Atributos: Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).

El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:

Atributos	Valor
	Muy bajo	Bajo	Nominal	Alto	Muy alto	Extra alto
Atributos de software
Fiabilidad	0,75	0,88	1,00	1,15	1,40
Tamaño de Base de datos		0,94	1,00	1,08	1,16
Complejidad	0,70	0,85	1,00	1,15	1,30	1,65
Atributos de hardware
Restricciones de tiempo de ejecución			1,00	1,11	1,30	1,66
Restricciones de memoria virtual			1,00	1,06	1,21	1,56
Volatilidad de la máquina virtual		0,87	1,00	1,15	1,30
Tiempo de respuesta		0,87	1,00	1,07	1,15
Atributos de personal
Capacidad de análisis	1,46	1,19	1,00	0,86	0,71
Experiencia en la aplicación	1,29	1,13	1,00	0,91	0,82
Calidad de los programadores	1,42	1,17	1,00	0,86	0,70
Experiencia en la máquina virtual	1,21	1,10	1,00	0,90
Experiencia en el lenguaje	1,14	1,07	1,00	0,95
Atributos del proyecto
Técnicas actualizadas de programación	1,24	1,10	1,00	0,91	0,82
Utilización de herramientas de software	1,24	1,10	1,00	0,91	0,83
Restricciones de tiempo de desarrollo	1,23	1,08	1,00	1,04	1,10

Modelo Detallado: Presenta principalmente dos mejoras respecto al anterior:

• Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la aplicación, utilización de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y además van variando de una etapa a otra.

• Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema.

Métricas del Software

Las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. El proceso se mide para intentar mejorarlo, el producto para intentar aumentar su calidad. Las métricas se clasifican en:


1) Orientadas al tamaño: Son medidas directas del software y del proceso.

kldc= cantidad de líneas de código.

productividad	kldc/ personas- mes.
calidad	errores/kldc.
costo	Dólares/kldc.
documentación	Páginas de documentación/kldc.

2) Orientadas a la función:  Son medidas indirectas del software se centran en la funcionalidad o utilidad del programa. Miden la cantidad de funciones que se van a lograr para lo que se precisa un excelente relevamiento, precisiones estables.Se calculan los puntos de función: número de entradas, número de salidas, números de peticiones, números de archivos.

Una vez calculados los puntos de función: PF=puntos de función

productividad	PF/pers-mes
calidad	errores/PF
costo	Dólares/PF
documentación	pág. de doc./PF

3) Orientadas a la persona:  Analizan en relación a las herramientas de desarrollo, el grado de capacitación en el uso de la herramienta y la complejidad estimada de la tarea.

Métricas de Calidad: Las métricas a posteriori incluyen :

• Corrección: Grado con que el software realiza la función requerida.
• Facilidad de mantenimiento: Facilidad con la que se puede corregir el programa. Se utilizan medidas indirectas y se calcula el tiempo medio entre cambios.
• Integridad: Habilidad de un sistema para resistir ataques contra seguridad. Se mide en base a una probabilidad de recibir ataque y la probabilidad de repelerlo.
• Facilidad de uso: Es un intento de cuantificar la amistad con el usuario. Se mide en función a la habilidad y tiempo requeridos para aprender el sistema, al aumento neto de productividad y la disponibilidad del usuario hacia el sistema.

 
Ver màs en: http://www.monografias.com/trabajos15/ingenieria-software/ingenieria-software2.shtml

Conceptos del espectro de gestión

El espectro de la gestión

La gestión eficaz de un proyecto de software se centra en las cuatro P's: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.

Personal

El <<factor humano>> es tan importante que el Instituto de Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión de personal (MMCGP) <<para aumentar la preparación de organizaciones del software.

El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas para el personal que desarrolla software: 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.

Producto

El desarrollador de software y el cliente deben reunirse para definir los objetivos del producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los requisitos del software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se conseguirán (desde el punto de vista del cliente).

Proceso

Un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. Un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.

Proyecto

Para evitar el fracaso del proyecto, un gestor de proyectos de software y los ingenieros de software que construyeron el producto deben eludir un conjunto de señales de peligro comunes; comprender los factores del éxito críticos que conducen a la gestión correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar y controlar el proyecto.

PERSONAL

Los participantes: El proceso del software (y todos los proyectos de software) lo componen participantes que pueden clasificarse en una de estas cinco categorías:

1.- Gestores superiores,que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.
2.- Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.
3.- Profesionales, que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.
4.- Clientes, que especifican los requisitos para la ingeniería del software y otros elementos que tienen menor influencia en el resultado.
5.- Usuarios finales, que interaccionan con el software una vez que ha entregado para la producción.

Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Y este es el trabajo del jefe del equipo.

Los jefes de equipo:Weinberg sugiere que el éxito de los gestores de proyecto se basa en aplicar un estilo de gestión en la resolución de problemas. Es decir, un gestor de proyectos de software debería concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo (mediante palabras y, mucho más importante, con hechos) que la calidad es importante y que no debe verse comprometida.

El equipo de software:Existen casi tantas estructuras de organización de personal para el desarrollo de software como organizaciones que se dedican a ello. Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas trabajando durante k años:

1. n individuos son asignados a m diferentes tareas funcionales, tiene lugar relativamente poco trabajo conjunto.
2. n individuos son asignados a m diferentes tareas funcionales (m<n) de manera que se establecen <<equipos>> informales.
3. n individuos se organizan en t equipos; a cada equipo se le asignan una o más tareas funcionales.

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. Mantei sugiere tres organigramas de equipo genéricos:

Descentralizado democrático (DD): Este equipo de ingeniería del software no tiene un jefe permanente. Más bien, <<se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas>>.

Descentralizado controlado (DC): Este equipo de ingeniería de software tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades sobre subtareas.

Centralizado controlado (CC): El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo.

Mantei describe siete factores de un proyecto que deberían considerarse cuando se planifica el organigrama de equipos de ingeniería del software:

· La dificultad del problema que hay que resolver.
· El tamaño del programa(s) resultante(s) en líneas de código o puntos de función.
· El tiempo que el equipo estará junto (tiempo de vida del equipo).
· El grado en que el problema puede ser modularizado.
· La calidad requerida y fiabilidad del sistema que se va a construir.
· La rigidez de la fecha de entrega.
· El grado de sociabilidad (comunicación) requerido para el proyecto.

Los equipos CC y DC producen menos defectos que los equipos DD, pero estos datos tienen mucho que ver con las actividades específicas de garantía de calidad que aplica el equipo. Los equipos descentralizados requieren generalmente más tiempo para completar un proyecto que un organigrama centralizado y al mismo tiempo son mejores cuando se precisa una gran cantidad de comunicación.

Constantine sugiere cuatro <<paradigmas de organización>> para equipos de ingeniería del software:

1.- Un paradigma cerrado estructura a un equipo con una jerarquía tradicional de autoridad (similar al equipo CC).

2.- El paradigma aleatorio estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo.

3.- El paradigma abierto intenta estructurar a un equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado, pero también utiliza el paradigma aleatorio.

4.- El paradigma sincronizado se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Constantine propone una variación en el equipo descentralizado democrático defendiendo a los equipos con independencia creativa cuyo enfoque de trabajo podría ser mejor llamado <<anarquía innovadora>>. Para conseguir un equipo de alto rendimiento:

· Los miembros del equipo deben confiar unos en otros.
· La distribución de habilidades debe adecuarse al problema.
· Para mantener la unión del equipo, los inconformistas tienen que ser excluidos del mismo.

Aspectos sobre la coordinación y la comunicación

Hay muchos motivos por los que los proyectos de software pueden tener problemas. La escala (tamaño) de muchos esfuerzos de desarrollo es grande, conduciendo a complejidades, confusión y dificultades significativas para coordinar a los miembros del equipo. La incertidumbre es corriente, dando como resultado un continuo flujo de cambios que impactan al equipo del proyecto. La interoperatividad se ha convertido en una característica clave de muchos sistemas. El software nuevo debe comunicarse con el anterior y ajustarse a restricciones predefinidas impuestas por el sistema o el producto.

Estas características del software moderno, son aspectos de la vida. Para enfrentarse a ellos eficazmente, un equipo de ingeniería del software debe establecer métodos efectivos para coordinar a la gente que realiza el trabajo. Para lograr esto se deben establecer mecanismos de comunicación formales e informales entre los miembros del equipo y entre múltiples equipos.

PRODUCTO

El gestor de un proyecto de software se enfrenta a un dilema al inicio de un proyecto de ingeniería del software. Se requieren estimaciones cuantitativas y un plan organizado, pero no se dispone de información sólida.

Ámbito del software: El ámbito se define respondiendo a las siguientes cuestiones:

Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de negocios mayor y qué limitaciones se imponen como resultados del contexto?

Objetivos de información: ¿Qué objetos de datos visibles al cliente se obtienen del software? ¿Qué objetos de datos son requeridos de entrada?

Función y rendimiento. ¿Qué función realiza el software para transformar la información de entrada en una salida? ¿Hay características de rendimiento especiales que abordar?

Descomposición del problema: La descomposición del problema, denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Durante la actividad de exposición del ámbito no se intenta descomponer el problema totalmente. Más bien, la descomposición se aplica en dos áreas principales: (1) la funcionalidad que debe entregarse y (2) el proceso que se empleará para entregarlo.

PROCESO

El gestor del proyecto debe decidir qué modelo de proceso es el más adecuado para (1) los clientes que han solicitado el producto y la gente que realizará el trabajo; (2) las características del producto en sí, y (3) el entorno del proyecto en el que trabaja el equipo de software. 

Maduración del producto y del proceso: La planificación de un proyecto empieza con la maduración del producto y del proceso. Se asumen las siguientes actividades estructurales:

· Comunicación con el cliente- tareas requeridas para establecer la obtención de requisitos eficiente entre el desarrollador y el cliente.
· Planificación- tareas requeridas para definir los recursos, la planificación temporal del proyecto y cualquier información relativa a él.
· Análisis del riesgo- tareas requeridas para valorar los riesgos técnicos y de gestión.
· Ingeniería- tareas requeridas para construir una o más representaciones de la aplicación.
· Construcción y entrega- tareas requeridas para construir, probar, instalar y proporcionar asistencia la usuario.
· Evaluación del cliente- tareas requeridas para obtener información de la opinión de cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementas durante la fase de instalación.

Descomposición del proceso: Un equipo de software debería tener un grado significativo de flexibilidad en la elección del paradigma de ingeniería del software que resulte mejor para el proyecto y de las tareas de ingeniería del software que conforman el modelo de proceso una vez elegido.

Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, el ECP estudiado anteriormente puede adaptarse al paradigma. El ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.

PROYECTO

Para gestionar un proyecto de software con éxito, debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien. En un excelente documento sobre proyectos de software, John Reel define diez señales que indican que un proyecto de sistemas de información está en peligro:

1.- La gente del software no comprende las necesidades de los clientes.
2.- El ámbito del producto está definido pobremente.
3.- Los cambios están mal realizados.
4.- La tecnología elegida cambia.
5.- Las necesidades del negocio cambian (o están mal definidas)
6.- Las fechas de entrega no son realistas.
7.- Los usuarios se resisten.
8.- Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente)
9.- El equipo del proyecto carece del personal con las habilidades apropiadas.
10.- Los gestores (y los desarrolladores) evitan buenas prácticas y sabias lecciones.

EL PRINCIPIO W5HH

El principio WWWWWHH conducen a la definición de las características clave del proyecto y el plan del proyecto resultante:

¿Por qué se desarrolla el sistema?. Dicho de otra forma, ¿justifica el propósito del negocio el gasto en personal, tiempo y dinero?

¿Qué se realizará y cuándo?. La respuesta a estas preguntas ayuda al equipo a establecer la planificación del proyecto identificando las tareas clave del proyecto y los hitos requeridos por el cliente.

¿Quién es el responsable de una función?

¿Dónde están situados organizacionalmente? No todos los roles y responsabilidades residen en el equipo de software. El cliente, los usuarios, y otros directivos también tienen responsabilidades.

¿Cómo estará realizado el trabajo desde el punto de vista técnico y de gestión?. Una vez establecido el ámbito del producto, se debe definir una estrategia técnica y de gestión para el proyecto.

¿Qué cantidad de cada recurso se necesita?. La respuesta a esta pregunta se deriva de las estimaciones realizadas basadas en respuestas a las preguntas anteriores.