Administracin del ciclo de vida de desarrollo de un producto de software

1
Administración del ciclo de vida de desarrollo
de un producto de software

• Gustavo A. Arellano
• garellano_at_siga.com.mx

2
Contenido

• Introducción general
• Modelo de categorías Borland ALM
• Ciclo de vida del proceso de desarrollo
• Sesión de preguntas y respuestas

3
Introducción general
Tres componentes básicas en el desarrollo de
aplicaciones comerciales
4
Procesos de desarrollo (i)
Fuente H. Oktaba, G Ibargüengoitia, 2001
5
Procesos de desarrollo (ii)
(Metodologías de desarrollo)

• Proceso Unificado (UP)
• Extreme programming
• Team Software Process
• etc.

6
Modelo de categorías Borland ALM
Borland ALM es un modelo de categorías que se
ajusta a cualquier proceso de desarrollo, debido
a que define seis actividades comunes a todas las
metodologías de desarrollo

• Definir
• Diseñar
• Desarrollar
• Probar
• Instalar
• Administrar

7
Calidad en software (ISO/IEC 9126-1)
Con la adopción de Borland ALM, una metodología
de desarrollo y una tecnología apropiada, será
posible generar productos de software apegados al
internacional de calidad ISO/IEC 9126-1 2000

• Funcionales
• Eficientes
• Confiables
• Mantenibles
• Portables
• Usables
• Reutilizables

G. Arellano, Congreso nacional de cómputo, 2003
8
Técnica (i)

• Es posible definir como técnica al grado de
  habilidad que se posee para manipular una o mas
  herramientas (o tecnologías) cuyo propósito es
  común.
• En nuestro caso, una buena técnica debe verse
  reflejada al implementar, de manera adecuada, la
  tecnología seleccionada, a través de las
  herramientas seleccionadas.
• Un proceso de desarrollo debe ser independiente
  de herramientas sin embargo, es fácil observar
  que la no utilización de éstas redunda en baja
  productividad y elevados tiempos de desarrollo
  con altas posibilidades de inyección de defectos,
  debidos principalmente, a la elaboración de
  artefactos, de manera manual.

9
Técnica (ii)
El modelo de categorías Borland ALM ofrece un
conjunto de herramientas cuyo propósito es cubrir
las actividades definidas por él mismo

• CaliberRM ? Definir Administración de
  requerimientos
• Together ? Diseñar Modelado UML, auditorías,
  métricas
• JBuilder ? Construir Codificación asistida,
  unidades de prueba
• Optimizeit ? Probar Desempeño, robustez,
  confiabilidad
• StarTeam ? Administrar Administración de equipos
  de desarrollo
• Administración de recursos humanos
• Control de cambios (no CVS)
• Discusiones hiladas
• Control de versiones

10
Técnica (iii)

• Un adecuado manejo de las herramientas en cada
  fase del proceso
• seleccionado, garantiza la liberación de
  productos
• 100 funcionales
• Portables entre diversas plataformas
• Fácilmente entendibles y utilizables
• Robustos y simples de modificar
• Fáciles de probar y reutilizar
• Todo lo anterior en el tiempo y costo acordado
  con el cliente.

11
Segunda parte
12
Las Primeras Fases de un Proceso

• Factibilidad. Determinar la viabilidad del
  proyecto.
• Lanzamiento. Definir el ambiente de desarrollo.
• Estrategia. Establecer criterios generales de
  desarrollo.
• Planeación. Asignación y control de tareas.

13
Requerimientos

• Detallar Alcance
• Entrevista no dirigida
• Entrevistas dirigidas
• Generar SRS
• Línea base del modelo de casos de uso
• Prototipo estático del sistema
• Entrevistas dirigidas
• Generar plan de pruebas de integración
• Generar línea base del glosario

14
Secuencia de la administración de requerimientos
Crear requerimiento
Modificar requerimiento

• - Actualizar referencias
• - Actualizar seguimiento
• Actualizar proceso de validación
• Actualizar histórico

(Procede cambio)
Cancelar requerimiento
(No procede cambio)
(No aprobado)
Consenso aprobatorio
Asignar responsable
(Aprobado)
15
Fases de análisis y diseño

• Generar modelo de negocio.
• Modelar escenarios de operación primarios
• Refinar casos de uso críticos
• Identificar clases de dominio de problema e
  posibles interacciones y relaciones entre estas.
• Generar manual de usuario
• Generar modelo técnico
• Refinar y extender el modelo de negocio
• Identificar clases de soporte a servicios de bajo
  nivel, clasificarlas y definir relaciones e
  interacciones entre ellas.
• Generar manuales de instalación
• Generar manuales de resolución de problemas.
• (Se recomienda el uso de UML para la realización
  de estas actividades.)

16
Una secuencia típica de modelado
Aunque, en teoría, es posible usar prácticamente
cualquier secuencia para la generación de
artefactos UML, nuestra experiencia como compañía
de desarrollo ha sido que el orden generalmente
utilizado ha sido el siguiente

• Generar diagramas de casos de uso
• Refinar diagramas de casos de uso
• Generar diagramas de actividades
• Generar diagramas de estados
• Generar diagramas de paquetes
• Generar diagramas de secuencia
• Generar diagramas de clases
• Generar diagramas de instalación

17
Fase de implementación y pruebas unitarias

• Generar ejecutables instalables
• Probar unitariamente
• Generar plan de pruebas de sistema

18
Secuencia en la codificación

• Codificar algoritmos basados en el modelo, los
  estándares organizacionales (tecnológicos y de
  estilo) y los comentaros insertos.
• Generar, con el asistente, unidades de prueba y
  ejecutar las pruebas unitarias.
• De los servicios de bajo nivel se encargará
  generalmente un contenedor de aplicaciones,
  evitando así tener que diseñar soluciones que
  resuelvan problemas comunes a todos los
  aplicativos, como un pool de conecciones,
  registro de transacciones, ejecusión de
  transacciones ACID, inicio de servicios
  auxiliares, etc.

19
Al concluir la codificación

• Una vez que la codificación quedó concluida, y
  que se demostró con pruebas unitarias que el
  código es algorítmicamente correcto, será
  necesario verificar que éste es óptimo y apegado
  a los estándares organizacionales tecnológicos y
  de estilo.
• Una de las formas de asegurar que el código esté
  apegado a los estándares corporativos y de
  garantizar una distribución uniforme de la
  complejidad del aplicativo es a través de
• La ejecución de auditorias
• El cálculo de métricas

20
Ejecución de auditorias
21
Cálculo de métricas
22
Pruebas de sistema

• Ejecución de pruebas de integración
• Ejecución de pruebas de estrés
• Carga
• Concurrencia
• Disponibilidad
• Velocidad de respuesta
• Ejecución de pruebas beta

23
Servicios típicos requeridos

• Code coverage
• Memory leak
• Thread debugger

24
Administración

• Durante el desarrollo de un sistema, será
  necesario administrar tiempos, actividades y
  artefactos que serán generados durante este
  proceso.
• Un simple CVS no ofrece los elementos requeridos
  por la administración del control de cambios.
• Un control de cambios robusto debe permitir la
  personalización de flujos de trabajo que modelen
  tales procesos de cambio.
• El uso de una herramienta automática que permita
  administrar el proceso de control de cambios será
  básica, durante el desarrollo de un sistema.

25
Flujo de un control de cambios

• Solicitar un cambio
• Evaluar impacto del cambio
• Aceptar o rechazar la solicitud
• Si se aceptó, ordenar su ejecución
• Realizar el cambio
• Revisar que el cambio es congruente con lo
  solicitado y verificar su efecto
• Documentar y guardar en el control de versiones

Plan de mitigación de riesgos
Proceso de reversión
Selección de ejecutores y substitutos
26
Aspectos importantes en la administración de
equipos de desarrollo

• Administración del control de cambios
• Definición de flujos de trabajo personalizados
• Administración de recursos humanos y equipos de
  trabajo (solicitud dinámica de reportes)
• Administración de tareas (asignación y
  seguimientos)
• Generación de reportes periódicos
• Trabajo colaborativo
• Establecimiento de discusiones hiladas
  (intercambio asíncrono de información)
• Establecimiento de salones de charla en grupo
  (intercambio síncrono de información)

27
Conclusiones

• El quehacer de la industria de desarrollo de
  software
• La problemática de nuestra labor
• Propuestas populares y prácticas probadas
• Herramientas de soporte a la tarea de desarrollo
• Soporte integral y coordinado
• Impacto en la productividad, desempeño y tiempo
  de desarrollo
• Relación esfuerzo resultado

28
Relación esfuerzo resultado
Resultado
Esfuerzo
Sin soporte de herramientas
Con soporte de herramientas
29
Gracias

• Sesión de preguntas y respuestas

30
Gracias

• M en C Gustavo A Arellano
• garellano_at_siga.com.mx