Mejores Prácticas de Desarrollo de Software
Gloria Quintanilla
Directora de Consultoría y
Servicios
Preparado por:
Miembro Fundador
Presidente del Consejo de Honor
Es una realidad...
“Sólo el 28% de los
proyectos de software
tienen éxito.”
Standish Group, CHAOS Report, 2001
Preparado por:
Hechos del software
•
Encontrar y corregir un error durante Producción cuesta 100 -1000
veces más que en el Diseño.
•
El tiempo de desarrollo no puede comprimirse más de un 25%
aumentando el número de gente.
•
Por cada $1 gastado en desarrollo, se gastan $2 en mantenimiento.
•
Los costos de desarrollo y mantenimiento están directamente en
función de las actividades manuales.
•
Programación representa solo un 15% del “esfuerzo” de desarrollo.
•
En desarrollo de software existe deseconomía de escala (costo/línea)
“Industrial Software Metrics Top 10 List”
Barry Boehm
Preparado por:
Síntomas de la crisis del Software
 No son cubiertas las necesidades del negocio.
 Requerimientos mal definidos.
 Módulos que no se integran.
 Difícil de mantener.
 Tardío descubrimiento de defectos.
 Baja calidad.
 Usuario finales insatisfechos.
 Bajo desempeño sobre altas cargas.
 Esfuerzo no coordinado del equipo.
 Liberaciones (Build-and-release issues)
Preparado por:
Problemática del desarrollo de Software
Dirección
Jefe de Proyecto
Desarrollador
Preparado por:
Maximizar
Beneficios
Conducir
el equipo al
éxito
Crear
Software
de
calidad
Problemática del desarrollo de Software
Dirección
 Retraso en proyectos
 Oportunidades perdidas
 Amenazas de la
competencia
Jefe de Proyecto
 Fechas ajustadas
 Recortes de
presupuestos
 Pocos recursos.
Desarrollador
 Reuniones
 Cambios
 Rehacer trabajo hecho
Preparado por:
Maximizar
Beneficios
Conducir
el equipo al
éxito
Crear
Software
de
calidad
Problemática del desarrollo de Software
Dirección
Dirección
 Retraso en proyectos
 Oportunidades perdidas
 Amenazas de la
competencia
Jefe
dede
Proyecto
Jefe
Proyecto
 Fechas ajustadas
 Recortes de
presupuestos
 Pocos recursos.
Desarrollador
Desarrollador
 Reuniones
 Cambios
 Rehacer trabajo hecho
Preparado por:
Maximizar
Beneficios
Conducir
el equipo al
éxito
Crear
Software
de
calidad
Mejores Prácticas en Desarrollo de Software
Mejores Prácticas
Proceso Práctico
Desarrollo Iterativo
Gestión de Requisitos
Arquitecturas Basadas en
Componentes
Modelado Visual (UML)
Verificación Continua de la
Calidad
Gestión del Cambio
Preparado por:
¿Qué son las Mejores Prácticas?
Es un conjunto de
principios, métodos y
procesos que permiten
mejorar la calidad y
productividad del
desarrollo de software.
Preparado por:
La validez de las Mejores Prácticas está probada
Utilizadas en:
• 1000’s de clientes.
• 1000’s de proyectos.
• Líderes del sector.
Preparado por:
Mejores Prácticas en Desarrollo de Software
Mejores Prácticas
Proceso Práctico
Desarrollo Iterativo
Gestión de requisitos
Arquitecturas Basadas en
Componentes
Modelado Visual (UML)
Verificación Continua de la
Calidad
Gestión del Cambio
Preparado por:
Desarrollo en cascada
ANÁLISIS DE REQUISITOS
DISEÑO
CODIFICACIÓN
INTEGRACIÓN
PRUEBAS
Preparado por:
Desarrollo iterativo
Iteración 1
Iteración 2
R
Iteración n
R
D
R
D
C
D
C
I
C
I
T
I
T
T
Tiempo
•
•
•
•
•
•
•
Cada iteración produce una versión executable del sistema.
Las primeras iteraciones atacan los riesgos mayores.
Se define y robustece la arquitectura de la aplicación en forma temprana.
Cada iteración permite la retroalimentación del usuario.
Se prueba desde el principio, verificando desempeño y escalabilidad.
Entregables bien definidos y delimitados permiten tener metas a corto
plazo y no una sola meta a largo plazo.
El progreso se mide mediante la evaluación de las implementaciones
(mediciones reales).
Preparado por:
Los retos del Líder del Proyecto
•
•
•
Dificultad para conocer el estado real de los proyectos
Falta de comunicación con el equipo y poca eficiencia
• En las juntas de equipo sólo se recopila información y no se resuelven
problemas
Múltiples proyectos, prioridades y procesos
?
?
?
Líder del proyecto
Preparado por:
?
?
?
?
Perfil de riesgo de un desarrollo iterativo
Cascada
Iterativo
Riesgo
Tiempo
Preparado por:
Reducción del retrabajo
Síntomas
deSecuenciales:
un proceso

Actividades
convencional
en cascadaCódigo
Análisis
Diseño
Integración
Pruebas
Inicio de
Integración
Progreso
(% codificado)
100%
Problemas de retrasos en proyectos
40% esfuerzo en integracion y pruebas
Problema
Fecha Fin
Original
Tiempo
Preparado por:
Fecha Fin
Real
Reducción del retrabajo
Prototipos
Arquitectura
Versiones
Funcionales
Fases secuenciales – Actividades iterativas
Versión
Final
Progreso
(% codificado)
100%
Fecha Fin
Original
Tiempo
Preparado por:
Fecha Fin
Real
Ejemplo de un proceso iterativo
Contenido
Tiempo
Preparado por:
Rational Unified Process
“Processes represent “recipes” for success, based on the past
experience on projects”
Dr. Pankaj Jalote, 2002
“RUP se ha convertido en el proceso de desarrollo de software más
utilizado”
Oktaba, Ibargüengoitia y Ruiz 2001
…to transform an organization into a highly productive team, one of
the best decisions you can make is to CHANGE what you can,
ACCEPT what you can’t change, and BORROW EVERYTHING
you can that has been validated by a successful software
community.
Philippe Krutchen, 2001
Preparado por:
Niveles de estimados
N1
Variación de
+/- 50% o más
N2
Variación de
+/- 30%
Preparado por:
N3
Variación de
+/- 10%
Niveles de Planes
N1
N2
Preparado por:
El plan de desarrollo de software
integra otros planes
Preparado por:
Mejores Prácticas en Desarrollo de Software
Mejores Prácticas
Proceso Práctico
Desarrollo Iterativo
Gestión de Requisitos
Arquitecturas Basadas en
Componentes
Modelado Visual (UML)
Verificación Continua de la
Calidad
Gestión del Cambio
Preparado por:
¿Por qué preocuparnos por los requisitos?
Preparado por:
Érase un proyecto ...
Como lo
solicitó
el cliente
Como lo diseñó
el arquitecto
Como lo construyó
el contratista
Preparado por:
Como lo especificó
el ingeniero
Como quedó
finalmente
Como lo solicitó
compras
LO QUE REALMENTE
SE NECESITABA
¿Porqué falla un Proyecto?
Entre Otros:
1.
2.
3.
4.
5.
6.
El usuario no sabe lo que quiere (¿o nosotros no lo
entendemos?).
Requerimientos y especificaciones incompletos.
Cambio en los requerimientos y especificaciones.
Carencia de participación por parte del usuario.
No existe documentación.
Falta de una metodología para la gestión de
requisitos.
Standish Group, ‘99
Preparado por:
¿Qué son los requisitos?
• Un requisito es una propiedad/característica que
debe ser mostrada por el sistema que se esté
construyendo.
• Característica que debe incluirse en un sistema
Preparado por:
Impacto de los errores en los requisitos
Etapa
1-2
Elicitación de requisitos
5
Diseño
10
Codificación
20
Pruebas unitarias
50
Pruebas
200
Mantenimiento
“ Resolver errores en
fase de mantenimiento
cuesta 200 veces más
que resolverlos en
gestión de requisitos.”
Average cost ratio 14:1
Grady 1989
Costo de reparación de errores
Boehm ‘76, 88
Preparado por:
Gestión de requisitos implica…
Asegurarse de:
– Resolver el problema correcto.
– Construir el sistema apropiado.
Fases de gestión de requisitos:
– Identificación.
– Organización (estructura y rastreabilidad).
– Documentación (especificación).
– Validación de requisitos.
– Gestión:
del cambio en requisitos, de los atributos, de
la rastreabilidad.
Preparado por:
Técnicas de trabajo con usuarios
• Talleres de requerimientos
• Entrevistas
• Cuestionarios
• Prototipos
• Juego de roles
• Análisis de regulaciones y procesos actuales
• Lluvia de ideas
Preparado por:
Atributos de los requisitos
Prioridad
Estado
Costo
Req.
Responsable
100
Dificultad
Relación
Riesgo
Req.
Req.
201
202
Preparado por:
Atributos de requisitos en la Admón. del Proyecto
Req. 10
Aprobado
Req. 13
Propuesto
Req. 40

Obligatorio
Preparado por:
Bajo
Medio

Alto

Alta
Baja
Alto
$$$

$$
$
Evaluación del impacto del cambio
Necesidades
Negocio
Necesidades
Negocio:
Características
del producto:
Características
producto
(casos de uso)
Casos de
Uso:
Pruebas
Preparado por:
es una característica de la
relación de
dependencia de los
requerimientos para
reaccionar a los
cambios de sus
elementos
relacionados
Rastreabilidad:
la relación
entre los
artifactos
Compartir los requisitos
Cada uno de los participantes del proyecto requiere
tener acceso a los requisitos.
Desarrolladores
y diseñadores
Aseguramiento de
la Calidad
Req
Analistas
Usuarios y
Clientes
`Gerentes
Preparado por:
Líder de Proyecto
Repositorio de requisitos
Preparado por:
Matriz de rastreabilidad
Muestra las dependencias entre requerimientos
Preparado por:
Mejores Prácticas en Desarrollo de Software
Mejores Prácticas
Proceso Práctico
Desarrollo Iterativo
Gestión de Requisitos
Arquitecturas Basadas en
Componentes
Modelado Visual (UML)
Verificación Continua de la
Calidad
Gestión del Cambio
Preparado por:
Evolución típica de una aplicación ...
arreglo A790
arreglo A812
nuevo requerimiento
V 1.2a
Arquitectura 1.0
Preparado por:
V 1.2
Resistencia al cambio
arreglo A790
arreglo A812
nuevo requerimiento
Arquitectu
Preparado por:
a 1.0
V 1.2a
¿Por qué utilizar arquitecturas de componentes?
• La clave del éxito es crear
arquitecturas:
– Duraderas
– Flexibles al cambio
– Basadas en componentes
La Arquitectura es el
20% del esfuerzo que
produce el 80% más
importante
Desarrollar:
• Con Reuso
• Para Reuso
Preparado por:
Activos de software reutilizable
• Reuso de todo “artefacto”
– Arquitectura
– Casos de Uso, Análisis, Diseño, Implementación y
Pruebas
– Modelos de interfaces, modelos de negocio, patrones
arquitectónicos, etc.
• Reuso de tecnología
– Proceso y automatización
– Proyectos
– Guías
Preparado por:
Ejemplo: Arquitectura basada en componentes
Funciones de
cliente/
productos
Funciones de
licenciamiento
Mecanismos de interfaces
Cliente
Producto
Licencia
Comprado
Existente
Database
Preparado por:
CRM
Nuevo
Arquitectura de los Sistemas Corporativos
3-capas
PRESENTACIÓN
Interfaces de
usuarios
LÓGICA NEGOCIO
Transactions
procesing monitors
Preparado por:
INTEGRACIÓN
Bases de
datos
J2EE
CLIENTE
SERVIDOR
Dispositivo Cliente
HTML,XML,WML
JDBC
HTTP
Web Server
Contenedor Web
EJB Server
Dispositivo Cliente
JSP
JavaMail
Mail Server
Servelet
Contenedor de
Applets
Contenedor de EJB
HTTP
Servicios J2EE
Applet
Servicios J2SE
Servicios J2SE
EJB
EJB
Servicios J2EE
JNDI
JMS
Servicios J2SE
HTTP
RMI
Dispositivo Cliente
Contenedor de
Aplicaciónes Cliente
Message
Queue
Java
Application
RMI
CORBA
Aplicación
Cliente
Servicios J2EE
Servicios J2SE
Directory
Services
PRESENTACIÓN
Preparado por:
LÓGICA DE NEGOCIO
INTEGRACIÓN
Mejores Prácticas en Desarrollo de Software
Mejores Prácticas
Proceso Práctico
Desarrollo Iterativo
Gestión de Requisitos
Arquitecturas Basadas en
componentes
Modelado Visual (UML)
Verificación Continua de la
Calidad
Gestión del Cambio
Preparado por:
¿Qué es UML?
UML es el lenguaje
estándar para
visualizar, especificar,
construir y
documentar los
artefactos de una
aplicación software
Preparado por:
UML: El lenguaje para el desarrollo software
Planned major revision (2003)
UML 2.0
Approved minor revision 2001
UML 1.4
Current minor revision 1999
UML 1.3
OMG Acceptance, Nov 1997
Final submission to OMG, Sept 1997
First submission to OMG, Jan 1997
UML 1.1
UML partners
UML 1.0
June 1996
UML 0.9
OOPSLA 95
Otras metodologías OOSE
Preparado por:
Unified Method 0.8
Booch method
OMT
UML
Modelado de
Requisitos
Modelado
Web
Modelado
de Negocio
Modelado de
Aplicaciones
Modelado de
Datos
Un único lenguaje para todo el equipo
Preparado por:
Perspectivas arquitectónicas de una casa
1
2
3
Preparado por:
Arquitectura en desarrollo de SW:
4+1 Vistas
VISTA LÓGICA
VISTA IMPLEMENTACIÓN
Repository
DocumentList
Document
FileMgr
FileManager
add( )
name : int
delete( )
fetchDoc( )
docid : int
sortByName( )
numField : int
get( )
read() fill the
open( )
Document
code..
close( )
read( )
FileList
sortFileList( )
fList
create( )
fillDocument( )
add( )
delete( )
1
GraphicFile
File
FileList
rep
File
Repository
(from Persistence)
read( )
GrpFile
name : char * = 0
CASOS DE USO
read( )
readDoc( )
open( )
readFile( )
create( )
fillFile( )
Use Case 1
Actor A
VISTA DE PROCESO
Use Case 2
Use Case 3
Actor B
VISTA DE DESPLIEGUE
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨
- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö
mainWnd
user
ƯÁ¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
fileMgr :
document :
FileMgr
Document
gFile
repository
1: Doc view request ( )
Windows95
Window95
Windows95
2: fetchDoc( )
3: create ( )
[yes]
¹®¼°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
4: create ( )
¹®¼°ü¸® ¾ÖÇø´
5: readDoc ( )
Windows
NT
ÈÀÏ°ü¸®ÀÚ´Â Àоî¿Â
¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )
Solaris
7: readFile ( )
¹®¼°ü¸® ¿£Áø.EXE
8: fillFile ( )
Alpha
UNIX
ÀÀ¿ë¼¹ö.EXE
È¸é °´Ã¼´Â ÀоîµéÀÎ
°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡
º¸¿©ÁØ´Ù.
9: sortByName ( )
Windows
NT
IBM
Mainframe
µ¥ÀÌŸº£À̽º¼¹ö
Preparado por:
Ambientes: roundtrip engineering
• Capacidad de modelado UML
• Sincronía entre modelos y código.
• Patrones de diseño.
Preparado por:
Diseño y construcción del sistema desde
una herramienta única
Diseño de Datos
Analista de
Negocio
Desarrollador
Arquitecto
Diseñador DB
Una Herramienta para todo el equipo.
Preparado por:
Mejores Prácticas en Desarrollo de Software
Mejores Prácticas
Proceso Práctico
Desarrollo Iterativo
Gestión de Requisitos
Arquitecturas Basadas en
Componentes
Modelado Visual (UML)
Verificación Continua de la
Calidad
Gestión del Cambio
Preparado por:
Verificación continua de la calidad
Es de 100 a 1000 veces más costoso encontrar y reparar
los problemas del software después del desarrollo
 Costo de reparar el software.
 Costo de perder oportunidades.
Costo
 Costo de perder clientes
Concepción
Elaboración
Preparado por:
Construcción
Transición
Causas principales de la baja calidad del software
• Probar Software es muy difícil.
• Cambios en los requerimientos.
• Falta de un proceso sistemático
de pruebas.
• Mala comunicación entre
miembros del equipo.
Preparado por:
Solución: Verificación Continua
We have lost two generations of developers who think they just
need to debug at the end, when they instead shouldn’t introduce
any defects along the way.
Ivar Jacobson, México 2001
• Problema de Actitud:
– “bugs” son normales, “defectos” no son aceptados
– los programadores “ensucian”, otros (clientes) “limpian”
• Cambiar:
– Verificar y probar todo continuamente desde el inicio.
– Toda actividad es verificada: los casos de prueba se definen a partir de:
requerimientos, análisis, diseño, codificación...
– Automatizar la verificación de la calidad con herramientas
Preparado por:
Cada actividad incluye su verificación
Todo aquello que hagas, no lo habrás terminado,
hasta que hayas verificado que hiciste
lo que debías de hacer.
Ejecución
Actividad
Acción
Preparado por:
Verificación
Plan de actividades de aseguramiento de la calidad
Conjunto de actividades que serán ejecutadas para
generar confianza en que el producto cumplirá con los
requerimientos y el proceso es efectivo
Cliente
Validaciones
Verificaciones
Necesidades
Producto
Requisitos
Revisiones
Preparado por:
Jerarquía de planes
Plan de Desarrollo
Plan de Aseguramiento de la Calidad
Plan de Pruebas (de software)
Preparado por:
IMPLEMENTACIÓN. Probar en cada iteración .....
Pruebas
Pruebas Manuales
Re-ejecutar
primeras
pruebas y ...
Tiempo
Build 1
Preparado por:
IMPLEMENTACIÓN. Pruebas de regresión
Pruebas
Pruebas Manuales
Difícil de forma
manual!
...las
nuevas
pruebas...
...más
tiempo
Tiempo
Build 1
Build 2
Build 3, 4, 5, 6, 7, 8
Preparado por:
Build 9
Build 10
Calidad - el elemento evasivo
•
La perspectiva transcendental...
algo que se puede reconocer pero no definir
•
La perspectiva del usuario…
apropiada para su objetivo (fitness for purpose)
•
La perspectiva de manufactura…
conformancia con la especificación
•
La perspectiva de producto…
la calidad se encuentra intensamen te relacionada con características
inherentes al producto
•
La perspectiva del valor…
la calidad es dependiente de la cantidad que el cliente quiere pagar
por ella
Preparado por:
Calidad:
IEEE Standard Glossary of Software Engineering
Terminology
El grado en el que un sistema,
componente o proceso cumple con:
1. los requisitos especificados, y
2. las necesidades y expectativas del
cliente o usuario
Preparado por:
Calidad del Software: Características
(ISO 9126)
Funcionalidad
Facilidad de Uso
Eficiencia
Facilidad de Mantenimiento
Portabilidad
Preparado por:
Calidad del Software
Fiabilidad
La capacidad del software de proveer funciones que
cumplan con las necesidades implícitas y las
establecidas …
Funcionalidad
Facilidad de Uso
Eficiencia
Facilidad de Mantenimiento
Portabilidad
Preparado por:
Calidad del Software
Fiabilidad
•apropiado
•precisión
•interoperación
•seguridad de acceso
•conformidad
functionality
suitability
accuracy
interoperability
security
compliance
La capacidad del software de mantener su
nivel de desempeño…
Funcionalidad
Facilidad de Uso
Eficiencia
Facilidad de Mantenimiento
Portabilidad
Preparado por:
Calidad del Software
Fiabilidad
•madurez
•tolerancia a fallos
•capacidad de recuperación
•conformidad
reliability
maturity
fault tolerance
recoverability
compliance
La capacidad del software de ser entendido,
aprendido, usado y gustado por el usuario …
Funcionalidad
Facilidad de Uso
Eficiencia
Facilidad de Mantenimiento
Portabilidad
Preparado por:
Calidad del Software
Fiabilidad
•entendible
•facilidad de aprendizaje
•facilidad de operación
•atractivo
•conformidad
usability
understandability
learnability
operability
attractiveness
compliance
La capacidad del software de proveer el desempeño
requerido, relativo a la catidad de recursos usados…
Funcionalidad
Facilidad de Uso
Eficiencia
Facilidad de Mantenimiento
Portabilidad
Preparado por:
Calidad del Software
Fiabilidad
•tiempos de respuesta
•consumo de recursos
•conformidad
efficiency
time behaviour
resource utilization
compliance
La capacidad del software de ser modificado.
Modificaciones pueden incluir correcciones, mejoras o
adaptaciones a cambios…
Funcionalidad
Facilidad de Uso
Eficiencia
Facilidad de Mantenimiento
Portabilidad
Preparado por:
Calidad del Software
Fiabilidad
•facilidad de análisis
•facilidad de modificaciones
•estabilidad
•facilidad de pruebas
•conformidad
maintainability
analysability
changeability
stability
testability
compliance
La capacidad del software de ser transferido de un
ambiente a otro (organizacional, hardware o
software)…
Funcionalidad
Facilidad de Uso
Eficiencia
Facilidad de Mantenimiento
Portabilidad
Preparado por:
Calidad del Software
Fiabilidad
•facilidad de adaptación
•facilidad de instalación
•co-existencia
•facilidad de reemplazo
•conformidad
portability
adaptabilit
installability
y
co-existence
replaceability
compliance
Mejores Prácticas en Desarrollo de Software
Mejores Prácticas
Proceso Práctico
Desarrollo Iterativo
Gestión de requisitos
Arquitecturas basadas en
componentes
Modelado Visual (UML)
Verificación Continua de la
Calidad
Gestión del Cambio
Preparado por:
¡Cambiar!
¿Qué es lo primero que se le viene a la mente?
¡Otra vez!
¡Problemas!
¡Ya no lo hago!
En elEspecificaciones
desarrollo de software,
de
Plataforma
distribución
Criterios
detiempo!
liberación
Pruebas
Errores
Código
¡Todo
el
Requerimientos
Modelos
integración
¡Los cambios
ocurren!
Preparado por:
El Proceso de Cambio: El Problema
¿El requerimiento Añadir cálculo de ¿Cuántos errores
849Prioridad 1
462 se incluyó en
promoción Errorde
Nueva
Error 527 Nueva plataforma
faltan?
Nuevo
esta liberación?
transacción del
botón GUI Error 98 Nuevo diseño web
Error 179 Error 251
Error 348
cliente
Líder de Proyecto
Analista
¿Por qué el
build no se
realizó?
Por supuesto
que no olvidé el
archivo...
¿Se arregló el
error 873 en
este build?
Build 3
Build 2 Build 1
Integrador
Desarrolladores
Preparado por:
Probadores
Dificultades del Desarrollador:
Desarrollador
• Acceso a la versión adecuada del producto.
• Desarrollar y probar en un entorno estable.
• Sincronización con el resto del equipo.
• Como resolver defectos sin afectar al
desarrollo
Preparado por:
Dificultades del Líder de Proyecto:
Líder de Proyecto
• Evaluar el estado del proyecto.
• Comunicación entre los miembros.
• Gestionar de proyectos en paralelo.
• Procesos de control y seguimiento.
Preparado por:
Dificultades del Integrador
Integrador
• Gran cantidad de versiones de archivos.
• Dependencias entre componentes.
• Pases a producción consistentes.
Jefe de Proyecto
Integrador
Preparado por:
Factores que dificultan la gestión del cambio
•
Complejidad en el entorno del
proyecto.
– Tamaño del equipo.
– Interdependencia entre componentes.
– Distribución geográfica.
•
Complejidad del Sistema de Software.
– Tamaño del producto.
– Complejidad de la arquitectura.
– Número de plataformas.
•
Aparición de nuevas tecnologías y
requisitos.
Preparado por:
Unificar la administración de cambios
La gente realiza las
actividades ( i.e., órdenes
de trabajo, corrección de
errores)
?
¿Cómo cerrar el
ciclo?
Añadir el
Error
Cálculo de
849
ErrorPromoción
Nueva
Nueva
plataforma
Nuevo 527
Nuevo diseñoTransacción del
Bug
98
boton GUI
Cliente
Web
Error
Erro 348
Error 179
251
Las Actividades
generan artefactos
(i.e., módulos de
código)
Preparado por:
Los artefactos se
integran en líneas base
El Proceso de Cambio: La Solución
Administración de
configuración y cambios
Órdenes de Trabajo
Petición de
cambios y
arreglo de
defectos
Fallas reportadas
Petición de nuevas
características
Preparado por:
Administración
de
configuración
Calidad
del
producto
Proceso basado en actividades
New widget
Bug 952
Bug 396
New ButtonBug 953
New Script
New widget
Bug 952
New
Newwidget
widget
Bug
951
New widgetNew Script
MS Windows 2000 New widget New List
Bug 952
Bug 400
Bugs 959 New Script
Bug 396
New
Button Bug
New DB support Update Doc Bug Fix 196
950
Preparado por:
Proceso basado en actividades
Bug Fix 480
Integration
Bugs 411
New Graphics
Bug Fix 581
Bug 611
New Script
Bug Fix 480
New widget
More stuff!
New GUI
New GUI
Bug 862
MS Win 2000
DB support
Bugs 411
New GUI
Bug 396
New button
New widget
New List
DB support
Bug Fix 196
Preparado por:
Controlar los cambios del software
Orden de Trabajo
Requerimientos
To Do List
1. Define Promo
2. Define GUI
3. Add Use Case
Diseño
Líder de
Proyecto
Desarrollo
Pruebas
To Do List
To Do List
1. Fix Bug 671
2. Special Promo
3. Fix Bug 829
1. Special Promo
2. Add copyright
3. Update price
Requirements
Code
Requirement
Document
hello.c
foo.c
Rose models
Preparado por:
Content
To Do List
1. Test Promo
2. Verify Bug 467
3. Test GUI applet
Test Scripts
Delete items
Cancel Order
Special Promo
Administración de la configuración y cambios:
Mediciones
• “¿Los defectos de alto grado se lograron resolver en
este build?”
• “¿Cúales cambios faltan por resolver?”
Métricas revelan el estado del
proyecto en cualquier
momento.
Líder del Proyecto
Preparado por:
Gestión del trabajo en paralelo
• Líneas de desarrollo y de
mantenimiento.
• Concurrencia en el desarrollo.
• Particularización de
componentes.
• Distintas versiones en
producción.
Preparado por:
Administración de Configuración y Cambios
• Permitir, controlar y monitorear cambios para habilitar un
desarrollo iterativo.
• Controlar todos los artefactos de software - modelos, código,
documentos, etc.
• Administrar todas las versiones, con integración automática a
los cambios realizados al software.
• Establecer espacios de trabajo seguros y aislados para cada
desarrollador.
• Contar con métricas de estado y avance.
¡ Saber qué está pasando en el equipo y en el proyecto !
Preparado por:
Gestión de Procesos
¿tenemos tiempo?….
Preparado por:
Modelos de Gestión de
Procesos
QUÉ Genérico
ISO 9000
CMM – Mejores Prácticas
Metodología- Proceso de la Organización
Herramientas
Preparado por:
QUÉ Especializado
CÓMO
CON QUÉ
Características de
ISO 9000
•
•
•
•
Norma mexicana
Certificación reconocida a nivel internacional
Asegura la mejora continua de procesos
Establece una cultura organizacional de
calidad
• No provee lineamientos específicos para
procesos especializados a un área de
aplicación (de software en particular)
Preparado por:
ISO 9000
En el año 2000 se emitió una
serie revisada de normas
ISO 9000
• Estructura orientada a procesos
• Énfasis en la mejora continua, para
mejorar la calidad del sistema y los
procesos
• Medición de la satisfacción del cliente
• Mayor atención a la provisión de recursos
• Análisis de datos del desempeño del
sistema
Preparado por:
Los Ocho Principios de Gestión
de la Calidad
•
•
•
•
•
•
•
•
Orientación al cliente
Liderazgo
Participación del personal
Enfoque a procesos
Enfoque sistémico
Mejora continua
Toma de decisiones basadas en hechos
Relaciones mutuamente benéficas con
proveedores
Preparado por:
ISO 9000
Enfoque a la Gestión de
Procesos ISO 9001:2000
Cliente
Cliente
Responsabilidad de
la Dirección
Gestión de los
Recursos
Medición, Análisis y
Mejora
Realización del
Producto
Requisitos
Preparado por:
ISO 9000
Producto
Satisfacción
Gestión de Procesos
• Establecer y mantener una política
organizacional.
• Establecer y mantener requisitos, objetivos y
planes.
• Proveer recursos adecuados.
• Asignación de la responsabilidad y autoridad.
• Capacitación de la gente.
• Realización del proceso.
• Administración de la configuración de los
productos de trabajo.
• Seguimiento y control de actividades.
• Verificación objetiva de la conformidad.
• Revisión por la alta gerencia y resolución de
asuntos.
Preparado por:
ISO 9000
Modelos de Gestión de
Procesos
QUÉ Genérico
ISO 9000
CMM – Mejores Prácticas
Metodología- Proceso de la Organización
Herramientas
Preparado por:
QUÉ Especializado
CÓMO
CON QUÉ
El Software Engineering
Institute (SEI)
•
El Software Engineering Institute (SEI) de la
Universidad de Carnegie Mellon
(Pittsburgh, Pa.) es financiado por el
departamento de defensa de los E.U.A.
•
El SEI ha desarrollado, y constantemente
está refinando, una metodología para la
gestión y mejora de la capacidad del
proceso de software
•
El Capability Maturity Model (CMM) fué
desarrollado con dos propósitos:
 Proporcionar al Departamento de
Defensa un medio para caracterizar la
capacidad de los contratistas de
software
 Ayudar a determinar y mejorar las
capacidades de las organizaciones de
desarrollo de software
Preparado por:
CMM
Información relacionada con el SEI:
http://www.sei.cmu.edu
Gestión del Proceso de
Software
CMM
Responsabilidad de
la Dirección
Gestión de los
Recursos
Medición, Análisis y
Mejora
Proceso de
Software
Realización del
Producto
5
Optimizado
4
Administrado
3
Definido/ Organización
2
Repetible/ Proyecto
1
A la medida
Niveles de Madurez de Capacidad del Proceso
Preparado por:
Institucionalización de
procesos
CMM
Compromiso para Ejecutar
Dirección
Recursos
Habilidad para Ejecutar
Medición
Realización
Actividades Realizadas
Verificación de la Implantación
Medición y Análisis
Plan de Calidad del Proceso
ISO 9001: 2000
Preparado por:
Características Comunes
del Proceso
CMM
Institucionalización de
procesos
CMM
Compromiso para Ejecutar
Dirección
Recursos
Habilidad para Ejecutar
Medición
Realización
Actividades Realizadas
Verificación de la Implantación
Medición y Análisis
Plan de Calidad del Proceso
ISO 9001: 2000
Preparado por:
Características Comunes
del Proceso
CMM
Institucionalización de
procesos
CMM
Compromiso para Ejecutar
Dirección
Recursos
Habilidad para Ejecutar
Medición
Realización
Actividades Realizadas
Verificación de la Implantación
Medición y Análisis
Plan de Calidad del Proceso
ISO 9001: 2000
Preparado por:
Características Comunes
del Proceso
CMM
Institucionalización de
procesos
CMM
Compromiso para Ejecutar
Dirección
Recursos
Habilidad para Ejecutar
Medición
Realización
Actividades Realizadas
Verificación de la Implantación
Medición y Análisis
Plan de Calidad del Proceso
ISO 9001: 2000
Preparado por:
Características Comunes
del Proceso
CMM
Institucionalización de
procesos
CMM
Compromiso para Ejecutar
Dirección
Recursos
Habilidad para Ejecutar
Medición
Realización
Actividades Realizadas
Verificación de la Implantación
Medición y Análisis
Plan de Calidad del Proceso
ISO 9001: 2000
Preparado por:
Características Comunes
del Proceso
CMM
Áreas Clave del Proceso de
Software
Coordinación Intergrupal (CI-3)
CMM
Revisiones entre Colegas (RC-3)
Ingeniería de Software (IS-3)
Programa Integral de Capacitación (PC-3)
Admón. Integrada de Software (AI–3)
Definición de Procesos de la Organización (PO-3)
Enfoque a Procesos de la Organización (EP-3)
Admón. de Configuraciones (AC-2)
Aseguramiento de la Calidad (QA-2)
5
Optimizado
4
Administrado
3
Definido/ Organización
2
Repetible/ Proyecto
1
A la medida
Admón. de Subcontratistas (AS-2)
Seguimiento a Proyectos (SP-2)
Planeación de Proyectos (PP-2)
Admón. de Requerimientos (AR-2)
Preparado por:
Niveles de Madurez de Capacidad del Proceso
Modelos de Gestión de
Procesos
QUÉ Genérico
ISO 9000
CMM – Mejores Prácticas
Metodología- Proceso de la Organización
Herramientas
Preparado por:
QUÉ Especializado
CÓMO
CON QUÉ
RUP : Un Proceso Práctico de
Desarrollo
Responsabilidad de
la Dirección
RUP
Gestión de los
Recursos
Medición, Análisis y
Mejora
Proceso de
Software
Realización del
Producto
5
Optimizado
4
Administrado
RUP: materializa las Mejores Prácticas y asegura que todos entiendan
claramente y puedan seguir un proceso práctico al desarrollar software
Preparado por:
RUP entrega el COMO que
requiere ISO y CMM
• El RUP define QUE
actividades hay que
hacer, QUIEN, CUANDO
y COMO hacerlas
• La información que necesitas
(con tanto detalle como
requieras)
• Cuando la necesitas
• En un formato realmente
utilizable
RUP is a way to successfully fulfill CMM requirements
Philippe Krutchen,2001
Preparado por:
RUP
Gracias
Preparado por:
Descargar

Slide 1