Metodologías y fases para desarrollar sistemas de información gerencial
Metodologías de Desarrollo
Sistema de Información
Las metodologías son sistemas completos
de técnicas que incluyen procedimientos paso a paso, productos resultante, funciones, herramientas y normas de calidad para la terminación del ciclo de vida completo del desarrollo de sistemas.
Metodología para el Desarrollo de SI
Una Metodología para el Desarrollo de SI es un conjunto de actividades llevadas a cabo para desarrollar y poner en marcha un Sistema
de Información.
Objetivos y Tipos de Metodologías
Objetivos de las metodologías
• Definir actividades a llevar a cabo en un proyecto de S.I.
• Unificar criterios en la organización para el desarrollo de S.I.
• Proporcionar puntos de control y revisión.
Tipos de Metodologías
• Estructurada
• Evolutiva-Incremental
• Prototipos
• Orientada a objetos
• Definir actividades a llevar a cabo en un proyecto de S.I.
• Unificar criterios en la organización para el desarrollo de S.I.
• Proporcionar puntos de control y revisión.
Tipos de Metodologías
• Estructurada
• Evolutiva-Incremental
• Prototipos
• Orientada a objetos
Miembros de un proyecto de Sistemas
•
Líder
(Gerencia el proyecto).
• Analista (recoge información inicial y define requerimientos).
• Diseñador de S.I.
• Diseñador de Bases de Datos (B.D.).
• Programador (Codifica/Prueba).
• Usuario directo. (Expresa necesidades).
• Analista (recoge información inicial y define requerimientos).
• Diseñador de S.I.
• Diseñador de Bases de Datos (B.D.).
• Programador (Codifica/Prueba).
• Usuario directo. (Expresa necesidades).
Agenda
•
Planificación de Proyectos
• Justificación
• Control de Proyectos
• Estudio de Factibilidad
• Análisis
• Diseño
• Implantación
• Actualización
• Justificación
• Control de Proyectos
• Estudio de Factibilidad
• Análisis
• Diseño
• Implantación
• Actualización
Planificación de Proyectos
• Permite saber qué se deberá hacer y quien lo va hacer. Tiempo
estimado de terminación del proyecto (aproximadamente).
• Pone en evidencia los obstáculos relevantes del proyecto, con el fin de tomar las precauciones necesarias.
• Establece marco de referencia que permite trabajar
eficientemente y sin desperdicio de recursos.
• Permite definir la metodología de desarrollo a seguir.
• Herramientas para la planificación (Cronograma de Actividades, Software de Planificación [Project]).
Justificación del proyecto
•
Se establecen las bases para soportar la aprobación.
• Incluye análisis costo/beneficio.
• Verifica:
• Definición correcta de objetivos del proyecto.
• Enunciación correcta de prioridades.
• Optimización de beneficios
• Razones para Proponer proyectos:
• Resolver un problema /necesidad.
• Aprovechar una oportunidad.
• Brindar soluciones a directivos.
• Incluye análisis costo/beneficio.
• Verifica:
• Definición correcta de objetivos del proyecto.
• Enunciación correcta de prioridades.
• Optimización de beneficios
• Razones para Proponer proyectos:
• Resolver un problema /necesidad.
• Aprovechar una oportunidad.
• Brindar soluciones a directivos.
Justificación del proyecto
•
Razones para iniciar proyectos
• Mayor capacidad (velocidad, memoria, recursos)
• Control.
• Reducción de costos.
• Alcanzar ventajas competitivas.
• Mayor capacidad (velocidad, memoria, recursos)
• Control.
• Reducción de costos.
• Alcanzar ventajas competitivas.
Control de Proyectos
•
Tareas del líder de Proyectos
• Prepara y ejecutar planes de acción.
• Dirigir reuniones para identificar y resolver problemas.
• Elaborar y presentar reportes de progresos.
• Ventajas de control de proyecto
• Permite reasignar personas con poca carga.
• Permite intercambiar personal de actividades no críticas a críticas
• Proyecto bajo control
• Cada persona sabe lo que tiene que hacer y cuándo debe hacerlo.
• Nadie está esperando que las cosas ocurran.
• No hay problemas escondidos.
• El líder sabe lo que se ha hecho y lo que no.
• Prepara y ejecutar planes de acción.
• Dirigir reuniones para identificar y resolver problemas.
• Elaborar y presentar reportes de progresos.
• Ventajas de control de proyecto
• Permite reasignar personas con poca carga.
• Permite intercambiar personal de actividades no críticas a críticas
• Proyecto bajo control
• Cada persona sabe lo que tiene que hacer y cuándo debe hacerlo.
• Nadie está esperando que las cosas ocurran.
• No hay problemas escondidos.
• El líder sabe lo que se ha hecho y lo que no.
Control de Proyectos
•
Para
mantener un proyecto
bajo control
• Preparar y seguir planes de acción.
• Realizar reuniones para detectar y corregir problemas.
• Delegar eficientemente.
• Medir el tiempo que realmente hace falta.
• Reconocer los síntomas del fracaso.
• Preparar y seguir planes de acción.
• Realizar reuniones para detectar y corregir problemas.
• Delegar eficientemente.
• Medir el tiempo que realmente hace falta.
• Reconocer los síntomas del fracaso.
Estudio de factibilidad
• Determina si es posible o no ofrecer
solución automatizada a los
problemas/situaciones actuales.
• Representa el primer paso a cumplirse dentro del ciclo de desarrollo.
• Brinda información muy amplia acerca de la unidad a quien se la va a desarrollar el S.I.
• Abarca la factibilidad:
• Técnica (existe tecnología para realizar el S.I).
• Operativa (habrá resistencia al cambio).
• Económica (relación costo/beneficio).
• Representa el primer paso a cumplirse dentro del ciclo de desarrollo.
• Brinda información muy amplia acerca de la unidad a quien se la va a desarrollar el S.I.
• Abarca la factibilidad:
• Técnica (existe tecnología para realizar el S.I).
• Operativa (habrá resistencia al cambio).
• Económica (relación costo/beneficio).
Estudio de Factibilidad
•
Beneficios
• Ahorro s funcionales
• Reducción de costos de operación (tiempo, diner).
• Beneficios tangibles
• Aumento de productividad
• Mejor uso de los activos
• Mejor control
• Beneficios intangibles
• Optimización o simplificación de procedimientos.
• Mayor entusiasmo en los trabajadores.
• Imagen de la organización.
• Mejora en la presición de las operaciones
• Ahorro s funcionales
• Reducción de costos de operación (tiempo, diner).
• Beneficios tangibles
• Aumento de productividad
• Mejor uso de los activos
• Mejor control
• Beneficios intangibles
• Optimización o simplificación de procedimientos.
• Mayor entusiasmo en los trabajadores.
• Imagen de la organización.
• Mejora en la presición de las operaciones
Estudio de factibilidad
Costos:
• Construcción del sistema
• Sueldos de los miembros del proyecto.
• Adiestramiento ( de ser necesario).
• Operación del sistema
• Software
• Hardware
• Mantenimiento.
Análisis
• Amplía resultados del estudio de factibilidad
• Define QUÉ va a hacer el nuevo sistema
• Herramientas
• Técnicas de recolección de información (entrevistas,
cuestionarios)
• Descripciones de procesos y procedimientos
• Diagramas de flujo de datos (herramienta gráfica que se emplea para describir y analizar el movimiento de datos a través de un sistema)
• Diagramas de flujo de procesos (representa el modelaje físico de un sistema, quién y cómo hace las cosas)
• Diccionario de datos (datos de los datos del sistema, catálogo de
los elementos de un sistema
• Construcción del sistema
• Sueldos de los miembros del proyecto.
• Adiestramiento ( de ser necesario).
• Operación del sistema
• Software
• Hardware
• Mantenimiento.
Análisis
• Amplía resultados del estudio de factibilidad
• Define QUÉ va a hacer el nuevo sistema
• Herramientas
• Técnicas de recolección de información (entrevistas,
cuestionarios)
• Descripciones de procesos y procedimientos
• Diagramas de flujo de datos (herramienta gráfica que se emplea para describir y analizar el movimiento de datos a través de un sistema)
• Diagramas de flujo de procesos (representa el modelaje físico de un sistema, quién y cómo hace las cosas)
• Diccionario de datos (datos de los datos del sistema, catálogo de
los elementos de un sistema
Análisis Preliminar
• Para el éxito de un desarrollo de un SI es esencial
una comprensión total de los requisitos.
• No importa lo bien diseñado o codificado que esté un programa, si no se ha analizado correctamente, pues defraudará al usuario y frustrará al desarrollado.
Análisis
• Definición de objetivos específicos del sistema.
• Identificación de usuarios.
• Identificación de procedimientos propuestos
• Elaboración de modelo del sistema actual (lógico y físico).
• Recopilación de reportes del sistema actual.
• Elaboración del modelo del sistema propuesto (lógico y físico).
• Mostrar beneficios potenciales del sistema propuesto.
• Refinación del plan de trabajo y costos.
• Elaboración de planificación del proyecto.
• Elaboración del diccionario de datos.
Análisis de Requisitos
• El análisis de los requisitos es una tarea de ingeniería de software que cubre un huevo entre la definición del software a nivel sistema y el diseño del software.
• El análisis de requisitos permite al ingeniero de sistemas especificar la función y el rendimiento del software, indica la interfaz del software con otros elementos del sistema y establece que debe cumplir el software
Diseño
• Genera soluciones a requerimientos planteados.
• Define CÓMO lo va hacer el nuevo sistema.
• Herramientas:
• Lenguaje de Modelado Unificado (UML), diagramas entidad relación, diagrama estructurado, normalización, diccionario de datos, etc.).
• Base de datos (colección integrada de archivos accesibles por múltiples aplicaciones).
Diseño de Salidas
• Diseño de salidas
• Deben satisfacer objetivos planteados.
• Se deben adaptar al usuario.
• Debe de proveer la cantidad adecuada de información.
• Se debe proporcionar el método apropiado para la salida
(reportes impresos, en pantalla, archivos y en discos).
• La salida debe de ser oportuna y disponible.
Programación/Codificación
• Consiste en traducir el diseño en instrucciones que la computadora pueda interpretar.
• Es la generación del código fuente y código objeto de la aplicación, de acuerdo a los resultados obtenido en el diseño.
• Actividades a cumplir
• Codificación.
• Compilación (corregir sintaxis).
• Depuración (corregir errores de los programas).
Implantación
• Incluye todas las actividades para poner un sistema en producción (entregar al usuario).
• Actividades
• Prueba.
• Conversión.
• Instalación de hardware y software.
• Adiestramiento.
• Documentación.
• Entrega al usuario.
Mantenimiento
• Modificar, corregir o mejorar los sistemas existentes.
• Tipos de Mantenimiento:
• Correctivo (elimina errores).
• Perfectivo (añade nuevas funciones).
• Adaptivo (modifica acciones).
• Preventivo (previene errores).
• Parches: modificaciones menores.
• Importancia de un mantenimiento:
• Si no hay apoyo continuo, el sistema puede dejar de funcionar.
• Un soporte continuo permite a los usuarios el uso adecuado del sistema.
• Permite realizar ajustes necesarios para que aún cuando el ambiente cambie, se pueda hacer uso eficiente de los recursos del sistema.
Mantenimiento
• Dificultades encontradas:
• Documentación inadecuada, obsoleta o inexistente.
• Componentes complejos.
• Componentes mal estructurados.
• Poca familiaridad de las aplicaciones.
• Presión del tiempo.
• Falta de comunicación y participación de los usuarios.
• Gran cantidad de requerimientos.
• Gran cantidad de parches.
• No importa lo bien diseñado o codificado que esté un programa, si no se ha analizado correctamente, pues defraudará al usuario y frustrará al desarrollado.
Análisis
• Definición de objetivos específicos del sistema.
• Identificación de usuarios.
• Identificación de procedimientos propuestos
• Elaboración de modelo del sistema actual (lógico y físico).
• Recopilación de reportes del sistema actual.
• Elaboración del modelo del sistema propuesto (lógico y físico).
• Mostrar beneficios potenciales del sistema propuesto.
• Refinación del plan de trabajo y costos.
• Elaboración de planificación del proyecto.
• Elaboración del diccionario de datos.
Análisis de Requisitos
• El análisis de los requisitos es una tarea de ingeniería de software que cubre un huevo entre la definición del software a nivel sistema y el diseño del software.
• El análisis de requisitos permite al ingeniero de sistemas especificar la función y el rendimiento del software, indica la interfaz del software con otros elementos del sistema y establece que debe cumplir el software
Diseño
• Genera soluciones a requerimientos planteados.
• Define CÓMO lo va hacer el nuevo sistema.
• Herramientas:
• Lenguaje de Modelado Unificado (UML), diagramas entidad relación, diagrama estructurado, normalización, diccionario de datos, etc.).
• Base de datos (colección integrada de archivos accesibles por múltiples aplicaciones).
Diseño de Salidas
• Diseño de salidas
• Deben satisfacer objetivos planteados.
• Se deben adaptar al usuario.
• Debe de proveer la cantidad adecuada de información.
• Se debe proporcionar el método apropiado para la salida
(reportes impresos, en pantalla, archivos y en discos).
• La salida debe de ser oportuna y disponible.
Programación/Codificación
• Consiste en traducir el diseño en instrucciones que la computadora pueda interpretar.
• Es la generación del código fuente y código objeto de la aplicación, de acuerdo a los resultados obtenido en el diseño.
• Actividades a cumplir
• Codificación.
• Compilación (corregir sintaxis).
• Depuración (corregir errores de los programas).
Implantación
• Incluye todas las actividades para poner un sistema en producción (entregar al usuario).
• Actividades
• Prueba.
• Conversión.
• Instalación de hardware y software.
• Adiestramiento.
• Documentación.
• Entrega al usuario.
Mantenimiento
• Modificar, corregir o mejorar los sistemas existentes.
• Tipos de Mantenimiento:
• Correctivo (elimina errores).
• Perfectivo (añade nuevas funciones).
• Adaptivo (modifica acciones).
• Preventivo (previene errores).
• Parches: modificaciones menores.
• Importancia de un mantenimiento:
• Si no hay apoyo continuo, el sistema puede dejar de funcionar.
• Un soporte continuo permite a los usuarios el uso adecuado del sistema.
• Permite realizar ajustes necesarios para que aún cuando el ambiente cambie, se pueda hacer uso eficiente de los recursos del sistema.
Mantenimiento
• Dificultades encontradas:
• Documentación inadecuada, obsoleta o inexistente.
• Componentes complejos.
• Componentes mal estructurados.
• Poca familiaridad de las aplicaciones.
• Presión del tiempo.
• Falta de comunicación y participación de los usuarios.
• Gran cantidad de requerimientos.
• Gran cantidad de parches.
Notas y referencias
- ↑ Shaikh, Aijaz A.; Karjaluoto, Heikki (1 de agosto de 2015). «Making the most of information technology & systems usage: A literature review, framework and future research agenda». Computers in Human Behavior 49: 541-566. doi:10.1016/j.chb.2015.03.059. Consultado el 2 de marzo de 2016.
- ↑ Aceituno, Vicente (2004). Seguridad de la Información. ISBN 84-933336-7-0.
- ↑ Angell, I. O. y Smithson, S. (1991): Information Systems Management: Opportunities and Risks.
- ↑ Bravo, Edgardo R.; Santana, Martin; Rodon, Joan (4 de marzo de 2015). «Information systems and performance: the role of technology, the task and the individual». Behaviour & Information Technology 34 (3): 247-260. ISSN 0144-929X. doi:10.1080/0144929X.2014.934287. Consultado el 7 de marzo de 2016.
- ↑ The Pyramid Model
- ↑ Diferencia entre programa y aplicación
- ↑ Laudon, Jane y Kenneth (2006). Sistemas de información gerencial- Administración de la empresa digital. Pearson Educación- Prentice Hall.
- ↑ Mata, Francisco J.; Fuerst, William L.; Barney, Jay B. (1 de enero de 1995). «Information Technology and Sustained Competitive Advantage: A Resource-Based Analysis». MIS Quarterly 19 (4): 487-505. doi:10.2307/249630. Consultado el 7 de marzo de 2016.
- ↑ Ciborra, C. (2002): Labyrinths of Information, Oxford, Oxford University Press
Bibliografía
- Dostal, J. «School information systems (Skolni informacni systemy).» En Infotech 2007 - modern information and communication technology in education. Olomouc, EU: Votobia, 2007. s. 540-546. ISBN 978-80-7220-301-7.
- Imperial College London - Information Systems Engineering degree - Information Systems Engineering
- O'Leary, Timothy y Linda. (2008). Computing Essentials Introductory 2008. McGraw-Hill on Computing2008.com
- Rainer, R. Kelly y Cegielski, Casey G. (2009). Introduction to Information Systems: Enabling and Transforming Business, 3rd Edition
- Kroenke, David (2008). Using MIS - 2nd Edition.
- Lindsay, John (2000). Information Systems – Fundamentals and Issues. Kingston University, School of Information Systems
- Sage, S. M. "Information Systems: A brief look into history", Datamation, 63-69, Nov. 1968. - Panorama de la historia temprana de los Sistemas de información.
Comentarios
Publicar un comentario