1. Técnicas de Programación y
Gestión de Proyectos
Centro de Energía
Marcelo Matus

2. Objetivos
• La tasa de “éxito” de proyectos medianos y grandes de software se estima
que es entre un 15 y 35 %.
• El objetivo de este curso es introducir al alumno en la problemática de
desarrollo de software de mediana y gran escala, así como también
familiarizarse con las experiencias y técnicas de desarrollo de proyectos
para aplicarlas a problemas de menor escala, académicos o personales.
• Se discutirán y analizarán las nociones básicas de los desafíos relacionados
al ciclo de desarrollo de software desde un punto vista pragmático y
aplicado.
• Distintas técnicas de desarrollo de software y project managment serán
presentadas, así como herramientas de soporte con ejemplos prácticos. Se
discutirán ventajas y/o desventajas de cada una de las soluciones.

3. Metodología
• Sesiones de seminario
• Revisión independiente de bibliografía,
técnicas y herramientas de desarrollo de
software
• Evaluaciones a través de homeworks e
informe final.

4. ¿Qué es programación?
• Según Hoc and Nguyen-Xuan
“the process of transforming a mental plan in
familiar terms into one compatible with the
computer.”
• Otra definición
“Computer Programming is the art of making a
computer do what you want it to do.”

5. ¿Qué es programación?
Programación
Programa
Mental Plan

6. El problema
• Un “mental plan” es una abstracción, no
necesariamente completa ni consistente.
• Un “programa” es otra abstracción, que
permite ejecutar acciones, no siempre en la
forma correcta o esperada.
• La abstracción y la programación son
actividades humanas…. muy humanas
• La programación es un ingeniería incipiente

7. Actividad 1
• Problema:
Dos islas separadas por 500mt, una productora de
tomates, otra de humitas, necesitan una forma de
intercambiar sus productos
• Diseñe una solución plausible

8. Actividad 2
• Problema:
Dos islas separadas por 500mt, una productora de
tomates, otra de humitas, necesitan un enlace
digital bidireccional para publicitar sus productos
• Diseñe el algoritmo y programa de
codificación y decodificación con detección
de error en 2 bits y corrección en 1 bit.

9. Programa & Producto de
Programación e Ingeniería
• Cualquiera puede construir su propia casa,
cualquiera puede escribir un programa
• Construir un edificio y un producto de
programación son empresas que requieren
ingeniería

10. Programación como Ingeniería
Puente Arkadiko, Grecia, 1300 A.C
Puente Alcántara, España, 100 D.C

11. Programación como Ingeniería
Primer Computador ENIAC , 1943
Computadora “Tablet”, 2009

12. Éxito de un Proyecto de Programación
• Simple de definir, como todo proyecto, éxito
se define según
– Entrega a tiempo
– Dentro de presupuesto
– El sistema realiza lo esperado
• Considere el caso de un puente

13. Éxito de un Proyecto de Programación
• Consideremos ahora proyectos de IT
– The category definitions for the Standish Group
are as follows:
• Successful projects were completed on time and on
budget, with all the features and functions that initially
specified.
• Failed projects were cancelled before completion or
never implemented.
• Challenged projects were completed and perational,
but over-budget, over the time estimate, and with
fewer features.

14. Éxito de un Proyecto de Programación
"CHAOS Summary 2009" study from the Standish Group
Failed Challenged Succeeded
100%
15% 18%
90% 28% 23% 24%
31%
80% 40%
70%
60% 51%
49% 53% 44%
50% 46%
53% 33%
40%
30%
20% 34% 32%
27% 26% 28% 29%
10% 16%
0%
1994 1996 1998 2000 2002 2004 2009

15. Update 2009
• Boston, Massachusetts, 23 April, 2009 - New Standish
Group report shows more project failing and less successful
projects:
"This year's results show a marked decrease in project
success rates, with 32% of all projects succeeding which are
delivered on time, on budget, with required features and
functions" says Jim Johnson, chairman of The Standish
Group, "44% were challenged which are late, over budget,
and/or with less than the required features and functions
and 24% failed which are cancelled prior to completion or
delivered and never used."

16. ¿Por qué un proyecto falla?
• Coverdale Organization (Cushing, 2002):
1. Poor planning
2. Unclear goals and objectives
3. Objectives changing during the project
4. Unrealistic time or resource estimates
5. Lack of executive support and user involvement
6. Failure to communicate and act as a team
7. Inappropriate skills

17. ¿Por qué un proyecto falla?
• Coley Consulting:
1. Lack of User Involvement
2. Long or Unrealistic Time Scales
3. Poor or No Requirements
4. Scope Creep
5. No Change Control System
6. Poor Testing

18. ¿Por qué un proyecto falla?
• The Bull Survey (1998)

19. ¿Por qué un proyecto falla?
• Project Challenged Factors (Chaos Summary 2009)
1. Lack of User Input (12.8%)
2. Incomplete Requirements & Specifications (12.3%)
3. Changing Requirements & Specifications (11.8%)
4. Lack of Executive Support (7.5%)
5. Technology Incompetence (7.0%)
6. Lack of Resources (6.4%)
7. Unrealistic Expectations (5.9%)
8. Unclear Objectives (5.3%)
9. Unrealistic Time Frames (4.3%)
10. New Technology (3.7%)

20. ¿Por qué un proyecto falla?
• Project Impaired Factors (Chaos Summary 2009)
1. Incomplete Requirements (13.1%)
2. Lack of User Involvement (12.4%)
3. Lack of Resources (10.6%)
4. Unrealistic Expectations (9.9%)
5. Lack of Executive Support (9.3%)
6. Changing Requirements & Specifications (8.7%)
7. Lack of Planning (8.1%)
8. Didn't Need It Any Longer (7.5%)
9. Lack of IT Management (6.2%)
10. Technology Illiteracy (4.3%)

21. ¿Por qué un proyecto NO falla?
• IT Project Success Factors
1. User Involvement (15.9%)
2. Executive Management Support (13.9%)
3. Clear Statement of Requirements (13.0%)
4. Proper Planning (9.6%)
5. Realistic Expectations (8.2%)
6. Smaller Project Milestones (7.7%)
7. Competent Staff (7.2%)
8. Ownership (5.3%)
9. Clear Vision & Objectives (2.9)
10. Hard-Working, Focused Staff (2.4%)

22. Razones que no se mencionan
• ¿Número de líneas de código?
• ¿Cantidad de documentos?
• ¿Lenguaje de Programación Inadecuado?
• ¿Hardware lento u obsoleto?

23. Aterrizando Conceptos: El problema de
Programación Computcional
Problema “económico”:
1. “En un limite de tiempo definido, desarrollar un
sistema que realice una tarea especificada,
sujeto a un presupuesto definido.”
2. “En un limite de tiempo definido, desarrollar a
mínimo costo un sistema que realice una tarea
especificada.”
3. “Desarrollar en el mínimo tiempo un sistema
que realice una tarea especificada, sujeto a un
presupuesto definido”
4. …..

24. Aterrizando Conceptos: El problema de
Programación Computacional
• Como sea que se formule, la programación
computacional es un problema económico:
"how do we satisfy unlimited wants with
limited resources?“
• Recursos:
– Tiempo y presupuesto
• Necesidad:
– Tarea definida según requerimientos

25. Requerimientos Económicos Implícitos
• Para recordar, antes de entrar en detalles, como
todo problema económico existen restricciones
fundamentales y requerimientos implícitos, como
calidad y seguridad.
• Estos requerimientos pueden depender de la
aplicación:
– Equipamiento médico
– Control de una planta nuclear
– Aplicaciones financieras
– Juego de video
– Tesis de magister

26. La Tarea y los Requerimientos
• Un requerimiento es una característica de qué es
lo que debe realizar un sistema, y en su conjunto
definen la tarea a realizar.
• Pueden ser catalogados en general como
– Business requirements: especifica qué es lo que el
negocio espera que agregue valor
– Product requirements: especifica características del
sistema que implementan los requerimientos del
negocio
– Process requirements: especifica como el sistema es
utilizado o interactúa con otros componentes del
negocio

27. La Tarea y los Requerimientos
• Desde un punto de vista computacional, los
requerimientos se categorizan según:
– Functional requirements: lo que el sistema debe
hacer en forma explícita o capacidades
– Non-Functional requirements: atributos o
características del sistema no necesariamente
visibles para el usuario, usualmente relativos a
calidad
– Constraint requirements: límites impuestos a la
implementación que se deben satisfacer siempre.

28. Actividad 3

29. Actividad 4
• El Ascensor
“Almacenes Pepito es una multitienda de tres pisos,
sin ascensor….”
Matriz de Requerimientos

30. Homework
• Busque otros dos informes similares al Standish
Group report (IT failure projects)
• Busque el detalle de tres fallas de proyectos de IT,
compare y discuta.
• Busque otros tres ejemplos de fallas de proyectos
en otras áreas de ingeniería, compare y discuta.
• Casos en Chile?, Casos Personales?... Bono extra
• ¿Qué es la Ingeniería de Requerimientos?