1. SISTEMAS DE INFORMACIÓN

2. SISTEMAS DE INFORMACIÓN Control u ordenación de elementos organizados para llevar acabo algún método, procedimiento o control mediante el proceso de la información.

3. ANÁLISIS Y DISEÑO Se refiere al proceso de examinar la situación de una empresa con el propósito de mejorar con métodos y procedimientos más adecuados.

4. COMPONENTES Análisis Diseño Proceso de clasificación e interpretación de hechos. Diagnóstico del problema Empleo de la información para recomendar mejoras al sistema actual Especifica las características del producto terminado Establece como alcanzar el objetivo

5. ACTIVIDADES Análisis de sistemas: Análisis y diseño de sistemas: Análisis, diseño y programación de sistemas:

6. Análisis del sistemas Actividad: Persona encargada: Reúne la información y determina los requisitos Los analista no son responsables del sistema Analista de Información

7. Análisis y diseño del sistemas Actividad: Persona encargada: Tiene la responsabilidad adicional de diseñar el nuevo sistema Diseñador de sistemas Diseñador de aplicaciones

8. Análisis, diseño y programación del sistemas Actividad: Persona encargada: Desarrolla las especificaciones de diseño Analiza el software necesario para implementar el diseño Analista programador

9. ELEMENTOS DE UN SI Software Hardware Gente Base de datos Documentación Procesamiento Control

10. ELEMENTOS DE UN SI software Hardware Programas Estructura de datos y documentación asociada para realizar el método lógico Dispositivos electrónicos que proporciona la capacidad de computación

11. ELEMENTOS DE UN SI Gente Base de datos Usuarios y operadores del software y del hardware Colección grande y organizada de información y que es una parte integral del funcionamiento del sistema

12. ELEMENTOS DE UN SI Documentación Procesamiento: Manuales, los impresos y otra información descriptiva que explica el uso y/o la operación Los pasos que definen el uso especifico de cada elemento del sistema

13. ELEMENTOS DE UN SI Control: Niveles de control tolerables de rendimiento del sistema

14. PROCESO DE DESARROLLO DE UN SI Identificación de las alternativas para el desarrollo del sistema. Creación de la propuesta Determinación de las necesidades del ejecutivo

15. PROCESO DE DESARROLLO DE UN SI Identificación de las alternativas para el desarrollo del sistema: Identificar si el sistema se lo hace de manera interna y partiendo de cero Hace modificaciones al existente Desarrolla el SI partiendo de cero y con la ayuda de desarrollares externos con experiencia

16. PROCESO DE DESARROLLO DE UN SI 2. Creación de la propuesta: Claro entendimiento con el ejecutivo Reducir la resistencia al cambio Manejar las expectativas, beneficios, informar los riesgos que implica y los recursos que requiere Lograr el compromiso delos recursos

17. PROCESO DE DESARROLLO DE UN SI 3. Determinación de las necesidades del ejecutivo: Cuestionar al ejecutivo acerca de cuales son sus necesidades y requerimientos Realizar entrevistas con los ejecutivos, directores y gerentes de las diferentes áreas de la empresa Listar los principales objetivos de la empresa a corto y largo plazo A partir de la observación o entrevista determinar la información que utiliza en la actualidad el ejecutivo

18. CARACTERISTICAS DE SI Logran ahorros significativos de mano de obra Necesitan información de entrada y salida para generar resultados, operaciones o reportes. Se adaptan a aplicaciones que se encuentran en el mercado.

19. Ingeniería de Software El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo.

20. Proceso de desarrollo de software Es aquel en que las necesidades del usuario son traducidas en requerimientos de software.

21. Proceso de desarrollo de software Es decir define ¿Cuándo de hace? ¿Qué se esta haciendo? ¿Qué se produjo? ¿Quién lo hace? Curso: fase e interacciones Actividades: Flujo de trabajo de procesos Artefactos: Modelos, reportes y documentos Persona: Grupo de desarrolladores

22. Ciclo de Vida del Software Comprende cuatro grandes fases: Concepción Elaboración Construcción Transición.

23. Ciclo de Vida del Software Concepción: Es definir el alcance del proyecto y definir el caso de uso

24. Ciclo de Vida del Software Elaboración: Es proyectar un plan, definir las características y cimentar la arquitectura.

25. Ciclo de Vida del Software Construcción : Es crear el producto

26. Ciclo de Vida del Software Transición. : Transferir el producto al usuario

27. Ciclo de Vida del Software Modelo en cascada Modelo escala Requisitos Esfuerzo Análisis prueba Diseño preliminar y detallado Implementación Implementación & prueba unitaria Diseño Análisis Tiempo Integración Mantenimiento

28. Proceso de desarrollo de Software Quiero ingresar los datos de los estudiantes ? <HTML> <HEAD> <TITLE> Mi paguina WEB </TITLE> </HEAD> <BODY> <CENTER><h1>Primera Paguina</h1></CENTER> <HR> Esta es mi primera paguina, aunque es muy sencilla. Como el lenguaje HTMLno es dificil <P>aqui va un segundo parrafo <ul> <li><b>el cine</b> <li><i>volly</i> </ul> <ol> <li><pre>salsa</pre> </tt> </ol> <dl> <dt>valores <dd>son actitudes </dl> </BODY> </HTML> MAESTRO Quiero generar reportes RECTOR

29. Proceso de desarrollo de software El problema central del desarrollo de software es transformar las necesidades del cliente en código “El camino desde las necesidades hasta el código del sistema es tan complejo que no es posible escribir el código instantáneamente”

30. Desarrollo de Software Proceso Unificado Comprende cuatro grandes fases: Concepción Elaboración Construcción Transición Arquitectura Objetivos Sistema Corriendo Presentación del Producto

31. Para reflexionar ¿Qué pasaría, si el ingeniero civil o el arquitecto construye una casa o un edificio sin hacer sus planos, proyectos o maquetas? ¿Crees que la obra pueda concluirse cubriendo las necesidades, con la calidad necesaria y a tiempo? Simplemente observa a tu alrededor

32. UMLLenguaje de Modelamiento Unificado

33. UMLLenguaje de Modelamiento Unificado Para representar adecuadamente la arquitectura de un sistema es necesario contar con varios diagramas o vistas. Dada la cantidad de características y de elementos que tiene un sistema de software no es posible incluirlos todos en un solo diagrama y que sirva, además, para todas las personas que participan en el desarrollo. Cada una de estas vistas es una estructura de la arquitectura del sistema, que muestran una parte del sistema como un conjunto de componentes, conectores y restricciones sobre sus tipos y relaciones.

34. UMLLenguaje de Modelamiento Unificado Permite representar la estructura de un sistema a un nivel mayor que el dado por la programación o incluso el diseño Además, cada estructura puede relacionarse con las demás para complementar la visión integral del sistema. En UML se utilizan para el modelamiento de un sistema diferentes elementos y relaciones, que tienen una semántica y sintaxis definidas. Estos elementos se agrupan en diagramas preestablecidos que corresponden a diferentes proyecciones del sistema

35. Notación Una notación es un conjunto de diagramas normalizados que posibilita al analista o desarrollador el describir el comportamiento del sistema (análisis) y los detalles de una arquitectura (diseño) de forma no ambigua.

36. Notación La acción de dibujar un diagrama no constituye ni análisis ni diseño Una notación no es un fin por si misma El hecho de que una notación sea detallada no significa que todos sus aspectos deban ser utilizados en todas las ocasiones La notación son como los planos para un arquitecto o un ingeniero

37. Notación Una notación no es más que un vehículo para capturar los razonamientos acerca del comportamiento y la arquitectura de un sistema Las notaciones deben ser lo más independientes posibles de los lenguajes de programación, sin embargo facilita el proceso de desarrollo que exista una equivalencia entre la notación y los lenguajes de programación El propósito de este tema es describir la sintaxis y semántica de la notación que se utiliza para el análisis y diseño orientado a objetos

38. Notación - UML UML ofrece nueve diagramas en los cuales modelar sistemas: Diagramas de Casos de Uso para modelar los procesos ’business’. Diagramas de Secuencia para modelar el paso de mensajes entre objetos. Diagramas de Colaboración para modelar interacciones entre objetos. Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. Diagramas de Clases para modelar la estructura estática de las clases en el sistema. Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema. Diagramas de Componentes para modelar componentes. Diagramas de Implementación para modelar la distribución del sistema.

39. Conclusiones ¿Qué es el Proceso Unificado? ¿Cuáles son las fases del proceso unificado? ¿Qué es UML? ¿Qué es Notación? ¿Es importante usar una metodología para desarrollo de SI? Porque

43. Prueba

45. Determinación de los Requerimientos HERRAMIENTAS: Datos relevantes Entrevistas Cuestionarios Prototipos DESARROLLADOR: Comprende que información necesitan los usuarios para trabajar Concepción

46. Determinación de los Requerimientos INVOLUCRADOS: Desarrolladores Usuarios Administradores LOS DESARROLLADORES NECESITAN: Detalles del SI ¿Quién? Personas ¿Qué? Actividades del SI ¿Dónde? Ambiente ¿Cuándo? En que momento ¿Cómo? De que manera se desarrollo Concepción

47. Determinación de los Requerimientos AL TÉRMINO DE LA FASE: Los desarrolladores deben comprender el porque de las funciones del SI Tener informe sobre personas, objetivos y procedimientos Concepción

48. Conclusiones ¿Cuáles son las fases del ciclo de vida dentro del proceso unificado? ¿Dentro de la Concepción que actividades se realiza? ¿Indica dos reglas para el planteamiento del problema? ¿Qué herramienta utilizarías para determinar los requerimientos del SI? ¿Qué obtiene el desarrollador al finalizar esta etapa?

49. TAREA Elabora una herramienta para determinar los requerimientos del SI a partir del problema expuesto a continuación: Se debe realizar un sistema capaz de mantener una base de datos con todos los equipos hardware y software de los laboratorio UNO y TRES del Colegio Eloy Alfaro, de manera que se pueda obtener información acerca del número de licencias instaladas y de los equipos en los que están instaladas dichas licencias. Además debe ser posible controlar el hardware, las modificaciones efectuadas en los equipos, las averías de dichos equipos, la composición de cada uno de los ordenadores y el software que está instalado en ellos.

50. Análisis Aunque el proceso es interactivo los pasos fundamentales son los siguientes: 1. Título de la aplicación El título de una aplicación debe reflejar de la mejor forma posible sus fines y su funcionalidad: Ejemplo: Mónica: Su asistente en los negocios Trasgu: Gestión de Hardware y Software Elaboración

51. Análisis 2. Documentos de análisis Son la documentación que aporta el cliente que encarga la aplicación También es la documentación elaborada de forma informal en reuniones de trabajo para entender las solicitudes del cliente Documento: Ejemplo de Documento de Análisis 3. Especificación de Requisitos o Requerimientos Es la especificación más técnica y elaborada de los documentos de análisis Es importante codificar los requisitos para poder seguirlos a lo largo del proceso de construcción del software Tarea: Realizar las especificaciones con el documento anterior Elaboración

52. Diseño Usa la información anterior para hacer el diseño lógico del SI (pseudo código, DF, etc) Diseña procedimientos precisos para la captura de datos Diseño de formas y pantallas Diseña la interfaz del usuario Diseño de base de datos Diseño de control y respaldos Elaboración

53. Diseño 4. Diagramas de Casos de Uso: Un caso de uso es una técnica de modelado utilizada para describir lo que un nuevo sistema debe hacer o lo que un sistema existente ya hace. Un modelo de casos de uso se construye mediante un proceso iterativo durante las reuniones entre los desarrolladores del sistema y los clientes (y/o los usuarios finales) conduciendo a una especificación de requisitos sobre la que todos coinciden. Un caso de uso captura algunas de las acciones y comportamientos del sistema y de los actores Un caso de uso es la típica interacción entre un usuario y un sistema informático Elaboración

54. Diseño Diagramas de Casos de Uso Es un diagrama que muestra sistemas, casos de uso y actores Es una documentación que describe cada caso de uso, cada sistema y cada actor Es importante codificar cada caso de uso Los casos de uso sólo muestran aspectos muy generales Elaboración

55. Diseño Diagramas de Casos de Uso Elaboración

56. Diseño Diagramas de Casos de Uso El sistema que se desea modelar se representa encerrado en un rectángulo Los actores son los que interactúan con el sistema. Representan todo lo que necesite intercambiar con el sistema. Un actor es una clase Se diferenciará entre actores y usuarios. Un usuario es una persona que utiliza el sistema Un actor representa el papel (rol) que una persona desempeña Un actor es el papel que el usuario juega con respecto al sistema. Un actor no tiene que ser un humano, puede ser por ejemplo otro sistema externo que pide información al sistema actual Por ejemplo una persona puede ser usuario y administrador en un sistema, unas veces actuará como usuario y otras como administrador, pero deben contemplarse ambos actores. Elaboración

57. Diseño Diagramas de Casos de Uso CONCLUSIÓN Los Casos de Uso es un camino específico para utilizar el sistema Para cada Caso de Uso, Actor y Sistema se realiza una descripción detallada Los Casos de Uso tan sólo indican opciones generales El diagrama de Casos de Uso es un diagrama sencillo que tiene como finalidad dar una visión global de toda la aplicación de forma que se pueda entender de una forma rápida y gráfica tanto por usuarios como por desarrolladores Elaboración

58. Diseño Diagramas de Casos de Uso EJEMPLO: Elige producto Pregunta por el precio CLIENTE Paga el producto COMPRA PRODUCTO Elaboración

59. TAREA Realizar el diagrama de caso de uso de los involucrados en el sistema para los laboratorios.

60. Proceso de Análisis y Diseño Preliminar Aunque el proceso es iterativo los pasos fundamentales son los siguientes: 1. Título de la aplicación El título de una aplicación debe reflejar de la mejor forma posible sus fines y su funcionalidad 2. Documentos de análisis – Son la documentación que aporta el cliente que encarga la aplicación – También es la documentación elaborada de forma informal en reuniones de trabajo para entender las solicitudes del cliente 3. Especificación de Requisitos o Requerimientos – Es la especificación más técnica y elaborada de los documentos de análisis – Es importante codificar los requisitos para poder seguirlos a lo largo del proceso de construcción del software

61. Proceso de Análisis y Diseño Preliminar 4. Diagramas de Casos de Uso – Es un diagrama que muestra sistemas, casos de uso y actores – Es una documentación que describe cada caso de uso, cada sistema y cada actor – Es importante codificar cada caso de uso – Los casos de uso sólo muestran aspectos muy generales 5. Escenarios y sub-escenarios – A cada caso de uso le corresponden varios escenarios donde se pueden mostrar los detalles – Cada escenario puede dividirse en sub-escenarios para bajar más el nivel de detalle – Los escenarios se codifican siguiendo los valores de los casos de uso

62. Proceso de Análisis y Diseño Preliminar 6. Diagramas de Secuencia – Se corresponden con los escenarios y sub-escenarios pero con mucho más detalle – Siguen la misma codificación que los escenarios y sub-escenarios – Algunos diagramas de secuencia pueden refinarse más en la fase de diseño detallado 7. Diccionario de datos – Contiene todas las clases – Se pueden ir definiendo los miembros de las clases (datos y métodos) – Se iré refinando paso a paso en cada iteración – Las herramientas lo van construyendo automáticamente

63. Diseño 5. Escenarios y sub-escenarios A cada caso de uso le corresponden varios escenarios donde se pueden mostrar los detalles Cada escenario puede dividirse en sub-escenarios para bajar más el nivel de detalle Los escenarios se codifican siguiendo los valores de los casos de uso Elaboración

64. Diseño Escenarios y sub-escenarios Se enumeran escenarios fundamentales para el funcionamiento del sistema Se estudia cada escenario utilizando guiones como los que se usan en el cine Cada equipo que pasa por un escenario identifica los objetos y sus responsabilidades, así como los mecanismos que relacionan los objetos De los escenarios iníciales se puede pasar a otros escenarios secundarios Elaboración

65. Diseño Escenarios y sub-escenarios Los escenarios también se pueden utilizar para probar el sistema en la fase de pruebas El estudio de los escenarios con detalle permite ir enriqueciendo el Diccionario de datos No es necesario hacer todos los escenarios y sub-escenarios posibles si se observa que no enriquecen el diccionario de datos Elaboración

66. Diseño Escenarios y sub-escenarios Numeración: Titulo: Precondiciones: Quien Lo Comienza: Quien Lo Finaliza: Postcondiciones: Descripción:

67. Diseño Escenarios y sub-escenarios Numeración: 1.1. Titulo: Hacer pedido Precondiciones: Sugerencias de compra, caducidad de licencias, bajas permanente hardware, … Quien Lo Comienza: Responsable de Informática. Quien Lo Finaliza: Responsable de Informática. Postcondiciones: Descripción: Son las operaciones de compra de todos los componentes (hardware, software y manuales) que realiza el responsable de informática. Además da estos equipos de alta y debe apoyarse en el sistema para gestionar los pedidos correctamente para lo que debe anotar en el sistema que ha pedido un componente a un proveedor ( por tanto que está pendiente de recibir).

68. Diseño Escenarios y sub-escenarios Numeración: 1.2. Titulo: Anular pedido Precondiciones: Cambio de precio, cambio de necesidades de la Empresa. Quien Lo Comienza: Responsable de Informática Quien Lo Finaliza: Responsable de Informática Postcondiciones: Descripción: Esta operación la realiza el responsable de informática cuando toma la decisión de anular un pedido que había realizado con anterioridad.

69. Diseño Escenarios y sub-escenarios Numeración: 1.3 Titulo: Recibir pedido Precondiciones: Haber realizado la petición de un pedido. Quien Lo Comienza: Responsable de Informática Quien Lo Finaliza: Responsable de Informática Postcondiciones: Descripción: El responsable de informática confirma la recepción de los pedidos

70. Diseño 6. Diagramas de Secuencia Se corresponden con los escenarios y sub-escenarios pero con mucho más detalle Siguen la misma codificación que los escenarios y sub-escenarios Algunos diagramas de secuencia pueden refinarse más en la fase de diseño detallado 7. Diccionario de datos Contiene todas las clases Se pueden ir definiendo los miembros de las clases (datos y métodos) Se iré refinando paso a paso en cada iteración Las herramientas lo van construyendo automáticamente Elaboración