Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Clase1 CACIC 2007
Clase1 CACIC 2007
de Proyectos de Software
CACIC 2007 - Clase 1
Agenda
Introducción
Software
Ingeniería de Software
Ciclo de vida de desarrollo de Software
Técnicas de desarrollo ágiles
1
Introducción – Modalidad del curso
Consta de 5 clases teórico – prácticas
2
Introducción - Planificación Estratégica
La planificación estratégica es el proceso
administrativo de desarrollar y mantener una
relación viable entre los objetivos recursos de la
organización y las cambiantes oportunidades
del mercado. El objetivo de la planificación
estratégica es modelar y remodelar los negocios
y productos de la empresa, de manera que se
combinen para producir un desarrollo y
utilidades satisfactorios.
Como se adecua esta “definición” al contexto del
software?
3
Agenda
Introducción
Software
Ingeniería de Software
Ciclo de vida de desarrollo de Software
Técnicas de desarrollo ágiles
Software - Introducción
“Antes de mirar más profundamente el proceso de
creación del software, será útil explorar algunos
aspectos del software mismo. Como dice el viejo adagio:
'Para derrotar a tu enemigo debes conocerlo'.”(Freeman)
4
Software - Introducción
Lo importante no es qué es el software, sino:
cómo se piensa sobre él (qué imagen se tiene)
qué papel juega en un contexto mayor
Software - Introducción
Esta simplificación se traduce en condicionar el
ambiente para producir código
Resultado:
montañas de código que no se pueden integrar a trabajar
como un sistema
construcción de sistemas que no satisfacen las necesidades
de los usuarios, aunque estén bien técnicamente
5
Software – Que es ?
Alma y cerebro de una computadora
Corporización de las funciones de un sistema
El conocimiento capturado acerca de un área de
aplicación
Colección de los programas y datos necesarios para
convertir a una computadora (de propósito general) en
una máquina de propósito especial diseñada para una
aplicación particular.
Información (documentación) producida durante el
desarrollo de un sistema software-intensivo.
Software – Que es ?
El software es muchas cosas, pero todos son aspectos
de la información
En definitiva es una cuestión de semántica:
si software = programas ejecutables, excluimos una cantidad
de información que debemos llamar de alguna manera
si incluimos toda la información relevante a una pieza de
software ejecutable, entonces nos debemos relacionar con esa
información en la misma forma rigurosa y sistemática que lo
hacemos con el software ejecutable,
Esto es crucial para un desarrollo exitoso, pues si no
se hace, la información se pierde o altera introduciendo
errores
6
Software - Representaciones
Cualquier información que en forma directa representa
un eventual conjunto de programas y los datos
asociados
Incluye
programas
diseños detallados
diseños de arquitectura (representados como diagramas de
estructura)
especificaciones escritas en un lenguaje formal
requerimientos del sistema expresados en una combinación de
notaciones
o cualquiera de centenares de posibilidades
Es intangible
Alto contenido intelectual
No se lo reconoce como un activo contable
Su proceso de desarrollo es mano de obra
intensivo, basado en equipos y por proyectos
Potencialmente es modificable hasta el infinito
7
Software – Cualidades (Procesos y Productos)
8
Software – Cualidades (Procesos y Productos)
Comprensibilidad: facilidad de ser entendidos por los usuarios
(desarrolladores)
Software
Ejercicio en grupo
9
Agenda
Introducción
Software
Ingeniería de Software
Ciclo de vida de desarrollo de Software
Técnicas de desarrollo ágiles
Ingeniería de Software
Objetivo de la Ingeniería: construcción de producto.
10
Ingeniería de Software
La producción de Software es humano-intensiva:
requiere más ingeniería que manufactura. El
proceso de producción de software se vincula
más con el diseño e implementación que con la
manufactura.
Ingeniería de Software
Fairley
La Ingeniería Software es la disciplina tecnológica y de administración que
se ocupa de la producción y evolución sistemática de productos de
software que son desarrollados y modificados dentro de los tiempos y
costos estimados
Ghezzi
Ingeniería Software es el campo de la ciencia de la computación que trata
con la construcción de sistemas de software que son tan grandes o
complejos que son construídos por un equipo o equipos de ingenieros
IEEE
1. El uso de un enfoque sistemático, disciplinado y cuantificable para el
desarrollo, operación y mantenimiento de software, es decir, la aplicación
de la ingeniería al software,
2. el estudio de enfoques relacionados con (1)
11
Ingeniería de Software - Proceso
Proceso: Conjunto de pasos que involucran actividades,
restricciones y recursos que producen un output de algún tipo
Ingeniería de Software
La aplicación exitosa de la disciplina ingeniería requiere:
12
Agenda
Introducción
Software
Ingeniería de Software
Ciclo de vida de desarrollo de Software
Técnicas de desarrollo ágiles
13
Ciclo de vida de desarrollo de Software
Planeamiento
Operación
y Desarrollo
Mantenimiento
Necesidades Resultado
PROJECT MANAGEMENT
14
Requerimientos
de softtware
MCV: Cascada completo
Diseño
arquitectura
Diseño
detallado
Codificación
Testeo
unitario
Testeo
integración
Testeo Operación y
sistema mantenimiento
CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software
software 29
15
Ventajas del Cascada
Buen desempeño con definición estable del producto y con
metodologías bien comprendidas
Como todo el planeamiento se hace al principio, minimiza el
overhead del planeamiento
No provee productos tangibles de software hasta el final, pero
la documentación que generan provee indicaciones de
progreso
Funciona bien en proyectos complejos y bien comprendidos
Funciona bien cuando los requerimientos de calidad
predominan sobre los de costo y cronograma
Como no hay cambios en el proceso, se elimina una fuente
de errores
Trabaja bien con gente técnicamente débil o inexperto,
porque provee una estructura que minimiza el deperdicio de
esfuerzo
CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 31
16
Problemas del Cascada
17
Code-and-fix
Habitualmente es el que se usa cuando no se
usa ningún ciclo de vida
Si no hay mucho planeamiento seguro se usa
este ciclo
Se parte de una idea general del producto (con
o sin especificación)
Luego se usa una combinación de diseño
informal, metodologías varias hasta que se tiene
un producto para entregar
Code-and-fix
Ventajas:
1. No hay overhead, no se pierde tiempo en ninguna actividad
más que en codificar
2. No requiere entrenamiento: cualquiera que sepa programar
está familiarizado con este ciclo
Desventajas:
1. Salvo proyectos pequeños es un modelo peligroso: no se
puede evaluar el progreso hasta que se hizo el código, no
hay forma de evaluar calidad ni de identificar riesgos
2. Si se descubre que el enfoque de diseño es equivocado, no
hay otra que volver a empezar
18
Modelo Espiral
McConnell
CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 37
19
Modelo Espiral - Características
Es el ciclo de vida más sofisticado
El
“riesgo” se refiere a no entender los requerimientos o la
arquitectura, problemas de performance, etc
Las iteraciones iniciales son las más baratas: se gasta menos en las
iniciales
Se
puede combinar con otros modelos de ciclo de vida de dos
maneras:
Una vez que se redujeron los riesgos con iteraciones se puede seguir
con otro ciclo
Dentro de un ciclo de vida, se puede incluir una iteración para resolver
algún tipo de riesgo
20
Modelo Espiral - Ventajas
21
Prototipos - Tipologia
Escenarios o simulaciones, herramienta para entender o
validar los requerimientos del usuario
Entrega en etapas
Requerimientos (implementación
de softtware
incremental)
Diseño
preliminar
Etapa 1
Diseño detallado,
Codificación, Etapa 2
Testeo, Delivery
Diseño detallado,
Codificación,
Testeo y Delivery Etapa n
Diseño detallado,
Codificación,
Testeo y Delivery
22
Entrega evolutiva
Concepto
del softtware
Requerimientos
de softtware Entrega de la
(preliminares) versión final
Diseño
arquitectura y
núcleo del sist.
Desarrollo
de versión
Incorporar el
feedback del Entrega de
consumidor versión
Elicitación del
feedback del
consumidor
Requerimientos Requerimientos
de softtware de softtware
Diseño Diseño
Codificación Codificación
Testeo Testeo
Análisis Análisis
23
Prácticas de desarrollo incremental
Aluden a desarrollo y entrega en etapas
Facilitan la visibilidad
24
Modelo Reuso
Sistema
desarrollado Repositorio de Nuevo sistema
previamente software a desarrollar
Requerimientos
Requerimientos de softtware Requerimientos
de softtware de softtware
Testeo Testeo
Testeo
Agenda
Introducción
Software
Ingeniería de Software
Ciclo de vida de desarrollo de Software
Técnicas de desarrollo ágiles
25
Métodos ágiles
Algunos problemas “motivadores”
Requerimientos fuera de control
No cumplimiento de los tiempos planificados (Desvíos)
Estimaciones deficientes
Re-trabajo excesivo
Baja calidad
Costos excedidos
Insatisfacción del Cliente
Insatisfacción de los profesionales participantes
Métodos ágiles
Características
Promueven prácticas adaptativas en lugar de predictivas
Iterativo. A intervalos regulares el equipo reflexiona
sobre cómo ser más efectivo.
Comunicación intensiva
La mayor prioridad es satisfacer al cliente a través de la
entrega temprana y continua de software con valor.
Se aceptan req cambiantes, incluso en etapas
avanzadas.
Se entrega software frecuentemente.
Los responsables de negocio y los desarrolladores
deben trabajar juntos diariamente a lo largo del
proyecto.
26
Métodos ágiles
Características
Proyectos con profesionales motivados.
Conversación cara a cara.
Software que funciona es la principal medida de
progreso.
Los procesos ágiles promueven el desarrollo sostenible.
La atención continua a la excelencia técnica y los
buenos diseños mejoran la agilidad.
Simplicidad es esencial.
Las mejores arquitecturas, req. y diseños surgen de
equipos que se auto-organizan.
27
XP - Valores
Comunicación: Promueve la comunicación entre los stakeholders y el
equipo, así como también entre los desarrolladores y el equipo.
XP - Cinco principios
Realimentación rápida: El tiempo entre una acción y la
retroalimentación de la misma es critico. Obtener feedback,
interpretarlo, poner lo aprendido en el sistema lo más rápido posible.
Asumir la Simplicidad: La solución simple es la mejor solución. Hacer
una buena tarea: resolver hoy la tarea de hoy y confiar a la habilidad
del desarrollador para añadir complejidad en el futuro.
Cambio Incremental: Grandes cambios de una vez no funcionan. Los
problemas se resuelven con una serie de pequeños cambios que
hacen diferencia.
Adherirse (Abrazar) al Cambio: La mejor estrategia es la que preseve
la mayor parte de las opciones mientras resuelve el problema de
mayor presión.
Trabajo de Alta Calidad: Debe realizarse con la mayor calidad y
rehacerlo, cuando exista algún motivo para ello. La calidad es una
variable dependiente
28
XP - Más principios Trabajar con el instinto de la gente y
no contra ellos: partir de que la gente
Enseñar a aprender: Más que quiere ganar, aprender, interactuar,
enseñar un método de testeo, diseño etc.
o lo que fuera, enseñar estrategias Responsabilidad aceptada: La
para hacer todo el testeo que se debe responsabilidad se acepta no se
hacer. impone. Se ejecutan las tareas que
Inversión inicial pequeña: Un gran decide el equipo.
presupuesto es fuente de desastres. Adaptarse a las condiciones locales:
Un presupuesto apretado fuerza a Todo lo que se intente hacer debe
limar requerimientos e incita a hacer adecuarse a las condiciones
un buen trabajo. específicas del ambiente.
Jugar para ganar: Diferenciar entre
Viajar liviano: No se puede mover
jugar para ganar y jugar para no rápido con un equipaje muy pesado.
perder, ayuda a poner la vara alta. Los artefactos deberían ser: pocos,
Hacer experimentos concretos: simples y valiosos.
Testear las ideas antes de ponerlas Mediciones honestas: Medir es valioso
en práctica. pero deben hacerse a un nivel de
Comunicación honesta y bbierta: detalle que lo permitan nuestros
Despersonalizar las argumentaciones, instrumentos.
no convertir en secreto cosas
innecesarias.
CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 57
XP - Actividades básicas
Codificación
Al final del día tiene que haber un programa
Es la actividad sin la que no se puede hacer nada
Testing
“Lo que no se puede medir no existe” (Hume)
Features del software que no se pueden demostrar por el testeo
no existen
Escuchar
Los programadores no conocen el dominio, luego aprenden
escuchando a los clientes
Diseño
El diseño organiza la lógica de cada una de las partes
29
XP - Materias primas
La historia
Los valores (comunicación, simplicidad, feedback y
coraje)
Los principios (cinco + más principios)
Actividades básicas (Codificar, Testear, Escuchar y
Diseñar)
XP - Las Prácticas
1. El Juego de la Planificación
2. Versiones Pequeñas
3. Diseño Simple
4. Testing
5. Refactoring
6. Metáforas
7. Programación por Pares
8. Propiedad Colectiva
9. Integración Continua
10. Semana de 40 hs
11. Cliente in Site
12. Estándares de Codificación
30
XP - Estrategia de gerenciamiento
Mediciones
Herramienta básica de gestión de XP
Pocas métricas y retirar las que cumplieron sus función
No es “gestión por los números”
Coaching
Preocupado por la ejecución (y evolución) técnica del proceso
Coacher: no tiene responsabilidad en las decisiones, sino que
los demás las tomen bien, buen comunicador y técnicamente,
apoyo en dificultades técnicas
Tracking
Medir lo hecho contra lo predecido
Intervención
Cuando los problemas no pueden ser resueltos por el equipo
XP - Estrategias clave
Planeamiento
Desarrollo
Diseño
Testeo
31
XP - Planeamiento
Se escriben las Historia de los usuarios
Se crean un Plan de Entrega de Versiones
Se hacen muchas versiones pequeñas
Se mide la velocidad del proyecto
El proyecto se divide en iteraciones
El Planeamiento de Iteración comienza con cada
iteración
Mover la gente
Cada día se comienza con un stand-up meeting
Se modifican los procesos de XP cuando sea necesario
XP - Codificación
El cliente está siempre disponible
Codificación estándar
Codificar primero la unidad de testeo
Todo el código de producción es programado de a pares
Solo un par por vez integran código
Integración continua
Código colectivo
Optimizar al final
No trabajar horas extras
32
XP - Diseño
Simplicidad
No agregar funcionalidad antes de tiempo
Refactorizar cuando y donde sea posible
XP - Testing
Todo el código debe tener unidades de testeo
Todo código debe pasar las unidades de testeo
antes de ser liberado
Cuando se encuentra un error, se crean tests.
Frecuentemente se corren tests de aceptación y
se publica el resultado.
33
SCRUM - Generalidades
Después de XP es la mas conocida, recomendada como complemento
(ocupa un lugar bajo en el mercado)
SCRUM – Valores
Equipos auto-dirigidos y auto-organizados. No hay manager que
decida, ni otros títulos que “miembros del equipo”; la excepción es el
Scrum Master que debe ser 50% programador y que resuelve
problemas, pero no manda. Los observadores externos pueden
observar, pero no interferir ni opinar.
Una vez elegida una tarea, no se agrega trabajo extra. En caso que se
agregue algo, se recomienda quitar alguna otra cosa.
Encuentros diarios 15 a 30 minutos “Scrums” con las tres preguntas:
• ¿Qué has hecho en este proyecto desde el ultimo encuentro ?
• ¿ Qué planeas hacer en el proyecto entre hoy y el próximo encuentro?
• ¿ Qué obstáculos se te han presentado para lograr lo prometido?
Iteraciones de trabajo de treinta días (“sprints”); se admite que sean
más frecuentes.
Al principio de cada iteración, planeamiento adaptativo guiado por el
cliente.
34
XP + SCRUM – Experiencias
35
Referencias
Arango, G., “¿Qué es la Ingeniería de Software?”, Noticiero SADIO, año 25, 1
(marzo-abril) 1993, 7-11.
Basili, V., Class Notes, Chap 1 The Software Business.
Freeman, P., “Psst, What Is Software, Anyway?”, en Software Perspectives. The
System is the Message, Addison-Wesley, Reading Mass, 1987. Capítulo 1, pp 3-28.
Ghezzi, C., Jazayeri, M., Mandrioli, D., Fundamentales of Software Engineering,
Prentice-Hall International, Englewood Cliffs, 1991.
McConnell, S., “Who Needs Software Engineering?”, IEEE Software, jan-feb 2001
McConnell, S., Software Project Survival Guide, Microsoft Press, 1998, Redmond
McConnell, S., Rapid Development, Microsoft Press, 1996
Zelkowitz, M.V., MSWE 607 Software Life Cycle Methods and Techniques, Maryland,
2000, Notas de aula
Reifer, D.J., “Web Development: Estimating Quick-to-Market Software”, IEEE
Software, nov/dic 2000
Feiler, P H and Humphrey, W S ‘Software process development and enactment:
concepts and definitions’ in Proc. 2nd Int. Conf: Software Process, Berlin, Germany
(25-26 February 1993) pp 28-39
Extreme Programming: A gentle introduction,
http://www.extremeprogramming.org/index2.html
Beck,K., Extreme Programming. Embrance Change, Addison-Wesley, Bosto, 2000
http://jeffsutherland.com/scrum
36