Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Capà Tulo 3. Gestià N de Proyectos Software
Capà Tulo 3. Gestià N de Proyectos Software
Un subconjunto de la gestión de riesgos que está ganando cada vez más atención es la
Gestión de Oportunidades, lo que significa la misma cosa, sólo que el resultado del
riesgo potencial tendrá un efecto positivo, en lugar de un impacto negativo. Aunque
teóricamente se manejan de la misma manera, el uso del término "oportunidad" en lugar
del término “riesgo”, como algo negativo, ayuda a mantener el equipo centrado en los
posibles resultados positivos de cualquier riesgo dado que pueda registrarse en el
proyecto, como proyectos spin-off, ganancias inesperadas, o liberar recursos
adicionales.
Otra parte importante de la gestión de proyectos es la gestión del cambio. La gestión del
cambio es el proceso de identificar, documentar, analizar, priorizar y acordar cambios
durante el desarrollo del proyecto. El análisis de impacto del cambio en el desarrollo (ya
57
Arquitectura de Fault Tolerance System distribuido entre UAVs
sea un ámbito nuevo o alterado) es también una parte importante del proceso de
ingeniería de software. El equipo de desarrollo de software identifica las necesidades
que han cambiado o requerimientos nuevos de un cliente, y una vez identificados, estos
requisitos forman la base para el diseño modificable de la solución buscada.
Teóricamente, cada cambio puede afectar el cronograma y presupuesto de un proyecto
de software, y por lo tanto, por definición, se debe incluir el riesgo-beneficio antes de su
aprobación.
Para llevar a cabo una gestión de proyectos adecuada hace falta realizar una gestión de
versiones. La Gestión de Versiones es el proceso de identificar, documentar, priorizar y
consensuar los lanzamientos de software, así como controlar las fechas de lanzamientos
y comunicar a las partes interesadas pertinentes. La mayoría de los proyectos de
software pueden lanzar versiones con diferentes estados, siendo estos en desarrollo, en
prueba o en producción. En proyectos muy grandes, donde los equipos están muy
distribuidos, estos necesitan integrar su trabajo antes del lanzamiento de programas
funcionales a los usuarios. A menudo, puede haber más de un estado de prueba, es
decir, este estado puede referirse a pruebas unitarias o pruebas de integración, antes de
su lanzamiento para las pruebas de aceptación del usuario (UAT). [56]
Una de las claves principales en Scrum es que se tiene en cuenta que los clientes pueden
cambiar de opinión sobre lo que quieren y necesitan durante el desarrollo del producto,
es decir cambian los requisitos. En este sentido, Scrum adopta un enfoque empírico,
aceptando que el problema inicial no puede ser totalmente comprendido o definido
(debido a la naturaleza cambiante de este), y enfocando a su vez en maximizar la
habilidad del equipo a la hora de la entregar código funcional que cumpla con los
requisitos variables.
Roles
58
Arquitectura de Fault Tolerance System distribuido entre UAVs
Los roles vinculados al proyecto en el proceso Scrum y los que llevan a cabo el producir
el producto (objetivo) son los roles principales, y a su vez representan al equipo
llamando en adelante equipo Scrum.
Roles principales
Product owner
El Product Owner se considera como la voz del cliente. Su labor es asegurar que
el equipo ofrezca un valor para el negocio, y se centra en el producto basándose
en el enfoque del cliente y en las historias de uso dándoles una prioridad en los
Product Backlog.
Los equipos Scrum deben configurarse con ciertos roles como es el Product
Owner, quien a su vez es parte del equipo de desarrollo. No conviene que se
combine con el Scrum Master, aunque en ciertos entornos empresariales se
combina con el Project Manager, ya que ofrece una mayor visión del alcance del
producto.
Equipo
El equipo se suele componer de entre 5 o 9 personas multifuncionales. Su
trabajo consiste en analizar, diseñar, desarrollar, probar la comunicación técnica,
documentar, etc. siendo su responsabilidad final el conseguir potenciales
incrementos en el producto al final de cada Sprint. Se trata de un equipo
organizado por sí mismo, aunque existe cierta comunicación con la gestión de
proyectos.
Scrum Master
El Scrum Master es quien debe velar por la buena marcha del proyecto para
conseguir el objetivo del Sprint, y ha de eliminar los obstáculos que aparezcan
para su equipo.
No se trata de ser un líder del equipo sino de tener el comportamiento de
amortiguador para que las influencias que pudieran darse no perturben al equipo.
También ha de hacer que se cumplan las reglas, para ello presidirá reuniones
importantes y motivará al equipo para mejorar.
Su diferencia con la del Project Manager reside en que éste último puede tener
responsabilidad sobre la gestión de personas externas, es decir, no relacionadas
con el equipo Scrum. [57]
59
Arquitectura de Fault Tolerance System distribuido entre UAVs
Roles auxiliares
Se trata de aquellos que no tienen una participación frecuente y formal en el proceso
Scrum; no obstante han de tenerse en cuenta:
Project Manager
Esta persona juega el rol de responsable para que el proyecto sea un éxito
Asesores de Proyecto
Cuando el equipo Scrum deba consultar algo, estas son las personas a las que deben
acudir. El grupo de Asesores de Proyecto está compuesto por representantes del Senior
Supplier, del Senior User y por el Project Executive.
Managers
Los manager como en cualquier proyecto son la personas que controlan de forma
general el entorno de trabajo.
Sprint
60
Arquitectura de Fault Tolerance System distribuido entre UAVs
Se trata de la unidad básica y principal de desarrollo del proceso Scrum (en la figura 9
se puede ver el proceso Scrum). Lo característico del Sprint es que:
-Tiene una " duración fija " de esfuerzo, fijada por anticipado y es norma que dure
entre una semana y un mes.
-Cada Sprint es precedido por una reunión de planificación, basada en:
· Identificación de tareas para el sprint.
· Estimación de los objetivos de sprint.
· Revisión/reunión retrospectiva.
· Examinación del progreso.
· Identificación de tareas para el próximo sprint.
Reuniones
Scrum Diario
El equipo de proyecto realiza una reunión cada día durante el sprint y sigue las
siguientes reglas:
61
Arquitectura de Fault Tolerance System distribuido entre UAVs
Scrum de Scrums
Es otro tipo de encuentro, generalmente tras el scrum diario. Aquí asiste una persona
asignada de cada grupo de scrum y pueden discutir su trabajo,
Es idéntico al scrum diario, con la adición de las siguientes cuestiones:
· ¿Qué ha hecho su equipo desde la última reunión?
· ¿Qué va a hacer su equipo antes de la siguiente reunión?
· ¿Hay algo atrasando a su equipo?
· ¿Se va a cargar algo a otro equipo?
62
Arquitectura de Fault Tolerance System distribuido entre UAVs
Fin de ciclo
Cuando acaba el ciclo sprint se dará lugar a otras dos reuniones [58]:
"Reunión de Revisión de Sprint":
· Revisar el trabajo completado y el trabajo planificado no completado.
· Demo: presentar el trabajo realizado con los grupos de interés.
· El tiempo para esta reunión es de 4 horas.
"Sprint Retrospectivo".
· Reflexión del sprint anterior por parte del equipo.
· Proceso de mejora continua.
· Preguntarse en la retrospectiva de Sprint: ¿Qué salió bien durante el
Sprint? ¿podría mejorarse en el siguiente sprint?
· Límite de tiempo de tres horas.
· Esta reunión se ve facilitada por el Scrum Master.
Objetos
Product Backlog
La Product Backlog es una lista ordenada de los "requisitos" que se mantiene
para un producto, se entiende como el "qué" se construirá, ordenado en el orden
relativo en el que se debe construir. Es abierto y editable por cualquier persona,
pero el Product Owner es en última instancia responsable de ordenarlos para el
equipo de desarrollo. Para realizar el orden se tiene en consideración el riesgo, el
valor de negocio, las dependencias, fechas… La pendiente del producto y el
valor comercial de cada elemento de la lista también es responsabilidad del
Product Owner.
Las características adicionales del Product Backlog se escriben normalmente en
formato de historia.
El equipo de desarrollo también forma parte de este objeto. Se encarga de
determinar el esfuerzo estimado para completar cada elemento. El equipo
63
Arquitectura de Fault Tolerance System distribuido entre UAVs
Sprint Backlog
Incremento
Se trata de un aumento, y es la suma de todas las historias de usuario de
productos terminados durante un sprint y todos los sprints anteriores. Esta suma
ha de hacerse al final de un sprint. [59]
64
Arquitectura de Fault Tolerance System distribuido entre UAVs
Burn down
Figura 12: Una iteración completada, mostrando el esfuerzo y tareas restantes para cada uno de los 21 días de
trabajo de la iteración.
Para analizar la viabilidad del proyecto tanto en factores internos como externos, se ha
realizado un análisis DAFO, conociendo a través de esta herramienta los puntos fuertes
por los que apostar y oportunidades que debemos explotar, así como combatir nuestras
debilidades y amenazas:
65
Arquitectura de Fault Tolerance System distribuido entre UAVs
F1: Todo el equipo y material necesario para llevar a cabo el O1: El proyecto se integra dentro de EC-SAFEMOBILE.
D1: Tiempo muy limitado. A1: Necesidad de asistencia por parte del tutor.
D2: Desarrollo de la arquitectura y del sistema de tolerancia de A2: Cambios en los requisitos del proyecto.
fallos de manera aislada. A3: Desarrollo de la arquitectura independientemente del
D3: Disponibildad limitada de asistencia técnica por parte del sistema de tolerancia de fallos (desarrollado en la Universidad)
tutor A4: La arquitectura no puede ser testada mas que con un
D4: Sin capacidad de uso de licencias. dummy.
D5: Capacidad limitada de Vigilancia tecnológica.
D6: No se hace uso de certificados y normas de calidad.
Una vez realizado el análisis, se establecen las distintas estrategias que se pueden llevar
a cabo:
66
Arquitectura de Fault Tolerance System distribuido entre UAVs
ü D4-O5: El limitado uso del software de pago debido al coste de las licencias,
puede verse apoyado por el uso de software libre.
67
Arquitectura de Fault Tolerance System distribuido entre UAVs
68
Arquitectura de Fault Tolerance System distribuido entre UAVs
Definiciones
Cuando se habla de un producto de calidad, se habla de un producto que cumple con sus
necesidades y que además satisface al usuario.
3.4.1 Descripción
Para cumplir con una garantía mínima en cuanto a la Calidad del Software conviene
seguir una guía de calidad en la propia organización.
Esta guía debe tratar una serie de normas, reglamentos y procedimientos a seguir; y a su
vez verificar, evaluar y confirmar los equipos de trabajo durante el ciclo de vida del
desarrollo de software; basándose en el conocimiento de las mejores prácticas y
aplicándose herramientas Off-The-Shelf.
Es importante que el plan contenga los objetivos de calidad que se deben alcanzar, así
como los riesgos previstos y la gestión de estos. Algunas acciones del SQP derivan de:
69
Arquitectura de Fault Tolerance System distribuido entre UAVs
Esta capa asegura que tanto el proceso SQA como SQP estén siendo seguidos por el
equipo de desarrollo, e incluye actividades como [60]:
(Cabe citar que muchas personas usan los términos SQM y SQA indistintamente)
70
Arquitectura de Fault Tolerance System distribuido entre UAVs
La calidad del producto junto con la calidad del proceso son los aspectos más
importantes actualmente en el desarrollo de Software. En calidad del producto
recientemente ha aparecido una nueva versión de la norma ISO/IEC 9126: la norma
ISO/IEC 25000.
En lo que se refiere a calidad del producto la norma ISO/IEC 25000 proporciona una
guía para el uso de las nuevas series de estándares internacionales, llamados Requisitos
y Evaluación de Calidad de Productos de Software (SQuaRE). Constituyen una serie de
normas basadas en la ISO 9126 y en la ISO 14598 (Evaluación del Software), y su
objetivo principal es guiar el desarrollo de los productos de software con la
especificación y evaluación de requisitos de calidad. Establece criterios para la
especificación de requisitos de calidad de productos software, sus métricas y su
evaluación.
Así como las características de calidad y sus medidas son útiles no solo para la
evaluación del producto de Software, sino también para definir requisitos de calidad; el
predecesor de SQuaRE, ISO/IEC 9126:1991 ha sido reemplazado por dos Estándares
Internacionales:
- ISO/IEC 9126, para la calidad del producto del Software (Software Product
Quality)
- ISO/IEC 14598, para la evaluación del producto del Software (Software Product
Evaluation)
El fin que se pretende conseguir con estos Estándares Internacionales es moverse a una
lógica organizada y enriquecer y unificar las series cubriendo los dos principales
procesos:
Las diferencias más notorias entre ISO/IEC 9126, IEC 14598 y la serie de Estándares
Internacionales SQuaRE son las que se citan a continuación:
71
Arquitectura de Fault Tolerance System distribuido entre UAVs
• Términos y definiciones
• Modelos de referencia
72
Arquitectura de Fault Tolerance System distribuido entre UAVs
• Guía General
· Vista interna: esta vista se ocupa de las propiedades del software en cuanto al
tamaño, la complejidad o la conformidad con las normas de orientación a
objetos; y puede utilizarse desde las primeras fases del desarrollo, permitiendo
detectar deficiencias en el software en edades muy tempranas del ciclo de vida
del software.
· Vista externa: es la vista que analiza el comportamiento del software, digamos
en producción, y estudia sus atributos, lo que podrían ser, por ejemplo, el
rendimiento de un software en una máquina determinada, el uso de memoria de
un programa o el tiempo de funcionamiento entre fallos. Esta segunda vista, a
diferencia de la interna, necesita que el producto software este completo y se
utilizará por tanto en el pase a producción del producto, siendo muy dependiente
de la máquina donde se ejecute.
· Vista en uso: mide la productividad y la efectividad del usuario final al utilizar
el software. Esta tercera vista también estudia el producto software finalizado y
será dependiente del usuario a la par que estará condicionada a los factores
personales del mismo. [62]
Puede observarse que las distintas vistas se interrelacionan afectando los valores de la
vista interna a los de la vista externa y los de la vista externa a los de la vista en uso. Así
por ejemplo, un software con una alta complejidad probado sobre una máquina con
bajas prestaciones tendrá un rendimiento bajo que provocará que el usuario final tenga
un rendimiento inferior al esperado independientemente de sus factores humanos.
La serie ISO 25000 no establece los niveles de calidad deseables para cada proyecto, si
bien se recomienda que los requisitos de calidad deban ser proporcionales a las
necesidades de la aplicación y lo crítico que debe ser el correcto funcionamiento del
sistema implementado.
Esta serie establece, que la calidad del producto software, está compuesta de
características de calidad que se indican en las denominadas medidas de calidad de
software (Software Quality Measures) (véase Figura 14), las cuales a su vez se
componen de subcaracterísticas y estas últimas de atributos. Aunque estos últimos no
se especifican ya que se entiende que son entidades dependientes del producto software
y variarán según varíe la naturaleza del software analizado: lenguaje, paradigma de
programación, complejidad tecnológica, etc.
73
Arquitectura de Fault Tolerance System distribuido entre UAVs
Figura 14: Modelo de Referencia de Medición de la Calidad del Producto Software, según la ISO/IEC 25000.
Estas mediciones dan como resultado una serie de métricas que se pueden clasificar en
tres categorías según sea su naturaleza:
El modelo establece diez características, seis que son comunes a las vistas interna y
externa y cuatro que son propias de la vista en uso. Las características que definen las
vistas interna y externa, se muestran a continuación en la Figura 15 y son:
74
Arquitectura de Fault Tolerance System distribuido entre UAVs
Mientras que las características propias de la vista en uso, son las siguientes y se
reflejan en la Figura 16:
75
Arquitectura de Fault Tolerance System distribuido entre UAVs
Ámbito / Alcance
76
Arquitectura de Fault Tolerance System distribuido entre UAVs
77