Ingeniería de Proyectos: Guía Completa

Ingeniería de Proyectos
M.C. Juan Carlos Olivares Rojas

• Este material se distribuye bajo una licencia
Creative Commons Reconocimiento 2.5 México.
Usted es libre de:
copiar, distribuir y comunicar públicamente la

obra
hacer obras derivadas
• Bajo las condiciones siguientes:
Reconocimiento. Debe reconocer y dar crédito al

autor original (Juan Carlos Olivares Rojas)
Agenda
• Introducción (Teoría de Proyectos)
– Elementos para identificar posibles proyectos
– Métodos y etapas del Desarrollo de Proyectos
• Comunicación
– Inicio
– Requerimientos
Introducción
• Proyecto: es la integración de una serie de
procedimientos y actividades haciendo uso de
una metodología definida que permita lograr
los objetivos y metas de la manera más
eficiente y efectiva.
• El término proyecto implica una actividad

futura.
Metodología
• Metodología: conjunto de pasos que nos conducen a
resolver un problema de manera sistemática.
• ¿Cuál es la diferencia con respecto a un algoritmo?
• Que la metodología se utiliza para resolver diversos

tipos de problemas. Los algoritmos son precisos, las
metodologías no dejan de ser mejores prácticas.
Metodología
• Eficacia hacer las cosas bien.
• Eficiencia hacer más con menos.
• En proyectos existe un trade-off entre lo que

es rendimiento de una aplicación (velocidad-
cantidad de recursos).
6
Objetivos y metas
• Un objetivo es lo que se aspira o se desea
obtener de un proyecto.
• Una meta es una métrica para cuantificar el

logro de un objetivo.
• Un objetivo es en general y una métrica en

particular.
Elementos de un Proyecto
Investigación
• Para lograr la realización de un proyecto es muy

importante que se lleven a cabo una serie de
pasos y procedimientos de investigación, los
cuales permitirán abrir aún más las perspectivas
que tenemos de dicho proyecto.
• ¿Qué es investigar?
– Es indagar en búsqueda de la verdad
Investigación
• Los tipos de investigación son:
• Investigación pura o básica: su finalidad es la

obtención de nuevo conocimientos.
Investigación por amor al arte.
• Investigación aplicada: su finalidad es utilizar el

conocimiento obtenido en la investigación en
algún producto reutilizable.
Desarrollo tecnológico
• Desarrollo tecnológico: su finalidad es el desarrollo de

un prototipo en el que se apliquen nuevas tecnologías
y conocimientos
• Investigación documental: aquella que se basa

solamente en bibliografía
• Investigación de campo: aquella que se realiza en el

lugar de los hechos, que requiere experimentación.
Investigación
• Investigación cualitativa: aquella en la que las
variables de investigación se evalúan en base a
unidades no numéricas. (Investigaciones de
Ciencias Sociales)
• Investigación cuantitativa: aquella cuyas

variables pueden ser cuantificadas por medio
de unidades tangibles (Investigaciones
científicas y tecnológicas).
Tarea
• Investigar métodos (estándares) que permitan
organizar la información de la carpeta del
proyecto de manera efectiva.
• ¿Qué diferencia existe entre una Carpeta de

Proyecto y un Portafolio de Proyecto?
13
Portafolio de Proyectos
Tarea
• Definir un Blog, Wiki o Sitio Web para el
proyecto.
• Diariamente se deberá hacer un registro para

visualizar el avance del proyecto al día de hoy.
15
Elementos para identificar posibles
proyectos
• A continuación se muestran algunos Motivos para
desarrollar proyectos (necesidades):
• Cambios demográficos
• Micromercados
• Volatilidad Corporativa
• Control de Costos
Necesidades
• Consumismo
• Crisis Educativas
• Ambientalismo
• Calidad*
• Globalización
• Regularizaciones
Investigación sobre Calidad del Software y Fábricas de
Software
Áreas de oportunidades
• Problemas con algún elemento actual
• Deseos de explotar nuevas necesidades
• Incremento de la competencia
• Hacer más efectivo el uso de la información
• Crecimiento organizacional
• Unión o adquisición corporativa
• Cambios en el ambiente o en el mercado

Proceso para el Desarrollo de Inventivas
• Los proyectos se originas de inventos, los cuales

son ideas materializadas.
• Aun no se conoce el substituto de una buena

idea.
• Las ideas constituyen el primer acercamiento, a

19
la realidad que habrá de investigarse.
Fuente de Ideas
• Las experiencias individuales
• Los materiales escritos (libros, periódicos,

revistas y tesis)
• Las conversaciones personales y las

observaciones de hechos
20
• Las creencias y aún los presentimientos.

¿Cuándo surgen las Ideas?
• Al leer una revista de divulgación popular
• Al estudiar en la casa
• Al ver televisión
• Al charlar con otras personas

21
• Al recordar algo vivido, etc.

Ideas
• Las buenas ideas necesitan de un ambiente
fertilizador.
• Las ideas surgen en ocasiones de problemas y

en otras de necesidades.
• Una necesidad es vital. Un problema no.

22
Ideas
• La mayoría de las ideas iniciales son vagas y
requieren analizarse cuidadosamente para
que sean transformadas en planteamientos
más precisos y estructurados.
• Se necesita de 1% de inspiración y 99% de

sudoración.
23
Ideas
• Cuando una persona desarrolla una idea de
investigación debe familiarizarse con el campo
de conocimientos donde se ubica la idea
(fundamentos o marcos teóricos).
• En el caso de proyectos empresariales se debe

conocer la cultura organizacional
(antecedentes) 24
Ideas
• Para adentrarnos en el tema es necesario
conocer los estudios, investigaciones y
trabajos anteriores (estado del arte).
Generalmente se resume en una tabla
comparativa.
• No reinventar la rueda. Salvo que sea más

costoso o inviable la solución. 25
Decidir el tipo de Investigación
• Tema ya investigados, estructurados y
formalizados.
• Temas ya investigados pero menos

estructurados y formalizados.
• Temas pocos investigados y estructurados.

26
• Temas no investigados.
Factores que restringen el éxito de
un Proyecto
• Alcance
• Costo
• Programa
• Satisfacción del Cliente 27

Factores que restringen el éxito de
un Proyecto
• Del grado de familiaridad de los

desarrolladores con el proyecto (empeño y
habilidades).
• La complejidad del mismo.
28
• La existencia de estudios previos.
Actividad
• Realizar una lluvia de ideas (Brainstorm) para

empezar el desarrollo de inventivas. (25%)
• De las ideas obtenidas seleccionar tres ideas

(5%).
• Revisar las ideas anteriores y el material 29
adicional y escoger una sola idea (70%).

Técnicas de Discusión Grupal
• El proceso de resolución de problemas tiene

tres fases según Mintzberg:
– identificar el problema
– desarrollar diferentes soluciones posibles
– evaluar las posibles soluciones y seleccionar la
más adecuada.
• Otros autores han agregado dos más fases:

– ejecutar la solución deseada
– evaluar los resultados de la ejecución de dicha
solución.
• Para la toma de decisiones grupales, existen varios
métodos que se pueden seguir como:
– votación (la decisión más votada gana),
– votación aprobatoria (cada miembro puede votar por más
de una opción, la opción más votada es la que gana),
– suma de rangos (se otorgan ponderaciones a las opciones,
siendo 1 para la menos votada, este proceso se realiza por
participante, gana la opción con mayor puntaje) y
– desviación mínima (se selecciona la opción que tenga
mayor puntaje y cuya desviación sea mínimo).
• Estas técnicas se pueden mejorar a través de
otras técnicas que ayudan a la toma de
decisiones que a continuación se mencionan:
– lluvia de ideas,
– rueda de mesa (similar a la lluvia de ideas pero
cada quien tiene un turno para exponer sus ideas
de forma cíclica),
– análisis FODA (Fortalezas Oportunidades
Debilidades Amenazas).
• La técnica del grupo nominal reúne características de
la tormenta de ideas y la rueda de mesa, su
funcionamiento es el siguiente:
– cada miembro del grupo escribe el mayor número de
soluciones posibles de manera anónima;
– un moderador recoge todas las respuestas, las presenta al
grupo escribiéndolas en un panel, tratando de agrupar
aquellas soluciones que sean afines;
– las ideas propuestas son discutidas por el grupo hasta que
sean suficientemente claras;
– Cada miembro del grupo, anónimamente, otorga
una puntuación a cada solución ya sintetizada, en
función de lo apropiada que le resulte cada una
para resolver el problema que se discute;
– por último, el moderador resume las
puntuaciones conseguidas por cada solución
alternativa, de forma que se puede establecer una
jerarquía de adecuación de las diferentes
propuestas de solución en función de la opinión
grupal.
• Para problemas más complejos se puede

utilizar la técnica Philips 66. La cual consiste
en hacer grupos de 6 personas que discutirán
el problema por 6 minutos.
• Otra técnica compleja es el Proceso Delphi, la

cual se utiliza cuando se desea aislar los
miembros del grupo para aislar sus opiniones;
o bien, cuando se necesita la opinión de
expertos los cuales se encuentran alejados
geográficamente.
• El proceso Delphi es el siguiente:
– Se elabora un primer cuestionario para recoger
información, posibles soluciones y causas del
problema, este cuestionario se envía a los
expertos, que los responde individual y
anónimamente;
– se analizan los datos recogidos en el primer
cuestionario categorizando las respuestas en
función de su parecido y se elabora con esto un
segundo cuestionario en el que se incluyen las
alternativas más elegidas;
– se envía el segundo cuestionario en el que

cada experto ordena las diferentes
alternativas en función de su adecuación,
asignándoles un número y argumentando
sus respuestas;
– se analizan las valoraciones del segundo
cuestionario y con ello se elabora un tercer
cuestionario dónde sólo aparecen las
opciones más votadas y un resumen de los
comentarios más importantes;
– los expertos contestan el tercer
cuestionario evaluando cada alternativa;
– se elaborará el informe final con los
resultados obtenidos, este informe servirá a
la persona encargada para tomar la decisión
final.
Actividad
• Realizar el marco teórico del tema
seleccionado (sugerencia utilizar metodología
PBL) (60%):
1.Leer y analizar el problema

2.Enumerar hipótesis, ideas y presentimientos
3.Anotar los factores conocidos
39
Actividad
4. Anotar los factores desconocidos
5. Planifique la investigación
6. Emita una declaración del problema.
7. Adquirir información (investigación).
8. Presentar el resultado de la investigación
(solución).
40
• Duración: 30 minutos
Actividad
• Realizar el estado del arte del proyecto.
Entregar tabla comparativa (50%) y
descripción de los trabajos relacionados
(50%).
• Fecha de entrega: Lunes 18 de junio de 2008.
41
Anexos Desarrollo de
Inventivas
Ideas para definir Ideas
Avances en Ciencias de
la Computación 2008
Introducción
• La computación como ciencia se actualiza a pasos
agigantados.
• La empresa de consultoría Gartner define una

gráfica denominada Hiperciclo, en las cuales mide
el avance de las tecnologías emergentes.
• En esta presentación se muestran las gráficas del

2006 y del 2012
Introducción
• La curva del hiperciclo tiene los siguientes
elementos:
– Disparo de la tecnología (1)
– Pico de expectaciones infladas (2)
– Desilusión (3)
– Grado de encantamiento (4)
– Productividad plena (5)
Hiperciclo 2006
• Disparo de la tecnología:
– Virtualización de aplicaciones para PC
– Procesadores multinúcleo
– Particiones de seguridad virtualizada
– Suites E-learning
– Suites de gestión (BPM)
Hiperciclo 2006
• Pico de expectaciones infladas:
– Aplicaciones de outsourcing
– Aplicaciones de almacenes de datos
– Redes inalámbricas de tercera generación
– WiMAX
– Linux en el escritorio
– Tablet PC
– Suites Empresariales Inteligentes
– Servicios de gestión de impresión
Hiperciclo 2006
• Desilusión:
– Operaciones con llave pública
– Portales básicos empresariales
– CRM
– BI
– Lectores de huella digital
– Clientes ligeros
– Puntos de acceso WiFi
Hiperciclo 2006
• Encantamiento:
– Tecnologías de manejo de contenido
– ERP
– Outsourcing de infraestructura de TI
Hiperciclo 2012
• Disparo de tecnologías:
– Computación cuántica
– Ajax offline
– Traducción de voz a voz
– Arquitectura orientadas a eventos
– Inteligencia colectiva
– Arquitecturas dirigidas por modelos
– RSS Empresarial
Hiperciclo 2012
• Disparo de tecnologías (continuación):

– Web semántica corporativa
– Reconocimiento del habla para dispositivos móviles
• Pico de expectaciones infladas

– IPv6
– Mashup
– Web 2.0
Hiperciclo 2012
• Pico de expectaciones infladas:
– “Folksonomías”
– Papel digital
– Análisis de redes sociales
• Desilusión:
– RFID
– Grid Computing
– Ajax
Hiperciclo 2012
• Pagos biométricos
• Wikis
• Blog corporativo
• Redes de sensores y mallas
• Tablet PC
• Pagos por dispositivos móviles
• Tecnologías de localización
• Mensajería Instantánea Empresarial
Hiperciclo 2012
• Encantamiento:
– Aplicaciones basadas en localización
– Smartphone
• Productividad
– VoIP
– Internal Web Services
Bibliografía
• Enciso, Enrique (2007). “Tendencias y
Predicciones Tecnológicas y Sociales”, Revista
RED, Junio, pp. 21-27.
Innovación en TI
Empresas TI
• cFares es un buscador de precios de boletos
de avión cubriendo la mayoría de las rutas en
el mundo. http://www.cfares.com/
• iPolipo: resuelve el problema de agendar

juntas, se requiere un promedio de 7 correos
electrónicos para confirmar una cita, lo que
representa 100 horas al año en una empresa
promedio. http://www.ipolipo.com/
Empresas TI
• MOG: sistema que con autorización del usuario,

permite acceder a una PC y catalogar toda la
música disponible. En base con otros usuarios
se sugieren nuevos títulos de canciones,
permite formar una red social. http://mog.com
• Startforce: Sistema Operativo desde la Web.

http://www.startforce.com/
Empresas TI
• YouSentit: Empresa que permite la entrega digital de
documentos para personas con poco conocimiento
de computación, permite llevar el seguimiento de los
documentos. http://www.yousendit.com/
• Payscale: los usuarios pueden definir posiciones

laborales mediante habilidades y experiencias y
compararlas en base a otras personas en otras
regiones. http://www.payscale.com/
Empresas TI
• SimulScribe: se dedica a convertir mensajes de
voz en texto con un mercado potencial de 5,000
millones de dólares. Se cobra 0.25 dólares por
correo de voz. http://www.simulscribe.com/
• SIBEAM: red inalámbrica multi gigabit de 60

GHz para transmitir video de alta definición sin
importar su comprensión.
http://www.sibean.com/
Referencias
• Enciso, Enrique. Innovación: clave para
permanecer en el juego (2007). Revista
Software Red, Septiembre de 2007, pp. 13.
Líneas de Investigación
2008
Áreas de Interés
• Sistemas Distribuidos
• Cómputo móvil
• Tecnologías Web
• Redes inalámbricas
• Bases de Datos 63
• Sistemas basados en localización (LBS) y
búsquedas contextuales.
• Sistemas asíncronos basados en tecnologías

SMS/MMS
• Programación de Sistemas usando .NET

64
Compact Framework y J2ME
No necesariamente van en orden de interés
• Sistemas de intermediarios (proxys,
middleware)
• Sistemas Distribuidos Inteligentes (Agentes

Móviles)
• Transcodificación multiformato y
65
Acaparamiento para dispositivos Móviles.
• Accesibilidad de recursos Web en dispositivos

móviles (W3C, WCAG, MobileOK)
• Minería de datos para y en dispositivos móviles.
• Mecanismos de Precarga de Dispositivos Web.

66
• Servicios Web y P2P en dispositivos móviles
• Cómputo paralelo en dispositivos móviles

(Grid, Clusters).
• Sistemas Operativos para dispositivos móviles

y empotrados
67
• Virtualización
• Seguridad en dispositivos móviles.
• Desarrollos de Sistemas Adaptativos en Redes
Inalámbricas (Redes de 3G, Redes de
Sensores).
• Metodologías para el desarrollo de

aplicaciones en entornos de computación con
recursos limitados. 68
• Cómputo móvil en la educación
• Multimedia en dispositivos de cómputo

limitado
69
Trabajos actuales
• Metodologías de Desarrollo en Computación con
Recursos Limitados (ISwM):
– “Desarrollo de Interfaces Adaptativas para Dispositivos
Móviles” (ITM)*
– “Diseño de un Lenguaje para Modelar Redes de
Computadoras” (ITM)
– “Utilización del Patrón MVC (Modelo‐Vista‐Controlador)
para el Desarrollo de Aplicaciones en Dispositivos Móviles”
(ITM)*
– “Estudio y Aplicación de Patrones Arquitectónicos en la 70
Construcción de Software para Dispositivos Móviles”

Trabajos actuales
• Proxy de accesibilidad móvil (UNID)*
• Weblog mininig en dispositivos móviles

(UNID)*
• Virtualización de recursos y aplicaciones en

dispositivos móviles (UNID)*
71
• Nuevas Técnicas de DSS.

Trabajos actuales
• Medios audiovisuales para la autenticación de
sistemas de cómputo (UNID)*
• Herramienta para validar la colocación de

puntos de acceso en redes inalámbricas
utilizando diagramas de voronoi. (UNID)*
72
• “Plataforma educativa utilizando tecnologías
Web 2.0” (ITM).
Trabajos actuales
• Seguridad en Dispositivos Móviles utilizando
RSA (UVAQ)*
• Redes en Malla (802.11s) *
• Redes 3G en México: Aplicaciones y Servicios

*
73
• Redes Inalámbricas de Banda Ancha: WiMax y

802.20 (WiBro) **
Propuestas de Trabajos
• Suite para la Conversión de Código de

Aplicaciones de Computadoras Personales a
Aplicaciones de Cómputo Móvil (2Mobi)
– “Traductor de J2ME a .NET CompactFramework”
– “Traductor de .NET CompactFramework a J2ME”
– “Traductor de J2SE a J2ME”
– “Traductor de J2EE a J2ME”
– “Traductor de .NET Framework a .NET CompactFramework” 74
• Transcodificador de contenidos Web
multiformatos
• Algoritmo para determinar de manera efectiva

los recursos que se deben precargar en un
sitio Web.
• Web Proxy caché con soporte para

75
operaciones en modo desconexión para J2ME

• Editor de páginas Web accesibles para
dispositivos móviles
• Comunicación entre procesos IPC en

máquinas virtuales
• Algoritmo de enrutamiento para dispositivos

76
móviles utilizando técnicas de agrupamiento y
distancias cortas
Propuestas de Trabajo
• Modificación al protocolo SMTP para permitir
la eliminación de correo no visto.
• Videostreaming en redes celulares de 2.5G de

manera descentralizada
• Localización geográfica de recursos de manera

77
descentraliza.
Propuestas de Trabajo
• Lenguaje para Modelar LBS
• Extensiones de UML para modelar

aplicaciones LBS
• Búsquedas Semánticas en LBS.

Anexos Desarrollo de
Inventivas
Ideas para definir Ideas
Calidad del Software
• El objetivo fundamental del Desarrollo
Estructurado de Proyectos es lograr la calidad
del software.
• Por calidad se entienden muchas cosas. Para

nuestro curso lo entenderemos como realizar
100% bien las cosas en el menor tiempo
posible. 80
Calidad de Software
• La calidad hace referencia intrínseca a eficacia
y eficiencia.
• ¿Qué tiene más calidad un “Vochito” o un

BMV?
• Los dos tienen igual calidad si cumplen con los

81
requerimientos (checklist).
Calidad de Software
• En general la Ing. Sw tiene los objetivos de
que el software sea correcto, utilizable y
costo-efectivo.
• Sinónimos de calidad es que esté libre de

errores. Muchas de las metodologías de
software actuales se basan en esta premisa.
82
Calidad de Software
• ¿Por qué es difícil lograr la calidad del
software?
• El software es un producto intangible el cual

se logra a través de un proceso creativo ya que
programar es un arte, el cual no puede ser
sistematizado del todo.
83
Calidad de Software
84
Calidad de Software
• ¿Por qué es importante el Desarrollo de
Proyectos de forma Metodológica? El software
es cada vez más complejo y costosos que se
compara con construir un edificio.
• En 1968 se da un hito importante al ocurrir la

“crisis del software” y definirse la Ingeniería de
Software como tal. 85
Construcción de una casa para
“wendo”
Puede hacerlo una sola persona

Requiere:
Modelado mínimo
Proceso simple
Herramientas simples
Construcción de una casa
Construida eficientemente y en un tiempo

razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
Construcción de un rascacielos
No cualquier persona o grupo de persona lo realiza.

Imposible sin técnicas de Ingeniería
Fábricas de Software
• Tratan de automatizar los procesos de
desarrollo de software tal cual lo realizan las
líneas de producción de los sistemas
industriales.
• No es nuevo pero actualmente está teniendo

mucho éxito. Requiere de mucho esfuerzo. Es
un modelo organizacional. 89
Etapas para el desarrollo de un
proyecto
• Los proyectos en general presentan 6 etapas
que a continuación se describen:
• Detección de necesidades: consiste en

determinar los elemento (procesos, equipos,
personas, etc.) que son requeridos o no para
cumplir los objetivos del proyecto.
proyecto
• Definición del problema: consiste en delimitar

las fronteras y el alcance de las necesidades
que se desean atender.
• Factibilidad: consiste en definir las

posibilidades de éxito de una solución.
91
proyecto
• Los niveles de factibilidad son:
– Operacional
– Técnico
– Económico
• La decisión de si se realiza un proyecto o no

depende del desarrollador y del cliente. 92
proyecto
• Planeación del proyecto: consiste en establecer
una serie de estrategias para resolver un
problema, además de las técnicas y el control
que se llevará a cabo.
• Elaboración del proyecto: consiste en definir el

diseño, la elaboración de módulos y la
integración de todos los elementos.
proyecto
• Se deben de dar a conocer en esta etapa todos
los distintos tipos de pruebas y técnicas de
análisis de resultados para determinar una
posible evaluación al final del proyecto.
• Documentación: consiste en explicar como están

compuestos los manuales técnicos y de usuario
del proyecto.
Ciclo de Vida de un Proyecto
• Identificar una necesidad (1)
• Desarrollar una propuesta de solución (2)
• Realizar el proyecto (3)
• Terminar el proyecto (4) 95

• Un proyecto puede comenzar con un SDP
(Solicitud de Propuesta, RFP Request For
Proposal) de un cliente.
• Un SDP es un documento en el cual se

describe la problemática o necesidad de la
empresa y se somete generalmente a
concurso la solución. 97
• En la mayoría de las ocasiones el SDP no existe
por lo cual se debe de hacer un análisis previo
para plantear la solución.
• Una vez obtenido el SDP el proyecto inicia

formalmente a través de un contrato*
98
Verdadero Ciclo de Vida
del Desarrollo de un
Proyecto
Primera fase
Segunda fase
Tercera fase
Cuarta fase
Metodologías de Desarrollo de
Software
• Las metodologías de software son un conjunto

de “mejores prácticas” que si no se llevan a la
práctica no sirven de nada.
• El factor humano es el recurso más

importante de cualquier proyecto de
software.
Software
• Por ejemplo, la Ley de Brooks: Si se aumenta

un programador más se retrasa el proyecto
mientras se explica que hay que hacer.
• El proceso de desarrollo de software implica

cuatro etapas:
105
Ley de Brooks
Software
– Especificación
– Desarrollo
– Evaluación
– Evolución
• El desarrollo de software se basa en modelos,

siendo los más representativos: 107
Software
• Cascada (clásico)
• Construcción de prototipos
• Espiral
• RAD (Desarrollo rápido de aplicaciones)
• Cada uno de estos modelos tiene sus 108

respectivas fases que pueden ser muy
similares entre sí.
Modelos de Ciclo de Vida
109
Cascada
Modelo Ciclo de Vida en Cascada
Actual
• Comunicación:
– Inicio del Proyecto
– Recopilación de Requerimientos
• Planeación:
– Estimación
– Itinerario
– Seguimiento 110
Modelo de Ciclo de Vida en
Cascada Actual
• Modelado
– Análisis
– Diseño
• Construcción
– Código
– Prueba
111
Modelo de Ciclo de Vida en
Cascada Actual
• Despliegue:
– Entrega
– Soporte
– Retroalimentación
• En el modelo iterativo se repiten algunas fases

al igual que en espiral.
112
Modelo de Ciclo de Vida en Cascada
Actual
Flujos de Trabajo de las Etapas
Inicio
Despliegue
Implementación
Diseño
Análisis
0 10 20 30 40 50 60 70 80 90 100
Elaboración
Despliegue
Implementación
Diseño
Análisis
0 10 20 30 40 50 60 70 80 90 100
Construcción
Despliegue
Implementación
Diseño
Análisis
0 10 20 30 40 50 60 70 80 90 100
Transición
Despliegue
Implementación
Diseño
Análisis
0 10 20 30 40 50 60 70 80 90 100
Modelo Iterativos
118
119
Modelo en Espiral
Actividad
• Investigar dos metodologías de desarrollo de
software por cada persona:
• MOPROSOFT
• Open UP (RUP)
• CMMI
Actividad
• Six Sigma
• TSP/PSP
• Métodos Ágiles (XP eXtreme Programming)
• MSF
121
• ITIL
•María Fernanda Chávez Salazar
•Cesar Espino Gutiérrez
UVAQ
Resumen
• Es la denominación del "Modelo de Procesos para la

Industria del Software" desarrollado por la Asociación
Mexicana para la Calidad en Ingeniería del Software (AMCIS)
de la Universidad Autónoma de México (UNAM) por encargo
de la Secretaría de Economía, es un modelo para la mejora y
evaluación de los procesos de desarrollo y mantenimiento de
sistemas y productos de software
Introducción
• MoProSoft es el nombre del modelo en la

comunidad universitaria y profesional, y la norma
técnica a la que da contenido es la NMX-059/01-
NYCE-2005 que fue declarada Norma Mexicana el
15 de agosto de 2005 con la publicación de su
declaratoria en el Diario de la Federación.
Introducción
• Le ha dado origen el Programa para el Desarrollo de la Industria del
Software (PROSOFT).
• PROSOFT tiene siete líneas estratégicas, siendo la sexta la que ha dado
origen a MoProSoft: "Alcanzar niveles internacionales en capacidad de
procesos“.
• Al comenzar el desarrollo de esta línea estratégica se evaluó la adopción
de los modelos: ISO 9000, ISO 15504, SW-CMM.
• El resultado de la evaluación fue: "Ninguno de los estándares o modelos
cumple con los requisitos expresados por la industria nacional", y se
decidió la elaboración de un modelo adecuado para las características
de las empresas mexicanas, que se basaría en los modelos evaluados.
• En base a esta decisión la Secretaría de Economía encargó la elaboración
de dicho modelo a la Asociación Mexicana para la Calidad en Ingeniería
del Software (AMCIS) en colaboración con la Universidad Nacional
Autónoma de México (UNAM).
• La primera versión de MoProSoft se publicó en diciembre de 2002.
Desarrollo
• Pocos procesos que abarcan todos los niveles de una

organización: directivo, gerencial y operativo.
• Procesos integrados como una red de comunicación.
• Definición explícita de roles responsables por las
actividades de cada proceso y la capacitación requerida.
• Definición explícita del propósito, objetivos específicos,
indicadores, metas cuantitativas y mediciones para cada
proceso.
• Definición explícita de productos de entrada, salida e
internos de cada proceso y sus características mínimas.
• Definición de flujos de trabajo con las actividades, tareas,
roles involucrados y productos generados
Desarrollo
• Existencia de una Base de Conocimiento de la organización

en la cual se resguardan todos los productos generados, se
administran y se consultan de acuerdo con los mecanismos
definidos.
• Definición de las actividades para recaudar lecciones
aprendidas y usarlas en proyectos futuros.
• Definición de un mecanismo específico para la reacción a
las situaciones excepcionales durante el desarrollo de las
actividades.
• Definición explícita de las actividades de verificación,
validación y pruebas
Desarrollo
 Definición explícita de guías de ajuste que sugieren la

adaptación de los procesos a las necesidades de las
organizaciones, sin perder de vista el cumplimiento de los
objetivos de los procesos.
 Los objetivos y metas cuantitativas son las que guían a los
demás procesos y proyectos y son los que se valúan para
conocer cuantitativamente la efectividad de los procesos
de la organización.
 Las sugerencias de mejora a los procesos se identifican y se
reportan a los responsables de gestión de procesos.
 Los procesos del modelo pueden ser ajustados con base al
contexto de la organización.
Desarrollo
• Contiene tres categorías de procesos que

corresponden a las capas de Alta Dirección,
Gestión y Operación.
Desarrollo
Desarrollo
Desarrollo
Desarrollo
Desarrollo
Desarrollo
Desarrollo
Conclusiones
Fuentes Consultadas
• http://es.wikipedia.org/wiki/Moprosoft, consultado el día 20 de Agosto del

2008
• http://www.iie.org.mx/boletin032003/ind.pdf , consultado el día 20 de
Agosto del 2008
• http://www.uv.mx/its/MoProSoft%20y%20su%20origen.pdf , consultado el
día 20 de Agosto del 2008
• http://www.navegapolis.net/content/view/515/59/ , consultado el día 20 de
Agosto del 2008
CMMI
-Capability Maturity Model Integration
-Modelo de Madurez de la Capacidad
De la Organización
De un conjunto de procesos agrupados
Área de Proceso
Es un modelo para la mejora de procesos que
proporciona a las organizaciones los elementos
esenciales para procesos eficaces.
Sucesor  CMM. Desarrollado desde 1987 hasta

1997.
En 2002  CMMI Versión 1.1

En Agosto de 2006  Versión 1.2.
El objetivo del proyecto CMMI es mejorar la

usabilidad de modelos de madurez integrando varios
modelos diferentes en un solo marco (framework).
Hay dos áreas de interés:
Sin embargo existen tres constelaciones de la versión

1.2 disponible:
1. CMMI para el Desarrollo (CMMI-DEV o CMMI

for Development).
2. CMMI para la adquisición (CMMI-ACQ o CMMI

for Acquisition).
3. CMMI para servicios (CMMI-SVC o CMMI for

Services).
Una organización es evaluada y recibe una calificación
de nivel 1-5 si sigue los niveles de Madurez.
La organización, puede elegir áreas de proceso y en

vez de por niveles de madurez puede obtener los
niveles de capacidad  "Perfil de Capacidad" de la
Organización.
REPRESENTACIONES
Según el modelo se tienen dos formas para mejorar:
Mejorar un proceso específico La mejora de la organización

o un conjunto de ellos. completa según los procesos
definidos y ocupados.
En la siguiente tabla se muestran los niveles para
estos dos tipos de representaciones:
Representación Representación
Continua Escalonada
Nivel De Capacidad Nivel De Madurez
Nivel 0 Incompleto -
Nivel 1 Realizado Inicial
Nivel 2 Manejado Manejado
Nivel 3 Definido Definido
Nivel 4 Manejado Manejado
Cuantitativamente Cuantitativamente
Nivel 5 Optimizando Optimizando
Representación Continua
Mejora de un Proceso  área de proceso en que una
organización desea mejorar.
Existen seis niveles de capacidad por donde transitan

los procesos asociados a un área de proceso:
Nivel 0 – Incompleto: Objetivos  No Satisfechos.
Nivel 1 – Realizado: Objetivos  Satisfechos.
Nivel 2 – Manejado: cuando tiene la infraestructura

base para apoyar el proceso.
Nivel 3 – Definido: cuando es adaptado desde el
conjunto de procesos estándares de la organización
de acuerdo a las guías de adaptación de la
organización.
Nivel 4 – Manejado Cuantitativamente: cuando es

controlado usando técnicas estadísticas y otras
técnicas cuantitativas.
Nivel 5 – Optimización: es mejorado basado en el

entendimiento de causas comunes de variación del
proceso.
Representación Escalonada
Método estructurado y sistemático  mejora de

procesos  etapas o niveles.
Al alcanzar un nivel, la organización se asegura de

contar con una infraestructura robusta en términos de
procesos para optar a alcanzar el nivel siguiente 
Nivel de Madurez.
Áreas de procesos en donde los objetivos asociados a

ese nivel deben ser cumplidos.
Existen cinco niveles de madurez:
Nivel 1 – Iniciado: la mayoría de los procesos son "ad-

hoc" y caóticos.
Nivel 2 – Manejado: se ordena el caos. Aquí Las

organizaciones se enfocan en tareas cotidianas
referentes a la administración.
Nivel 3 – Definido: los procesos son caracterizados y

entendidos de buena forma, y son descritos en
estándares, procedimientos, herramientas, y
métodos.
Nivel 4 – Manejado Cuantitativamente: la
organización y proyectos establecen objetivos
cuantitativos para medir la calidad y realización de los
procesos y los usa como criterios en el manejo de
ellos.
Nivel 5 – Optimizado: una organización mejora

continuamente sus procesos basándose en el
conocimiento de las causas comunes de variación
inherente en los procesos.
AREAS DE PROCESO
Son un conjunto de prácticas relacionadas que

cuando son implementadas colectivamente,
satisfacen un conjunto objetivos considerados
importantes para mejorar esa área de proceso.
El modelo CMMI v1.2(CMI-DEV) contiene 22 áreas de

proceso:
Área de Proceso Categoría Nivel de Madurez
Análisis y Resolución Causales Soporte 5
(CAR)
Análisis y Resolución de Soporte 3
Decisiones (DAR)
Aseguramiento de la Calidad de Soporte 2
Procesos y Productos (PPQA)
Definición de Procesos Gestión de Procesos 3

Organizacionales +IPPD (OPD
+IPPD)
Desarrollo de Requerimientos Ingeniería 3
(RD)
Entrenamiento Organizacional Gestión de Procesos 3
(OT)
Administración Cuantitativa de Gestión de Proyectos 3
Proyectos (QPM)
Administración de Acuerdos con Ingeniería 2
Proveedores (SAM)
Administración de Gestión de Proyectos 3
Requerimientos (REQM)
Administración de Riesgos (RSKM) Soporte 2
Administración de la Gestión de Proyectos 3

Configuración (CM)
Administración Integral de Gestión de Proyectos 3
Proyecto + IPD (IPM+IPPD)
Innovación y Despliegue Gestión de Procesos 5

Organizacional (OID)
Integración de Producto (PI) Ingeniería 3

Medición y Análisis (MA) Soporte 2
Monitoreo y Control de Gestión de Proyectos 2
Proyecto (PMC)
Planificación de Proyecto (PP) Gestión de Proyectos 2
Procesos Orientados a la Gestión de Procesos 3

Organización (OPF)
Rendimiento de Procesos Gestión de Procesos 4

Organizacionales (OPP)
Solución Técnica (TS) Ingeniería 3

Validación (VAL) Ingeniería 3
Verificación (VER) Ingeniería 3
Cuatro categorías:
1. Administración de Procesos,
2. Administración de Proyectos,
3. Ingeniería y
4. Soporte.
Este agrupamiento es realizado para mostrar cómo se

relaciona cada área de proceso dentro de una
categoría.
COMPONENTES
Componentes Requeridas
Son las componentes que obligatoriamente deben ser

satisfechas y visiblemente implementadas para poder
cumplir con un área de proceso:
1. Objetivo Específico (SG): única característica 

satisfacer el área de proceso.
2. Objetivo Genérico (GG): características 

satisfechas por un conjunto de áreas de
proceso.
Componentes Esperadas
Son las componentes que pueden ser utilizadas para

alcanzar una componente requerida:
1. Practicas Específicas (SP): describe una

actividad  alcanzar un objetivo específico.
2. Prácticas Genéricas (GP): describe una actividad

 alcanzar un objetivo genérico.
Componentes Informativos
 Propósito
 Notas introductorias
 Nombres
 Tablas de relaciones práctica – objetivo
 Prácticas
 Productos típicos
 Sub-prácticas
 Ampliaciones de disciplina
 Elaboraciones de prácticas genéricas
Evaluaciones
Una evaluación de CMMI corresponde al estudio y

análisis de uno o más procesos realizado por un
equipo capacitado de profesionales, utilizando un
modelo de referencia de evaluación como base para
determinar, a lo menos, fortalezas y debilidades
dentro de una organización.
El SEI ha publicado dos documentos guías que

actualmente son utilizados para realizar una
evaluación de CMMI:
1. Appraisal Requirements for CMMI (ARC).
1. Clase A
2. Clase B
3. Clase C
Las clases definen los requerimientos que debe

cumplir una evaluación de cierta complejidad.
2. Standard CMMI Appraisal Method for Process

Improvement (SCAMPI).
Clase A
Corresponde al método de evaluación que satisface el

100% de los requerimientos que el documento define.
Se denomina SCAMPI clase A:
1. Capacidades de la organización,
2. Identificar fortalezas y debilidades en los
procesos y
3. Relacionar estas fortalezas y debilidades con el
modelo de referencia CMMI.
Clase B
Ayuda a una organización a comprender el estado de

los procesos relativos a CMMI.
Una evaluación clase B se ejecuta  auto-evaluar sus

procesos.
Esta clase de evaluación debe ser ejecutada por dos

personas, incluyendo a un líder de CMMI y requiere
mucho menos información que la evaluación clase A.
Clase C
Es realizada por sólo una persona y tiene por objetivo

evaluar pequeños aspectos de la organización que
quieren apoyarse.
CONCLUSIONES
CMMI provee:
1. Una forma de integrar los elementos funcionales

de una organización.
2. Un conjunto de mejores prácticas basadas en casos

de éxito probado de organizaciones
experimentadas en la mejora de procesos.
3. Ayuda para identificar objetivos y prioridades para
mejorar los procesos de la organización,
dependiendo de las fortalezas y debilidades de la
organización que son obtenidas mediante un
método de evaluación.
4. Un apoyo para que las empresas complejas en

actividades productivas puedan coordinar sus
actividades en la mejora de los procesos.
5. Un punto de referencia para evaluar los procesos

actuales de la organización.
REFERENCIAS
1. http://es.wikipedia.org/wiki/CMMI
2. http://www.monografias.com/trabajos57/model
o-calidad-cmmi/modelo-calidad-cmmi.shtml
3. http://www.mityc.es/NR/rdonlyres/A570B90C-
B41A-46E2-BD39-
4A31D18BB7FD/0/s01CeciliaRigoni.pdf
Team Software Process
Personal Software Process
Presenta:
Linda Adriana Quesada Ruiz
TSP/PSP
Watts S. Humphrey es el inventor
del PSP (Personal Software
Process) y el TSP (Team Software
Process)
TSP/PSP
¿Qué es PSP?
+ Se utiliza cuando no existe un equipo de
programadores.
+ Es un proceso de mejora continua --> esta diseñado
para que se realicen varias pruebas antes de liberar el
producto.
+ Consta de varias tareas que el programador tiene
que realizar repetidamente.
Para tener una buena calidad se requiere de tener
métricas de calidad bastante elevadas, esto es,
aproximadamente un error por cada mi líneas de
código,
PSP proporciona la opción de crear un programa de
10000 líneas de código con únicamente 10 errores, los
cuales para un programador son fáciles de depurar
comparado con los errores que se pueden presentar al
no utilizar dicho proceso.
Las diferentes etapas del PSP son:
+ Proceso base
El programador conoce las necesidades del cliente para tener
una idea clara de lo que programara.
+ Ambiente de mejora
En caso de tener un proyecto ya hecho esta es la etapa de
depuración, se utiliza para mejorar el proyecto anterior.
+ Estimación de tamaño de proyecto, pruebas
En caso de no ser así se estima el tamaño que tendrá el
software. Tomando en cuenta el tiempo que se le dedicara y las
especificaciones del cliente.
+ Plantación de tareas y horario.

Ya teniendo el tamaño del software se puede hacer una
estimación del tiempo que se tomara para hacer la
programación, así como, las diferentes tareas, de debe realizar
un horario para tomar en cuenta cuanto tiempo debe tomar
cada tarea y terminar a tiempo.
+ Control de calidad personal.
Por medio de pruebas se califica la eficiencia del sistema así
como los errores que pueda llegar a tener, se tiene que
confirmar que la calidad del software es la deseada.
+ Proceso Cíclico
Teniendo en cuenta la calidad con la que el programa será
liberado se decide si el software se liberara o tiene que volver a
entrar en el proceso como proceso base.
El problema mas grande que se presenta con el PSP es que para
los programadores es difícil tratar de visualizar todas las tareas
y etapas del desarrollo.
Es por eso que en muchas ocasiones se necesita de otros
programadores, pero al estar mas de uno no se puede utilizar
el proceso de software personal, este problema se soluciona
formando un equipo de trabajo y llevando a cabo el desarrollo
por medio de TSP.
¿Qué es TSP?
TSP , en conjunto con PSP , ayuda al Ingeniero
a:
+ Asegurar la calidad en los productos de
software
+ Crear productos de software seguros
+ Mejorar procesos de Administración en una
organización
+ Se utiliza cuando en el desarrollo existe un equipo de
programadores.
+ Se utilizan todas las tareas que el PSP indica, pero además se

utilizan métodos de organización de personal debido a que al
haber un equipo deben realizarse roles de trabajo.
+ Se tiene que tener un líder del equipo que este en

comunicación con todos y que tenga control sobre la
organización del proyecto.
Contar con personal suficientemente capacitado.
Que el personal tenga la capacidad de trabajar en equipo.
Debe haber convivencia en el equipo para facilitar la
comunicación.
Tienen que realizarse roles de trabajo y cada integrante debe
estar en el área en la que mejor se desarrolla para que sea mas
eficiente.
Reducción significativa en los errores que
presenta el software
Reducción en el tiempo que de toma para
desarrollar el software
Es más fácil y rápida la estimación del tiempo
que se necesita para programar.
Facilidad para realizar cambios.
CarnegieMellon University (2008). Overview of Team Software
Process and Personal Software Process. Consultado en Agosto, 19,
2008 en http://www.sei.cmu.edu/tsp/index.html.
Melendez, Miguel (2006). Personal Software Process/Team Software

Process. Consultado en Agosto, 19, 2008 en
homepages.mty.itesm.mx/al796320/SoftwareProcess.doc.
Referencias
METODOLOGIA SIX SIGMA EN EL
DESARROLLO DE SOFTWARE
Ingeniería de Proyectos
MISION
• Proporcionar la información adecuada  Máxima calidad del producto o

servicio.
• Crear confianza y comunicación entre todos los participantes  Eleva la calidad

y el manejo administrativo
Introducción
• Motorola, General Electric y Allied Signal utilizaron por primera vez Seis Sigma
para procesos de recuperación de datos, mejorar la calidad, disminuir los costos
y prácticamente eliminar los defectos en los productos sobre el terreno.
• En la actualidad los profesionales están estudiando la forma de aplicar las

técnicas de Seis Sigma para mejorar los sistemas de software y desarrollo.
Metodología Seis Sigma
Incluye:
• Una filosofía. Mejorar la satisfacción del cliente

resultando en una mayor rentabilidad.
• Un conjunto de métricas
• Una mejora de marco (también llamado un

conjunto de instrumentos)
Sigma (S)
Seis Sigma (6S) se refiere a una medida del proceso de variación (seis
desviaciones estándar) que se traduce en un error o irregularidad tasa de 3,4
partes por millón, o 99.9997 por ciento.
Defecto = producto, servicio o proceso de variación que impide cumplir con las
necesidades del cliente.
Proceso de Seis Sigma
• 1. Definir el producto y servicio.
• 2. Identificar los requisitos de los clientes.
• 3. Comparar los requisitos con los productos.
• 4. Describir el proceso.
• 5. Implementar el proceso.
• 6. Medir la calidad y producto.

• ¿Podemos usar Seis-Sigma en programas de
mejoramiento de procesos de software?
Calidad de software:
• Fiabilidad
• Disponibilidad
• Mantenimiento de Control
• Productividad
Protagonistas en Seis Sigma.
• Equipo de Liderazgo
• Lead Black Belts
• Campeón (Champion)
• Maestro Cinta Negra (Master Black Belt)
• Cinta Negra (Black Belt)
• Cinta Verde (Green Belt)

Herramientas Estadísticas
• Diagrama de Flujo de Procesos
• Diagrama de Causa-Efecto
• Diagrama de Pareto
• Histograma
• Gráfica de Corrida
• Gráfica de control
• Diagrama de Dispersión
• Modelo de Regresión
Métodos y procesos actuales
• ISO 9001
• CMM (Modelo de Capacidad de Madurez)
• BOOTSTRAP
• ISO/IEC TR 15504
• Microsoft Accelerator for Six Sigma

CONCLUSIONES
• Aplicada a procesos industriales con el fin de obtener una
buena calidad de los productos (bienes y servicios).
• Ha evolucionado desde el trabajo de manufactura, y ahora para

los productos de software y sus procesos.
• La mayoría de las compañías a nivel mundial utilizan la

metodología 6σ elaborando inspecciones visuales y electrónicas
y aplicando las herramientas estadísticas, con las cuales se
puede observar el comportamiento de los procesos.
• Una vez observado el comportamiento del proceso, se procede

a reducir al máximo los defectos en los productos o servicios, y
lograr la plena satisfacción del cliente.
BIBLIOGRAFÍA:
• Estrategias de Manufactura aplicando la metodología Seis-Sigma; Maya Héctor, Rodríguez-Salazar Jesús,
Rojas Julieta, Zazueta Guillermo; Editorial Oceánica; 1996.
• Six Sigma. The breaktrough Management Strategy; Harry Mikel , Schoeder Richard; Mc Graw Hill Editorial;
2000.
• The Introduction to Six-Sigma Methodology; Brown Steve, Morrinson George; Editorial Trillas; 1991.
• http://mercadeo.com/archivos/six-sigma.pdf
• http://www.sei.cmu.edu/news-at-sei/features/2004/1/feature-3.htm
• http://www.sei.cmu.edu/news-at-sei/features/2004/1/pdf/feature-3.pdf
• http://villeneuve.iespana.es/files/SeisSigma%20%20presentacion%20Final.ppt
• http://www.cimat.mx/Sitios/seissigma/seissigma2/index.php?cod=a2&cod2=b4
• http://es.wikipedia.org/wiki/Modelo_de_Capacidad_y_Madurez
• http://es.wikipedia.org/wiki/ISO/IEC_15504
INTEGRANTES
MARCO ANTONIO HERRERA GALVEZ
RODRIGO ACEVEDO MORONES

Metodologías Ágiles
José Carlos García Cubillo
y
eXtreme Programming (XP)
Ingeniería De Proyectos
Universidad Vasco de Quiroga
Contenidos
I. Introducción
II. eXtreme Programming (XP)
III. Conclusiones
Introducción
¿Qué es una Metodología Ágil?
• Las Metodologías Ágiles (MAs) valoran:
– Al individuo y las interacciones en el equipo de
desarrollo más que a las actividades y las
herramientas
– Desarrollar software que funciona más que conseguir
una buena documentación  Minimalismo respecto
del modelado y la documentación del sistema
– La colaboración con el cliente más que la negociación
de un contrato
– Responder a los cambios más que seguir
estrictamente una planificación
Costo de los Cambios en SW
Tradicional
Costo
del
cambio
Suposición MAs
tiempo
Comparación Ágil v/s Tradicional
Metodología Ágil Metodología Tradicional

Pocos Artefactos. El modelado es Más Artefactos. El modelado es esencial,
prescindible, modelos desechables. mantenimiento de modelos
Pocos Roles, más genéricos y flexibles Más Roles, más específicos
No existe un contrato tradicional, debe Existe un contrato prefijado
ser bastante flexible
Cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de
(además in-situ) desarrollo mediante reuniones
Orientada a proyectos pequeños. Corta Aplicables a proyectos de cualquier
duración (o entregas frecuentes), equipos tamaño, pero suelen ser especialmente
pequeños (< 10 integrantes) y trabajando efectivas/usadas en proyectos grandes y
en el mismo sitio con equipos posiblemente dispersos
La arquitectura se va definiendo y Se promueve que la arquitectura se defina
mejorando a lo largo del proyecto tempranamente en el proyecto
Énfasis en los aspectos humanos: el Énfasis en la definición del proceso: roles,
individuo y el trabajo en equipo actividades y artefactos
Se esperan cambios durante el proyecto Se espera que no ocurran cambios de
gran impacto durante el proyecto
Principales MAs
• Crystal Methodologies, Alistarir Cockburn,
www.crystalmethodologies.org
• SCRUM, Ken Schwaber & Jeff Sutherland,
www.controlchaos.com
• DSDM (Dynamic Systems Development Method),
www.dsdm.org
• Lean Programming, Mary Poppendieck,
www.poppendieck.com
• FDD (Feature-Driven Development), Peter Coad & Jeff De Luca,
www.nebulon.com/fdd, www.coad.com/peter/#fdd
• Extreme Programming, Kent Beck
www.extremeprogramming.org, www.xprogramming.com
• Adaptative Software Development, Jim Highsmith www.adaptivesd.com
Programación Extrema
Historia de XP
• Creada por Kent Beck a raíz de su experiencia en el proyecto

C3 en Chrysler
 Kent fue contratado para dirigir el proyecto
 Durante el proceso nació una nueva metodología:
 C3 concluyó exitosamente en 1997
Valores que fomenta XP
• Comunicación
• Simplicidad
• Retroalimentación
• Coraje
Roles XP
Programador Jefe de Proyecto (Manager)

– Responsable de – Organiza y guía las reuniones
decisiones técnicas – Asegura condiciones
– Responsable de construir adecuadas para el proyecto
el sistema
Cliente (Customer)
– Sin distinción entre – Es parte del equipo
analistas, diseñadores o – Determina qué construir y
programadores cuándo
– En XP, los programadores – Establece las pruebas de
diseñan, programan y aceptación
realizan las pruebas
... Roles XP
Encargado de Pruebas
(Tester)
– Ayuda al cliente con las
pruebas de aceptación Entrenador (Coach)
– Se asegura de que las – Responsable del proceso
pruebas aceptación se
– Tiende a estar en un
superan
segundo plano a medida que
el equipo madura
Rastreador (Tracker)
– “Metric Man”
– Observa sin molestar
– Mantiene datos históricos
Artefactos esenciales en XP
• Historias del Usuario

• Tareas de Ingeniería
• Pruebas de Aceptación
• Pruebas Unitarias y de Integración

• Plan de la Entrega
• Código
Historia de Usuario
Historia de Usuario
Número: 1 Nombre: Enviar artículo
Usuario: Autor
Modificación de Historia Número: Iteración Asignada: 2
Prioridad en Negocio: Alta
Puntos Estimados:
(Alta / Media / Baja)
Riesgo en Desarrollo:
Puntos Reales:
(Alto / Medio / Bajo)
Descripción:
Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de
los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como
autor de contacto. El sistema confirma la correcta recepción del artículo enviando un
e-mail al autor de contacto con un userid y password para que el autor pueda
posteriormente acceder al artículo.
Observaciones:
Spike para Historia de Usuario
Tarea de Ingeniería
Tarea
Número tarea: Número historia:
Nombre tarea:
Tipo de tarea :
Puntos estimados:
Desarrollo / Corrección / Mejora / Otra
Fecha inicio: Fecha fin:
Programador responsable:
Descripción:
Prueba de Aceptación
Caso de Prueba
Número Caso de Prueba: Número Historia de Usuario:
Nombre Caso de Prueba:
Descripción:
Condiciones de ejecución:
Entradas:
Resultado esperado:
Evaluación:
Escenarios en XP : Exploración
? Historias de Usuario
Prioridad Riesgo
Esfuerzo (puntos)
Definir
Historias
de Usuario
Estimar Esfuerzo
Elaborar y Riesgo
Spikes
Spikes (Bosquejos)
Escenarios en XP:
Planificación de la Entrega
Velocidad de
Proyecto (VP)
puntos/semana
Historias
de Usuario
Segunda N-ésima Última
Primera Iteración Iteración
Iteración Iteración
Historias
fuera de la
… entrega
2a3
semanas
Entrega
<= 3 meses
Escenarios en XP :
Comenzar Iteración
Definir y
Historias de la ordenar
Iteración Tareas de
Ingeniería
Tareas de
la iteración
Escenarios en XP :
Programación
Historias de la
Iteración
Tareas de
Historias de
la iteración
Programación
Diseño en Parejas
Pruebas de
Refactoring Aceptación
Programación de Historias
de la iteración
Pruebas Unitarias
Integración
Pruebas de Integración
Pruebas de Aceptación
Versión del
Producto
Escenarios en XP :
Pruebas de Aceptación
Definir Pruebas
de Aceptación Pruebas de
Aceptación
Corregir errores
Definir nuevas Historias
Aplicar Pruebas
de Aceptación
Entorno y clima de trabajo
Espacio de trabajo XP
• Espacio abierto
• Mesas centrales
• Cubículos en el espacio exterior
Espacio de trabajo
del proyecto C3 de
DaimlerChrysler
… Entorno y clima de trabajo
Reunión diaria XP
• Reunión diaria: “Stand-up Meeting”
– Todo el equipo
• Problemas
• Soluciones
– De pie en un círculo
• Evitar discusiones largas
• Sin conversaciones separadas
Conclusiones
¿Cuándo utilizar una Metodología Ágil?
• ¿Tienes ya un proceso? No
o existe pero no reacciona bien a los cambios
o existe pero el equipo no está contento con
él
 Una Metodología Ágil puede ser una buena

forma de empezar
• No involucra gran inversión
• A los programadores les (suele) gustar
• A los clientes les ofrece mayor visibilidad y
menor riesgo en el proyecto
Sitios Consultados
• Sitio Extreme Programming: A Gentle Introduction. www.extremeprogramming.org
• Secciones “Artículos” y “Roadmap” del sitio de la Agile Alliance. www.agilealliance.org
• Sitio Xprogramming, mantenido por Ron Jeffries. www.xprogramming.com
• WikiWiki de Extreme Programming http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
• Revista electrónica Software Development. www.sdmagazine.com
• Número monográfico de revista CrossTalk: Agile Software Development.
www.stsc.hill.af.mil/crosstalk/2002/10/
• Una extensiones de XP, Agile+. www.agiletek.com
• Sitios de modelado ágil, mantenidos por Scott W. Ambler. www.agilemodeling.com y www.agiledata.org
• Refactoring, mantenido por Martin Fowler. www.refactoring.com
• Pruebas en contexto ágil, www.junit.org
• International Conference on eXtreme Programming and Agile Methods in Software Development
(XP200x) http://www.xp2004.org
• XP Agile Universe http://www.agileuniverse.com
MSF
(Microsoft Solutions Framework)
Presenta:
Gonzalo Bolaños López
Héctor Jaime Carrasco
Definición
• Es una muy flexible e interrelacionada

serie de conceptos, modelos y prácticas
de uso que controlan la planificación, el
desarrollo y la gestión de proyectos
tecnológicos.
• Se centra en los modelos de proceso y de
equipo dejando en un segundo plano las
elecciones tecnológicas.
Antecedentes
• Originalmente creado en 1994 para conseguir
resolver los problemas a los que se enfrentaban
las empresas en sus respectivos proyectos, se ha
convertido posteriormente en un modelo práctico
que facilita el éxito de los proyectos tecnológico.
Principios
1. Fomentar la comunicación abierta
2. Trabajar en pro de una visión compartida
3. Potenciar a los miembros del equipo
4. Establecer una clara rendición de cuentas y la
responsabilidad compartida
5. Enfoque en la entrega de valor del negocio
6. Manténgase ágil, esperar el cambio
7. Invertir en calidad
8. Aprender de todas las experiencias.
Modelo de Equipo
• Proporciona una estructura flexible para organizar
los equipos de un proyecto. Puede ser escalado
dependiendo del tamaño del proyecto y del
equipo de personas disponibles.
Modelo de Proceso
• Proporciona una estructura de pautas a seguir en
el ciclo de vida del proyecto, describiendo las
fases, las actividades, la liberación de versiones y
explicando su relación con el Modelo de equipo.
FASES
• Previsión.
• Planeamiento
• Desarrollo
• Estabilización
• Implementación
Disciplina de Gestión de Riesgos
• Este modelo proporciona un entorno

estructurado para la toma de decisiones y
acciones valorando los riesgos que puedan
provocar.
Disciplina de Gestión de Proyectos
• Describe el rol de la gestión del proyecto dentro

del modelo de equipo de MSF, y como permite
mayor escalabilidad, desde proyectos pequeños a
proyectos largos y complejos.
Disciplina de Gestión de la Preparación
• Describe aquellos conocimientos, aptitudes y

habilidades que son necesarias para planificar,
desarrollar y gestionar soluciones satisfactorias.
Gestión de productos
• Lograr la satisfacción del cliente.
• Actuar como el defensor del cliente al equipo y
como el equipo defensor al cliente.
Programa de gestión
• Satisfacer la meta de calidad de la entrega de los
productos dentro de las limitaciones del proyecto.
Garantiza que el producto se entrega en el
momento adecuado.
• Calendario
• Características
• Presupuesto
Usuario de la educación
• Mejorar el rendimiento del usuario de modo que
los usuarios son tan productivo como sea posible
con el producto
Gestión de la logística
• Defensor de las operaciones, soporte de
producto, asistencia al usuario, y otras
organizaciones de canales de entrega y gestión en
curso.
Conclusiones
• El Microsoft Solutions Framework proporciona las mejores prácticas para
planear, diseñar, convertir y desarrollar exitosas soluciones empresariales. Es
una herramienta muy eficaz para el desarrollo de proyectos porque te da las
bases esenciales para que desde el comienzo se desarrolle todos los procesos
que se necesitan realizar de manera eficiente y eficaz y con el mínimo de
errores que permitan evolucionar todo tipo de proyecto y no se tenga que
regresar demasiado a etapas anteriores por fallas en el manejo de decisiones o
acciones deficientes.
• Nos ayuda a realizar mejores `proyectos en tiempos mas rápidos, los cuales
siempre son la meta a alcanzare n una empresa de desarrollo.
Referencias
• http://www.mentores.net/articulos/intro_microsoft_sol_frame.htm
• http://209.85.141.104/search?q=cache:uDkabg6xdlUJ:www.malagadnug.org/fic
heros/MSFMartinLuisReq.pdf+microsoft+solutions+framework&hl=es&ct=clnk
&cd=8&gl=mx
• http://translate.google.com.mx/translate?hl=es&sl=en&u=http://www.echoes.
com/msf/&sa=X&oi=translate&resnum=4&ct=result&prev=/search%3Fq%3Dmi
crosoft%2Bsolutions%2Bframework%26start%3D10%26hl%3Des%26sa%3DN
• http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/planificacion/m
sf.mspx
GRACIAS
Biblioteca de Infraestructura de
Tecnologías de Información
POR:
LUIS MANUEL SUÁREZ HUERTA
ANTONIO DE JESUS FERREIRA GARCÍA
INTRODUCCION
• La Biblioteca de Infraestructura de
Tecnologías de Información (‘Information
Technology Infrastructure Library’),
frecuentemente abreviada ITIL, es un marco de
trabajo de las mejores prácticas destinadas a
facilitar la entrega de servicios de tecnologías
de la información (TI).
• ITIL es una metodología desarrollada a finales
de los años 80’s por iniciativa del gobierno del
Reino Unido, específicamente por la OGC u
Oficina Gubernativa de Comercio Británica
(Office of Goverment Comerce).
• Esta metodología es la aproximación más
globalmente aceptada para la gestión de servicios
de Tecnologías de Información en todo el mundo,
ya que es una recopilación de las mejores
prácticas tanto del sector público como del sector
privado.
• . Estas mejores practicas de dan en base a
toda la experiencia adquirida con el tiempo en
determinada actividad, y son soportadas bajo
esquemas organizacionales complejos, pero a
su vez bien definidos, y que se apoyan en
herramientas de evaluación e
implementación.
EL OBJETIVO DE USAR ITIL
• ITIL como metodología propone el
establecimiento de estándares que nos ayuden en
el control, operación y administración de los
recursos (ya sean propios o de los clientes).
• Plantea hacer una revisión y reestructuración
de los procesos existentes en caso de que
estos lo necesiten (si el nivel de eficiencia es
bajo o que haya una forma mas eficiente de
hacer las cosas), lo que nos lleva a una mejora
continua.
• Otra de las cosas que propone es que para
cada actividad que se realice se debe de hacer
la documentación pertinente, ya que esta
puede ser de gran utilidad para otros
miembros del área, además de que quedan
asentados todos los movimientos realizados,
permitiendo que toda la gente este al tanto de
los cambios y no se tome a nadie por
sorpresa.
SOLUCIONES PARA ITIL DESDE EL
PUNTO DE VISTA DE NEGOCIO.
• Según el diagrama 1.1 vemos como
aparentemente tenemos segmentos del
negocio aislados, pero en realidad todos
tienen algo que ver para la obtención de las
soluciones.
• Por ejemplo la prestación de servicios muchas
veces no seria posible sin la gestión de
infraestructura, asimismo las perspectivas del
negocio no se darían sin la prestación de servicio
y los servicios no serian posibles sin un soporte al
servicio.
Diagrama 1.1
FORMA DE USO DE ITIL EN
MANAGED SERVICES.
• ITIL postula que el servicio de soporte, la administración
y la operación se realiza a través de cinco procesos:
• Manejo de Incidentes
• Manejo de Problemas
• Manejo de Configuraciones
• Manejo de Cambios
• Manejo de Entregas
PROCESO DE MANEO DE INCIDENTES.
• Su objetivo primordial es reestablecer el servicio
lo mas rápido posible para evitar que el cliente se
vea afectado, esto se hace con la finalidad de que
se minimicen los efectos de la operación.
PROCESO DE MANEJO DE
PROBLEMAS
• El Objetivo de este proceso es prevenir y reducir
al máximo los incidentes, y esto nos lleva a una
reducción en el nivel de incidencia. Por otro lado
nos ayuda a proporcionar soluciones rápidas y
efectivas para asegurar el uso estructurado de
recursos.
• En este proceso lo que se busca es que se pueda
tener pleno control del problema, esto se logra
dándole un seguimiento y un monitoreo al
problema.
PROCESO DE MANEJO DE
CONFIGURACIONES.
• Su objetivo es proveer con información real y
actualizada de lo que se tiene configurado e
instalado en cada sistema del cliente.
• Este proceso es de los más complejos, ya que se
mueve bajo cuatro vértices que son:
administración de cambios, administración de
liberaciones, administración de configuraciones y
la administración de procesos diversos.
PROCESO DE CONTOL DE CAMBIOS.
• El objetivo de este proceso es reducir los riesgos
tanto técnicos, económicos y de tiempo al
momento de la realización de los cambios.
PROCESO DE MANEJO DE ENTREGAS.
• Su objetivo es planear y controlar exitosamente la
instalación de Software y Hardware bajo tres
ambientes: ambiente de desarrollo, ambiente de
pruebas controladas y ambiente real.
CERTIFICACION.
• Los particulares pueden conseguir varias
certificaciones oficiales ITIL. Los estándares de
calificación ITIL son gestionados por la ITIL
Certification Management Board (ICMB) que
agrupa a la OGC, a itSMF International y a los dos
Institutos Examinadores existentes: EXIN (con
sede en los Países Bajos) e ISEB (con sede en el
Reino Unido).
• Existen tres niveles de certificación ITIL para
profesionales:
• 1. Foundation Certificate (Certificado Básico): acredita

un conocimiento básico de ITIL en gestión de servicios
de tecnologías de la información y la comprensión de
la terminología propia de ITIL. Está destinado a
aquellas personas que deseen conocer las buenas
prácticas especificadas en ITIL.
• 2. Practitioner's Certificate (Certificado de
Responsable): destinado a quienes tienen
responsabilidad en el diseño de procesos de
administración de departamentos de
tecnologías de la información y en la
planificación de las actividades asociadas a los
procesos.
• 3. Manager's Certificate (Certificado de Director):
garantiza que quien lo posee dispone de
profundos conocimientos en todas las materias
relacionadas con la administración de
departamentos de tecnologías de la información,
y lo habilita para dirigir la implantación de
soluciones basadas en ITIL.
CONCLUSIONES.
• ITIL es una metodología que nos va a ayudar a
que las cosas se puedan hacer de una forma más
eficiente, ya que lo que se propone es que se
adopten ciertas métricas y procedimientos que
otros proveedores de IT adoptaron y que gracias a
ellas son catalogadas como mejores prácticas.
• El hecho de adoptar mejores practicas implica
que no tengamos que descubrir el hilo negro y
que si alguien sabe como hacer las cosas y
explotar los recursos nos podemos apoyar en
el para que nosotros también podamos
hacerlo. El mayor objetivo es que todos
lleguemos a un nivel de eficiencia que se
traduzca en una buena prestación de
servicios.
FUENTES:
• Wikipedia Foundation. Inc(2008) Information

Technology Infrastructure Library. Disponibilidad:
<http://es.wikipedia.org/wiki/Information_Techn
ology_Infrastructure_Library> [Fecha de consulta:
20 de Agosto 2008].
• Hernández García, Carlos (2002) Metodología
ITIL Disponibilidad:
<http://www.monografias.com/trabajos31/meto
dologia-itil/metodologia-itil.shtml> Fecha de
consulta: 20 Agosto 2008
• Consultoría asentti, (2005), Descubriendo ITIL,
Disponibilidad:
http://www.cepra.com.mx/itil.pdf Fecha de
consulta: 20 Agosto 2008.
Actividad
• De las metodologías que se les hayan asignado,
preparar una presentación donde se exprese
brevemente la metodología de manera muy
general (80%).
• Una vez realizada todas las presentaciones,

redactar un escrito en el que se indique que
metodología es la que mejor aplica para el 270
proyecto a desarrollar (20%).
Rúbrica de Presentaciones
• Vestimenta formal: 10%
• Material de Entrega: 10%
• Contenido de la presentación: 70%
• Presentación fluida sin lectura: 20% 271

Radiografía de la
Industria del Software
en México
¿Por qué son importantes las

metodologías de desarrollo de
software? 272
Tipos de Organización
6.70% Área de Sistemas
8.40% 9.30%
Proveedor de
Servicios
47.40%
Canal/Distribuidor
26.80%
ISV (Independent
1.30% Software Vendor)
Servicios Educativos
Otros
Esquema de Contratación
3.40%
6.30%
24.10% Nómina
Honorarios
66.20%
Independiente
Otro
Edad
1.50%
8.60% 0.20%
16.40%
18-24
25-29
37.70% 30-39
35.60% 40-49
50-59
60-X
Escolaridad
1.20%
Preparatoria
0.90% 2.70%
16.70% Técnica
4.80%
26.70%
Universidad sin
Titular
47% Universidad
Titulado
Posgrado
Maestría
Género
14.30%
Femenino
85.70% Masculino
Antigüedad
8.90%
22.40%
16.00% <1 año
1-3 años
14.30% 3-5 años
38.40% 5-10 años
>10 años
Salarios
1.70%
3% 2% 3.60% <4000
7.90% 8.20%
4-6 mil
7-10 mil
9.60% 14.90% 11-15 mil
12.10% 16-20 mil
18.50% 21-25 mil
17.50% 26-30 mil
31-40 mil
41-50 mil
51-60 mil
Salarios
NL
11,993 DF
12,133 9,054 25,068
24,742 QRO
13,571
MEX
15,857 AGS
23,523 MOR
JAL
CHI
TAB
BC
21,247 GTO
16,147
18,847 MICH
16,224 PUE
18,538 18,788
16,630 SIN
Salarios
1.90% 2.80% NL
3.10% 2.90%
2.50% DF
3.30% 9.10% QRO
MEX
1.70% AGS
2% MOR
8.20% JAL
35.10% CHI
TAB
7.40%
1.50% BC
2.70% GTO
MICH 281
2.80% PUE
SIN
VER
Salario Internacional
10,625 EU
10,500 9,000
12,000 Chile
15,278 62,727 Guatemala
España
Argentina
33,500
Colombia
26,864 27,000 Perú
15,917
Ecuador
Venezuela
18,944 Bolivia
Salario Tipo de Organización
Educación
13,700
22,500 Distribuidor
15,800
ISV
19,900
19,200
Área de Servicios
Proveedor de
Servicios
Salario por Función
Soporte
12,700
Docencia
9,800 13,000
Webmaster
40,800 13,500
27,500 Redes
16,200 DBA
Desarrollo
27,100 16,600
Calidad
Seguridad
Consultoría
17,300
Ventas
23,900 21,500
22,300 Project Managment
Arquitectura
Dirección
Salario por Rango Edad
10,100
16,000
30,200
18-24
23,600 25-29
30-39
38,900
40-49
35,700 50-59
60-X
Salario Grado de Estudios
Preparatoria
14,700
16,400 Universidad Sin
31,900
Titular
Universidad
19,300 Titulado
26,600
25,300 Postgrado
Maestría
Doctorado
Conocimiento y Habilidades
26%
17,000
33%
20,800 PHP
VB
28% 37%
18,800 Delphi
20,500
20% C
19,500 ASP
JSE
9%
18,900
Conocimiento y Habilidades
4%
29,800
22% Ajax
16% 20,900
24,500 Flex
Perl
JME
6%
21,300 .NET
COBOL
4% 2%
22,000 21,100
Plataformas
4% 13%
6% 28%
32,400 17,300
24,200 25,800 DOS
39% Linux
19,500 Apple
9% Win
21,800 89% Win CE
19,800 AS400
Unix
7%
19,600 Mainframe
BD
13% 2%
8%
6% 26,100 15,700
25,300 Firebird
24,600 41%
MySQL
17,600
40% PostgreSQL
23,300 SQL Server
61% Oracle
20,200 Sybase
Informix
DB2
11%
18,800
Otras habilidades
3%
31% 31,700 21%
20% 24,900 15,600 35% Diseño Gráfico
23,600 17,500 Redes
UML
58% BI
21,800 ERP
Testing
Mejora de Procesos
45%
25% EDI
21,000
21,800
Certificaciones
17,800 Cisco
28,500 19,100
Linux
24,100 MS Professional
Sun-Java
23,600 22,900 OMG-UML
23,200 MS DBA
MS Solution Dev
Novell
20,500
Certificaciones
29,100
Oracle
40,300 28,600 Sw. Quality Eng.
29,000
33,900 Solaris
MS System Eng.
SEI
IBM DB2 x
SAP
33,200
30,200 Seguridad
29,200
29,500 29,500 IBM Websphere
PMI
Problemas de Comunicación
Ejemplo de Metodologías
• Problema: El profesor se encuentra actualmente
ante una necesidad de extrema importancia.
Necesita realizar una corbata para ir a una junta
en donde se encontrarán altos empresarios del
sector informático, el detalle es que no sabe a ser
un nudo de corbata
• ¿Cómo podría resolver el problema?

Ejemplo de Metodologías
• La solución más fácil es realizar outsorcing (que
lo hagan otros).
• Sino se puede, se deberá realizar en base a tres

formas básicas de solución de problemas:
• Conocimiento
• Experiencia
• Sentido Común
Ejemplos de Metodologías
• La forma más fácil es a través de una metodología
para realizar nudos de corbatas como la
planteada en http://www.nudo-de-corbata.com/
• Lo primero que se tiene que saber es si debe ser

un tipo especial de corbata o no. Los tipos
pueden ir desde nudo de corbata simple, doble,
windsor, medio windsor, nudo pequeño.
Simple
Doble
Windsor
Medio Windsor
Nudo pequeño.
Nudo Cruzado
Actividad
• Lectura del Artículo: “La Catedral y el Bazar”.
• Realizar en forma grupal una presentación de

los puntos más relevantes (80%)
• De forma personal escribir los tres principios

que más llamaron mi atención.
304
Requerimientos
• Un requisito no es otra cosa que una
condición o capacidad de un usuario o sistema
para satisfacer un objetivo o resolver un
problema.
• Los requerimientos pueden ser funcionales

(explícitos) o no funcionales (implícitos).
Requerimientos
• Las características que deben perseguir los
requerimientos son: necesario, conciso,
completo, consistente, no ambiguo, verificable.
• Los problemas que presenta la Ingeniería de

Requerimientos son muchos:
Requerimientos
• Los requerimientos no son obvios y provienen
de muchas fuentes.
• Son difíciles de expresar en palabras.
• Un requerimiento puede cambiar en el

transcurso del proyecto.
Requerimientos
• Lo que se pretende con una buena Ingeniería
de Requerimientos es reducir costos y retrasos
del proyecto, mejorar la calidad del software,
evitar el rechazo de los usuarios finales entre
otras cuestiones.
Requerimientos
• Es muy importante definir los límites y
alcances del sistema.
• El éxito de la obtención de requerimientos

consiste en ponernos en los zapatos de
nuestros clientes y no desarrollando a
nuestros gustos.
309
Diferentes Vistas
Diferentes Vistas
Diferentes Vistas
Requerimientos
• Se deben evaluar y negociar cada uno de los

requerimientos con el fin de priorizar cada uno
de los requerimientos.
• Se deben documentar cada uno de los

requerimientos obtenidos así como el control del
cambio.
Requerimientos
• Para obtener requerimientos se siguen
muchas técnicas. Las más populares son las
entrevistas y cuestionarios.
• Tips para Diseñar Cuestionarios.
• Es necesario realizar un muestreo de los datos

para encontrar necesidades.
Requerimientos
• Se deberán poner escalas (preguntas cerradas)
para cuantificar lo que se pretende.
• Actividad: diseñar un cuestionario sobre el

proyecto y aplicarlo a por los menos a 20
personas. Se sugiere utilizar sistemas en líneas
para realizar los cuestionarios. (Diseño:20%,
Aplicación:80%)
Request For Proposal
• Solicitud de Propuesta 1:
• Desarrollar un sistema de cómputo móvil para la

ayuda en la toma de requerimientos de
proyectos de software.
• El sistema deberá sincronizarse con un servidor

en donde se centralizará la información y podrá
compartirse con otros a través de un portal Web.
• El Sistema de cómputo móvil deberá tener la
capacidad de implantar las técnicas de obtención
de requerimientos más comunes (cuestionarios,
encuestas, prototipos, FODA, FURPS, etc.) y
plasmarlo en una lista de requerimientos que
permita obtener un diccionario de datos y algún
modelo visual como los diagramas de casos de
uso.
• Solicitud de Propuesta 2:
• Realización de un sistema LBS que permita

conocer la ruta “ideal” entre dos puntos de la
ciudad de Morelia para utilizarse en sistemas de
Taxi.
• La aplicación deberá de ser de preferencia para

un dispositivo móvil con GPS o 3G.
• Otra forma de realizarse es a través de un
“mashup” para la Web utilizando la API de
Google Map o Google Earth.
• Se deberá calcular costos utilizando la

información espacial disponible.
• Se excluyen elementos como tráfico,

manifestaciones y otra información no disponible
en el modelo.
Requerimientos
• Tips para realizar entrevistas:
• Utilizar una técnica de rombo de preguntas

cerradas, abiertas y cerradas.
• Observación del mundo (STROBE).

• Tener un guión flexible (improvisación).
321
Requerimientos
• Tarea: realizar una entrevista a personal

relacionado con el proyecto. Primera parte
diseño entrevista (50%) una vez aprobada por el
profesor (entrega martes 10 junio) se procede a
la aplicación (50%).
• En metodologías ágiles el cliente participa de

manera activa en el desarrollo del sistema. 322
FODA
• Se pueden utilizar técnicas como la Lluvia de
Ideas o análisis FODA, el cual consiste en
hacer una relación entre elementos:
• Fortaleza: Factor interno positivo.

• Oportunidades: Factor externo positivo.
• Debilidades: Factor interno negativo.
• Amenazas: Factor externo negativo.
Requerimientos
• Actividad: Realizar un análisis FODA del
proyecto. Cada integrante del equipo se
encarga de un área y se junta (100%)
• Otras técnicas de obtención de

requerimientos son:
• Matriz de requisitos
• Metodología FURPS+
Actividad
• El buen estilo de codificación trae como
consecuencia una mejor reestructuración del
código lo cual lo hace menos propenso a cometer
errores y más fácil de mantener.
• El término codificación hace hincapié a codificar

ciertos “datos” en un formato en específico.
Actividad
• En los primeros lenguajes de programación como
las computadoras eran escasas y costosas, se
realizaban muchas pruebas de escritorio, antes de
codificar un programa, este se escribía en un
formato especial llamado hoja de control tabular,
en la cual se escribían en cada celda un carácter
de control, de esta forma se podían hacer las
perforaciones en una tarjeta perforada.
Actividad
Actividad
Actividad
Actividad
Actividad
• Desarrollar un programa en Fortran que permita
calcular las raíces de una ecuación de segundo
grado utilizando fórmula general.
• El programa deberá de validar las entradas,

indicando si las raíces obtenidas son imaginarias
o reales.
• Dicho programa se hará en la hoja tabular y se

probará a lápiz y papel.
Actividad
• Una vez realizada la prueba de escritorio, se
tendrá hasta tres oportunidades de poder correr
el programa en la computadora.
• Si corre a la primera, se tendrá un 100, a la

segunda 90, tercera 80, después se tendrá 70
siempre y cuando se entreguen la hoja de control
y se corrija el error.
• A continuación se presenta un pequeño resumen

de Fortran.
Fortran
• Es el lenguaje de programación de
computadoras más antiguo. Se originó en
1957 por IBM.
• El nombre viene de Formula Translator, el cual

se orientó a cálculos científicos.
• Existen varios compiladores de Fortran, en

este curso se utilizarán el GNU Fortran.
Fortran
• Existen varios dialectos de FORTRAN siendo
los más representativos, Fortran IV, Fortran
77, Fortran 95 y Fortran 2003.
• La versión manejada en este curso es el

compilador g95 que también incluye aspectos
de la versión 2003.
Fortran
• Una vez instalado el compilador, los
programas se editan utilizando un editor de
texto plano y compilando desde línea de
comandos.
• Los archivos de código fuente deben de tener

la extensión .f o .for; existen algunos
compiladores que reconocen otras
extensiones.
Fortran
• El proceso de compilación se realiza
identificando la carpeta bin y se ejecuta el
comando:
• >_ g95 archivo.f –o ejecutable
• Donde con la opción –o se renombra el

ejecutable en caso contrario el archivo
ejecutable pasará a llamarse a.exe
Fortran
• La estructura de un programa es la siguiente:
• C Estructura de un programa en Fortran

• Program nombre
• Bloque de instrucciones
• End
• !Declaraciones de funciones y rutinas

Fortran
• Nótese que el programa en sus palabras clave
pueden ir en mayúsculas y minúsculas. Se
acostumbra que todas las palabras clave se
hagan en mayúsculas.
• También es ampliamente recomendable poner

comentarios, los cuales inician con la letra C al
inicio de renglón o bien con ! En cualquier
parte del código.
Fortran
• Es de suma importancia dejar el programa de
forma tabular, ya que los primeros 6
caracteres están reservados para etiquetas
que generalmente son números. Si no se deja
dicho espacio el programa no compilará bien.
• En Fortran es posible no realizar programación

estructurada por lo que se debe evitar la
instrucción GO TO
Fortran
• El nombre del programa debe de ser un
identificador válido (comenzar con al menos
una letra)
• El sistema no es fuertemente tipeado por lo

que se pueden utilizar variables sin
declararlas.
• Se debe de terminar el programa principal con

la instrucción end.
Fortran
• C Programa hola mundo
• PROGRAM hola
• WRITE(*,*) ‘Hola mundo’ !Pantalla
• END
• Se recomienda sangrar el código. La salida

estándar es el monitor y se utiliza la
instrucción WRITE.
Fortran
• La instrucción WRITE tiene dos argumentos, el
primero de ellos indica el dispositivo de salida
y el segundo formato. Si se utiliza el operador
* o bien se omiten los parámetros de la
instrucción, se utiliza
Fortran
• Actividad: realizar la lectura de dos números y
mostrar el resultado de las 4 operaciones
básicas.
• ¿Qué estructuras de programa necesito?

Fortran
• Se ocupa de una instrucción para leer datos
que es READ(*, *).
• Una vez asignado se necesitan hacer los

cálculos para ello se necesitan conocer los
operadores aritméticos: +, -, *, / y ** que sirve
de exponenciación.
• También se puede utilizar el comando PRINT

para imprimir datos en pantalla de forma
básica.
Fortran
• Actividad: Desarrollar un programa para
calcular el área de un triángulo conociendo
solamente la longitud de sus tres lados.
• ¿Qué se necesita? Entender el problema. La

fórmula es:
• S = (A + B + C)/2
Fortran
• Donde A, B y C son los lados del triangulo.
Después se aplica la fórmula:
Área  S (S  A)( S  B)( S  C)
• Para ello se necesita el operador SQRT para

poder sacar la raíz cuadrada.
• ¿Cómo se garantiza que los lados introducidos

sean válidos?
Fortran
• Los datos 1,2 y 3 como longitudes de los lados
de un triangulo no forman realmente un
triangulo, en cambio los datos 3,4 y 5 si ya que
forman un triangulo rectángulo con área de 6
unidades cuadradas.
• La evidencia obvia es garantizar que cada dato

no sea 0 o negativo.
Fortran
• La otra no tan evidente es validar el resultado
de las áreas, ya que está no puede ser ni 0 ni
negativa.
• Para poder realizar estas acciones se necesita

de la instrucción de decisión IF, el cual tiene la
siguiente sintaxis IF (expresión) XX, XX, XX
Fortran
• Esta es la vieja sintaxis, la cual salta a la
primera etiqueta si el resultado es menor que
0, a la segunda si es igual a 0 y salta a la
tercera línea cuando sea mayor a 0.
• La instrucción STOP permite parar un

programa.
Fortran
• Las etiquetas generalmente son números y
deben ir en la primera columna.
• Actividad: modificar el programa anterior para

que permita la introducción de un lado hasta
que este sea positivo.
• ¿Qué se necesita un ciclo? Que se puede

obtener con un GO TO y una condicional.
Fortran
• La otra forma de hacer una decisión es con el
IF lógico, el cual tiene la sintaxis: IF
(expresión) GO TO etiqueta.
• Para ello se necesita conocer los operadores

relacionales los cuales son: .GT., .LT., .EQ., .NE.,
.GE., .LE. Para >,<, =, <>, >= y <=
respectivamente.
Fortran
• Algunos compiladores permiten hacer uso de
dichos operadores de manera normal.
• Actividad: realizar el factorial de un número.

Tomando en cuenta que Fortran no permite
recursividad en la gran mayoría de sus
versiones.
Fortran
• El operador + o $ al inicio de una línea de
código (6ta columna) indica que la línea
continúa de la línea anterior.
• Algunos compiladores limitan la extensión de

las sentencias hasta 72 caracteres, dado que
las tarjetas perforadas eran de hasta 80 líneas.
Fortran
• El operador de asignación es =.
• Los operadores lógicos son: .NOT., .AND., .OR.,

.EQUIV. Y .NEQUIV. Para la negación,
conjunción, disyunción, equivalencia y no
equivalencia.
• Otras funciones aritméticas son: ABS, MOD,

DIV, MAX, MIN, SIN, COS, TAN. Utilizadas en
casi todos los lenguajes.
Fortran
• Los tipos de datos básicos en Fortran son:
• INTEGER: enteros
• REAL: decimales
• DOBLE PRECISION: decimales largos
• LOGICAL: lógicos, .TRUE. Y .FALSE.
• CHARACTER: caracateres
• COMPLEX: Complejos como (1,2) CMPLX(-
0.5,1.E-3).
Fortran
• Ejemplo de Declaración de Variables:
• INTEGER A
• REAL B, C
• LOGICAL D
• La instrucción PARAMETER sirve para declarar

constantes. PARAMETER (PI=3.14159)
Fortran
• La instrucción FORMAT recibe la siguiente
secuencia de caracteres para especificar el
formato de los datos:
• A Cadenas
• I Enteros
• F Decimales
• E Notació Científica
Fortran
• D Doble Precisión
• X Espacio en blanco
• / Salto de renglón
• Ejemplos:
• A20: Cadena de 20 caracteres

• 5I3: 5 enteros de 3 dígitos cada uno
• F3.2 Un decimal con tres dígitos enteros y 2
dígitos fraccionarios
Fortran
• 3X: tres espacios en blanco
• /// Tres líneas en blanco
• Se pueden utilizar sentencias de decisión

doble del tipo: IF (condición) THEN sentencias
ELSE sentencias ENDIF.
• Actividad: Realizar un programa para calcular

las raíces de una ecuación cuadrada,
indicando si son reales o imaginarias las
raíces.
Fortran
• Las subrutinas se llaman con la instrucción
CALL desde el programa principal y se
declaran de la siguiente manera:
• SUBROUTINE nombre(parametros)
• !Declaraciones
• RETURN
• END
• Modificar el programa de las raíces utilizando

subrutinas
Fortran
• Las funciones permiten regresar un valor a
diferencia de las subrutinas. Se declaran de la
siguiente forma:
• Tipo FUNCTION nombre(parametros)

• !Declaraciones
• nombre = valor
• RETURN
• END
Fortran
• Reescribir el programa Factorial utilizando una
función.
• Realizar un programa que permita jugar

“Craps”. Dicho juego consiste en lanzar dos
dados (simulación realizada a través de una
función que se invoque dos veces) y sumar la
puntuación. Si la suma de los dados da 2,3 o
12 el usuario pierde inmediatamente.
Fortran
• Si la suma da 7 u 11 el usuario gana. Si da
cualquier otra combinación 4,5,6,8,9 o 10, el
usuario tiene otra segunda oportunidad.
• El programa debe de pedir al usuario la

cantidad de dinero con la que cuenta el
usuario. Por cada juego se debe pedir la
apuesta. Se debe sumar o restar dependiendo
de si ganó o perdió el juego. El juego termina
hasta tener 0 pesos o bien que el usuario
decida salir.
Fortran
• Para generar números aleatorio se utiliza la
función RAND(TIME()) que genera un número
aleatorio entre 0 y 1 por lo que necesita ser
convertido a enteros con INT.
• Los ciclos se pueden realizar de manera

estructura con la instrucción:
• DO inicialización, límite, incremento

• sentencias
• ENDO
Fortran
• Actividad: realizar un programa que permita
simular una partida de póker. El usuario
deberá tener 5 cartas. La simulación consiste
en repartir aleatoriamente cartas. Del 1 al 10
las cartas de corazones (donde el 1 representa
el as), del 11 al 20 los diamantes (por ejemplo
el 13) indica que se sacó el tres de diamantes,
del 21 al 30 el trebol, y del 31 al 40 las picas.
Los jotos están representados del 41 al 44,
donde el 41 representa el joto de corazones y
así sucesivamente.
Fortran
• Las reinas están representadas del 51 al 54
(por ejemplo el 52 representa la reina de
diamantes), y los reyes están del 61 al 64
(donde el 64 es el rey de picas).
• No se deberán repartir cartas. Se debe indicar

si se hizo alguna jugada válida del póker (par,
dos pares, tercia, full (tercia, par), póker (4
figuras igual), flor y flor imperial).
Fortran
• Los arreglos se declaran poniendo al final de la
declaración de variables, las dimensiones y el
tamaño de éstas. Por ejemplo:
• INTEGER A(30) !Arreglo de 30 enteros

• CHARACTER*40 N(30) !Arreglo de 30 cadenas
de tamaño 40 cada una
• REAL T(3,4) !Matriz de 3 filas por 4 columnas
de números decimales.
Fortran
• Los arreglos inician a partir del subíndice 1.
• Se pueden especificar el rango de los arreglos.

Por ejemplo: REAL A(-5:5) !10 elementos.
• La instrucción DATA permite inicializar un

arreglo: DATA A/.1,.2,.3/
• Se puede utilizar la instrucción CYCLE para

continuar la siguiente iteración de un ciclo y
EXIT para salir.
Fortran
• Se puede acceder a subcadenas definiendo su
rango. Sea la cadena X=‘Morelia’, la
instrucción Y=X(1:4) seria equivalente ‘More’.
• El operador // sirve para concatenar cadenas.

Otras operaciones son LEN(cad) para
determinar el tamaño de una cadena,
CHAR(num) regresa el carácter representado
por el código ASCII dado. ICHARC(c) regresa el
valor númerico ASCII del código.
Fortran
• La función INDEX(cad1, cad2) regresa la
posición en donde se encuentra la subcadena
2 en la subcadena 1.
• Actividad. Realizar un programa que dado los

siguientes datos: nombre, apellido paterno,
apellido materno y fecha (en formato
dd/mm/aaaa) pueda calcular el RFC de dicho
usuario.
Fortran
• El RFC se calcula con la primera letra del
apellido paterno, la primera vocal del apellido
paterno, la primera letra del apellido materno,
la primera letra del nombre, los dos últimos
dígitos del año de nacimiento, los dos dígitos
que representan el mes, los dos dígitos del
día.
Fortran
• También existen archivos en Fortan. A
continuación se muestra un ejemplo.
• PROGRAM ARCHI
• PARAMETER(MAXP=20)
• CHARACTER*48 PAL(MAXP)
•
OPEN(UNIT=9,FILE='PALABRAS.TXT',STATUS='O
LD',ERR=99)
Fortran
• READ(9,*,ERR=99) (PAL(I), I=1,MAXP)
• CLOSE(9)
• DO I=1,MAXP
• PRINT *, I,') ',PAL(I)
• ENDDO
• STOP
• 99 PRINT *, 'ERROR'
• END
Fortran
• El programa inicia definiendo una constante
para indicar un máximo de 20 palabras de
tamaño máximo de 48 caracteres.
• La instrucción OPEN abre un archivo, el primer

argumento es el identificador de archivo, el
segundo es el nombre, el tercero es el estado.
Dicho estado puede ser OLD (debe de existir el
archivo), NEW (se crea) y REPLACE (reeplza el
archivo si existe).
Fortran
• El último argumento ERR define la etiqueta a
la cual se salta si ocurre algún error.
• Se utiliza READ para leer desde el archivo,

indicando el ID, el formato y el código de
error. Se lee cada palabra desde 1 hasta 20.
Posteriormente se imprime cada una de las
palabras.
Fortran
• Actividad: desarrollar un programa en forma que
permita obtener el valor de verdad de cualquier
operador lógico. Por ejemplo si las entradas son
A=.TRUE. B=.FALSE. C=.FALSE. El programa debe
devolver que A .AND. B .AND. C = FALSE, y así con
los demás operadores .OR., .NOT., .EQUIV. Y
.NEQUIV.
• La salida se deberá guardar en archivos. Se

sugiere utilizar evaluación de expresiones por
corto circuito.
Fortran
calcular la exponencial de un número dado.
2 n
x x x
e  1    ... 
x
1! 2! n!
Fortran
• Actividad: Desarrollar un programa que dado
n como entrada permita desarrollar el
teorema binomial, dada la siguiente fórmula:
n n(n  1) 2 n(n  1)...( n  r  1)

(1  x)  1  x 
n
x  ... 
1! 2! r!
Fortran
• Desarrollar un programa que permita convertir
cualquier número en cualquier base a cualquier
otra.
• El algoritmo consiste en convertir el número

original a base a diez y después cambiarlo a la
nueva base.
• Para convertir a base diez se debe multiplicar el

número por su peso en cada uno de sus dígitos.
Fortran
• Para convertir de decimal a cualquier base, se
debe dividir el número por la base dejando los
residuos almacenados en una parte y la parte
entera pasa a ser el siguiente número. El proceso
se realiza hasta que el cociente quede a 0. El
resultado se obtiene invirtiendo cada uno de los
dígitos de residuo obtenidos con la división, para
ello se necesita manejar un arreglo.
Metodología FURPS+
• Funcional (Functional): características,
capacidades y seguridad.
• Facilidad de Uso (Usability): factores

humanos, ayuda, documentación.
• Fiabilidad (Reliability): frecuencia de fallos,

capacidad de recuperación.
Metodología FURPS+
• Rendimiento (Performance): tiempos de
respuesta, productividad, precisión,
disponibilidad, uso de los recursos
• Soporte (Supportability): adaptabilidad,

facilidad de mantenimiento,
internacionalización, configurabilidad.
Metodología FURPS+
• +:
• Implementación: limitación de recursos,
lenguajes y herramientas, hardware
• Interfaz: restricciones impuestas para la
interacción humana
• Operaciones: gestión del sistema
• Empaquetamiento
• Legales: licencias, auditorias, etc.
Métodología FURPS
Req F U R P S +
Consultas a Deberán Pocos Optimizad Soporte en Ejecutarse
través de realizarse a movimient o para Plataforma con
un celular través de os del desplegar s J2ME Equipos
SMS/MMS, teclado informació Nokia serie
la n 60
respuesta importante
será en
MMS
Sistema Seguridad Optimizad
Web de por o para
Captura autenticaci navegador
Indicadore ón y huella Opera
s digital
… ….
Metodología FURPS+
• Actividad: una vez identificado los posibles
requerimientos del proyecto se comienza por
hacer una matriz de estos, colocando en cada
una de las una de las letras de FURPS+ para
evaluarlo y poder darle prioridad e identificar
Factores Críticos de Éxito. Matriz FURPS grupal
100%, al menos 5 requisitos evaluados.
Factores Críticos de Éxito
• La metodología de Factores Críticos de Éxito
sirven para determinar aquellas áreas o cosas
que son críticas para la empresa.
• El FCE nos ayuda a enfocar nuestros esfuerzos

y en determinar como se debe monitorear
cada una de nuestras alternativas.
FCE
• No son medidas estándar para toda la industria,

ni para todos los negocios. Son específicos para
una situación particular en un momento dado.
• Pueden ser medidos cuantitativa o

cualitativamente
FCE
• Existen factores:
– Internos
– Externos
– De seguimiento de operaciones
– De seguimiento de planes
FCE
• Principales fuentes (según Rockart):

– La industria
– La estrategia competitiva o posición en la
industria
– Factores del medio ambiente
– Factores temporales
– Posición administrativa
FCE
• Algunos FCE de la Industria Automotriz:
• Economía en el combustible
• Imagen
• Organización eficiente de agencias
• Control de costos de manufactura, etc.
FCE
• Se deben considerar los siguientes elementos:
• Información crítica: información necesaria

para dar seguimiento a los FCE (extraída de
otros SI, comprada, etc.)
FCE
• Supuestos críticos: Los objetivos y FCE están
basados en supuestos. Deben ser validados
constantemente. Ej. Actividades de la
competencia, inflación, etc.
• Decisiones críticas: Determinar cuáles son las

decisiones críticas que se deben hacer. Ej. ¿dar
de baja un producto?, ¿compra o desarrollo?,
máximo riesgo aceptable.
FCE
Fase 1. Formación de un equipo de trabajo

– Pocos recursos
– Reconocimiento y posibilidad de comunicación con
la alta dirección
– Conocimiento de la industria, sus problemas,
puntos clave, etc.
– Entender la empresa, y su posicionamiento,
estructura, cultura y política, posición competitiva.
FCE
Fase 2. El equipo se prepara para el estudio

– Estudiar la metodología
– Estudiar la técnica de entrevistas seleccionada
– Familiarizarse sobre la situación de la empresa y
su entorno
Metodología para generar FCE
Fase 3. Sesión introductoria con la alta
administración, para:
– Obtener apoyo
– Obtener lista de personas a entrevistar en la
siguiente fase
– Obtener un primer nivel de FCE, problemas,
oportunidades, etc...de todo el negocio, no sólo
de informática.
FCE
• ¿Cuáles son las cosas que ud. ve como FCE en su
trabajo?
• ¿Cuál es el área que más le perjudicaría si fallase?,

¿Dónde le molestaría más que se fallase?
• Si lo aislaran del negocio 3 semanas, ¿sobre qué sería

lo primero que quisiera que lo enterarán en relación
al negocio?
FCE
Fase 4. Sintetizar el resultado de las entrevistas
– Sintetizar los resultados, combinando respuestas,

eliminando duplicidades y priorizando (como un
primer resultado).
FCE
Fase 5. Reunión de enfoque del equipo

directivo (paso clave):
– El equipo se reúne con los ejecutivos
– Los ejecutivos determinarán los FCE de acuerdo a la
información recolectada
– Mejores resultados si la reunión es con participación
abierta
Rúbrica
• Una rúbrica es un elemento que nos permite

definir en forma tabular los requisitos que debe
tener un producto en general y evaluarlos en
base a un criterio determinado.
Ejemplo de Rúbrica
Tarea
• Definir una rúbrica para evaluar una clase de
videojuegos, definir al menos 5 características,
ubicar porcentajes a cada una.
• Evaluar al menos tres videojuegos. Distribuir

la rúbrica a sus demás compañeros para que
puedan evaluar.
Actividad
• Realizar un programa en Python que permita
calcular el área de un triángulo conociendo la
longitud de sus tres lados. Para ello se aplica la
fórmula:
Área  S (S  A)( S  B)( S  C)
• Donde S = (A+B+C)/2
Python
• Lenguaje creado a principios de la década de
1990 por Guido van Rossum. Actualmente es un
proyecto de Software Libre.
• Se trata de un lenguaje interpretado o de script,

con tipado dinámico, fuertemente tipado,
multiplataforma y orientado a objetos (en
realidad es multiparadigma ya que permite
programación estructurada y funcional).
Python
• Es un lenguaje muy similar a Perl y a otros
lenguajes de script disponibles en los sistemas
Unix tales como AWK, PHP, etc.
• La versión que se utilizará para este curso es la

2.5.2 del proyecto GNU para Windows, aunque
existen otras como ActivePython. Cada
implementación de Python tiene sus
características propias como iPython para
desplegar una shell más útil.
Python
• Existen varias implementaciones del lenguaje
como Jpython, IronPython y Cpython, siendo esta
última la más robusta e implementada por que
está hecha en C.
• Al ejecutar Python se muestra un shell (>>>) que

nos permite interpretar comandos del lenguaje o
correr aplicaciones.
Python
• En la shell se pueden ejecutar expresiones
simples como expresiones aritméticas. Ejemplo:
• >>> 1+1
• 2
• Se puede salir del shell a través de la función

exit() o bien la combinación de teclas Ctrl + D
Python
• La shell permite trabajar de manera interactiva.
• Python genera código muy legible por lo que no

se utilizan conceptos como llaves o caracteres
raro como || ó &&, en su lugar se utilizan
palabras en inglés más claras como or ó and.
• Se recomienda utilizar IDEs como PyDEV que es

un plugin para Eclipse.
Python
• El primer programa en cualquier lenguaje de
programación es el “hola mundo”, aquí se seguirá
la tradicción:
• >>> print “Hola Mundo”

• Hola mundo
• Si se desea ejecutar este programa sin el shell, se

deberá ejecutar la instrucción: python hola.py
Para esto se asume que se escribió el código en
un editor de texto plano.
Python
• El programa se ejecutará muy rápido para
detenerlo hasta que se presione una tecla, se
deberá añadir la siguiente línea:
• raw_input()
• Si se estuviera en un Unix se puede agregar la

línea #!/usr/bin/python al inicio de cualquier
programa para “firmarlo” y así permitir que este
sea autoejecutable.
Python
• Los tipos de datos básicos son:
• Numéricos: 7 (enteros), 12.5 (flotantes) 5+3j

(complejos)
• Cadenas de Texto como “UVAQ”
• Lógicos: true y false

Python
• Aunque no es necesario declarar variables se
puede utilizar el operador type(var) para saber el
tipo de datos de una variable.
• Los tipos de datos enteros pueden ser int y long.
Como internamente Python se maneja en C, la
longitud de los tipos de datos es la misma que en
las implementaciones de C. Por lo que se utilizan
las mismas convenciones (prefijo L al final de un
número para indicar que es long, iniciar con un 0
indica que es octal, si inicia con 0x es
hexadecimal).
Python
• Los operadores aritméticos son los clásicos de todo
lenguaje, incluyendo: ** para potencia, // para división
entera, % para módulo.
• También existen operadores a nivel de bits como el &

(and), | (or), ~ (not), ^ (xor), << y >> para corrimientos a
la izquierda y a la derecha.
• Actividad: realizar un programa que dado dos números

permita saber si un número es par o impar, hacerlo a
través de operadores de bits.
Python
• Actividad: Realizar otro programa que permita
determinar la multiplicación y la división de un
número entero por dos. Se debe de hacer con
operadores de bits.

determinar si un número tiene paridad par o
impar, considerar todos los bits menos el más
significativo, el cual deberá contener un 0 si es
paridad par o un 1 si es paridad impar.
Python
• Los comentarios se ponen a través del carácter #
• Las cadenas puede utilizar comillas dobles “” o

comillas simples ‘’
• Se pueden utilizar caracteres especiales como \n,

\t, entre otros, que son comunes a C. Se puede
utilizar el operador + para concatenar cadenas.
Python
• Tarea: traer una computadora con Linux (unix) en
cualquiera de sus variantes: LiveCD (usb distro),
máquina virtual, instalación física, emulador de
Linux, etc. Que permita la realización de scripts y
tenga instalado el compilador gcc y python.
• Es necesario el manejo de este entorno para los

problemas de esta clase y tareas.
Python
• Los valores de tipo lógicos o bool, se llaman true
y false.
• Los operadores lógicos son and, or y not. El

operador de comparación es ==. Los otros
operadores relacionales son !=, <, >, <= y >=.
• Una de las características fundamentales de

Python es su manejo avanzado de tipos de datos,
entre ellos se encuentran las listas.
Python
• Las listas (colecciones) pueden manejar
elementos de cualquier tipo. Un ejemplo es:
• L = [1, 2.5, “UVAQ”, true]

• print l[1]
• Una propiedad importante es el particionamiento

(slicing) el cual permite acceder a un rango de
elementos o crear una sublista del tipo:
• Inicio:fin:incremento
Python
• Las tuplas son similares a las lista salvo que tienen
menos opciones y consumen menos memoria. Se
declaran separando los elementos por comas:
• t = 1, 2.3, “hola”
• type(t)
• Los diccionarios son útiles para almacenar pares

de indice-contenido. Por ejemplo peliculas =
{“odisea espacial”:”kubrick”, “jurasic park”:
“Spilberg”}
Python
• peliculas[“jurasik park”] devolvería “Spilberg”
• La estrustura condicional if tiene la siguiente

sintaxis:
• if (condicionAEvaluar):
• acciones cuando es verdadero
• else:
• acciones cuando es falos
Python
• Se puede utilizar la palabra clave elif (condicion):
para anidar else.
• También existe la condicional de una sóla línea: A

if B else C
• V = “par” if (n%2==0) else v=“impar”
• Existe el ciclo precondicional:

• while (condicion):
Python
• Las funciones se definen de la siguiente forma
• def nombre(param1, param2):

• acciones
• Existe el concepto de datos inmutables que no

pueden cambiar después de la ejecución de la
función (similar al concepto de variable local y
global, o bien parámetros por valor y por
referencia).
Python
• La función int(), convierte una cadena a número y
la función str() convierte un número a cadena.
• La función raw_input(cad) nos permite introducir

datos desde consola y color el prompt con la
cadena cad.
• Los ciclos for … in ..:, permiten acceder a los

elementos de una colección.
Python
• #Imprime todos los elementos de la lista l
• for e in l
• print e
Python
• Trabajos:
• Calcular el tiempo de vuelo entre dos horarios

suponiendo que no tarda más de 24 horas. El
tiempo se dará en el formato de hh:mm:tt, donde
hh va de 0 a 12, m de 0 a 59, y tt puede ser am o
pm. Se deben validar los dos horarios
Python
• Dadas dos listas A y B, dejar en la lista A los
valores impares y en la B los valores pares. Pedir
los valores de la lista al usuario.
• Leer N números y calcular los siguientes

estadísticos: media, moda, mediana y desviación
estándar.
Python
• Realizar un programa quedado un número de bits
determine el número de KB (Kilo Bytes), MB y GB.
Un byte son 8 bits. Un KB son 1024 bytes, un MB
son 1024 KB, un GB son 1024 MB.
• Por ejemplo si el usuario introduce la cantidad:
12,896,521 bits el programa debe devolver:
– 1,612,065 (1612065.18) bytes
– 1574.28 KB
– 1 1.53 MB
– 0.0015 GB
Desarrollo de Prototipos
• Los prototipos son una excelente
herramienta para la obtención de
requerimientos dado que el cliente puede
ver elementos funcionales en operación del
proyecto.
• El problema es que es una técnica muy

costosa, motivo por el cual su utilización está
muy restringida.
Diseño de Prototipos
• Champcart
• Motor: Turbocargado, 2.65 litros V-8

• Caja de velocidad: Manual con 6 o 7
velocidades delanteras
• LLantas: Bridgestone.
• Peso mínimo: 1,565 libras
• Formula1
• Motor: Aspirado, 3 litros (183 cubic inches) V10

Turbocarga está prohibido.
• Caja de velocidad: Semiautomática de 6 o 7
velocidades delanteras
• Llantas: sin marca
• Peso mínimo: 1,322.77 libras con conductor
Diseño de Componentes
• Chasis básico: $450,000.
• Motor: no se venden de manera individual
• Llantas: 28 llantas por evento con un costo de

$1,200 por juego, alrededor de $150,000 al año
• Costo equipo: 50 personas

• Otras partes: $150,000 de refacciones y

$350,000 de partes de la caja de velocidades.
• Costo transporte: $500,000 al año de

transporte.
• Total: mínimo 2 millones, en promedio de 5-10

millones de dólares
Tarea
• Para el Lunes:
• Traer 5 hojas de rotafolio por equipos. Los

equipos serán de tres personas como máximo.
• Traer hojas tamaño carta, bolígrafos y plumones.

Actividad
• En equipos de 2 Personas se deberá crear un
prototipo de avión de papel el cual deberá ser
aquel que en las pruebas de ensayo llegue más
lejos.
• Ganará el equipo que con el recurso disponible

y las restricciones de tiempo realice bien cada
uno de los pasos indicados en la actividad.
Actividad
• Paso 1: Poner nombre a los equipos.
• Paso 2: Escoger un líder de proyecto.
• Paso 3: Diferenciar roles entre los equipos de

trabajo: diseñador, probador, constructor, etc.
(Paso 1 a 3: 10%)
Actividad
• Paso 4: Elaborar especificación de prototipo

(50%).
• En este caso se debe tener un diseño claro que

permita la construcción a gran escala del mismo.
• Cada equipo es responsable de su material, todos

los equipos cuentan con igual recurso.
Actividad
• Paso 5: Personalizar su prototipo con algún
detalle y mostrar las mejoras realizadas (la
presentación se hace hasta el final) (10%)
• Paso 6: Construcción y elaboración del

prototipo a gran escala (20%).
Actividad
• Paso 7: Se escogerán una muestra aleatoria de
dos aviones para la realización de la
comprobación de la calidad (10%).
• ¿Qué se aprendió con la práctica de hoy?
441
• Los prototipos son versiones reducidas,
demos o conjunto de pantallas (que no son
totalmente operativos) de la aplicación
pedida.
• Esta técnica es útil cuando:
1. El área de aplicación no está bien definida

(puede ser algo novedoso)
2. El costo del rechazo de la aplicación es muy
alto.
3. Es necesario evaluar primeramente el impacto

del sistema en la organización.
• La técnica ayuda para visualizar la diferencia

entre desarrolladores y usuarios.
• Aunque limitado, se dispone de un sistema
funcional en las primeras etapas de desarrollo.
• Esta técnica se resume en: “No sé

exactamente lo que quiero, pero lo sabré
cuando lo vea”
• Es una técnica costosa

Casos de Uso
• Otra forma de obtener requerimientos es a
través de diagramas de casos de uso dentro de
UML
• Se recomienda utilizar diagramas de caso de

uso ya que nos dan los macrorequisitos de la
aplicación. Cada caso de uso debe ser
especificado de manera correcta.
UML
• UML (Unified Modelling Language), lenguaje
de modelado unificado. Fue desarrollado en
1997 al fusionar las metodologías de Ivar
Jacobson, Jame Rumbaugh y Grady Booch.
• Es un lenguaje visual, su premisa básica radica

en que una imagen vale más que 1,000 líneas
de código.
UML
• Al ser UML un lenguaje posee gramáticas y
alfabetos que definen como deben de
estructurarse cada una de las palabras válidas
del lenguaje.
• Un modelo es una representación de la

realidad. No sólo se modela software sino
prácticamente cualquier actividad.
UML
• Es el lenguaje estándar para modelar proyectos
de software.
• La versión más actual del lenguaje es la 2.1
• Los métodos que se fusionaron para crear UML

fueron OMT (Rumbaugh), Objectory (Jacobson)
y el método Booch.
¿Por qué modelar?
• Casi el 80% de los proyectos de software
fallan.
• Nadie construye una casa sin un plano.
• Actualmente existen muchas herramientas

que auxilian el proceso de modelado como
Visio, ArgoUML, Rational Rose, Together, etc.
Modelos
• Los modelos deben ser más baratos que la
realidad.
• Es más fácil para una persona entender un

diagrama que las líneas de código fuente de
un programa.
• Los diagramas al igual que el texto consumen

tiempo.
Modelos
• Se deben construir modelos que sean
representativos para que sean útiles
(imaginense hacer un documento de 100
hojas que nadie va a leeer)
• UML define varios tipos de diagramas los

cuales pueden ser extensibles.
Métodos Orientado a Objetos
• UML tiene 5 diferentes vistas con diferentes
diagramas en cada una de ellas.
• Vista usuario: representa el sistema

(producto) desde la perspectiva del usuario.
Se suele utilizar diagramas de casos de uso.
• Vista estructural: modela los datos y la
funcionalidad del sistema; es decir, la estructura
estática (clases, objetos y relaciones).
• Vista de implementación: Los aspectos

estructurales y de comportamiento se
representan aquí tal y como van a ser
implementados.
• Vista del comportamiento: representa los
aspectos dinámicos o de comportamiento del
sistema. También muestra las interacciones o
colaboraciones entre los diversos elementos
estructurales descritos en vistas anteriores.
• Vista del entorno: aspectos estructurales de
comportamiento en el que el sistema a
implementar se representa (diagramas de
componentes y despliegue).
Tipos de diagramas
• Los diagramas más utilizados en UML son:
• Diagramas de casos de uso

• Diagramas de actividades
• Diagramas de clases
• Diagramas de interacción
– Diagramas de secuencia
– Diagramas de colaboración
Tipos de diagramas
• Diagramas de estado
• Diagramas de componentes
• Otros diagramas
– Diagrama de topología del despliegue
• Los diagramas deben de reflejar lo que se

pretende modelar
Diagramas de casos de uso
• Son responsables de documentar los
macrorequisitos del sistema.
• Lista de capacidades que debe brindar el

sistema.
• Los elementos principales son los actores y los

casos de usos que en conjunto forman un
escenarios.
• Se deben establecer prioridades para las
capacidades del sistema.
• ¿Cuál es la diferencia entre un editor de textos

como Notepad y Word?
• Objetivos primarios: crear, guardar e imprimir

documentos de texto.
Diagramas de caso de uso
• Objetivos secundarios: guardar el archivo en
formato HTML, RTF y PDF.
• Los diagramas de uso sirven para mostrar

detalles de implementación del sistema a
usuarios finales.
• Los conectores asocian a los actores y los

casos de uso.
• Las líneas continuas representan una
asociación y las puntuadas dependencias.
• Si el conector tiene un triangulo hueco en la

punta representa una generalización que es
una relación de herencia.
• Los estereotipos agregan detalles a una

relación.
• Los estereotipos más utilizados son: inclusión y
de extensión.
• Muchas herramientas no implantan UML al

100% existen muchos problemas de
compatibilidad entre dichas herramientas. XMI
es la descripción de un diagrama UML en XML el
cual utilizan varias herramientas para exportar
diagramas.
• Incluir implica una dependecia de utilización
de un caso de uso.
• Las notas ayudan ha aclarar los diagramas.
• Extender da más detalle de dependecia de un

caso de uso al cual se le agregan más
capacidades.
• Las notas deben ser como elementos
taquigráficos.
• Se deben incluir la siguiente documentación:

párrafo que describa el caso de uso, párrafo
que describa cada una de las funciones
primarias y secundarias, entre otros.
• Se deben detallar ejemplos de la utilización de
casos de uso.
• Los actores pueden ser usuarios o partes del

sistema.
• En general los primeros diagramas que se

deben construir son los casos de uso
Preguntas frecuentes
• ¿Cuántos diagramas debo crear? No existe
una respuesta específica.
• ¿Debo hacer diagramas de todo tipo? No, sólo

se deben utilizar los diagramas que mejor
reflejen el modelado de la problemáticaoe
Preguntas frecuentes
• ¿Qué tan grande debe de ser un diagrama?
Entre más grande sea un diagrama mayor es la
confusión. Se deben realizar diagramas bien
detallados, pero no tan detallados.
• ¿Cuánto texto debe complementar el modelo?

Entre menos texto mejor, son como los
comentarios del código fuente: pocos pero
claros.
Modelado de software
• Algunas recomendaciones para el modelado de

software son:
• No tenga a los programadores esperando los

modelos.
• Trabajar de una macrovista a una

microvista(enfoque Top-Down).
Modelado de software
• Se debe documentar en forma económica.
• Si es obvio no se debe de modelar.
• Hacer hincapié en la especialización.
• Utilizar patrones de diseño.
• Refactorizar.
Actividad
• Desarrollar los diagramas de casos de uso del
proyecto.
• Especificar cada escenario de manera

completa (30%)
• Explotar los diagramas de casos de uso por lo

472
menos un nivel (70%)
Otras Técnicas
• La Ingeniería de Requerimientos comprende
las actividades de obtención (captura,
descubrimiento y adquisición), análisis
(negociación), especificación y validación de
requerimientos.
• También establece la gestión para manejar

cambios, mantenimiento y seguimiento de los
requerimientos.
JAD
• Joint Application Development, Desarrollo
Conjunto de Aplicaciones es una técnica que
consiste en realizar sesiones conjuntas entre los
analistas de sistemas y los expertos del dominio.
• Con esta técnica se obtienen sistemas más

enfocados a la realidad, muchas metodologías
nuevas se fundamentan en esta premisa.
JAD
• ¿Por qué JAD funciona?
• Por que las entrevistas son lentas, difíciles de hacer y

complicadas de obtener datos.
• Al ser muchos revisores del proyecto es más fácil

detectar errores.
• Problema: se requiere de mucha organización

ETHICS
• Implementación Efectiva de Sistemas

Informáticos desde los puntos de vista Humano
y Técnico.
• Fue desarrollada en 1979 por E. Mumford, se

enfoca en los aspectos sociales que están
presentes en el desarrollo del software, dado
que un sistema no tendrá éxito sino es utilizado
eficientemente por los empleados.
Puntos de vista
• Todos los sistemas ocupan de un grupo de
usuarios interesados (stakeholders), cada uno
puede tener intereses diferentes, incluso en
muchas casos contradictorios.
• Existen métodos que toman los puntos de vistas

de los usuarios para encontrar cosas en común,
un ejemplo es VORD (Definición de
Requerimientos Orientados a Puntos de Vista).
Puntos de vista
• VORD consiste de los siguientes pasos:
• Identificación de puntos de vista

• Estructuración de dichos puntos de vista
• Documentación de puntos de vista
(refinación)
• Trazado del punto de vista (conversión a un
diseño orientado a objetos)
Etnografía
• Es una técnica de observación que se puede utilizar
para entender los requerimientos sociales y
organizacionales. Se centra en los siguientes aspectos:
• La forma en la que las personas trabajan y no como el

sistema los hace trabajar
• Los requerimientos se derivan de la cooperación de

muchas personas
Tips para la obtención de
requerimientos
• Aprender de todos los documentos,
formularios, informes y archivos existentes.
• De ser posible se observará el sistema en

acción. Se tomarán notas y dibujos. Conviene
que las personas no sepan que están siendo
evaluadas.
Tips para la obtención de
requerimientos
• Realizar entrevistas o sesiones de trabajo en
grupo para refinar los requisitos de la
aplicación.
• Es necesario verificar los requerimientos

nuevamente hasta estar seguros
Referencias
• Guido, J. y Clements, J., “Administración

Exitosa de Proyectos”, Segunda Edición,
Thomson, México, 2003, ISBN: 0-324-07168-X.
¿Preguntas, dudas y comentarios?

Ingeniería de Proyectos: Guía Completa

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería de Proyectos: Guía Completa

Cargado por

Copyright:

Formatos disponibles

Ingeniería de Proyectos

M.C. Juan Carlos Olivares Rojas

copiar, distribuir y comunicar públicamente la

• Bajo las condiciones siguientes:

Reconocimiento. Debe reconocer y dar crédito al

• El término proyecto implica una actividad

• ¿Cuál es la diferencia con respecto a un algoritmo?

• Que la metodología se utiliza para resolver diversos

• Eficiencia hacer más con menos.

• En proyectos existe un trade-off entre lo que

• Una meta es una métrica para cuantificar el

• Un objetivo es en general y una métrica en

• Para lograr la realización de un proyecto es muy

• Investigación pura o básica: su finalidad es la

• Investigación aplicada: su finalidad es utilizar el

• Desarrollo tecnológico: su finalidad es el desarrollo de

• Investigación documental: aquella que se basa

• Investigación de campo: aquella que se realiza en el

• Investigación cuantitativa: aquella cuyas

• ¿Qué diferencia existe entre una Carpeta de

• Diariamente se deberá hacer un registro para

• Deseos de explotar nuevas necesidades

• Hacer más efectivo el uso de la información

• Unión o adquisición corporativa

• Cambios en el ambiente o en el mercado

• Los proyectos se originas de inventos, los cuales

• Aun no se conoce el substituto de una buena

• Las ideas constituyen el primer acercamiento, a

• Los materiales escritos (libros, periódicos,

• Las conversaciones personales y las

• Las creencias y aún los presentimientos.

• Al charlar con otras personas

• Al recordar algo vivido, etc.

• Las ideas surgen en ocasiones de problemas y

• Una necesidad es vital. Un problema no.

• Se necesita de 1% de inspiración y 99% de

• En el caso de proyectos empresariales se debe

• No reinventar la rueda. Salvo que sea más

• Temas ya investigados pero menos

• Temas pocos investigados y estructurados.

• Satisfacción del Cliente 27

• Del grado de familiaridad de los

• La complejidad del mismo.

• Realizar una lluvia de ideas (Brainstorm) para

• De las ideas obtenidas seleccionar tres ideas

• Revisar las ideas anteriores y el material 29

adicional y escoger una sola idea (70%).

• El proceso de resolución de problemas tiene

• Otros autores han agregado dos más fases:

• Para problemas más complejos se puede

• Otra técnica compleja es el Proceso Delphi, la

– se envía el segundo cuestionario en el que

1.Leer y analizar el problema

• Fecha de entrega: Lunes 18 de junio de 2008.

• La empresa de consultoría Gartner define una

• En esta presentación se muestran las gráficas del

• Disparo de tecnologías (continuación):

• Pico de expectaciones infladas

• iPolipo: resuelve el problema de agendar

• MOG: sistema que con autorización del usuario,

• Startforce: Sistema Operativo desde la Web.

• Payscale: los usuarios pueden definir posiciones

• SIBEAM: red inalámbrica multi gigabit de 60