01 Sistemas

Sistemas y Sub Sistemas

Feedback

Control

Diseño

Gerencia

Manufactura Entorno

Ventas

Elementos de un Sistema de Información

Atributos de la Información

Dimensión Tiempo Oportunidad

Debe suministrarse en el momento que sea mnecesaria

Actualidad

Debe ser reciente al momento de suministrarse

Frecuencia

Debe suministrarse con la frecuencia que sea necesaria

Periodo

Puede proporcionarse sobre periodos pasados, presentes y futuros

Dimensión Contenido Exactitud

Debe estar libre de errores

Pertinencia

Debe estar relacionada con las necesidades de información de un destinatario específico

Integridad

Debe suministrarse toda la información que sea necesaria

Brevedad

Debe proporcionarse sólo la información que se necesite

Alcance

Puede tener alcance amplio o estrecho y un enfoque interno o externo

Desempeño

Puede revelar el desempeño alcanzado, las actividades logradas, los recursos acumulados

Dimensión Forma Claridad

Debe suministrarse en un formato fácil de entender

Detalle

Puede proporcionarse en formato de detalle o resumen

Orden

Puede ordenarse en una secuencia predeterminada

Presentación

Puede presentarse en forma narrativa, numérica, gráfica u otros

Medios

Puede proporcionarse en forma de documentos, video u otros.

Finalidad de un Sistema de Información

La información reduce nuestra incertidumbre (sobre algún aspecto de la realidad) y, por tanto, nos permite tomar mejores decisiones Los Sistemas de Información deben cumplir objetivos básicos: 3. Automatización de procesos operativos, acelerando procesos y reduciendo costos operativos 4. Proporcionar información que sirva de apoyo al proceso de toma de decisiones y gestión de recursos 5. Lograr ventajas competitivas a través de su implantación y uso.

Preocupación en la Industria del Software

He visitado docenas de tiendas comerciales, tanto buenas como malas, y he observado proyectos de sistemas de información de soporte a estos procesos, de nuevo buenos como malos. Con mucha frecuencia he visto con horror cómo los gerentes de proyectos de sistemas, luchan inútilmente con proyectos de pesadilla, sufriendo por fechas límite imposibles o sistemas entregados que indignaron a sus usuarios y devoraron una enorme cantidad de tiempo de mantenimiento. [PAG85 Page-Jones, M. Practical Project Management, Dorset House, 1985, p.viii

Qué factores contribuyeron a generar esta situación?

Preocupación en la Industria del Software

Porqué se tarda tanto en la obtención del software terminado? Porqué son tan altos los costos de desarrollo del software? Porqué es imposible encontrar todos los errores en el software antes de entregarlo a los clientes? Porqué se gasta tanto tiempo y esfuerzo en el mantenimiento de los programas existentes? Porqué es difícil medir el progreso al desarrollar y mantener el software? Estimación de desarrollo y costos impreciso Sobre costos y Costos ocultos

Mitos de la Administración

Ya se tiene un libro de estándares y procedimientos para la construcción del software. Esto proporcionará a mi gente el conocimiento necesario. Es cierto que existe, pero, se usa?, es práctico, está completo?, es adaptable?

Estamos atrasados en los cronogramas, necesitamos mas programadores Agregar gente a un proyecto atrasado, lo atrasa más

Si subcontratamos el proyecto de software, podemos relajarnos y dejar que la empresa lo construya. Si no es posible entender la naturaleza de los proyectos de software entraremos en conflicto con la empresa contratada

Mitos de los Clientes

Un enunciado general de los objetivos es suficiente para comenzar a escribir los programas, los detalles se pueden afinar después. Objetivos ambiguos son la receta perfecta para el fracaso del software Los requerimientos precisos se desarrollan sólo mediante la comunicación continua.

Los cambios a los requerimientos pueden ajustarse con facilidad Es cierto, pero el impacto del cambio varía de acuerdo a la etapa en que se encuentre

Mitos de los Desarrolladores

Una vez que el programa haya sido escrito y puesto a funcionar, el trabajo está terminado Entre mas rápido se empiece a codificar, más tiempo pasará hasta terminar

Mientras el programa no esté instalado no se podrá evaluar su calidad El QA es posible de ser aplicado desde el inicio del proyecto, documentación La misma que sirve para los trabajos de mantenimiento. La Ing. de Software implica la elaboración de documentación voluminosa lo que hace que el proceso de software sea más lento. La Ing. de Software está relacionada con la creación de calidad, la misma que reduce trabajos innecesarios, por lo tanto reduce los tiempos de entrega

Esquema de Ingeniería de Software

No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable Actividades Herramientas

Personas

Proceso SW Artefactos

Roles

RUP

ISO

PMI

RAD

CMM

Notación

Las 4 P de la Gestión de Proyectos

PERSONA: La ingeniería de software es un trabajo con humanos Ejecutivos, clientes, usuarios finales, profesionales de TI Comunicación, organización, resolución de conflictos, rasgos personales y “conflicto de intereses”

Las 4 P de la Gestión de Proyectos

PRODUCTO: Soluciones elegantes para problemas equivocados Determinación del alcance del sistema, descomposición funcionalidad básica. El usuario requiere plazos y cronograma “Estudio preliminar”

Las 4 P de la Gestión de Proyectos

PROCESO: El proceso de software debe ser configurado y adecuado a la situación.

Comunicación

Intensa colaboración y entendimiento con los clientes

Planeación

Determinar las tareas, responsables, plazos, riesgos, recursos y entregas

Modelado

Empleo de técnicas que ayudan al entendimiento entre clientes y técnicos

Construcción

Generación de código (auto, manual), pruebas

Despliegue

Entrega del producto de software a los clientes

Las 4 P de la Gestión de Proyectos

PROYECTO: WW 5HH [BOE96 Boehm, B., “Anchoring the software process” IEEE Software, v13 n4 1996]

Preguntas que conducen a una definición de las características claves del proyecto y proporcionan excelentes lineamientos para la planificación: Why: el propósito del proyecto justifica el gasto en personal, tiempo y dinero? What: las tareas requeridas para desarrollar el proyecto When: planificación del proyecto: tareas y producto Who: establecer la responsabilidad a los miembros del equipo Where: las responsabilidades también están fuera del equipo de software: usuarios y clientes How: además del requerimiento (qué) es necesario definir el cómo se desarrolla

How much: cuántos recursos de cada tipo serán consumidos durante el proyecto.

Compromiso de todos los involucrados

NEGOCIO

Usuarios

Gerencia Optimización

Analista

Modelado Gestión de Requerimientos

Soporte Gestión de Proyecto

Análisis Y Diseño

Arquitecto

Despliegue

Despliegue

Construcción Pruebas

Programador

Entrenamiento SOPORTE

Calidad

DESARROLLO

Facilitar la comunicación, asegurar la calidad del producto final, aumentar la productividad, instrumentalizar el mantenimiento, mejorar la predicción sobre los planes y presupuestos, Incrementa la satisfacción de los usuarios