INGENERIA DE SOFTWARE

Ing. Lisbeth Arévalo.

GESTION DE PROYECTOS • 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. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado. El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y herramientas eficaces al vacío. El gestor que emprende un proyecto sin un plan sólido arriesga el éxito del producto.

Personal • La necesidad de contar con personal para el desarrollo del software

altamente preparado y motivado se viene discutiendo desde los años 60 (por ejemplo, De hecho, 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 para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de 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.

PARTICIPANTES • El proceso del software (y todos los proyectos de software) lo componen

participantes que pueden clasificarse en una de estas cinco categorías: • Gestores superiores, que definen los aspectos de negocios que a menudo

tienen una significativa influencia en el proyecto. • Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y

controlar a los profesionales que realizan el trabajo de software. • Profesionales, que proporcionan las capacidades técnicas necesarias para

la ingeniería de un producto o aplicación. • Clientes, que especifican los requisitos para la ingeniería del software y

otros elementos que tienen menor influencia en el resultado. • Usuarios finales, que interaccionan con el software una vez que se 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.

• Antes de poder planificar un proyecto, se deberían establecer los objetivos y el ámbito del producto‘, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin esta información, es imposible definir unas estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso. 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).

Producto

Ámbito del software • La primera actividad de gestión de un proyecto de software

es determinar el á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 resultado 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 • 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. Diferentes conjuntos de tareas, hitos, productos del trabajo y puntos de garantía de calidad permiten a las actividades estructurales adaptarse a las características del proyecto de software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras -tales como garantía de calidad del software, gestión de la configuración del software y medición- cubren el modelo de proceso. Las actividades protectoras son independientes de las estructurales y tienen lugar a lo largo del 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. Cuando se selecciona un modelo de proceso, el equipo define entonces un plan de proyecto preliminar basado en un conjunto de actividades estructurales. Una vez establecido el plan preliminar, empieza la descomposición del proceso. Es decir, se debe crear un plan completo reflejando las tareas requeridas a las personas para cubrir las actividades estructurales

Maduración del producto y del proceso • 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.

• Ingeneria- 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 al usuario (por ejemplo: documentación y formación).

• Evaluación del cliente- tareas requeridas para obtener información de la opinión del cliente basadas en la evaluación de las representaciones de software creadas durante la fase de ingeniería e implementadas durante la fase de instalación.

• Los miembros del equipo que trabajan en cada función aplicarán todas las actividades estructurales

Descomposición del proceso • La descomposición del proceso comienza cuando el gestor

del proyecto pregunta: «¿Cómo vamos a realizar esta actividad

• Por ejemplo, un pequeño proyecto, relativamente simple, requiere las siguientes tareas para la actividad de comunicación con el cliente:

1. Desarrollar una lista de aspectos que se han de clarificar. 2. Reunirse con el cliente para resolver los aspectos que se han de clarificar. 3. Desarrollar conjuntamente una exposición del ámbito del proyecto. 4. Revisar el alcance del proyecto con todos los implicados. 5. Modificar el alcance del proyecto cuando se requiera

Descomposición del proceso • Ahora, consideremos un proyecto más complejo que tenga un

ámbito más amplio y un mayor impacto comercial. • Un proyecto como ése podría requerir las siguientes tareas para la

actividad de comunicación con el cliente: 1. Revisar la petición del cliente. 2. Planificar y programar una reunión formal con el cliente. 3. Realizar una investigación para definir soluciones propuestas y enfoques existentes. 4. Preparar un «documento de trabajo» y una agenda para la reunión formal. 5. Realizar la reunión. 6. Desarrollar conjuntamente mini-especificaciones que reflejen la información, función y características de comportamiento del software.

Proyecto • Dirigimos los proyectos de software planificados y

controlados por una razón principal es la Única manera conocida de gestionar la complejidad Y todavía seguimos esforzándonos. En 1998, los datos de la industria del software indicaron que el 26 por 100 de proyectos de software fallaron completamente y que el 46 por 100 experimentaron un desbordamiento en la planificación y en el costo. 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

• Para gestionar un proyecto de software con éxito, debemos comprender qué puede ir mal (para evitar esos problemas) y cómo hacerlo bien 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 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.

¿Cómo actúa un gestor para evitar los problemas señalados anteriormente? Se sugiere una aproximación de sentido común a los proyectos de software dividida en cinco partes: • Empezar con el pie derecho. Esto se realiza trabajando duro (muy duro) para

comprender el problema a solucionar y estableciendo entonces objetivos y expectativas realistas para cualquiera que vaya a estar involucrado en el proyecto.

• Mantenerse. Muchos proyectos no realizan un buen comienzo y entonces se desintegran lentamente. Para mantenerse, el gestor del proyecto debe proporcionar incentivos para conseguir una rotación del personal mínima.

• Seguimiento del Progreso. Para un proyecto de software, el progreso se sigue mientras se realizan los productos del trabajo (por ejemplo, especificaciones, código fuente, conjuntos de casos de prueba) y se aprueban (utilizando revisiones técnicas formales) como parte de una actividad de garantía de calidad.

• Tomar Decisiones Inteligentes. En esencia, las decisiones del gestor del proyecto y del equipo de software deberían «seguir siendo sencillas>>Siempre que sea posible,

• Realizar un Análisis «Postmortem» (después definalizar el proyecto}. Establecer un mecanismo consistente para extraer sabias lecciones de cada proyecto. Evaluar la planificación real y la prevista, reunir y analizar métricas del proyecto de software y realimentar con datos de los miembros del equipo y de los clientes, y guardar los datos obtenidos en formato escrito.

Garantía de Calidad de Software • Se dice que dos copos de nieve no son iguales. Ciertamente cuando se observa caer

la nieve, es difícil imaginar que son totalmente diferentes, por no mencionar que cada copo posee una estructura única. Este fenómeno, variación entre muestras, se aplica a todos los productos del hombre así como a la creación natural.

• El control de variación es el centro del control de calidad. Un fabricante quiere reducir la variación entre los productos que se fabrican, incluso cuando se realiza algo relativamente sencillo como la duplicación de disquetes.

• ¿Cómo se aplica esto al software? ¿Cómo puede una organización de desarrollo de software necesitar controlar la variación? De un proyecto a otro, queremos reducir la diferencia entre los recursos necesarios planificados para terminar un proyecto y los recursos reales utilizados, entre los que se incluyen personal, equipo y tiempo. En general, nos gustaría asegurarnos de que nuestro programa de pruebas abarca un porcentaje conocido del software de una entrega a otra. No sólo queremos reducir el número de defectos que se extraen para ese campo, sino también nos gustaría asegurarnos de que los errores ocultos también se reducen de una entrego a otra.

CALIDAD • El American Heritage Dictionary, define la calidad como «una característica o

atributo de algo». Como un atributo de un elemento, la calidad se refiere a las características mensurables -cosas que se pueden comparar con estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc.-. Sin embargo, el software en su gran extensión, como entidad intelectual, es más difícil de caracterizar que los objetos físicos. No obstante, sí existen las medidas de características de un programa. Entre estas propiedades se incluyen complejidad ciclomática, cohesión, número de puntos de función, líneas de código y muchas otras estudiadas Cuando se examina un elemento según sus características mensurables, se pueden encontrar dos tipos de calidad: calidad del diseño y calidad de concordancia.

• La calidad de diseño se refiere a las características que especifican los ingenieros de software para un elemento. El grado de materiales, tolerancias y las especificaciones del rendimiento contribuyen a la calidad del diseño

• La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseño durante su realización. Una vez más, cuanto mayor sea el grado de cumplimento, más alto será el nivel de calidad de concordancia.

Garantía de calidad • La garantía de calidad consiste en la auditoría y las

funciones de información de la gestión. El objetivo de la garantía de calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Por supuesto, si los datos proporcionados mediante la garantía de calidad identifican problemas, es responsabilidad de la gestión afrontar los problemas y aplicar los recursos necesarios para resolver aspectos de calidad.

Coste de calidad • El coste de calidad incluye todos los costes acarreados en la búsqueda de la calidad

o en las actividades relacionadas en la obtención de la calidad. Se realizan estudios sobre el coste de calidad para proporcionar una línea base del coste actual de calidad, para identificar oportunidades de reducir este coste, y para proporcionar una base normalizada de comparación. La base de normalización siempre tiene un precio. Una vez que se han normalizado los costes de calidad sobre un precio base, tenemos los datos necesarios para evaluar el lugar en donde hay oportunidades de mejorar nuestros procesos.

• Es más, podemos evaluar cómo afectan los cambios en términos de dinero. Los costes de calidad se pueden dividir en costes asociados con la prevención, la evaluación y los fallos.

• Entre los costes de prevención se incluyen: • planificación de la calidad, • revisiones técnicas formales, • equipo de pruebas, • formación.

Coste de calidad • Entre los costes de evaluación se incluyen actividades para tener una visión más profunda de-la

condición del producto «la primera vez a través de» cada proceso. A continuación se incluyen algunos ejemplos de costes de evaluación:

• inspección en el proceso y entre procesos, • calibrado y mantenimiento del equipo, • pruebas. • Los costes de fallos son los costes que desaparecerían si no surgieran defectos antes del envío de un

producto a los clientes. Estos costes se pueden subdividir en costes de fallos internos y costes de fallos externos. Los internos se producen cuando se detecta un error en el producto antes de su envío. Entre estos se incluyen:

• retrabajo (revisión), • reparación, • análisis de las modalidades de fallos. • Los costes de fallos externos son los que se asocian a los defectos encontrados una vez enviado el

producto al cliente. A continuación se incluyen algunos ejemplos de costes de fallos externos: • resolución de quejas, • devolución y sustitución de productos, • soporte de línea de ayuda, • trabajo de garantía.

EL ESTÁNDAR DE CALIDAD ISO 9901 • El estándar, que ha sido adoptado por más de 130 países

para su uso, se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que no es específico de la industria: está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos como cojinetes de bolas (rodamientos), secadores de pelo, automóviles, equipamientos deportivos y televisiones, así como por desarrolladores de software. Se han realizado muchos documentos que relacionan el estándar con la industria del software, pero no entran en una gran cantidad de detalles.

EL ESTÁNDAR DE CALIDAD ISO 9901 • Para la industria del software los estándares relevantes son:

• ISO 9001. Quality Systems- Model for Quality Assurance in Design, Development, Production, Installation and Servicing. Este es un estándar que describe el sistema de, calidad utilizado para mantener el desarrollo de un producto que implique diseño.

• ISO 9000-3. Guidelines for Application of ISO 9001 to the Development, Supply and Maintainance of ISO 9004-2. Quality Management and Quality System Elements -Part 2-. Este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.

• Los requisitos se agrupan bajo 20 títulos:

• Responsabilidad de la gestión.

• Inspección, medición y equipo de pruebas.

• Sistema de calidad.

• Inspección y estado de pruebas.

• Revisión de contrato.

• Acción correctiva.

• Control de diseño.

EL ESTÁNDAR DE CALIDAD ISO 9901 • Control de producto no aceptado. • Control de documento. • Tratamiento, almacenamiento, empaquetamiento y entrega. • Compras. • Producto proporcionado al comprador. • Registros de calidad. • Identificación y posibilidad de seguimiento del producto, • Auditorías internas de calidad. • Formación • Control del proceso • Servicios. • Inspección y estado de prueba. • Técnicas estadísticas.