Your SlideShare is downloading. ×
T%c3%a9cnicas de-programaci%c3%b3n-y-gesti%c3%b3n-de-proyectos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

T%c3%a9cnicas de-programaci%c3%b3n-y-gesti%c3%b3n-de-proyectos

50
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
50
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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íaPuente Arkadiko, Grecia, 1300 A.C Puente Alcántara, España, 100 D.C
  • 11. Programación como IngenieríaPrimer 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 Succeeded100% 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 years 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. Didnt 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 ComputcionalProblema “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?