clase1 CACIC 2007

1

Planificación Estratégica de Proyectos de Software

CACIC 2007 - Clase 1

Mg. Rodolfo Bertone Mg. Pablo Thomas

Facultad de Informática - UNLP

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

Agenda

IntroducciónSoftwareIngeniería de SoftwareCiclo de vida de desarrollo de SoftwareTécnicas de desarrollo ágiles

2


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 globalSe puede aplicar esta definición al área de Informática de una organización?Cuales es el contexto que debería tenerse en cuenta?

3


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?


Introducción - Planificación EstratégicaLa 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?

4


Agenda



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

5


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

Punto de vista de una computadora: El software es sólo programasPensar 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 degenerar código


Software - IntroducciónEsta 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 sistemaconstrucción de sistemas que no satisfacen las necesidades de los usuarios, aunque estén bien técnicamente

6


Software – Que es ?

Alma y cerebro de una computadoraCorporización de las funciones de un sistemaEl conocimiento capturado acerca de un área de El conocimiento capturado acerca de un área de aplicaciónaplicaciónColecció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ónEn definitiva es una cuestión de semántica:

si software = programas ejecutables, excluimos una cantidad de información que debemos llamar de alguna manerasi 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

7


Software - RepresentacionesCualquier información que en forma directa representa un eventual conjunto de programas y los datos asociados Incluye

programasdiseños detalladosdiseños de arquitectura (representados como diagramas de estructura)especificaciones escritas en un lenguaje formalrequerimientos del sistema expresados en una combinación de notacioneso cualquiera de centenares de posibilidades


Software – Por qué es único ?

Es intangibleAlto contenido intelectualNo se lo reconoce como un activo contableSu proceso de desarrollo es mano de obra intensivo, basado en equipos y por proyectosPotencialmente es modificable hasta el infinito

8


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)


Software – Cualidades (Procesos y Productos)

"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

9


Software – Cualidades (Procesos y Productos)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

10


Agenda



Ingeniería de SoftwareObjetivo 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

11


Ingeniería de SoftwareLa 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.


Ingeniería de SoftwareFairley

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

IEEE1. 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)

12


Ingeniería de Software - ProcesoProceso: 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ósitodado [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.


Ingeniería de SoftwareLa aplicación exitosa de la disciplina ingeniería requiere:

Una combinación de soluciones técnicas y gerencialesUn conjunto bien definido productos necesita:

satisfacer el clienteasistir al desarrollador en el cumplimiento de esas necesidadescrear competencias para futuros negocios

Un conjunto bien definido de procesos:para cumplir con las necesidades a ser cumplidaspara controlar el desarrollopara mejorar el negocio

Un ciclo de proceso que soporte aprendizaje y realimentaciónTecnologías clave para soportar estas necesidades incluyen:

modelización, medición, reuso de procesos, productos, yotras formas de conocimiento realevante a la disciplina

13


Agenda



Ciclo de vida de desarrollo de 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.

14



Planeamiento

DesarrolloOperación

yMantenimiento



Resultado

Requerimientos Diseño preliminar

Diseño detallado

Código

Necesidades

DeliveryDiseñar arquitectura

Especificar Requerimientos

Diseñar módulos

Codificar

PROJECT MANAGEMENT

15


MCV: Cascada completoRequerimientos

de softtware

Diseño arquitectura

Diseño detallado

Codificación

Testeo unitario

Testeo integración

Testeo sistema software

Operación y mantenimiento


Características del CascadaComienzo: cuando los requerimientos están completamente determinadosUna etapa debe concluir antes de comenzar la subsiguienteRecorre las etapas secuencialmenteCuando se requiere, vuelve atrás y rehace el material: en la práctica es típicamente iterativoHistóricamente fue el primero de todos los modelosFue utilizado en una variedad de contextos y aún continua siendo el modelo de referencia que ha dado lugar a múltiples modelos

16


Ventajas del CascadaBuen desempeño con definición estable del producto y con metodologías bien comprendidasComo todo el planeamiento se hace al principio, minimiza el overhead del planeamientoNo provee productos tangibles de software hasta el final, pero la documentación que generan provee indicaciones de progresoFunciona bien en proyectos complejos y bien comprendidosFunciona bien cuando los requerimientos de calidad predominan sobre los de costo y cronogramaComo no hay cambios en el proceso, se elimina una fuente de erroresTrabaja bien con gente técnicamente débil o inexperto, porque provee una estructura que minimiza el deperdicio de esfuerzo


Desventajas del CascadaLas desventajas provienen de la dificultad de especificar los requerimientos al comienzo del proyecto Reparar un olvido en el desarrollo puede ser muy costosoCiertos errores de requerimientos sólo se pueden apreciar en momentos de construcción avanzada del sistemaEl 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 esfuerzoAlgunas herramientas, métodos y actividades abarcan varias etapas y es difícil adecuarlos al modelo de fases disjuntasPara un desarrollo rápido genera demasiada documentaciónHasta el final genera pocos signos visibles de progreso, con lo que crea la percepción de avance lento

17


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)

18


Code-and-fixHabitualmente es el que se usa cuando no se usa ningún ciclo de vidaSi no hay mucho planeamiento seguro se usa este cicloSe 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-fixVentajas:

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

19


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.

20


Modelo Espiral - CaracterísticasEs el ciclo de vida más sofisticado

Es un ciclo de vida orientado al riesgo que parte el proyecto enpequeñ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 loharí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ísticasCada 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 cicloDentro de un ciclo de vida, se puede incluir una iteración para resolver algún tipo de riesgo

21


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

22


Prototipos - TipologiaEscenarios 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.


Requerimientosde softtware

Diseño preliminar

Diseño detallado, Codificación,

Testeo, DeliveryDiseño detallado,

Codificación, Testeo y Delivery

Diseño detallado, Codificación,

Testeo y Delivery

Etapa 1

Etapa 2

Etapa n

Entrega en etapas (implementación incremental)

23


Entrega evolutivaConcepto

del softtware


(preliminares)

Diseño arquitectura y

núcleo del sist.

Desarrollo de versión

Elicitación del feedback del consumidor

Incorporar el feedback del consumidor

Entrega de versión

Entrega de la versión final


Diseño

Codificación

Testeo

Análisis

Diseño

Codificación

Testeo

Análisis

Otra vista de la entrega evolutiva



24


Prácticas de desarrollo incrementalAluden 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:EspiralPrototipo evolutivoEntrega en etapasEntrega evolutiva


Compra de software (Commercial-off-the-shelf-software)

Es una alternativa que a veces no lo se la considera adecuadamenteRaramente satisface las necesidadesEstá disponible inmediatamenteHasta el momento en que se pone en funcionamiento los usuarios pueden trabajar sobre alguna versiónNo debe comparárselo con el producto planeado, sino con lo que resulta en la realidadEn el desarrollo se concede en diseño, costo y cronogramaRequiere la habilidad para la gestión de compras de softwareUna variante es la de contratar el desarrollo

25


Diseño

Codificación

Testeo

Diseño

Codificación

Testeo

Sistema desarrollado previamente

Nuevo sistema a desarrollar


Codificación

Testeo

Repositorio de software

Diseño

Modelo Reuso




Agenda


26


Métodos ágiles

Algunos problemas “motivadores” Requerimientos fuera de controlNo cumplimiento de los tiempos planificados (Desvíos)Estimaciones deficientesRe-trabajo excesivoBaja calidadCostos excedidosInsatisfacción del ClienteInsatisfacción de los profesionales participantes


Métodos ágilesCaracterísticas

Promueven prácticas adaptativas en lugar de predictivasIterativo. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo. Comunicación intensivaLa 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.

27


Métodos ágiles

CaracterísticasProyectos 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 & PrincipiosValores

ComunicaciónSimplicidadFeedbackCoraje

Cinco PrincipiosRealimentación rápidaAsumir la SimplicidadCambio IncrementalAdherirse (Abrazar) al CambioTrabajo de Alta Calidad

Más principiosEnseñar a aprenderInversión inicial pequeñaJugar para ganarHacer experimentos concretos: Comunicación honesta y abierta: Trabajar con el instinto de la gente y no contra ellosResponsabilidad aceptadaAdaptarse a las condiciones locales: Viajar livianoMediciones honestas

28


XP - ValoresComunicació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

29


XP - Más principiosEnseñar a aprender: Más que enseñar un método de testeo, diseño o lo que fuera, enseñar estrategias para hacer todo el testeo que se debe hacer.Inversión inicial pequeña: Un gran presupuesto es fuente de desastres. Un presupuesto apretado fuerza a limar requerimientos e incita a hacer un buen trabajo. Jugar para ganar: Diferenciar entre jugar para ganar y jugar para no perder, ayuda a poner la vara alta. Hacer experimentos concretos: Testear las ideas antes de ponerlas en práctica.Comunicación honesta y bbierta: Despersonalizar las argumentaciones, no convertir en secreto cosas innecesarias.

Trabajar con el instinto de la gente y no contra ellos: partir de que la gente quiere ganar, aprender, interactuar, etc.Responsabilidad aceptada: La responsabilidad se acepta no se impone. Se ejecutan las tareas que decide el equipo.Adaptarse a las condiciones locales: Todo lo que se intente hacer debe adecuarse a las condiciones específicas del ambiente. Viajar liviano: No se puede mover rápido con un equipaje muy pesado. Los artefactos deberían ser: pocos, simples y valiosos. Mediciones honestas: Medir es valioso pero deben hacerse a un nivel de detalle que lo permitan nuestros instrumentos.


XP - Actividades básicas

CodificaciónAl final del día tiene que haber un programaEs 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

EscucharLos programadores no conocen el dominio, luego aprenden escuchando a los clientes

DiseñoEl diseño organiza la lógica de cada una de las partes

30


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ón2. Versiones Pequeñas3. Diseño Simple4. Testing5. Refactoring6. Metáforas7. Programación por Pares8. Propiedad Colectiva9. Integración Continua10. Semana de 40 hs11. Cliente in Site12. Estándares de Codificación

31


XP - Estrategia de gerenciamiento

MedicionesHerramienta básica de gestión de XPPocas métricas y retirar las que cumplieron sus funciónNo es “gestión por los números”

CoachingPreocupado por la ejecución (y evolución) técnica del procesoCoacher: no tiene responsabilidad en las decisiones, sino que los demás las tomen bien, buen comunicador y técnicamente, apoyo en dificultades técnicas

TrackingMedir lo hecho contra lo predecido

IntervenciónCuando los problemas no pueden ser resueltos por el equipo


XP - Estrategias clave

PlaneamientoDesarrolloDiseñoTesteo

32


XP - Planeamiento

Se escriben las Historia de los usuariosSe crean un Plan de Entrega de VersionesSe hacen muchas versiones pequeñasSe mide la velocidad del proyectoEl proyecto se divide en iteracionesEl Planeamiento de Iteración comienza con cada iteraciónMover la genteCada 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 disponibleCodificación estándarCodificar primero la unidad de testeoTodo el código de producción es programado de a paresSolo un par por vez integran códigoIntegración continuaCódigo colectivoOptimizar al finalNo trabajar horas extras

33


XP - Diseño

SimplicidadNo agregar funcionalidad antes de tiempoRefactorizar cuando y donde sea posible


XP - Testing

Todo el código debe tener unidades de testeoTodo código debe pasar las unidades de testeo antes de ser liberadoCuando se encuentra un error, se crean tests.Frecuentemente se corren tests de aceptación y se publica el resultado.

34


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 – ValoresEquipos 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.

35


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 server2006 integration server



Ejercicio de Ciclos de Vida

36


ReferenciasArango, 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 2001McConnell, S., Software Project Survival Guide, Microsoft Press, 1998, RedmondMcConnell, S., Rapid Development, Microsoft Press, 1996Zelkowitz, M.V., MSWE 607 Software Life Cycle Methods and Techniques, Maryland, 2000, Notas de aulaReifer, D.J., “Web Development: Estimating Quick-to-Market Software”, IEEE Software, nov/dic 2000Feiler, 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-39Extreme Programming: A gentle introduction,

http://www.extremeprogramming.org/index2.htmlBeck,K., Extreme Programming. Embrance Change, Addison-Wesley, Bosto, 2000http://jeffsutherland.com/scrum

clase1 CACIC 2007

Documents

Transcript of clase1 CACIC 2007