Download
1 / 98
E N D
1. 1 Proyectos Informticos M.C. Juan Carlos Olivares Rojas
2. Agenda 1.1 Introduccin
1.2 Elementos para identificar posibles proyectos
1.3 Mtodos y etapas del Desarrollo de Proyectos
1.4 Ingeniera de requerimientos
3. 1.1 Introduccin Proyecto: es la integracin de una serie de procedimientos y actividades haciendo uso de una metodologa definida que permita lograr los objetivos y metas de la manera ms eficiente y efectiva.
El trmino proyecto implica una actividad futura.
4. Metodologa Metodologa: conjunto de pasos que nos conducen a resolver un problema de manera sistemtica.
Cul es la diferencia con respecto a un algoritmo?
Que la metodologa se utiliza para resolver diversos tipos de problemas. Los algoritmos son precisos, las metodologas no dejan de ser mejores prcticas
5. Metodologa Eficacia hacer las cosas bien.
Eficiencia hacer ms con menos.
En proyectos existe un trade-off entre lo que es rendimiento de una aplicacin (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 mtrica para cuantificar el logro de un objetivo.
Un objetivo es en general y una mtrica en particular.
7. Investigacin Para lograr la realizacin de un proyecto es muy importante que se lleven a cabo una serie de pasos y procedimientos de investigacin, los cuales permitirn abrir an ms las perspectivas que tenemos de dicho proyecto.
Qu es investigar?
Es indagar en bsqueda de la verdad
8. Investigacin Los tipos de investigacin son:
Investigacin pura o bsica: su finalidad es la obtencin de nuevo conocimientos. Investigacin por amor al arte.
Investigacin aplicada: su finalidad es utilizar el conocimiento obtenido en la investigacin en algn producto reutilizable.
9. Desarrollo tecnolgico Desarrollo tecnolgico: su finalidad es el desarrollo de un prototipo en el que se apliquen nuevas tecnologas y conocimientos
Investigacin documental: aquella que se basa solamente en bibliografa
Investigacin de campo: aquella que se realiza en el lugar de los hechos, que requiere experimentacin.
10. Investigacin Investigacin cualitativa: aquella en la que las variables de investigacin se evalan en base a unidades no numricas. (Investigaciones de Ciencias Sociales)
Investigacin cuantitativa: aquella cuyas variables pueden ser cuantificadas por medio de unidades tangibles (Investigaciones cientficas y tecnolgicas).
11. Tarea Asignar una carpeta especial para el proyecto, la cual deber contener una portada. En dicha carpeta estarn todas las actividades realizadas del proyecto y se deber traer diario.
Utilizar un CD/DVD regrabable o con sesin abierta para guardar cambios en la Carpeta Electrnica. 11
12. Tarea Investigar mtodos (estndares) que permitan organizar la informacin 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 da de hoy. 13
14. 1.2 Elementos para identificar posibles proyectos A continuacin se muestran algunos Motivos para desarrollar proyectos (necesidades):
Cambios demogrficos
Micromercados
Volatilidad Corporativa
Control de Costos Se refiere a cambios en la distribucin de grupos humanos dentro de una entidad.
Se refiere a la necesidad de atender a segmentos de usuarios muy especficos 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 presin por contener y reducir gastos.
Se refiere a cambios en la distribucin de grupos humanos dentro de una entidad.
Se refiere a la necesidad de atender a segmentos de usuarios muy especficos 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 presin por contener y reducir gastos.
15. Necesidades Consumismo
Crisis Educativas
Ambientalismo
Calidad*
Globalizacin
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 algn elemento actual
Deseos de explotar nuevas necesidades
Incremento de la competencia
Hacer ms efectivo el uso de la informacin
Crecimiento organizacional
Unin o adquisicin corporativa
Cambios en el ambiente o en el mercado Errores, ineficiencias, retardos, deseos de algn incremento, reduccin de gastos, etc.
Nuevos mercados, nueva produccin, mas formas de obtener venta competitiva, uso de sistemas de informacin.
Nuevas caractersticas en los competidores, mejorar un servicio o un producto.
Nueva informacin, mejor aprovechamiento, rapidez, mejores decisiones.
Crecimiento en las empresas, mas necesidades.
Consolidacin de sistemas y procesos, requerimientos, reducir actividades redundantes.
Clientes, proveedores, leyes y regulaciones, clima.Errores, ineficiencias, retardos, deseos de algn incremento, reduccin de gastos, etc.
Nuevos mercados, nueva produccin, mas formas de obtener venta competitiva, uso de sistemas de informacin.
Nuevas caractersticas en los competidores, mejorar un servicio o un producto.
Nueva informacin, mejor aprovechamiento, rapidez, mejores decisiones.
Crecimiento en las empresas, mas necesidades.
Consolidacin 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, peridicos, revistas y tesis)
Las conversaciones personales y las observaciones de hechos
Las creencias y an los presentimientos. 18
19. Cundo surgen las Ideas? Al leer una revista de divulgacin popular
Al estudiar en la casa
Al ver televisin
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 mayora de las ideas iniciales son vagas y requieren analizarse cuidadosamente para que sean transformadas en planteamientos ms precisos y estructurados.
21
22. Ideas Cuando una persona desarrolla una idea de investigacin debe familiarizarse con el campo de conocimientos donde se ubica la idea (fundamentos o marcos tericos).
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 ms costoso o inviable la solucin. 23
24. Decidir el tipo de Investigacin 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
Satisfaccin del Cliente 25
26. Factores que restringen el xito de un Proyecto Del grado de familiaridad de los desarrolladores con el proyecto (empeo 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 terico del tema seleccionado (sugerencia utilizar metodologa PBL) (60%):
Leer y analizar el problema
Enumerar hiptesis, ideas y presentimientos
Anotar los factores conocidos 28
29. Actividad Anotar los factores desconocidos
Planifique la investigacin
Emita una declaracin del problema.
Adquirir informacin (investigacin).
Presentar el resultado de la investigacin (solucin).
Duracin: 30 minutos 29
30. Actividad Realizar el estado del arte del proyecto. Entregar tabla comparativa (50%) y descripcin de los trabajos relacionados (50%).
Fecha de entrega: Lunes 9 de junio de 2008, en el saln de clases, 10:00 hrs. 30
31. Anexos Ideas para definir Ideas
32. Avances en Ciencias de la Computacin 2008 M.C. Juan Carlos Olivares Rojas
33. Introduccin La computacin como ciencia se actualiza a pasos agigantados.
La empresa de consultora Gartner define una grfica denominada Hiperciclo, en las cuales mide el avance de las tecnologas emergentes.
En esta presentacin se muestran las grficas del 2006 y del 2012
34. Introduccin La curva del hiperciclo tiene los siguientes elementos:
Disparo de la tecnologa
Pico de expectaciones infladas
Desilusin
Grado de encantamiento
Productividad plena
35. Hiperciclo 2006 Disparo de la tecnologa:
Virtualizacin de aplicaciones para PC
Procesadores multincleo
Particiones de seguridad virtualizada
Suites E-learning
Suites de gestin (BPM)
36. Hiperciclo 2006 Pico de expectaciones infladas:
Aplicaciones de outsourcing
Aplicaciones de almacenes de datos
Redes inalmbricas de tercera generacin
WiMAX
Linux en el escritorio
Tablet PC
Suites Empresariales Inteligentes
Servicios de gestin de impresin
37. Hiperciclo 2006 Desilusin:
Operaciones con llave pblica
Portales bsicos empresariales
CRM
BI
Lectores de huella digital
Clientes ligeros
Puntos de acceso WiFi
38. Hiperciclo 2006 Encantamiento:
Tecnologas de manejo de contenido
ERP
Outsourcing de infraestructura de TI
39. Hiperciclo 2012 Disparo de tecnologas:
Computacin cuntica
Ajax offline
Traduccin de voz a voz
Arquitectura orientadas a eventos
Inteligencia colectiva
Arquitecturas dirigidas por modelos
RSS Empresarial
40. Hiperciclo 2012 Disparo de tecnologas (continuacin):
Web semntica corporativa
Reconocimiento del habla para dispositivos mviles
Pico de expectaciones infladas
IPv6
Mashup
Web 2.0
41. Hiperciclo 2012 Pico de expectaciones infladas:
Folksonomas
Papel digital
Anlisis de redes sociales
Desilusin:
RFID
Grid Computing
Ajax
42. Hiperciclo 2012 Pagos biomtricos
Wikis
Blog corporativo
Redes de sensores y mallas
Tablet PC
Pagos por dispositivos mviles
Tecnologas de localizacin
Mensajera Instantnea Empresarial
43. Hiperciclo 2012 Encantamiento:
Aplicaciones basadas en localizacin
Smartphone
Productividad
VoIP
Internal Web Services
44. Bibliografa Enciso, Enrique (2007). Tendencias y Predicciones Tecnolgicas y Sociales, Revista RED, Junio, pp. 21-27.
45. Innovacin en TI M.C. Juan Carlos Olivares Rojas
46. Empresas TI cFares es un buscador de precios de boletos de avin cubriendo la mayora 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 electrnicos para confirmar una cita, lo que representa 100 horas al ao en una empresa promedio. http://www.ipolipo.com/ 47
48. Empresas TI MOG: sistema que con autorizacin del usuario, permite acceder a una PC y catalogar toda la msica disponible. En base con otros usuarios se sugieren nuevos ttulos 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 computacin, 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 dlares. Se cobra 0.25 dlares por correo de voz. http://www.simulscribe.com/
SIBEAM: red inalmbrica multi gigabit de 60 GHz para transmitir video de alta definicin sin importar su comprensin. http://www.sibean.com/
51. Referencias Enciso, Enrique. Innovacin: clave para permanecer en el juego (2007). Revista Software Red, Septiembre de 2007, pp. 13.
52. Lneas de Investigacin 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 diseo accesible de pginas Web y aplicarlas para la correcta visualizacin de recursos Web en dispositivos mviles. Se realiz un pequeo estudio tomando en cuenta dichas consideraciones, obteniendo que es factible aplicar dichas recomendaciones o prcticas de buen diseo para su uso en dispositivos mviles. Tambin se presenta una propuesta para solucionar el problema de la correcta visualizacin de pginas Web en dispositivos mviles.El objetivo de este trabajo es utilizar las recomendaciones para el diseo accesible de pginas Web y aplicarlas para la correcta visualizacin de recursos Web en dispositivos mviles. Se realiz un pequeo estudio tomando en cuenta dichas consideraciones, obteniendo que es factible aplicar dichas recomendaciones o prcticas de buen diseo para su uso en dispositivos mviles. Tambin se presenta una propuesta para solucionar el problema de la correcta visualizacin de pginas Web en dispositivos mviles.
54. reas de Inters Sistemas Distribuidos
Cmputo mvil
Tecnologas Web
Redes inalmbricas
Bases de Datos 54
55. Lneas de Investigacin Sistemas basados en localizacin (LBS) y bsquedas contextuales.
Sistemas asncronos basados en tecnologas SMS/MMS
Programacin de Sistemas usando .NET Compact Framework y J2ME 55
56. Lneas de Investigacin Sistemas de intermediarios (proxys, middleware)
Sistemas Distribuidos Inteligentes (Agentes Mviles)
Transcodificacin multiformato y Acaparamiento para dispositivos Mviles. 56
57. Lneas de Investigacin Accesibilidad de recursos Web en dispositivos mviles (W3C, WCAG, MobileOK)
Minera de datos para y en dispositivos mviles.
Mecanismos de Precarga de Dispositivos Web. 57
58. Lneas de Investigacin Servicios Web y P2P en dispositivos mviles
Cmputo paralelo en dispositivos mviles (Grid, Clusters).
Sistemas Operativos para dispositivos mviles y empotrados
Virtualizacin
58
59. Lneas de Investigacin Seguridad en dispositivos mviles.
Desarrollos de Sistemas Adaptativos en Redes Inalmbricas (Redes de 3G, Redes de Sensores).
Metodologas para el desarrollo de aplicaciones en entornos de computacin con recursos limitados. 59
60. Lneas de Investigacin Cmputo mvil en la educacin
Multimedia en dispositivos de cmputo limitado 60
61. Trabajos actuales PaqWebCel: Paquete para Desplegar Publicidad en Terminales Mviles Celulares (CITEDI)
Sistema de publicidad para comercio electrnico mvil (m-commerce) (ITM)
Desarrollo de estrategias para desplegar publicidad en dispositivos mviles (multimedia, geoposicionamiento, seguridad y privacidad).
61
62. Trabajos actuales Metodologas de Desarrollo en Computacin con Recursos Limitados (ISwM):
Desarrollo de Interfaces Adaptativas para Dispositivos Mviles (ITM)*
Diseo de un Lenguaje para Modelar Redes de Computadoras (ITM)
Utilizacin del Patrn MVC (Modelo-Vista-Controlador) para el Desarrollo de Aplicaciones en Dispositivos Mviles (ITM)*
Estudio y Aplicacin de Patrones Arquitectnicos en la Construccin de Software para Dispositivos Mviles 62
63. Trabajos actuales Proxy de accesibilidad mvil (UNID)*
Weblog mininig en dispositivos mviles (UNID)*
Virtualizacin de recursos y aplicaciones en dispositivos mviles (UNID)*
Nuevas Tcnicas de DSS. 63
64. Trabajos actuales Medios audiovisuales para la autenticacin de sistemas de cmputo (UNID)*
Herramienta para validar la colocacin de puntos de acceso en redes inalmbricas utilizando diagramas de voronoi. (UNID)*
Plataforma educativa utilizando tecnologas Web 2.0 (ITM). 64
65. Trabajos actuales Seguridad en Dispositivos Mviles utilizando RSA (UVAQ)
Redes en Malla (802.11s)
Redes 3G en Mxico: Aplicaciones y Servicios
Redes Inalmbricas de Banda Ancha: WiMax y 802.20 (WiBro) 65
66. Propuestas de Trabajos Suite para la Conversin de Cdigo de Aplicaciones de Computadoras Personales a Aplicaciones de Cmputo Mvil (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 desconexin para J2ME 67
68. Propuestas de Trabajos Editor de pginas Web accesibles para dispositivos mviles
Comunicacin entre procesos IPC en mquinas virtuales
Algoritmo de enrutamiento para dispositivos mviles utilizando tcnicas de agrupamiento y distancias cortas
68
69. Propuestas de Trabajo Modificacin al protocolo SMTP para permitir la eliminacin de correo no visto.
Videostreaming en redes celulares de 2.5G de manera descentralizada
Localizacin geogrfica 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 intrnseca a eficacia y eficiencia.
Qu tiene ms 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.
Sinnimos de calidad es que est libre de errores. Muchas de las metodologas de software actuales se basan en esta premisa. 72
73. Calidad de Software Por qu es difcil lograr la calidad del software?
El software es un producto intangible el cual se logra a travs 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 Metodolgica? El software es cada vez ms 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 Ingeniera de Software como tal. 75
76. Construccin de una casa para wendo Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).
77. Construccin de una casa Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).
Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).
78. Construccin de un rascacielos Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).
Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuracin adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado ms ligth, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difcil eludir un proceso y modelado ms 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."
Extrada desde la presentacin Software Architecture and UML de Grady Booch (Rational Software).
Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuracin adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado ms ligth, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difcil eludir un proceso y modelado ms 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. Fbricas de Software Tratan de automatizar los procesos de desarrollo de software tal cual lo realizan las lneas de produccin 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 continuacin se describen:
Deteccin 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 Definicin 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 solucin. 81
82. Etapas para el desarrollo de un proyecto
Los niveles de factibilidad son:
Operacional
Tcnico
Econmico
La decisin de si se realiza un proyecto o no depende del desarrollador y del cliente. 82
83. Etapas para el desarrollo de un proyecto
Planeacin del proyecto: consiste en establecer una serie de estrategias para resolver un problema, adems de las tcnicas y el control que se llevar a cabo.
Elaboracin del proyecto: consiste en definir el diseo, la elaboracin de mdulos y la integracin 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 tcnicas de anlisis de resultados para determinar una posible evaluacin al final del proyecto.
Documentacin: consiste en explicar como estn compuestos los manuales tcnicos y de usuario del proyecto.
85. Ciclo de Vida de un Proyecto Identificar una necesidad
Desarrollar una propuesta de solucin
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 problemtica o necesidad de la empresa y se somete generalmente a concurso la solucin. 86
87. Ciclo de Vida de un Proyecto En la mayora de las ocasiones el SDP no existe por lo cual se debe de hacer un anlisis previo para plantear la solucin.
Una vez obtenido el SDP el proyecto inicia formalmente a travs 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. Metodologas de Desarrollo de Software Las metodologas de software son un conjunto de mejores prcticas que si no se llevan a la prctica no sirven de nada.
El factor humano es el recurso ms importante de cualquier proyecto de software.
94. Metodologas de Desarrollo de Software Por ejemplo, la Ley de Brooks: Si se aumenta un programador ms se retrasa el proyecto mientras se explica que hay que hacer.
El proceso de desarrollo de software implica cuatro etapas: 94
95. Metodologas de Desarrollo de Software Especificacin
Desarrollo
Evaluacin
Evolucin
El desarrollo de software se basa en modelos, siendo los ms representativos:
95
96. Metodologas de Desarrollo de Software Cascada (clsico)
Construccin de prototipos
Espiral
RAD (Desarrollo rpido 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 Comunicacin:
Inicio del Proyecto
Recopilacin de Requerimientos
Planeacin:
Estimacin
Itinerario
Seguimiento 98
99. Modelo de Ciclo de Vida en Cascada Actual Modelado
Anlisis
Diseo
Construccin
Cdigo
Prueba 99
100. Modelo de Ciclo de Vida en Cascada Actual Despliegue:
Entrega
Soporte
Retroalimentacin
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 metodologas de desarrollo de software por cada persona:
MOPROSOFT
Open UP (RUP)
CMMI 103
104. Actividad Six Sigma
TSP/PSP
Mtodos 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 metodologas que se les hayan asignado, preparar una presentacin donde se exprese brevemente la metodologa de manera muy general (80%).
Una vez realizada todas las presentaciones, redactar un escrito en el que se indique que metodologa es la que mejor aplica para el proyecto a desarrollar (20%). 105
106. Rbrica de Presentaciones Vestimenta formal: 10%
Material de Entrega: 10%
Contenido de la presentacin: 70%
Presentacin fluida sin lectura: 20% 106 Material de Entrega puede ser desde las diapositivas hasta servicio de cafeteraMaterial de Entrega puede ser desde las diapositivas hasta servicio de cafetera
107. Radiografa de la Industria del Software en Mxico Por qu son importantes las metodologas de desarrollo de software? 107
108. Tipos de Organizacin
109. Esquema de Contratacin
110. Edad
111. Escolaridad
112. Gnero
113. Antigedad
114. Salarios
115. Salarios
116. Salarios 116
117. Salario Internacional
118. Salario Tipo de Organizacin
119. Salario por Funcin
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 Artculo: La Catedral y el Bazar.
Realizar en forma grupal una presentacin de los puntos ms relevantes (80%)
De forma personal escribir los tres principios que ms llamaron mi atencin. 129
130. 1.4 Ingeniera de Requerimientos Un requisito no es otra cosa que una condicin o capacidad de un usuario o sistema para satisfacer un objetivo o resolver un problema.
Los requerimientos pueden ser funcionales (explcitos) o no funcionales (implcitos).
131. Requerimientos Las caractersticas que deben perseguir los requerimientos son: necesario, conciso, completo, consistente, no ambiguo, verificable.
Los problemas que presenta la Ingeniera de Requerimientos son muchos:
132. Requerimientos Los requerimientos no son obvios y provienen de muchas fuentes.
Son difciles de expresar en palabras.
Un requerimiento puede cambiar en el transcurso del proyecto.
133. Requerimientos Lo que se pretende con una buena Ingeniera 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 lmites y alcances del sistema.
El xito de la obtencin 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 tcnicas. Las ms populares son las entrevistas y cuestionarios.
Tips para Disear Cuestionarios.
Es necesario realizar un muestreo de los datos para encontrar necesidades.
141. Requerimientos Se debern poner escalas (preguntas cerradas) para cuantificar lo que se pretende.
Actividad: disear un cuestionario sobre el proyecto y aplicarlo a por los menos a 20 personas. Se sugiere utilizar sistemas en lneas para realizar los cuestionarios. (Diseo:20%, Aplicacin:80%) 141
142. Requerimientos Tips para realizar entrevistas:
Utilizar una tcnica de rombo de preguntas cerradas, abiertas y cerradas.
Observacin del mundo (STROBE).
Tener un guin flexible (improvisacin). 142
143. Requerimientos Tarea: realizar una entrevista a personal relacionado con el proyecto. Primera parte diseo entrevista (50%) una vez aprobada por el profesor (entrega martes 10 junio) se procede a la aplicacin (50%, entrega viernes 13).
En metodologas giles el cliente participa de manera activa en el desarrollo del sistema. 143
144. FODA Se pueden utilizar tcnicas como la Lluvia de Ideas o anlisis FODA, el cual consiste en hacer una relacin entre elementos:
Fortaleza: Factor interno positivo.
Oportunidades: Factor externo positivo.
Debilidades: Factor interno negativo.
Amenazas: Factor externo negativo.
145. Requerimientos Actividad: Realizar un anlisis FODA del proyecto. Cada integrante del equipo se encarga de un rea y se junta (100%)
Otras tcnicas de obtencin de requerimientos son:
Matriz de requisitos
Metodologa FURPS+
146. Metodologa FURPS+ Funcional (Functional): caractersticas, capacidades y seguridad.
Facilidad de Uso (Usability): factores humanos, ayuda, documentacin.
Fiabilidad (Reliability): frecuencia de fallos, capacidad de recuperacin.
147. Metodologa FURPS+ Rendimiento (Performance): tiempos de respuesta, productividad, precisin, disponibilidad, uso de los recursos
Soporte (Supportability): adaptabilidad, facilidad de mantenimiento, internacionalizacin, configurabilidad.
148. Metodologa FURPS+ +:
Implementacin: limitacin de recursos, lenguajes y herramientas, hardware
Interfaz: restricciones impuestas para la interaccin humana
Operaciones: gestin del sistema
Empaquetamiento
Legales: licencias, auditorias, etc.
149. Metodologa 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 Crticos de xito. Matriz FURPS grupal 100%, al menos 10 requisitos evaluados. 149 Agregar FCEAgregar FCE
150. Factores Crticos de xito La metodologa de Factores Crticos de xito sirven para determinar aquellas reas o cosas que son crticas 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 estndar para toda la industria, ni para todos los negocios. Son especficos para una situacin 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 (segn Rockart):
La industria
La estrategia competitiva o posicin en la industria
Factores del medio ambiente
Factores temporales
Posicin administrativa
154. FCE Algunos FCE de la Industria Automotriz:
Economa en el combustible
Imagen
Organizacin eficiente de agencias
Control de costos de manufactura, etc.
155. FCE Se deben considerar los siguientes elementos:
Informacin crtica: informacin necesaria para dar seguimiento a los FCE (extrada de otros SI, comprada, etc.)
156. FCE Supuestos crticos: Los objetivos y FCE estn basados en supuestos. Deben ser validados constantemente. Ej. Actividades de la competencia, inflacin, etc.
Decisiones crticas: Determinar cules son las decisiones crticas que se deben hacer. Ej. dar de baja un producto?, compra o desarrollo?, mximo riesgo aceptable.
157. FCE Fase 1. Formacin de un equipo de trabajo
Pocos recursos
Reconocimiento y posibilidad de comunicacin con la alta direccin
Conocimiento de la industria, sus problemas, puntos clave, etc.
Entender la empresa, y su posicionamiento, estructura, cultura y poltica, posicin competitiva.
158. FCE Fase 2. El equipo se prepara para el estudio
Estudiar la metodologa
Estudiar la tcnica de entrevistas seleccionada
Familiarizarse sobre la situacin de la empresa y su entorno
159. Metodologa para generar FCE Fase 3. Sesin introductoria con la alta administracin, 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 slo de informtica.
160. FCE Cules son las cosas que ud. ve como FCE en su trabajo?
Cul es el rea que ms le perjudicara si fallase?, Dnde le molestara ms que se fallase?
Si lo aislaran del negocio 3 semanas, sobre qu sera lo primero que quisiera que lo enterarn en relacin 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. Reunin de enfoque del equipo directivo (paso clave):
El equipo se rene con los ejecutivos
Los ejecutivos determinarn los FCE de acuerdo a la informacin recolectada
Mejores resultados si la reunin es con participacin abierta
163. Desarrollo de Prototipos Los prototipos son una excelente herramienta para la obtencin de requerimientos dado que el cliente puede ver elementos funcionales en operacin del proyecto.
El problema es que es una tcnica muy costosa, motivo por el cual su utilizacin est muy restringida.
164. Diseo de Prototipos
165. Diseo de Prototipos
166. Diseo de Prototipos Champcart
Motor: Turbocargado, 2.65 litros V-8
Caja de velocidad: Manual con 6 o 7 velocidades delanteras
LLantas: Bridgestone.
Peso mnimo: 1,565 libras
167. Diseo de Prototipos Formula1
Motor: Aspirado, 3 litros (183 cubic inches) V10 Turbocarga est prohibido.
Caja de velocidad: Semiautomtica de 6 o 7 velocidades delanteras
Llantas: sin marca
Peso mnimo: 1,322.77 libras con conductor
168. Diseo de Prototipos
169. Diseo de Componentes
170. Diseo de Componentes Chasis bsico: $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 ao
Costo equipo: 50 personas
171. Diseo de Componentes Otras partes: $150,000 de refacciones y $350,000 de partes de la caja de velocidades.
Costo transporte: $500,000 al ao de transporte.
Total: mnimo 2 millones, en promedio de 5-10 millones de dlares
172. Actividad En equipos de 2 Personas se deber crear un prototipo de avin de papel el cual deber ser aquel que en las pruebas de ensayo llegue ms 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 lder de proyecto.
Paso 3: Diferenciar roles entre los equipos de trabajo: diseador, probador, constructor, etc. (Paso 1 a 3: 10%)
174. Actividad Paso 4: Elaborar especificacin de prototipo (50%).
En este caso se debe tener un diseo claro que permita la construccin 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 algn detalle y mostrar las mejoras realizadas (la presentacin se hace hasta el final) (10%)
Paso 6: Construccin y elaboracin del prototipo a gran escala (20%).
176. Actividad Paso 7: Se escogern una muestra aleatoria de dos aviones para la realizacin de la comprobacin de la calidad (10%).
Qu se aprendi con la prctica de hoy? 176
177. Desarrollo de Prototipos Los prototipos son versiones reducidas, demos o conjunto de pantallas (que no son totalmente operativos) de la aplicacin pedida.
Esta tcnica es til cuando:
El rea de aplicacin no est bien definida (puede ser algo novedoso)
178. Desarrollo de Prototipos El costo del rechazo de la aplicacin es muy alto.
Es necesario evaluar primeramente el impacto del sistema en la organizacin.
La tcnica 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 tcnica se resume en: No s exactamente lo que quiero, pero lo sabr cuando lo vea
Es una tcnica costosa
180. Rbrica Una rbrica 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 Rbrica
182. Actividad Definir una rbrica para evaluar una clase de videojuegos, definir al menos 5 caractersticas, ubicar porcentajes a cada una.
Evaluar al menos tres videojuegos. Distribuir la rbrica a sus dems compaeros para que puedan evaluar.
183. Casos de Uso Otra forma de obtener requerimientos es a travs 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 aplicacin. 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 metodologas de Ivar Jacobson, Jame Rumbaugh y Grady Booch.
Es un lenguaje visual, su premisa bsica radica en que una imagen vale ms que 1,000 lneas de cdigo.
185. UML Al ser UML un lenguaje posee gramticas y alfabetos que definen como deben de estructurarse cada una de las palabras vlidas del lenguaje.
Un modelo es una representacin de la realidad. No slo se modela software sino prcticamente cualquier actividad.
186. UML Es el lenguaje estndar para modelar proyectos de software.
La versin ms actual del lenguaje es la 2.1
Los mtodos que se fusionaron para crear UML fueron OMT (Rumbaugh), Objectory (Jacobson) y el mtodo 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 ms baratos que la realidad.
Es ms fcil para una persona entender un diagrama que las lneas de cdigo 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. Mtodos 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. Mtodos Orientado a Objetos Vista estructural: modela los datos y la funcionalidad del sistema; es decir, la estructura esttica (clases, objetos y relaciones).
Vista de implementacin: Los aspectos estructurales y de comportamiento se representan aqu tal y como van a ser implementados.
192. Mtodos Orientado a Objetos Vista del comportamiento: representa los aspectos dinmicos o de comportamiento del sistema. Tambin muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en vistas anteriores.
193. Mtodos 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 ms utilizados en UML son:
Diagramas de casos de uso
Diagramas de actividades
Diagramas de clases
Diagramas de interaccin
Diagramas de secuencia
Diagramas de colaboracin
195. Tipos de diagramas Diagramas de estado
Diagramas de componentes
Otros diagramas
Diagrama de topologa 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.
Cul 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 implementacin del sistema a usuarios finales.
Los conectores asocian a los actores y los casos de uso.
199. Diagramas de caso de uso Las lneas continuas representan una asociacin y las puntuadas dependencias.
Si el conector tiene un triangulo hueco en la punta representa una generalizacin que es una relacin de herencia.
Los estereotipos agregan detalles a una relacin.
200. Diagramas de caso de uso Los estereotipos ms utilizados son: inclusin y de extensin.
Muchas herramientas no implantan UML al 100% existen muchos problemas de compatibilidad entre dichas herramientas. XMI es la descripcin 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 utilizacin de un caso de uso.
Las notas ayudan ha aclarar los diagramas.
Extender da ms detalle de dependecia de un caso de uso al cual se le agregan ms capacidades.
202. Diagramas de caso de uso Las notas deben ser como elementos taquigrficos.
Se deben incluir la siguiente documentacin: prrafo que describa el caso de uso, prrafo que describa cada una de las funciones primarias y secundarias, entre otros.
203. Diagramas de casos de uso Se deben detallar ejemplos de la utilizacin 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 Cuntos diagramas debo crear? No existe una respuesta especfica.
Debo hacer diagramas de todo tipo? No, slo se deben utilizar los diagramas que mejor reflejen el modelado de la problemtica
207. Preguntas frecuentes Qu tan grande debe de ser un diagrama? Entre ms grande sea un diagrama mayor es la confusin. Se deben realizar diagramas bien detallados, pero no tan detallados.
Cunto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del cdigo 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 econmica.
Si es obvio no se debe de modelar.
Hacer hincapi en la especializacin.
Utilizar patrones de diseo.
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 Tcnicas La Ingeniera de Requerimientos comprende las actividades de obtencin (captura, descubrimiento y adquisicin), anlisis (negociacin), especificacin y validacin de requerimientos.
Tambin establece la gestin para manejar cambios, mantenimiento y seguimiento de los requerimientos.
212. JAD Joint Application Development, Desarrollo Conjunto de Aplicaciones es una tcnica que consiste en realizar sesiones conjuntas entre los analistas de sistemas y los expertos del dominio.
Con esta tcnica se obtienen sistemas ms enfocados a la realidad, muchas metodologas nuevas se fundamentan en esta premisa.
213. JAD Por qu JAD funciona?
Por que las entrevistas son lentas, difciles de hacer y complicadas de obtener datos.
Al ser muchos revisores del proyecto es ms fcil detectar errores.
Problema: se requiere de mucha organizacin
214. ETHICS Implementacin Efectiva de Sistemas Informticos desde los puntos de vista Humano y Tcnico.
Fue desarrollada en 1979 por E. Mumford, se enfoca en los aspectos sociales que estn 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 mtodos que toman los puntos de vistas de los usuarios para encontrar cosas en comn, un ejemplo es VORD (Definicin de Requerimientos Orientados a Puntos de Vista).
216. Puntos de vista VORD consiste de los siguientes pasos:
Identificacin de puntos de vista
Estructuracin de dichos puntos de vista
Documentacin de puntos de vista (refinacin)
Trazado del punto de vista (conversin a un diseo orientado a objetos)
217. Etnografa Es una tcnica de observacin 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 cooperacin de muchas personas
218. Tips para la obtencin de requerimientos
Aprender de todos los documentos, formularios, informes y archivos existentes.
De ser posible se observar el sistema en accin. Se tomarn notas y dibujos. Conviene que las personas no sepan que estn siendo evaluadas.
219. Tips para la obtencin de requerimientos
Realizar entrevistas o sesiones de trabajo en grupo para refinar los requisitos de la aplicacin.
Es necesario verificar los requerimientos nuevamente hasta estar seguros
220. 220 Preguntas, dudas y comentarios?
