Download
1 / 98
E N D
1. 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). 5
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. 11
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? 12
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. 13
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 Se refiere a cambios en la distribución de grupos humanos dentro de una entidad.
Se refiere a la necesidad de atender a segmentos de usuarios muy específicos y donde se requieren de productos y servicios adecuados.
Es la necesidad de llegar a acuerdos, uniones, alianzas o adquisiciones que modifican el estado de una empresa.
Se refiere a la presión por contener y reducir gastos.
Se refiere a cambios en la distribución de grupos humanos dentro de una entidad.
Se refiere a la necesidad de atender a segmentos de usuarios muy específicos y donde se requieren de productos y servicios adecuados.
Es la necesidad de llegar a acuerdos, uniones, alianzas o adquisiciones que modifican el estado de una empresa.
Se refiere a la presión por contener y reducir gastos.
15. Necesidades Consumismo
Crisis Educativas
Ambientalismo
Calidad*
Globalización
Regularizaciones es la necesidad de reaccionar a la demanda y seleccionar a sus consumidores.
Es la necesidad de trabajar con empleados quienes cuentan con un desintegrado sistema educacional.
Es la necesidad para reaccionar a los cambios del medio, así como el crecimiento que este genera.
Se refiere al mejoramiento del producto final.
Se refiere a la necesidad de tener mayor cobertura.
.- Se refiere a cambios dentro del ambiente provocados por acciones gubernamentales. Por ej. Las leyes y los impuestos.
es la necesidad de reaccionar a la demanda y seleccionar a sus consumidores.
Es la necesidad de trabajar con empleados quienes cuentan con un desintegrado sistema educacional.
Es la necesidad para reaccionar a los cambios del medio, así como el crecimiento que este genera.
Se refiere al mejoramiento del producto final.
Se refiere a la necesidad de tener mayor cobertura.
.- Se refiere a cambios dentro del ambiente provocados por acciones gubernamentales. Por ej. Las leyes y los impuestos.
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 Errores, ineficiencias, retardos, deseos de algún incremento, reducción de gastos, etc.
Nuevos mercados, nueva producción, mas formas de obtener venta competitiva, uso de sistemas de información.
Nuevas características en los competidores, mejorar un servicio o un producto.
Nueva información, mejor aprovechamiento, rapidez, mejores decisiones.
Crecimiento en las empresas, mas necesidades.
Consolidación de sistemas y procesos, requerimientos, reducir actividades redundantes.
Clientes, proveedores, leyes y regulaciones, clima.Errores, ineficiencias, retardos, deseos de algún incremento, reducción de gastos, etc.
Nuevos mercados, nueva producción, mas formas de obtener venta competitiva, uso de sistemas de información.
Nuevas características en los competidores, mejorar un servicio o un producto.
Nueva información, mejor aprovechamiento, rapidez, mejores decisiones.
Crecimiento en las empresas, mas necesidades.
Consolidación de sistemas y procesos, requerimientos, reducir actividades redundantes.
Clientes, proveedores, leyes y regulaciones, clima.
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. 17
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. 18
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. 19
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. 20
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.
21
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) 22
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. 23
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. 24
25. Factores que restringen el éxito de un Proyecto Alcance
Costo
Programa
Satisfacción del Cliente 25
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. 26
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%). 27
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 28
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 29
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, 10:00 hrs. 30
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/ 47
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 Se debe dar una cordial bienvenida, introduciendo el tiempo.Se debe dar una cordial bienvenida, introduciendo el tiempo.
53. 53 Agenda El objetivo de este trabajo es utilizar las recomendaciones para el diseño accesible de páginas Web y aplicarlas para la correcta visualización de recursos Web en dispositivos móviles. Se realizó un pequeño estudio tomando en cuenta dichas consideraciones, obteniendo que es factible aplicar dichas recomendaciones o prácticas de buen diseño para su uso en dispositivos móviles. También se presenta una propuesta para solucionar el problema de la correcta visualización de páginas Web en dispositivos móviles.El objetivo de este trabajo es utilizar las recomendaciones para el diseño accesible de páginas Web y aplicarlas para la correcta visualización de recursos Web en dispositivos móviles. Se realizó un pequeño estudio tomando en cuenta dichas consideraciones, obteniendo que es factible aplicar dichas recomendaciones o prácticas de buen diseño para su uso en dispositivos móviles. También se presenta una propuesta para solucionar el problema de la correcta visualización de páginas Web en dispositivos móviles.
54. Áreas de Interés Sistemas Distribuidos
Cómputo móvil
Tecnologías Web
Redes inalámbricas
Bases de Datos 54
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 55
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. 56
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. 57
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
58
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. 59
60. Líneas de Investigación Cómputo móvil en la educación
Multimedia en dispositivos de cómputo limitado 60
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).
61
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-Controlador) 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” 62
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. 63
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). 64
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) 65
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” 66
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 67
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
68
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. 69
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. 70
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). 71
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. 72
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. 73
74. Calidad de Software 74
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. 75
76. Construcción de una casa para “wendo” Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
77. Construcción de una casa Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
78. Construcción de un rascacielos Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc.
Una lectura interesante:
Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales
About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000.
"What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay."
In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP.
"Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions."
Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."
Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc.
Una lectura interesante:
Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales
About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000.
"What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay."
In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP.
"Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions."
Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."
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. 79
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. 81
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. 82
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 85
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. 86
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* 87
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: 94
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:
95
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í.
96
97. Modelos de Ciclo de Vida 97
98. Modelo Ciclo de Vida en Cascada Actual Comunicación:
Inicio del Proyecto
Recopilación de Requerimientos
Planeación:
Estimación
Itinerario
Seguimiento 98
99. Modelo de Ciclo de Vida en Cascada Actual Modelado
Análisis
Diseño
Construcción
Código
Prueba 99
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. 100
101. Modelo Iterativos 101
102. Modelo en Espiral 102
103. Actividad Investigar dos metodologías de desarrollo de software por cada persona:
MOPROSOFT
Open UP (RUP)
CMMI 103
104. Actividad Six Sigma
TSP/PSP
Métodos Ágiles (XP eXtreme Programming)
MSF
ITIL 104 Scrum
COBIT
Balanced Score Card
Melé
Crystal
Metrica3Scrum
COBIT
Balanced Score Card
Melé
Crystal
Metrica3
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%). 105
106. Rúbrica de Presentaciones Vestimenta formal: 10%
Material de Entrega: 10%
Contenido de la presentación: 70%
Presentación fluida sin lectura: 20% 106 Material de Entrega puede ser desde las diapositivas hasta servicio de cafeteríaMaterial de Entrega puede ser desde las diapositivas hasta servicio de cafetería
107. Radiografía de la Industria del Software en México ¿Por qué son importantes las metodologías de desarrollo de software? 107
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 116
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. 129
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. 134
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ño:20%, Aplicación:80%) 141
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). 142
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. 143
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. 149 Agregar FCEAgregar FCE
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
152
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? 176
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%) 210
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. 220 ¿Preguntas, dudas y comentarios?
