CONCEPTOS DE ANÁLISIS

1. CONCEPTOS DE ANÁLISIS Prof. Nelliud D. Torres

2. CICLO DE DESARROLLO DE SISTEMAS Capítulos 3 - 5 Capítulo 2 Aprobación del usuario Vida útil Capítulos 6 - 8 Capítulo 10 HCI – Human computer interface Pruebas, conversión, adiestramientos y documentación. Capítulos 6 - 8 Capítulo 9

3. FASE DE ANÁLISIS

4. En este capítulo se discuten las técnicas de requirements modeling y los métodos que los analistas de sistemas utilizan para vizualizar y documentar nuevos sistemas. • También se explican los requerimientos de los sistemas y técnicas de búsqueda de factores (fact-finding) lo cual incluye entrevistas, cotejo de documentos, observación, encuestas y cuestionarios, (muestreo) sampling e investigación.

5. REQUIREMENTS MODELING (Capítulo 3) • Envuelve búsqueda de factores (Fact finding). • Identifica el sistema vigente y los requerimientos del nuevo sistema. Entre estos requerimientos se incluyen los siguientes: • Outputs –Información producida por el sistema. (sea electrónica o impresa) • Inputs – Data necesária que entra al sistema. • Processes – Reglas lógicas para transformar la data en información importante. • Performance – Características del sistema como velocidad, volumen, capacidad, disponibilidad y confiabilidad. • Security – Incluye hardware, software y controles de procedimientos que salvaguardan al sistema y sus datos de amenazas internas o externas.

6. Systems Analysis Phase Overview • Destrezas del Analista de Sistemas • Analíticas – Identificar problemas, evaluar elementos claves y desarrollar una solución viable. • Interpersonales – Poder comunicarse con los empleados a todos los niveles, comunnicarse efectivamente y saber balancear necesidades conflictivas de los usuarios.

7. TEAM ORIENTED • Debido a que los Sistemas de Información afectan a todas las personas de una empresa, se deben considerar estrategias que envuelvan trabajo en equipo. • Team-Oriented Methods and Techniques • Joint application development (JAD) • Rapid application development (RAD)

8. PARTICIPACIÓN DEL USUARIO • Antes los departamentos de IT eran los únicos que se responsabilizaban y trabajaban el análisis y diseño de un sistema. • Hoy en día la visión es más orientada a trabajo en grupo. • Los usuarios tienen un punto clave en el desarrollo de un sistema. Sobre todo ellos van a ser los end-users del sistema. • Sistemas exitosos deben ser orientados a las necesidades del usuario. Por eso es que ellos tienen que estar incluidos en estos procesos.

9. Joint Application Development • Un JAD Team se compone de usuarios, gerentes y profesionales de IT. • Trabajan juntos para poder recopilar información, discutir necesidades del negocio y definir los nuevos requerimientos del sistema. • Generalmente se reunen por un periodo de días o semanas en un salón de conferencias o en un lugar fuera de la oficina. (evitar distraciones)

10. Joint Application Development • JAD Participants and Roles Figure 3-4

11. Joint Application Development Figure 3-5

12. DESVENTAJAS Comparado con los métodos tradicionales, el JAD suele ser más caro. Si el grupo es muy grande, el costo aumenta significativamente. VENTAJAS Permite que los usuarios participen más efectivamente en los procesos. Les da una sensación de pertenencia con respecto al sistema. Cumple con mayor precisión los requerimientos del sistema. Mejor entendimiento de las metas comunes. Joint Application Development

13. Rapid Application Development • Al igual que el JAD, el RAD es una técnica basada en equipo que agiliza un Sistema de Información. • Se diferencia en que produce un Sistema de Información funcional. • Se basa en prototipos con la participación directa del usuario. • Utilizan CASE tools para construir los prototipos y la documentación requerida.

14. Rapid Application Development RAD Phases and Activities • Requirements Planning – En esta fase los miembros del RAD discuten y se ponen de acuerdo sobre las necesidades del negocio, alcance del proyecto, limitciones y requerimientos del sistema. • User Design– El usuario y el analista trabajan juntos para desarrollar prototipos que represente lo procesos, inputs y outputs. Utilizan Case Tools para crear modelos funcionales. • Construction – Se desarrolla los programas y aplicaciones. Es importante indicar que el usuario participa también de esta actividad y que puede sugerir cambios a las pantallas y reportes que se desarrollen. • Cutover – Incluye conversión de datos, pruebas de los programas, cambiar al sistema nuevo y entrenamiento d los usuarios. Si se compara con los métodos tradicionales, se puede decir que el proceso completo se comprime y como resultado, se contruye e implanta el sistema mucho más rápido.

15. Rapid Application Development • RAD Phases and Activities Figure 3-7

16. Rapid Application Development • RAD Objectives • Cortar tiempo de desarrollo y por ende los gastos asociados a eso integrando de lleno la participación del usuario en cada fase del desarrollo del sistema. • Para que el RAD team sea exitoso, debe tener recursos del departamento de IT, las destrezas necesarias (conocimiento) y apoyo de la gerencia. • Ayudar al team de desarrollo diseñar un sistema que requiera una interfaz altamente interactiva y compleja para el usuario.

17. DESVENTAJAS Por la prisa, el sistema se concentra en su funcionamiento y podría no enfatizar las necesidades estratégicas del negocio. Se tiene menos tiempo para desarrollar estándares de calidad, consistencia y diseño. VENTAJAS Los sistemas pueden ser desarrollados más rápidamente con ahorros en costos bien significativos. Rapid Application Development

18. Modeling Tools and Techniques • CASE Tools – Provee herramientas que el analista puede utilizar para documentar los procesos del negocio. • Los analistas utilizan el modeling y la búsqueda de factores interactivamente. • Primero se pasan esos factores a modelos y se estudian para determminar si hay que hacer más búsqueda de factores. • Para lograr esto, los analistas utilizan los diagramas tipo functional decomposition yel lenguaje unified modeling. Figure 3-8

19. Modeling Tools and Techniques Ejemplo de una herramienta que el analista puede utilizar para documentar los procesos del negocio, el porque se hacen y quién las hace. Pag: 98

20. Modeling Tools and Techniques • Functional Decomposition Diagram(FDD) – Representación tipo top-down de una función o de un proceso. También se conocen como structure chart (organization). Aqui el analista conoce la jerarquía de operaciones de la empresa. A cóntinuación se muestra un ejemplo de un FDD. (Pag: 99)

21. Functional Decomposition Diagrams Figure 3-9, Pag: 99

22. Structure Chart (Organization) • Ayuda a entender como los departamentos funcionan. • Generalmente se obtiene en el departamento de recursos humanos. • Indica quien responde o delega cada oficina. • Si la compañía notiene uno, el analista debe recopilar la información para poder crearlo.

23. COMPONENTES DEL STRUCTURE (Organization) CHART ASISTENTE Comentarios RESPONDE

24. EJEMPLOS DE STRUCTURE CHART

25. EJEMPLOS DE STRUCTURE CHART

26. Modeling Tools and Techniques • Unified Modeling Language – Método de utilizar programas que visualizan y documentan los procesos u operaciones de la empresa. Provee varias herramientas gráficas como las que se discuten a continuación. • Use Case Diagrams – Muestra visualmente la interación entre usuarios y los procesos. • Sequence Diagrams – Muestra el tiempo de interación entre dos o más objetos.

27. Modeling Tools and Techniques Unified Modeling Language - Use Case Diagrams Figure 3-10 Ejemplo de un diagrama tecato en donde el cliente va a validar una tarjeta de crédito. Pag: 100

28. Modeling Tools and Techniques Unified Modeling Language - Use Case Diagrams Documento tipo tabla que detalla lospasos del diagrama anterior. Pag: 100 Figure 3-11

29. EJEMPLOS DE CASE DIAGRAMS

30. EJEMPLOS DE CASE DIAGRAMS

31. EJEMPLOS DE CASE DIAGRAMS Al llegar al Hogar deben mostrar su evaluación médica. Luego son evaluados por la enfermera del Hogar. El niño es removido del hogar por el Departamento de la Familia, por la Ley #177 de Protección de Menores. El niño es evaluado por un doctor antes de llegar al Hogar. Luego de esto, es llevado al Hogar del Niño El Ave María. Una solicitud de admisión es llenada completamente a mano. Los datos son guardados en un archivo.

32. Modeling Tools and Techniques Unified Modeling Language - Sequence Diagrams Sequence Diagram Figure 3-13

33. System Requirements Checklist • Se debe identificar y describir todos los requerimientos del Sistema. • Existen 5 categorias dentro de los requerimientos. • Outputs – Ver ejemplos en la página 101 • Inputs – Ver ejemplos en la página 102 • Processes – Ver ejemplos en la página 102 • Performance – Ver ejemplos en la página 102 • Controls – Ver ejemplos en la página 102-103

34. Future Growth, Costs, and Benefits • Scalability • La habilidad del sistema de manejar el aumento de volumen de transacciones en el futuro. • Al tener un ciclo de vida mayor resulta en una mejor inversión a largo plazo. • Para poder evaluar este beneficio, se necesita información sobre el futuro volumen que va a tener el sistema en cuanto a los output, inputs y procesos se refiere.

35. Future Growth, Costs, and Benefits • Total Cost of Ownership (TCO) • Esto incluye no solo los costos directos, sino también los indirectos..El analista debe conocer e identificar estos costos indirectos que puede convertir un proyecto viable en uno no costo-efectivo. • Microsoft ha desarrollado un método para medir los costos y beneficios llamado Rapid Economic Justification (REJ) Pag: 104, figura 3-14

36. Fact-Finding • Overview • Aunque existe software que puede ayudar a agrupar y analizar factores, no hay programas que puedan hacer el fact-finding por uno • El primer paso es identificar la información queuno necesita

37. Fact-Finding Preguntas guías: Who, What, Where, When, How, and Why? Figure 3-15

38. Fact-Finding • The Zachman Framework • A model that asks the traditional fact-finding questions in a systems development context • Ayuda a los gerentes y usuarios a entender el modelo del sistema y se asegura de que las metas (goals) del negocio en general se traduscan enproyectos exitosos. • En la página 106 se muestra un ejemplo de un programa que sigue este modelo. En el próximo slide se muestra el mismo ejemplo.

39. Fact-Finding - The Zachman Framework Figure 3-16

40. Interviews • Los analistas pasan mucho tiempo hablando e interactuando con las personas de la empresa. • Mucho de ese tiempo se lleva a cabo en entrevistas. • Para lograr una entrevista exitosa, sedeben seguir los siguientes 7pasos

41. Interview • Step 1: Determine the People to Interview – Cotejando el Organization chat se puede determinar las personas claves que vas a entrevistar. Se debe determinar las personas idoneas y las preguntas correctas para esas personas. • Informal structures – Las entrevistas no siempre tienen que ser formales, puede ser algo casual en una cafeteria, coffe break, etc. • Otro factor a considerar es si se va a entrevistar individualmente o en grupo. Ambas técnicas tienen ventajas y desventajas.

42. Interview • Step 2: Establish Objectives – Una vez determinada las personas a entrevistar, se debe tener claro los objetivos a discutir. • Determine the general areas to be discussed – • List the facts you want to gather – • Se debe solicitar ideas, sugerencias y opiniones durante la entrevista. • Los objetivos de la entrevistan cambian de acuerdo a la persona que se va a entrevistar. • Los gerentes te van a dar una idea general del sistema, mientras que los usuarios te pueden dar detalles específico de como trabaja.

43. Interviews • Step 3: Develop Interview Questions • Creating a standard list of interview questions helps to keep you on track and avoid unnecessary tangents • Avoid leading questions – Por ejemplo en lugar de preguntar ¿Qué ventajas ves al sistema propuesto?, debes preguntar ¿Ves alguna ventaja en el sistema propuesto? • Open-ended questions – Provee respuestas espontáneas y no estructuradas por parte del usuario. En la página 108 se muestran ejemplos. • Closed-ended questions – Limita o restringe larespuesta del usuario. (página108 para ejemplos) • Range-of-response questions – El usaurio evalua una preguntautilizando escalas ( ideal para estadísticas)

44. Interviews • Step 4: Prepare for the Interview • Es importante una preparación cuidadosa para la entrevista ya que no es una charla informal y deben tomarse medidas para que sea exitosa. • Es bueno enviar un e-mail el dia antes como recordatorio de la entrevista. • La entrevista no debe durar más de una hora. • Enviale al usuario una lista de los tópicos de los cuales le vas a entrevistar. Esto lo ayuda a prepararse para una mejor entrevista. • Solicitale al entrevistado que traiga muestras (documentos, formas, etc.) • Asegura un ambiente en donde no hayan interrupciones (llamadas, gente entrando a la oficina, etc.)

45. Interviews Ejemplo de un e-mail notificando sobre entrevistas a realizarse. Figure 3-18

46. Interviews Ejemplo sobre confirmación de reunión y tópicos a discutir. Figure 3-19

47. Interviews • Step 5: Conduct the Interview • Desarrollar una logística para la entrevista. • Comienza conuna buena introducción • Use engaged listening – Concenrarse en lo que le dice el entrevistado y observar cualquier comunicación no-verbal. • Dale tiempo a la persona a pensar las respuestas a tus preguntas. • Resume los puntos principales (cotejar si entendiste al usuario claramente)

48. Interviews • Step 6: Document the Interview • Durante la entrevista, las anotaciones debes mantenerlas al mínimo posible. • Despues de la entrevista apunta y registra lo más rapido posible los puntos más importantes de la entrevista. Recuerda que uno olvida el 50% de una conversación despues de 30 minutos. • No todos los usuarios se sienten a gusto cuando grabas la conversación. Debes preguntar primero. • Despues de la entrevista, envia un memo expresando tu gratitud por la entrevista. Incluye los puntos principales discutidos y un resumen general de modo que elusuariopueda estar egurodeque la comunicación y el intercambio de ideas fue efectivo.

49. Interviews • Step 7: Evaluate the Interview • En adición de anotar la conversación, se tiene que tratar de indentificar cualquier biases. Por ejemplo que un usuario no este diciendo la verdad porque teme ser reemplazado en su trabajo, etc. • Unsuccessful Interviews – Esto siempre puede ocurrir. Evalúa el porque no fue exitos para evitar el mismo error en el futuro. • No matter how well you prepare for interviews, some are not successful

50. Other Fact-Finding Techniques • Document Review • Observation • Seeing the system in action gives you additional perspective and a better understanding of the system procedures • Plan you observations in advance – Prepara una lista de las tareas que quieres observar y de las preguntas que quieres hacer. En la página 113 hay una lista de las cosas a considerar durante la observación. • Hawthorne Effect – La gente trabaja diferente cuando sabe que es observada.