Proyectos Informticos

1
Proyectos Informáticos

• M.C. Juan Carlos Olivares Rojas

2
Agenda

• 1.1 Introducción
• 1.2 Elementos para identificar posibles proyectos
• 1.3 Métodos y etapas del Desarrollo de Proyectos
• 1.4 Ingeniería de requerimientos

3
1.1 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.

4
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

5
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.

7
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

8
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.

9
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.

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

11
Tarea

• Asignar una carpeta especial para el proyecto, la
  cual deberá contener una portada. En dicha
  carpeta estarán todas las actividades realizadas
  del proyecto y se deberá traer diario.
• Utilizar un CD/DVD regrabable o con sesión
  abierta para guardar cambios en la Carpeta
  Electrónica.

12
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
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.

14
1.2 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

15
Necesidades

• Consumismo
•  
• Crisis Educativas
•  
• Ambientalismo
•  
• Calidad
•  
• Globalización
•  
• Regularizaciones

Investigación sobre Calidad del Software y
Fábricas de Software
16
Á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

17
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
  la realidad que habrá de investigarse.

18
Fuente de Ideas

• Las experiencias individuales
• Los materiales escritos (libros, periódicos,
  revistas y tesis)
• Las conversaciones personales y las observaciones
  de hechos
• Las creencias y aún los presentimientos.

19
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
• Al recordar algo vivido, etc.

20
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.

21
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.

22
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)

23
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.

24
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.
• Temas no investigados.

25
Factores que restringen el éxito de un Proyecto

• Alcance
• Costo
• Programa
• Satisfacción del Cliente

26
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.
• La existencia de estudios previos.

27
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
  adicional y escoger una sola idea (10).

28
Actividad

• Realizar el marco teórico del tema seleccionado
  (sugerencia utilizar metodología PBL) (60)
• Leer y analizar el problema
• Enumerar hipótesis, ideas y presentimientos
• Anotar los factores conocidos

29
Actividad

• Anotar los factores desconocidos
• Planifique la investigación
• Emita una declaración del problema.
• Adquirir información (investigación).
• Presentar el resultado de la investigación
  (solución).
• Duración 30 minutos

30
Actividad

• Realizar el estado del arte del proyecto.
  Entregar tabla comparativa (50) y descripción de
  los trabajos relacionados (50).
• Fecha de entrega Lunes 9 de junio de 2008, en el
  salón de clases, 1000 hrs.

31
Anexos

• Ideas para definir Ideas

32
Avances en Ciencias de la Computación 2008

• M.C. Juan Carlos Olivares Rojas

33
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

34
Introducción

• La curva del hiperciclo tiene los siguientes
  elementos
• Disparo de la tecnología
• Pico de expectaciones infladas
• Desilusión
• Grado de encantamiento
• Productividad plena

35
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)

36
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

37
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

38
Hiperciclo 2006

• Encantamiento
• Tecnologías de manejo de contenido
• ERP
• Outsourcing de infraestructura de TI

39
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

40
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

41
Hiperciclo 2012

• Pico de expectaciones infladas
• Folksonomías
• Papel digital
• Análisis de redes sociales
• Desilusión
• RFID
• Grid Computing
• Ajax

42
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

43
Hiperciclo 2012

• Encantamiento
• Aplicaciones basadas en localización
• Smartphone
• Productividad
• VoIP
• Internal Web Services

44
Bibliografía

• Enciso, Enrique (2007). Tendencias y
  Predicciones Tecnológicas y Sociales, Revista
  RED, Junio, pp. 21-27.

45
Innovación en TI

• M.C. Juan Carlos Olivares Rojas

46
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/

47
Empreas TI

• 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/

48
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/

49
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/

50
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/

51
Referencias

• Enciso, Enrique. Innovación clave para
  permanecer en el juego (2007). Revista Software
  Red, Septiembre de 2007, pp. 13.

52
Líneas de Investigación 2008

• M.C. Juan Carlos Olivares Rojas

53
Agenda
Áreas de Interés
Líneas de Investigación
Trabajos actuales
Propuestas de Trabajos
54
Áreas de Interés

• Sistemas Distribuidos
• Cómputo móvil
• Tecnologías Web
• Redes inalámbricas
• Bases de Datos

55
Líneas de Investigación

• 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 Compact
  Framework y J2ME

No necesariamente van en orden de interés
56
Líneas de Investigación

• Sistemas de intermediarios (proxys, middleware)
• Sistemas Distribuidos Inteligentes (Agentes
  Móviles)
• Transcodificación multiformato y Acaparamiento
  para dispositivos Móviles.

57
Líneas de Investigación

• 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.

58
Líneas de Investigación

• 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
• Virtualización

59
Líneas de Investigació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.

60
Líneas de Investigación

• Cómputo móvil en la educación
• Multimedia en dispositivos de cómputo limitado

61
Trabajos actuales

• PaqWebCel Paquete para Desplegar Publicidad en
  Terminales Móviles Celulares (CITEDI)
• Sistema de publicidad para comercio electrónico
  móvil (m-commerce) (ITM)
• Desarrollo de estrategias para desplegar
  publicidad en dispositivos móviles (multimedia,
  geoposicionamiento, seguridad y privacidad).

62
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-Controla
  dor) para el Desarrollo de Aplicaciones en
  Dispositivos Móviles (ITM)
• Estudio y Aplicación de Patrones Arquitectónicos
  en la Construcción de Software para Dispositivos
  Móviles

63
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)
• Nuevas Técnicas de DSS.

64
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)
• Plataforma educativa utilizando tecnologías Web
  2.0 (ITM).

65
Trabajos actuales

• Seguridad en Dispositivos Móviles utilizando RSA
  (UVAQ)
• Redes en Malla (802.11s)
• Redes 3G en México Aplicaciones y Servicios
• Redes Inalámbricas de Banda Ancha WiMax y 802.20
  (WiBro)

66
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

67
Propuestas de Trabajos

• 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 operaciones en
  modo desconexión para J2ME

68
Propuestas de Trabajos

• Editor de páginas Web accesibles para
  dispositivos móviles
• Comunicación entre procesos IPC en máquinas
  virtuales
• Algoritmo de enrutamiento para dispositivos
  móviles utilizando técnicas de agrupamiento y
  distancias cortas

69
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
  descentraliza.

70
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.

71
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
  requerimientos (checklist).

72
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.

73
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.

74
Calidad de Software
75
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.

76
Construcción de una casa para wendo
Puede hacerlo una sola persona Requiere Modelado
mínimo Proceso simple Herramientas simples
77
Construcción de una casa
Construida eficientemente y en un tiempo
razonable por un equipo Requiere Modelado Proc
eso bien definido Herramientas más sofisticadas
78
Construcción de un rascacielos
No cualquier persona o grupo de persona lo
realiza. Imposible sin técnicas de Ingeniería
79
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.

80
1.3 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.

81
Etapas para el desarrollo de un 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.

82
Etapas para el desarrollo de un 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.

83
Etapas para el desarrollo de un 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.

84
Etapas para el desarrollo de un 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.

85
Ciclo de Vida de un Proyecto

• Identificar una necesidad
• Desarrollar una propuesta de solución
• Realizar el proyecto
• Terminar el proyecto

86
Ciclo de Vida de un Proyecto

• 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.

87
Ciclo de Vida de un Proyecto

• 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

88
Verdadero Ciclo de Vida del Desarrollo de un
Proyecto

• M.C. Juan Carlos Olivares Rojas

89
Primera fase
90
Segunda fase
91
Tercera fase
92
Cuarta fase
93
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.

94
Metodologías de Desarrollo de 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

95
Metodologías de Desarrollo de Software

• Especificación
• Desarrollo
• Evaluación
• Evolución
• El desarrollo de software se basa en modelos,
  siendo los más representativos

96
Metodologías de Desarrollo de Software

• Cascada (clásico)
• Construcción de prototipos
• Espiral
• RAD (Desarrollo rápido de aplicaciones)
• Cada uno de estos modelos tiene sus respectivas
  fases que pueden ser muy similares entre sí.

97
Modelos de Ciclo de Vida
Cascada
98
Modelo Ciclo de Vida en Cascada Actual

• Comunicación
• Inicio del Proyecto
• Recopilación de Requerimientos
• Planeación
• Estimación
• Itinerario
• Seguimiento

99
Modelo de Ciclo de Vida en Cascada Actual

• Modelado
• Análisis
• Diseño
• Construcción
• Código
• Prueba

100
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.

101
Modelo Iterativos
102
Modelo en Espiral
103
Actividad

• Investigar dos metodologías de desarrollo de
  software por cada persona
• MOPROSOFT
• Open UP (RUP)
• CMMI

104
Actividad

• Six Sigma
• TSP/PSP
• Métodos Ágiles (XP eXtreme Programming)
• MSF
• ITIL

105
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
  proyecto a desarrollar (20).

106
Rúbrica de Presentaciones

• Vestimenta formal 10
• Material de Entrega 10
• Contenido de la presentación 70
• Presentación fluida sin lectura 20

107
Radiografía de la Industria del Software en México

• Por qué son importantes las metodologías de
  desarrollo de software?

108
Tipos de Organización
109
Esquema de Contratación
110
Edad
111
Escolaridad
112
Género
113
Antigüedad
114
Salarios
115
Salarios
116
Salarios
117
Salario Internacional
118
Salario Tipo de Organización
119
Salario por Función
120
Salario por Rango Edad
121
Salario Grado de Estudios
122
Conocimiento y Habilidades
123
Conocimiento y Habilidades
124
Plataformas
125
BD
126
Otras habilidades
127
Certificaciones
128
Certificaciones
129
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.

130
1.4 Ingeniería de 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).

131
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

132
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.

133
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.

134
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.

135
(No Transcript)
136
Diferentes Vistas
137
Diferentes Vistas
138
Diferentes Vistas
139
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.

140
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.

141
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ño20,
  Aplicación80)

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

143
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, entrega viernes 13).
• En metodologías ágiles el cliente participa de
  manera activa en el desarrollo del sistema.

144
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.

145
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

146
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.

147
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.

148
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.

149
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 10 requisitos evaluados.

150
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.

151
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

152
FCE

• Existen factores
• Internos
• Externos
• De seguimiento de operaciones
• De seguimiento de planes

153
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

154
FCE

• Algunos FCE de la Industria Automotriz
• Economía en el combustible
• Imagen
• Organización eficiente de agencias
• Control de costos de manufactura, etc.

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

156
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.

157
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.

158
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

159
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.

160
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?

161
FCE

• Fase 4. Sintetizar el resultado de las
  entrevistas
• Sintetizar los resultados, combinando respuestas,
  eliminando duplicidades y priorizando (como un
  primer resultado).

162
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

163
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.

164
Diseño de Prototipos
165
Diseño de Prototipos
166
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

167
Diseño de Prototipos

• 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

168
Diseño de Prototipos
169
Diseño de Componentes
170
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

171
Diseño de Componentes

• 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

172
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.

173
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)

174
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.

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

176
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?

177
Desarrollo de Prototipos

• 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
• El área de aplicación no está bien definida
  (puede ser algo novedoso)

178
Desarrollo de Prototipos

• El costo del rechazo de la aplicación es muy
  alto.
• Es necesario evaluar primeramente el impacto del
  sistema en la organización.
• La técnica ayuda para visualizar la diferencia
  entre desarrolladores y usuarios.

179
Desarrollo de Prototipos

• 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

180
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.

181
Ejemplo de Rúbrica
182
Actividad

• 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.

183
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.

184
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.

185
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.

186
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.

187
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.

188
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.

189
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.

190
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.

191
Métodos Orientado a Objetos

• 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.

192
Métodos Orientado a Objetos

• 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.

193
Métodos Orientado a Objetos

• Vista del entorno aspectos estructurales de
  comportamiento en el que el sistema a implementar
  se representa (diagramas de componentes y
  despliegue).

194
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

195
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

196
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.

197
Diagramas de casos de uso

• 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.

198
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.

199
Diagramas de caso 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.

200
Diagramas de caso de uso

• 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.

201
Diagramas de caso de uso

• 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.

202
Diagramas de caso de uso

• 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.

203
Diagramas de casos de uso

• 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

204
Diagramas de casos de uso
205
Diagramas de casos de uso
206
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ática

207
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.

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

209
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.

210
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
  menos un nivel (70)

211
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.

212
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.

213
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

214
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.

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

216
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)

217
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

218
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.

219
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

220
Preguntas, dudas y comentarios?