Clase1 CACIC 2007

Planificación Estratégica
de Proyectos de Software
CACIC 2007 - Clase 1
Mg. Rodolfo Bertone

Mg. Pablo Thomas
Facultad de Informática - UNLP
Agenda
Introducción
Software
Ingeniería de Software
Ciclo de vida de desarrollo de Software
Técnicas de desarrollo ágiles
CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 2
1
Introducción – Modalidad del curso
Consta de 5 clases teórico – prácticas
El día viernes en la segunda mitad del

horario establecido, habrá un examen
general tipo elección múltiple.
Introducción - Planificación Estratégica

La planificación estratégica es un enfoque de
sistemas para guiar a una empresa durante un
tiempo a través de su medio ambiente, para
lograr las metas dictadas.
Esto define la PE de manera global
Se puede aplicar esta definición al área de
Informática de una organización?
Cuales es el contexto que debería tenerse en
cuenta?
2
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?

La planificación estratégica proporciona la dirección que
guiará la misión, los objetivos y las estrategias de la
empresa, pues facilita el desarrollo de planes para cada
una de sus áreas funcionales.
Un plan estratégico completo guía cada una de las
áreas en la dirección que la organización desea seguir y
les permite desarrollar objetivos, estrategias y
programas adecuados a las metas.
La relación entre la planificación estratégica y la de
operaciones es parte importante de las tareas de la
gerencia.
Como podemos aplicar esta ideas ideas en la industria del
software?
3
Agenda
Introducción
Software
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)
El software es más que programas.
Hay una característica de él que debe atenderse: el

hecho que es un sistema
4
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
Punto de vista de una computadora:

El software es sólo programas
Pensar así genera problemas.
Ej: medir la productividad por las líneas de código producidas por
unidad de tiempo (la visión errónea más difundida). Identifica
productividad en la construcción del sistema con la capacidad de
generar código
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
Software – Por qué es único ?
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)
Corrección funcional: se comporta de acuerdo a las

especificación de requerimientos funcionales.
Confiabilidad: el usuario puede depender del software
Robustez: se comporta "razonablemente", incluso en

circunstancias no previstas en la especificación de
requerimientos
Performance: uso económico de los recursos de compu-

tación (en Ingeniería Software se la identifica con eficiencia)

"Amistosidad“: fácil uso por los seres humanos
Verificabilidad: sus propiedades pueden verificarse

fácilmente
Mantenibilidad: puede repararse y evolucionar
Reusabilidad: utilizar componentes sin modificarlas en otros

sistemas
Portabilidad: puede correr en distintos ambientes
8
Comprensibilidad: facilidad de ser entendidos por los usuarios
(desarrolladores)
Interoperatividad: capacidad de coexistir y cooperar con otros

sistemas
Productividad: mide la eficiencia del proceso de producción de

software
Oportunidad: capacidad de liberar un producto en tiempo
Visibilidad: sus pasos previos y estado actual están correctamente

documentados
Software
Ejercicio en grupo
9
Agenda
Introducción
Software
Objetivo de la Ingeniería: construcción de producto.
Objetivo de la Ingeniería Software: sistemas de software
Principal diferencia: el software es maleable.
Existe la idea que los cambios en el software son fáciles.
En este punto debe pensarse a los productos de software de

otra forma:
Un cambio en el soft debe ser visto como un cambio en el
diseño más que en el código
10
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.
En la ingeniería el ingeniero dispone de

herramientas para describir el producto que son
distintas del producto, no es así en la Ingeniería
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
Involucra: Técnicas, Herramientas, Procedimientos
Proceso: Secuencia de pasos ejecutadas con un propósito

dado [IEEE-STD-610].
Proceso Software: Un conjunto de actividades, métodos,

prácticas y transformaciones que la gente usa para
desarrollar y mantener software y los productos asociados.
La aplicación exitosa de la disciplina ingeniería requiere:
Una combinación de soluciones técnicas y gerenciales

Un conjunto bien definido productos necesita:
satisfacer el cliente
asistir al desarrollador en el cumplimiento de esas necesidades
crear competencias para futuros negocios
Un conjunto bien definido de procesos:
para cumplir con las necesidades a ser cumplidas
para controlar el desarrollo
para mejorar el negocio
Un ciclo de proceso que soporte aprendizaje y realimentación
Tecnologías clave para soportar estas necesidades incluyen:
modelización, medición, reuso de procesos, productos, y
otras formas de conocimiento realevante a la disciplina
12
Agenda
Introducción
Software
En el proceso de desarrollo de software:

conjunto de actividades que generan productos
intermedios
los que, a su vez, son transformados en otros
productos por otros procesos.
El desarrollo puede verse como una cadena de

actividades con productos intermedios, esa
visión es la de ciclo de vida.
13
Planeamiento
Operación
y Desarrollo
Mantenimiento
Necesidades Resultado
Requerimientos Diseño Diseño Código

preliminar detallado
Especificar Diseñar Diseñar Codificar Delivery

Requerimientos arquitectura módulos
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
Características del Cascada

Comienzo: cuando los requerimientos están
completamente determinados
Una etapa debe concluir antes de comenzar la
subsiguiente
Recorre las etapas secuencialmente
Cuando se requiere, vuelve atrás y rehace el material:
en la práctica es típicamente iterativo
Históricamente fue el primero de todos los modelos
Fue utilizado en una variedad de contextos y aún
continua siendo el modelo de referencia que ha dado
lugar a múltiples modelos
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
Desventajas del Cascada

Las desventajas provienen de la dificultad de especificar los
requerimientos al comienzo del proyecto
Reparar un olvido en el desarrollo puede ser muy costoso
Ciertos errores de requerimientos sólo se pueden apreciar en
momentos de construcción avanzada del sistema
El mayor problema es la falta de flexibilidad (en el desarrollo
real en muchos casos no se trata de construir todo, sino lo
máximo posible)
Se puede volver atrás, pero con un gran esfuerzo
Algunas herramientas, métodos y actividades abarcan varias
etapas y es difícil adecuarlos al modelo de fases disjuntas
Para un desarrollo rápido genera demasiada documentación
Hasta el final genera pocos signos visibles de progreso, con
lo que crea la percepción de avance lento
16
Problemas del Cascada
El desarrollo de software es iterativo en su esencia
En los hechos de una etapa se pasa a cualquiera de las

otras
Se ha convertido en un “modelo ideal típico”
MCV: Code-and-fix (prueba y error)
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
Modelo Espiral - Componentes
Objetivos. Objetivo general a alcanzar, luego se ira

desglosando en más niveles.
Restricciones. Restricciones que se imponen al proyecto.
Alternativas. Se detallan las alternativas de solución.
Riesgos. Se detallan los riesgos que podría generar cada
alternativa.
Resolución de Riesgos. Propuesta de solución a cada uno
de los riesgos.
Plan de la etapa siguiente. Plan de la etapa siguiente.
Compromiso. Detalles de Compromisos para llevarla a
cabo.
19
Modelo Espiral - Características
Es el ciclo de vida más sofisticado
Esun ciclo de vida orientado al riesgo que parte el proyecto en

pequeños mini-proyectos, cada uno de los cuáles ataca algún riesgo
El
“riesgo” se refiere a no entender los requerimientos o la
arquitectura, problemas de performance, etc
Una vez que se atacaron los principales riesgos concluye como lo

haría un cascada
Diagrama expresa: se parte en pequeña escala, explora los riesgos,

hace un plan para manejarlos y plantea un enfoque para la próxima
iteración
Modelo Espiral - Características

Cada iteración abarca los seis pasos del espiral
Las iteraciones iniciales son las más baratas: se gasta menos en las
iniciales
No hay que tomar el diagrama muy rígidamente: pueden no ser los

seis pasos o más/menos de los cuatro loops
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
La mayor ventaja es que el aumento del costo disminuye

el riesgo
Provee tanto control gerencial como el modelo

tradicional de cascada
Como está orientado por los riesgos, provee información

temprana sobre estos
Salir del proyecto no tiene alto costo de salida en las

etapas tempranas
Modelo Espiral - Desventajas

La única dificultad es que es complicado:
requiere un gerenciamiento cuidadoso
Puede ser dificultoso definir hitos para

establecer el siguiente loop
Si el proyecto es modesto y no se requiere la

flexibilidad y gestión de riesgo de este modelo
conviene no aplicarlo
21
Prototipos - Tipologia
Escenarios o simulaciones, herramienta para entender o
validar los requerimientos del usuario
Rápidos desechables, construcción “quick and dirty” que

atacan un aspecto particular para que el usuario
potencial lo utilice durante un tiempo y provea
información al equipo.
Evolutivos, atacan una funcionalidad acotada del

sistema que resuelve algunos de 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
Otra vista de la entrega evolutiva
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
Reducen el riesgo con el principio “divide y conquistarás”: los

proyectos pequeños son menos dificultosos que los grandes
Facilitan la visibilidad
Permiten cambios durante el desarrollo
Los MCV que soportan el incremental:

Espiral
Prototipo evolutivo
Entrega en etapas
Entrega evolutiva
Compra de software (Commercial-off-the-

shelf-software)
Es una alternativa que a veces no lo se la considera
adecuadamente
Raramente satisface las necesidades
Está disponible inmediatamente
Hasta el momento en que se pone en funcionamiento
los usuarios pueden trabajar sobre alguna versión
No debe comparárselo con el producto planeado, sino
con lo que resulta en la realidad
En el desarrollo se concede en diseño, costo y
cronograma
Requiere la habilidad para la gestión de compras de
software
Una variante es la de contratar el desarrollo
24
Modelo Reuso
Sistema
desarrollado Repositorio de Nuevo sistema
previamente software a desarrollar
Requerimientos
Requerimientos de softtware Requerimientos
de softtware de softtware
Diseño Diseño Diseño
Codificación Codificación Codificación
Testeo Testeo
Testeo
Agenda
Introducción
Software
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.
XP - Valores & Principios

Valores Más principios
Comunicación Enseñar a aprender
Simplicidad Inversión inicial pequeña
Jugar para ganar
Feedback
Hacer experimentos concretos:
Coraje
Comunicación honesta y
abierta:
Cinco Principios Trabajar con el instinto de la
Realimentación rápida gente y no contra ellos
Asumir la Simplicidad Responsabilidad aceptada
Cambio Incremental Adaptarse a las condiciones

locales:
Adherirse (Abrazar) al Cambio
Viajar liviano
Trabajo de Alta Calidad
Mediciones honestas
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.
Simplicidad: Es importante que los desarrolladores entiendan el

modelo para simplificar el proceso y el software en sí. Es mejor
desarrollar algo simple y mejorarla más adelante si es necesario,
que gastar tiempo en una idea compleja que nunca se usará
plenamente.
Feedback: “Optimismo es una ocupación peligrosa de programación,

Feedback es el tratamiento” [Beck]. Con la comunicación de ideas
a través de diagramas se tiene una rápida retroalimentación.
Coraje: El Coraje es importante porque se necesita tomar decisiones

importantes y ser capaz de cambiar la dirección o rehacer el
trabajo cuando alguna decisión fue inadecuada.
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.
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)
El trabajo consiste en estructurar las cuatro actividades

básicas
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)
La palabra Scrum, procede de la terminología del juego de rugby, donde

designa al acto de preparar el avance del equipo en unidad pasando la
pelota a uno y otro jugador. Igual que el juego, Scrum es adaptativo, ágil,
auto-organizante y con pocos tiempos muertos.
Fundamento: un proceso necesita aceptar el cambio en lugar de esperar

predictibilidad.
No está concebido como método independiente, sino que se promueve como

complemento de otras metodologías (por ej. XP)
Como método tiene valores y prácticas de gestión, sin pronunciarse sobre

requerimientos, implementación y demás cuestiones técnicas; de allí su
deliberada insuficiencia y función de complemento
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
Microsoft ha combinado los modelos de trabajo

ágiles XP y Scrum para finalizar el lanzamiento
de las nuevas versiones: SQL Server 2005,
Visual Studio 2005 tool suite y Biztalk server
2006 integration server
Ejercicio de Ciclos de Vida
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

Clase1 CACIC 2007

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Clase1 CACIC 2007

Hochgeladen von

Copyright:

Verfügbare Formate

Planificación Estratégica

Mg. Rodolfo Bertone

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 2

 El día viernes en la segunda mitad del

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 3

Introducción - Planificación Estratégica

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 4

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 5

Introducción - Planificación Estratégica

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 6

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 7

 El software es más que programas.

 Hay una característica de él que debe atenderse: el

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 8

 Punto de vista de una computadora:

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 9

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 10

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 11

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 12

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 13

Software – Por qué es único ?

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 14

 Corrección funcional: se comporta de acuerdo a las

 Confiabilidad: el usuario puede depender del software

 Robustez: se comporta "razonablemente", incluso en

 Performance: uso económico de los recursos de compu-

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 15

Software – Cualidades (Procesos y Productos)

 Verificabilidad: sus propiedades pueden verificarse

 Mantenibilidad: puede repararse y evolucionar

 Reusabilidad: utilizar componentes sin modificarlas en otros

 Portabilidad: puede correr en distintos ambientes

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 16

 Interoperatividad: capacidad de coexistir y cooperar con otros

 Productividad: mide la eficiencia del proceso de producción de

 Oportunidad: capacidad de liberar un producto en tiempo

 Visibilidad: sus pasos previos y estado actual están correctamente

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 17

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 18

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 19

 Objetivo de la Ingeniería Software: sistemas de software

 Principal diferencia: el software es maleable.

 Existe la idea que los cambios en el software son fáciles.

 En este punto debe pensarse a los productos de software de

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 20

 En la ingeniería el ingeniero dispone de

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 21

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 22

 Involucra: Técnicas, Herramientas, Procedimientos

 Proceso: Secuencia de pasos ejecutadas con un propósito

 Proceso Software: Un conjunto de actividades, métodos,

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 23

 Una combinación de soluciones técnicas y gerenciales

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 24

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 25

Ciclo de vida de desarrollo de Software

 En el proceso de desarrollo de software:

 El desarrollo puede verse como una cadena de

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 26

CACIC 2007 - Clase 1 Planificación estratégica de Proyectos de Software 27

Ciclo de vida de desarrollo de Software

Requerimientos Diseño Diseño Código

Especificar Diseñar Diseñar Codificar Delivery

El día viernes en la segunda mitad del

El software es más que programas.

Hay una característica de él que debe atenderse: el

Punto de vista de una computadora:

Corrección funcional: se comporta de acuerdo a las

Confiabilidad: el usuario puede depender del software

Robustez: se comporta "razonablemente", incluso en

Performance: uso económico de los recursos de compu-

Verificabilidad: sus propiedades pueden verificarse

Mantenibilidad: puede repararse y evolucionar

Reusabilidad: utilizar componentes sin modificarlas en otros

Portabilidad: puede correr en distintos ambientes

Interoperatividad: capacidad de coexistir y cooperar con otros

Productividad: mide la eficiencia del proceso de producción de

Oportunidad: capacidad de liberar un producto en tiempo

Visibilidad: sus pasos previos y estado actual están correctamente

Objetivo de la Ingeniería Software: sistemas de software

Principal diferencia: el software es maleable.

Existe la idea que los cambios en el software son fáciles.

En este punto debe pensarse a los productos de software de

En la ingeniería el ingeniero dispone de

Involucra: Técnicas, Herramientas, Procedimientos

Proceso: Secuencia de pasos ejecutadas con un propósito

Proceso Software: Un conjunto de actividades, métodos,

Una combinación de soluciones técnicas y gerenciales

En el proceso de desarrollo de software:

El desarrollo puede verse como una cadena de

El desarrollo de software es iterativo en su esencia

En los hechos de una etapa se pasa a cualquiera de las

Se ha convertido en un “modelo ideal típico”

Objetivos. Objetivo general a alcanzar, luego se ira

Esun ciclo de vida orientado al riesgo que parte el proyecto en

Una vez que se atacaron los principales riesgos concluye como lo

Diagrama expresa: se parte en pequeña escala, explora los riesgos,

No hay que tomar el diagrama muy rígidamente: pueden no ser los

La mayor ventaja es que el aumento del costo disminuye

Provee tanto control gerencial como el modelo

Como está orientado por los riesgos, provee información

Salir del proyecto no tiene alto costo de salida en las

Puede ser dificultoso definir hitos para

Si el proyecto es modesto y no se requiere la

Rápidos desechables, construcción “quick and dirty” que

Evolutivos, atacan una funcionalidad acotada del

Reducen el riesgo con el principio “divide y conquistarás”: los

Permiten cambios durante el desarrollo

Los MCV que soportan el incremental:

Cambio Incremental Adaptarse a las condiciones

La palabra Scrum, procede de la terminología del juego de rugby, donde