Anda di halaman 1dari 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

METODOLOGÍA

para

DESARROLLO

de

SISTEMAS de INFORMACIÓN

Gestión de Proyectos

ÍNDICE

OBJETIVO

4

ALCANCE

4

LA EVOLUCIÓN DEL SOFTWARE

4

UNA PERSPECTIVA INDUSTRIAL

5

OBREROS DE LA FÁBRICA DE

6

EL SOFTWARE

6

CARACTERÍSTICAS DEL SOFTWARE

6

ORGANIZACIÓN DEL EQUIPO DEL PROYECTO

10

ROLES DEL INGENIERO DEL SOFTWARE

11

EQUIPO DE PROYECTO

11

RESPONSABILIDADES

12

INGENIERÍA DEL SOFTWARE

19

MODELOS DE PROCESO DEL SOFTWARE

20

PRODUCTO Y PROCESO

23

DIAGRAMA RESUMEN

24

DIAGRAMA DE FASES

25

DIAGRAMA DE ETAPAS, TAREAS Y ENTREGABLES POR FASE

27

IMPLANTACIÓN Y CIERRE DEL PROYECTO

35

DESCRIPCIÓN DE LAS FASES

38

FASE: ESTUDIO PRELIMINAR

39

FASE: ESTUDIO FACTIBILIDAD

40

FASE: DESCRIPCIÓN DE NECESIDADES

46

47

DESCRIPCIÓN DE FASES FASE: DESCRIPCIÓN DE NECESIDADES

¡ERROR! MARCADOR NO DEFINIDO.

FASE: DISEÑO GLOBAL

55

FASE: PROCESO DE COMPRAS

¡ERROR! MARCADOR NO DEFINIDO.

FASE: DISEÑO DETALLADO

60

FASE: DISEÑO DETALLADO

61

FASE: CONSTRUCCIÓN

74

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: PRODUCCIÓN

91

FASE: BALANCE DEL PROYECTO

95

CARPETA DE PROYECTOS

97

FASE: DESCRIPCIÓN DE NECESIDADES

97

FASE: ESTUDIO DE FACTIBILIDAD

101

FASE: DISEÑO GLOBAL

108

FASE: DISEÑO DETALLADO

115

FASE: CONSTRUCCIÓN

136

FASE: IMPLANTACIÓN

148

FASE: PRODUCCIÓN

151

FASE: BALANCE DEL PROYECTO

152

ANEXO: MODELO DE PLAN DE PROYECTO

153

ACUERDO DE SERVICIO DE PROYECTO

156

CONTRATO DE SERVICIO DE PRODUCCIÓN

162

MODELO ÚNICO DE CONTRATO DE SERVICIO

168

GLOSARIO

179

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

OBJETIVO Y ALCANCE

OBJETIVO

El objetivo de esta publicación es generar una guía para la gestión de proyectos informáticos basados en el desarrollo de software y brindar un enfoque práctico para establecer los lineamientos generales, el marco metodológico y los responsables en la gestión de un proyecto

a lo largo de todo el ciclo de vida del mismo

Pretende servir a estudiantes y profesionales, brindando una introducción completa al tema de la ingeniería de software.

El formato y estilo de esta primera edición está orientada tanto a los aspectos teóricos, como a los prácticos; ya que se incluye fichas y documentos que se utilizan en los proyectos de desarrollo de software.

ALCANCE

El alcance de esta guía abarca los aspectos metodológicos involucrados desde la identificación de necesidades y la consecuente creación del proyecto hasta la puesta en producción del software, incluyendo su administración y soporte.

LA EVOLUCIÓN DEL SOFTWARE

Roger S. Pressman, dice en su obra que el Software es a la vez un producto y el vehículo de entrega de un producto. Como producto puede residir en un teléfono celular inteligente o una computadora central donde produce, transforma, adquiere, modifica muestra y transmite información tan compleja como un bit o una presentación multimedia.

Como vehículo para hacer entrega del producto actúa como la base de control de una PC (Sistema Operativo), la comunicación de información (Redes) y creación y control de otros programas (Entornos y herramientas de programación).

A lo largo de mi carrera he leído en no poca bibliografía que la programación es “un arte”, y quizás en algún modo lo sea, pero este “arte” no tiene nada de intuitivo ya que se basa en teorías sólidas y metodologías probadas y adoptadas por la industria del software; de acuerdo

a las necesidades / motivaciones de las empresas que consume este “arte” (el software).

Es por ello que quienes estamos en el área de la enseñanza, debemos orientar y ayudar a quienes quieren ser expertos en esta profesión fascinante a contextualizar el concepto de “arte”.

y fundamentalmente

apliquen técnicas y herramientas para crear desarrollos sólidos y perdurables con base en una

documentación orientada a la calidad, ya que es esto lo que las empresas requieren y necesitan del software.

Esta publicación pretende que los

alumnos

comprendan,

dominen

En lo que a mí respecta (y desde ya pido disculpas a quienes opinen diferente) el software antes que creativo debe ser eficiente y eficaz, es decir cumplir con las necesidades de los usuarios y que permita ser construido y mantenido con el mínimo costo y esfuerzo posible.

El software ha sufrido una serie de cambios importantes desde los años 50 del siglo pasado de la mano de avances tecnológicos impresionantes.

En el comienzo de la era informática el desarrollo de software se realizaba prácticamente sin planificación y con un esfuerzo enorme, el hardware era de propósito general y el software se diseñaba a medida; la falta de documentación en los antiguos sistemas los hacía poco menos que inentendibles para quienes no habían participado en su diseño y desarrollo.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Con el advenimiento de facilidades como la multiprogramación y los sistemas multiusuario se abrió un nuevo mundo de aplicaciones, lo que generó una mayor sofisticación del hardware y software.

Luego aparecieron los sistemas de tiempo real y la primera generación de sistemas de gestión de bases de datos. El software a partir de allí se estableció como producto y tuvo una amplia distribución.

Los aspectos de depuración comenzó a tener relevancia ya que la mayor complejidad y diversidad en los sistemas provocaron la aparición de fallas y como consecuencia de esto nació el mantenimiento. Mayor complejidad, demanda, fallas y necesidades especificas, dio lugar al software personalizado. El mantenimiento de este software dio lugar a una crisis en la construcción del software.

Luego los sistemas de tiempo real y la primera generación de sistemas de gestión de bases de datos aparecieron los sistemas distribuidos y las redes de área local y global que provocaron una importante presión sobre los desarrolladores de software. La aparición del microprocesador (ejemplo la familia PIC) produjo muchos productos inteligentes(partes de automóviles, robots, artefactos del hogar, etc.) y la aparición de la computadora personal con su formidable y rápido acceso para él público masivo impactó fuertemente en el desarrollo del software.

Hace ya mucho tiempo se supero el concepto de las computadoras individuales y se oriento al uso colectivo de computadoras y software. Los entornos centralizados pasaron a ser cliente/servidor, la aparición de Internet facilitó la aparición de las tecnologías orientadas a objetos, los sistemas expertos y el software de inteligencia artificial.

Como seguramente el lector podrá percibir en la muy apretada síntesis hasta aquí desarrollada, los problemas relacionados con el software han persistido a lo largo de la evolución de los sistemas informáticos y lastimosamente continúan aumentando. Los motivos del aumento en la problemática del desarrollo del software tiene múltiple aristas.

1. Las empresas requieren un software que explote más y mejor el hardware (que día a día es más sofisticado y especifico)

2. Los desarrolladores se ven expuestos a esta “carrera” (en términos de adquirir habilidades) para satisfacer la demanda de este nuevo software.

3. Las empresas y aún los individuos comunes se han hecho dependientes al software. (imaginen no más lo que significa el uso de los productos como Cajeros automáticos, Pagos de servicios, Compras vía internet, o Webs Banking si fallaran)

4. La comunidad de desarrolladores lucha por la construcción de un software confiable.

5. Lo anteriormente mencionado impacta en la habilidad de soportar el desarrollo con diseños pobres, documentación inadecuada y falta de recursos apropiados.

Una perspectiva industrial

Al principio el software se utilizaba para gestionar el hardware que era el factor principal en el presupuesto del proyecto. Por tal motivo, se aplicaron controles, métodos y herramientas conocidas como ingeniería del hardware y el software no era más que un añadido.

En relación con lo mencionado, es muy lógico que a la programación se la asociara a “un arteya que existía muy pocos métodos formales. Actualmente la construcción del software es en cuanto al costo de un proyecto el elemento mas importante. Cabe aquí cuestionar (en función de orientar al lector novel) ¿ Por qué se demora tanto tiempo en crear el software?, ¿ Por qué es tan oneroso?, ¿ Porque el software cuando se implementa no se encuentra libre de errores? (lo que aumenta el costo de mantenimiento de los sistemas).

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Estas y otras muchas cuestiones han determinado la necesidad de pensar a la construcción del software a verlo más lejos del romántico arte y adoptar conceptos de una “ciencia dura” como la ingeniería del software.

Obreros de la fábrica de software.

Los “obreros del bit”, nuestros queridos ingenieros del software deben poseer herramientas metodológicas basadas en teorías sólidas para lograr la creación y renovación de aplicaciones.

El ingeniero del software debe tener métodos y herramientas para asegurar la calidad y el mantenimiento de los costos dentro de la razonabilidad que las empresas puedan destinar de su presupuesto para obtener un software que sea sustentable.

Las aplicaciones que utilizan datos críticos de la organización debe tener una consideración particular por parte del ingeniero de sistema (y por ende técnicas y herramientas específicas) a fin de resguardar lo más precioso que tiene una empresa (sus datos y el software que contiene las reglas de su negocio).

Un aspecto sobre el cual los ingenieros del software deben tener especial atención es la criticidad en cuanto al uso de los sistemas en una empresa. La salida de servicio de sistemas sensibles de una organización implica la pérdida de enormes sumas de dinero. En este aspecto los ingenieros del software deberán comprender y utilizar las recomendaciones de entes dedicados al aseguramiento de la calidad y productividad como las normas ISO e ITIL.

Sin la intención de que lo expuesto sea toda las “preocupaciones” que los ingenieros deban atender (de hecho no se mencionó aspectos de seguridad y conectividad entre otros), es necesario que el lector comprenda la multiplicidad de aspectos que deberá resolver como “obrero del bit”; de allí la necesidad de apegarse a los métodos, el desarrollo de técnicas y el estricto uso de las herramientas de diseño y construcción de un software.

El software

Hasta ahora, se ha mencionado al software como un sustantivo “mágico” de gran importancia y complejidad pero ¿que es exactamente el software y que significado le damos cuando hablamos de él? La definición estricta indica que el software es:

Instrucciones que cuando se ejecutan proporcionan la función y el rendimiento deseados.

Estructuras

de

datos

que

permiten

a

los

programas

manipular

adecuadamente

 

información

Documentos que describen la operación y uso de programas.

Creo conveniente y estimo necesario considerar algo más que la mencionada definición formal y para ello exploraremos los siguientes aspectos.

Características del software

Cuando el ingeniero del software construye un software mediante el proceso creativo (análisis, diseño, construcción, etc.) se traduce finalmente en una forma física. El software es un elemento del sistema que es lógico en lugar de físico por lo tanto:

a) El software se desarrolla, no se fabrica. La fase de construcción del software depende de la completitud de la fase de descripción de las necesidades y cuando digo completitud me refiero a que no puede existir faltantes en cuanto a la funcionalidad pretendida como a la documentación detallada de cada función pretendida. Es necesario comprender el concepto “de lo general a lo particular” ya que el desarrollador NECESITA todos los detalles funcionales para proceder a la escritura del código y NO DEBE

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

“crear intuitivamente” la funcionalidad del sistema (en esto me baso en cuestionar el concepto de “arte”). Para asegurar el desarrollo del software, es necesario el apego irrestricto al uso de una metodología y utilización de sus herramientas.

b) El software no se estropea. La falla en el software es consecuencia directa de los defectos

en el análisis y diseño del mismo refiriéndonos a la funcionalidad que se espera que cumpla. No es menos importarte (es crucial) efectuar un buen diseño de las pruebas que será sometido el software para asegurar su funcionalidad antes de su puesta en producción. Como un componente vital que se incluye en el proceso de pruebas es diseñar un adecuado circuito para resolver las no conformidades que se detecten a fin de que estos se resuelvan.

Es muy importante que el lector observe que los defectos no detectados del software, hacen que el mismo falle durante las primeras etapas de su vida, de allí la necesidad de una estrategia consistente para evitar la aparición de errores en la puesta en producción. Es muy obvio que el ingeniero del software pondrá especial atención a la corrección (sin introducir nuevos errores), para asegurar que estos no vuelven a aparecer.

Lamentablemente el software en producción, se deteriora. ¿el motivo? El software esta sometido a las solicitudes de cambios por mantenimiento. Las solicitudes de cambio por mantenimiento puede ser por nuevas necesidades o correctivos a funciones existentes. La introducción de solicitudes de cambios puede generar nuevos defectos que antes de que desaparezcan se solicita un nuevo cambio que introduce nuevos errores y así sucesivamente; esto provoca que el mantenimiento del software tiene una complejidad que debe ser tenida muy en cuenta.

c) Componentes del Software

Cuando se diseña nuevo software se utilizan los llamados CI‟s,(ítems Componentes) estos componentes estándares pueden ser reutilizables y son creados por el ingeniero del software para utilizarlo en diferentes lugares de la aplicación. La reutilización de componentes (CI‟s), permite minimizar la tasa de errores (un componente siempre se comporta de igual modo) y redunda en una mayor productividad (generado una sola vez es utilizado en múltiples lugares).

d) Aplicaciones del Software

El software puede construirse siempre que se haya previamente definido un conjunto especifico de pasos procedimentales (algoritmo). Se debe tener en cuenta el contenido, es decir el significado y forma de la información de entrada y salida. Otro aspecto es el determinismo, predecibilidad del orden y del tiempo de llegada de los datos; los datos llegan en orden y se ejecuta un proceso.

e) Software de gestión

El procesamiento de información comercial es el área de mayor desarrollo de aplicaciones. Los sistemas (inventarios, producción, contables, facturación, RRHH, etc.) han evolucionado hacia el software de sistemas de información de gestión (conocidos como ERP) que accede a una o más bases de datos donde está contenida la información comercial para facilitar la toma de decisiones.

f) Crisis en el desarrollo del software. La definición de crisis como el punto decisivo sobre los problemas que un ingeniero del software deberá afrontar en el desarrollo del software, no se limita al software que no funciona, si no que abarca los problemas asociados a como desarrollar software, como mantener el software existente y como afrontar la demanda creciente.

ESTRUCTURA DE LA GUÍA DE GESTIÓN

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Con el propósito de generar una metodología que acompañe el esfuerzo del ingeniero del software en la creación de aplicaciones a continuación se presenta la estructura de la misma.

Niveles de Desagregación Esta guía propone 3 niveles de desagregación, donde la entidad FASE es la que reviste mayor peso como entidad. Las etapas comprendidas en cada fase, se desarrollan en forma secuencial, mientras que las tareas de una misma, pueden ejecutarse en forma paralela.

FASE

ETAPA

TAREA
TAREA

Cada fase se define a través de:

- etapas

- hitos

FASES ETAPAS I M PREPARACIÓN IMPLANTACIÓN P L A N T PUESTA EN PRODUCCIÓN A
FASES
ETAPAS
I
M
PREPARACIÓN
IMPLANTACIÓN
P
L
A
N
T
PUESTA EN
PRODUCCIÓN
A
C
I
O
FORMALIZACIÓN
N
PUESTA EN
PRODUCCIÓN
HITO 5 :
SISTEMA EN PRODUCCIÓN

Cada etapa se define a través de:

- sus tareas,

- entregables (los principales entregables de las tareas de una misma etapa)

- el coordinador (la figura responsable de coordinar todas las tareas dentro de esta etapa)

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

- Ejecución de Confiabilización de Datos

   

- Conversión de Datos

PREPARACIÓN

PREPARACIÓN - Aprobación de Conversión de Datos

- Aprobación de Conversión de Datos

IMPLANTACIÓN

- Carga Inicial y Parametrización

 

- Capacitación

- Comunicación

Inicial y Parametrización   - Capacitación - Comunicación - Aprobación Conversión Datos Líder Funcional

- Aprobación Conversión Datos

Líder

Funcional

Cada tarea se define a través de:

- su descripción,

- los inputs,

- los outputs (o entregables)

- los actores (lista de participantes de la tarea) y

- el responsable (figura responsable de ejecutar esta tarea)

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INPUT

OUTPUT

ACTORES

RESPONSABLE

- Descripción de la Necesidad

- Especificación

- Líder funcional

- Líder funcional

Funcional

- Líder

- Procesos de Negocio

informática

- Usuarios

Cada entregable se define a través de:

- Nombre

- Objetivo

- Contenido

- Responsable

NOM BRE

Descripción de la Necesidad

OBJETIVO

Describir el objetivo y alcance de la necesidad de un nuevo

sistema o una modificación

CONTENIDO

Proyecto:

Responsable:

Sector:

Participantes:

- Objetivo del Proyecto

- Alcance del Proyecto

- Breve Descripción Funcional

- Beneficios esperados / Motivación

- Procesos / Sub-procesos impactados

- Reemplaza sistema/s actual/es? A cuál/es?

- Fecha requerida de implantación

- Documentación asociada

RESPONSABLE

Líder Funcional

Hitos En la finalización de la mayoría de las fases, se desarrollan tareas de revisión, análisis, aprobación y/o convalidación de los principales entregables de las mismas. Estas tareas, por su relevancia, determinan en sí mismas el cierre de la fase. Luego del cierre de la fase y considerando el resultado global de la misma, se conforma una instancia de validación.

Por lo tanto, cada hito se define a través de:

- Tarea de cierre de la fase

- Los inputs,

- Los outputs (o entregables)

- Los actores (lista de participantes)

- El responsable (figura responsable del hito)

- Check list

A su vez, los hitos se pueden clasificar en:

- Hitos de Go- No Go: Aquellos hitos donde se decide la continuación, interrupción y/o postergación de un proyecto

- Hitos de Validación: Aquellos hitos donde se validan y se controla la realización de las tareas y de los entregables de una fase.

ORGANIZACIÓN DEL PROYECTO

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

CONCEPTOS SOBRE GESTIÓN DE PROYECTOS

EL ESPECTRO DE LA GESTIÓN La gestión eficaz de un proyecto de software se centra en las tres „pes‟: personal, problema y proceso.

Personal El modelo de Madurez de gestión de personal define las siguientes áreas prácticas clave para el personal que desarrolla soft:

Reclutamiento

Selección

Gestión de rendimiento

Entrenamiento

Retribución

Desarrollo de la carrera

Diseño de la organización y del trabajo

Desarrollo cultural y espíritu de equipo.

Los participantes

El proceso del software lo componen participantes que pueden clasificarse en una de cinco categorías:

1. Gestores superiores

2. Gestores (técnicos) del proyecto

3. Profesionales

4. Clientes

5. Usuarios finales

Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Éste es el trabajo del jefe del equipo.

Los jefes del equipo

Cuando seleccionamos a alguien para dirigir un proyecto de software se tienen en cuenta las siguientes habilidades, propuestas por el modelo MOI:

Motivación

Organización

Ideas e innovación

Otro punto de vista de las características que definen a un gestor de proyecto eficiente resalta

cuatro apartados clave:

Resolución del problema

Dotes de gestión

Incentivo de los logros

Influencia y construcción de espíritu de equipo

El equipo de software La mejor estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Se sugieren tres organigramas de equipo genéricos:

Descentralizado democrático DD). No tiene un jefe permanente, se nombran coordinadores de tareas a corto plazo. La comunicación entre los miembros es horizontal. Descentralizado controlado (DC). Tiene un jefe definido que coordina tareas y jefes secundarios con responsabilidades sobre sub tareas. Comunicación entre subgrupos e individuos es horizontal. Vertical a lo largo de la jerarquía de control. Centralizado controlado (CC). El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros es vertical.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Paradigmas de organización para equipos de ingeniería de software:

Paradigma cerrado: estructura al equipo con una jerarquía tradicional de autoridad. Paradigma aleatorio: estructura al equipo libremente y depende de la iniciativa individual de los miembros del equipo. Paradigma abierto: estructura el equipo de manera que consiga algunos de los controles asociados con el paradigma cerrado. Paradigma sincronizado: se basa en la compartimentación natural de un problema y organiza los miembros del equipo para trabajar en partes del problema con poca comunicación activa entre ellos.

Aspectos sobre la coordinación y la comunicación Hay muchos motivos por los que los proyectos de software pueden tener problemas: la escala (tamaño), la incertidumbre, la interoperatividad (comunicación soft nuevo con el anterior). Las técnicas de coordinación se categorizan de la siguiente manera:

Formal, enfoque impersonal: incluyen documentos, entregas memorandos técnicos, etc.

Formal, procedimientos interpersonales: actividades de garantía de calidad. Incluyen reuniones de revisión de estado e inspecciones de diseño y de código.

Informal, procedimientos interpersonales: incluyen reunioes de grupo para divulgación de información, resolución de problemas, definición de requisistos etc

Comunicación electrónica: videoconferencia, correos electronicos.

Red interpersonal: discusiones informales con personas que no están en el proyecto pero que pueden tener experiencia.

ORGANIZACIÓN DEL EQUIPO DEL PROYECTO

Los ingenieros del software están habilitados para cumplir cualquier rol en los equipos de implantación, producción o quality assurance (Aseguramiento de calidad). Es importante que el lector comprenda el alcance de los roles a fin de determinar los conocimientos que debe adquirir para desarrollar adecuadamente las tareas del rol.

ROLES DEL INGENIERO DEL SOFTWARE

En esta sección se definen los roles que intervienen en un Equipo de Proyecto. Los mismos no se encuentran asociados a un sector o persona específica de la organización, sino que, en cambio, se definen de manera tal que, de acuerdo al tipo de proyecto, su envergadura y cantidad de entidades involucradas, una persona podrá adoptar más de un rol o por el contrario un rol podrá estar compuesto por más de una persona.

Cabe destacar, que independientemente de los roles específicos, cada integrante del equipo del proyecto deberá garantizar el cumplimiento de las normas de la empresa.

EQUIPO DE PROYECTO

El siguiente diagrama describe una propuesta genérica de la constitución del Equipo del Proyecto. Cabe señalar, que el Comité Director definirá la organización particular para cada proyecto, de acuerdo a la envergadura del mismo.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

COM ITÉ DIRECTOR

RESPONSABLE OWNER DEL RESPONSABLE FUNCIONAL PROYECTO INFORM ÁTICO COM ITÉ EJECUTIVO LÍDER LÍDER FUNCIONAL
RESPONSABLE
OWNER DEL
RESPONSABLE
FUNCIONAL
PROYECTO
INFORM ÁTICO
COM ITÉ EJECUTIVO
LÍDER
LÍDER
FUNCIONAL
INFORM ÁTICO
EXPERTO EN
EXPERTO
PROCESOS DE
RESPONSABLE
INFORM ÁTICO
NEGOCIO
SOPORTE AL
CAM BIO
EXPERTO
RESPONSABLE
SEGURIDAD
CAPACITACIÓN
EXPERTO EN
INFORM ÁTICA
CALIDAD
EXPERTO
EXPERTO
ECONÓM ICO/
TECNOLÓGICO
FINANCIERO
ADM INISTRADOR
FUNCIONAL
PROVEEDOR
EXPERTO EN
(INTERNO o
REDES
EXTERNO)
EQUIPO DE IM PLANTACIÓN
SOPORTE
SOPORTE
ADM INISTRADOR
USUARIOS
APLICATIVO
FUNCIONAL
SOPORTE
SOPORTE
SOPORTE
FUNCIONAL
SEGURIDAD
TÉCNICO
EQUIPO DE PRODUCCIÓN

RESPONSABILIDADES

COMITÉ DIRECTOR Integrado por los responsables ejecutivos de las áreas funcionales, informáticas y de calidad. Sus principales responsabilidades son:

- Monitorear el avance del Plan Director de Sistemas de Información

- Aprobar el lanzamiento de los Proyectos informáticos

- Identificar los aspectos estratégicos del Proyecto

- Garantizar consistencia entre los objetivos de la Organización y los objetivos de los Proyectos

- Monitorear el avance de los Proyectos

- Establecer prioridades y conciliación de conflictos de intereses entre áreas.

- Designar integrantes del Comité Ejecutivo.

El Comité Director podrá delegar sus responsabilidades de acuerdo a la envergadura del proyecto.

COMITÉ EJECUTIVO Integrado por los roles Owner del Proyecto, Responsable Funcional, Responsable Informático y los Usuarios Finales. Sus principales responsabilidades son:

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

- Participar de la planificación, administración y el control del Proyecto informático.

- Garantizar el compromiso de las áreas involucradas y la disponibilidad oportuna del personal clave requerido.

- Acordar expectativas, alcances, objetivos, esquemas de implantación y planes de trabajo al inicio del Proyecto.

- Asegurar que el Proyecto sea consistente con las pautas y alcances fijados. Determinar orientación a adoptar para llevar a cabo el Proyecto.

- Validar documentos y/o productos a obtener en cada fase.

- Definir responsabilidades de las entidades sobre el equipo de implantación en función de la naturaleza de cada Proyecto.

- Interactuar con el Comité Director y el equipo de implantación.

EQUIPO DE IMPLANTACIÓN Integrado por los roles Líder Funcional, Líder Informático, Responsable de Soporte al Cambio, Responsable de Capacitación, Experto tecnológico, Experto informático, Experto en Procesos de Negocio, Experto Económico/Financiero, Experto en Calidad, Experto en Seguridad Informática, Experto en Redes, Administrador Funcional y el Proveedor (Interno o Externo). Sus principales responsabilidades son:

- Generar y ejecutar el diseño global y detallado, los análisis técnicos y funcionales, los planes de trabajo y estrategias de implantación.

- Informar el avance del proyecto al Comité Ejecutivo.

- Implementar bajo la coordinación del Líder Informático, los elementos informáticos (hardware, software de base y de aplicación, redes, capacitación técnica).

- Poner en marcha los nuevos procedimientos definidos bajo la responsabilidad del Líder Funcional.

EQUIPO DE PRODUCCIÓN Integrado por los roles Administrador Funcional, Soporte Usuarios, Soporte Funcional, Soporte Técnico, Soporte en Seguridad y Soporte Aplicativo. Sus principales responsabilidades son:

- Brindar soporte funcional, a través de asesoramiento

- Realizar la administración de los sistemas en producción

- Reparar y restaurar el servicio

- Asegurar la consistencia de la información

- Monitorear la performance de la operación del sistema luego de su puesta en marcha

- Evaluar cumplimiento de los objetivos del sistema

- Identificar cambios y mejoras potenciales

- Detectar desvíos

OWNER DEL PROYECTO Sus principales responsabilidades son:

- Identificar las necesidades en uno o más procesos de negocio de la organización que requiera la solución informática correspondiente.

- Al ser el principal beneficiario del proyecto, es el responsable de “velar” en términos generales por el cumplimiento de la metodología.

RESPONSABLE FUNCIONAL Sus principales responsabilidades son:

- Asesorar al Comité Director con respecto a las decisiones estratégicas vinculadas con la funcionalidad del Sistema y con sus aspectos económicos.

- Coordinar esfuerzos de todos los servicios involucrados en el Proyecto.

- Establecer los recursos funcionales requeridos para el Proyecto, y elevar necesidades respecto a los recursos no funcionales necesarios para el éxito del Proyecto.

- Participar de la definición de esquemas de acceso, seguridad y controles.

- Validar tareas de prueba piloto e implantación.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

- Garantizar la coherencia global del Sistema desde el punto de vista funcional (definiendo procedimientos funcionales, evaluando impactos en la Organización, etc.).

- Junto al Usuario final evaluar beneficios e impactos del Proyecto (en procesos y sistemas) en áreas usuarias priorizando las necesidades.

- Definir los lineamientos generales del Plan de Capacitación del Sistema junto al Responsable Informático.

- Validar el Business Plan del Proyecto.

- Definir y revisar el Acuerdo de Servicio de Proyecto en conjunto con el Responsable Informático.

- Participar en el aseguramiento de la logística necesaria para soportar el Sistema.

- Identificar, en conjunto con el Usuario Final, los impactos organizacionales que genera un cambio de Sistemas/Procesos, la población afectada y el dimensionamiento respecto de las tareas, competencias y localizaciones necesarias previas al cambio.

LÍDER FUNCIONAL Sus principales responsabilidades son:

- Preparar las especificaciones funcionales y los requerimientos del Usuario para los Sistemas en desarrollo.

- Administrar y documentar los requerimientos de acceso, seguridad y controles.

- Validar diseños funcionales y detallados.

- Asegurar la capacitación de los usuarios finales

- Participar y aprobar de las pruebas del producto.

- Supervisar al equipo de implantación en sus aspectos funcionales.

- Coordinar la prueba piloto desde el punto de vista funcional, organizacional, participar de la logística (elegir sitios pilotos y su preparación)

- Coordinar los soportes funcionales locales y la asistencia funcional.

- Fijar objetivos de explotación y seguimiento.

- Evaluar, en la fase de Prueba, si las aplicaciones y entorno satisfacen los requerimientos funcionales.

- Interactuar principalmente con el Responsable Funcional y Líder informático.

- Elaborar el Business Plan del Proyecto junto al Responsable Funcional.

- Participar en la elaboración de los manuales de usuarios

RESPONSABLE INFORMÁTICO Sus principales responsabilidades son:

- Proveer el Sistema Solución o nuevo Sistema a desarrollar, garantizando la coherencia global respecto del resto de los Sistemas de información existentes y proyectados de la compañía.

- Definir los lineamientos del Plan de Capacitación junto con el Responsable Funcional.

- Participar de la definición del esquema de planificación, administración y control del Proyecto:

- planes de trabajo informático y estimación de costos del Proyecto;

- establecer recursos informáticos requeridos para el Proyecto;

- elevar necesidades de recursos no informáticos para el éxito del Proyecto;

- definir las premisas/supuestos del proyecto.

- Informar al Comité Ejecutivo periódicamente sobre el avance del desarrollo, implantación, desvíos, factores críticos identificados, soluciones propuestas, etc.

- Participar en la evaluación técnico/económico de las alternativas de las soluciones propuestas.

- Definir aspectos informáticos del Proyecto, siendo el nexo con los restantes roles del área informática.

- Definir los servicios informáticos a contratar.

- Interactuar principalmente con el Líder Informático y el Responsable Funcional

- Definir y revisar el Acuerdo de Servicio del Proyecto en conjunto con el Responsable Funcional.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

LÍDER INFORMÁTICO Sus principales responsabilidades son:

- Garantizar que el Proyecto, desde el punto de vista informático se realice en tiempo y forma cumpliendo los objetivos y planes de trabajo aprobados por el Comité Ejecutivo.

- Definir la arquitectura informática y el desarrollo del Sistema.

- Nexo con los proveedores involucrados, intermediando entre estos y el Líder Funcional.

- Asegurar capacitación informática del equipo de implantación.

- Garantizar el cumplimiento de los aspectos informáticos del proyecto (requerimientos, desarrollo, etc.)

- Definir las especificaciones detalladas del nuevo Sistema o producto.

- Definir los ambientes de desarrollo, prueba, capacitación y operación del Sistema.

- Asegurar la logística informática necesaria para soportar el Sistema y sus sucesivas versiones.

- Definir desarrollo de adecuaciones necesarias para soportar las especificaciones funcionales recibidas y las de integración con otros Sistemas existentes y/o planificados.

- Monitorear el avance y calidad de las tareas e informar y corregir los desvíos.

- Organizar el Proyecto y preparar los planes de trabajo.

- Interactuar principalmente con el Responsable Informático y el Líder Funcional.

USUARIO FINAL Sus principales responsabilidades son:

- Colaborar y validar la definición de los requerimientos

- Participar y validar las pruebas funcionales del sistema

- Evaluar el sistema una vez implantado.

QUALITY ASSURANCE Sus principales responsabilidades son:

- Determinar los estándares de calidad adecuados para el proyecto y cómo satisfacerlos

- Asegurar la aplicación de una metodología común y un conjunto de estándares compartidos por todos los equipos del proyecto.

- Evaluar periódicamente la realización total del proyecto.

- Colaborar con los líderes del proyecto para detectar y anticipar posibles desvíos y problemas.

- Participar en la elaboración y seguimiento de Plan de Calidad del Proyecto

RESPONSABLE SOPORTE AL CAMBIO Sus principales responsabilidades son:

- Analizar y definir las acciones necesarias para abordar el impacto organizacional generado por la implementación del Proyecto.

- Plan de Distribución Dotacional

- Plan de Comunicación

RESPONSABLE CAPACITACIÓN Sus principales responsabilidades son:

- Definir la Estrategia de Capacitación

- Definir el Plan de Capacitación a Capacitadores, Usuarios Finales y Administradores Funcionales.

- Ejecutar el Plan de Capacitación a Capacitadores, Usuarios Finales y Administradores Funcionales.

- Asegurar la logística necesaria para impartir la capacitación (manuales, materiales, salas, puestos de trabajo, etc.)

- Elaborar los requerimientos para el ambiente de capacitación.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

EXPERTO TECNOLÓGICO Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Sus principales responsabilidades son:

- Asegurar que el sistema a implantar respete los lineamientos del Plan Tecnológico de la Compañía.

- Participar de los estudios de mercado, del análisis de productos y de la identificación de alternativas.

- Colaborar en las pruebas en maqueta.

- Garantizar la coherencia tecnológica de las ofertas presentadas por los proveedores respecto de la tecnología actual y proyectada.

EXPERTO INFORMÁTICO Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Sus principales responsabilidades son:

- Colaborar en el análisis costo/beneficio de un proyecto.

- Participar en el análisis de requerimientos técnicos/funcionales del proyecto

- Colaborar en la elaboración de pliegos

- Definir el plan de contingencia / recuperación de desastres informático.

- Participar en las pruebas del sistema en general con especial participación en las pruebas de performance, volumen y stress.

- Realizar las pruebas de compatibilidad.

- Estudiar y definir el capacity planning

- Definir normas técnicas para la operación del sistema (backups, transmisiones, verificación de equipos, etc.) y controlar que sean cumplidas en la instalación.

- Ejecutar el pasaje a producción

- Evaluar tiempos y costos de terceros y propios relacionados con el proyecto.

- Verificar el parque informático para determinar si la tecnología actual de la empresa está preparada para dicho proyecto.

- Convalidar y evaluar los aspectos técnicos/informáticos de las ofertas de proveedores con respecto al pliego de compra

- Confeccionar el Plan de Pruebas Técnicas y testeo de las mismas, concluyendo en las recomendaciones técnicas pertinentes.

- Definición del Plan de Trabajo Detallado

EXPERTO EN SEGURIDAD INFORMÁTICA Sus principales responsabilidades son:

- Participar del estudio de factibilidad técnico.

- Realizar las recomendaciones necesarias de seguridad ya fijadas y específicas para el proyecto en particular en su comienzo, con el objetivo que sean incorporadas al pliego de compra.

- Verificar el cumplimiento de los requerimientos y normas de seguridad en el análisis de las ofertas.

- Participar de las distintas pruebas, para verificar efectivamente que se hayan realizado las recomendaciones esperadas.

- Aprobar o no desde el punto de vista de la seguridad del sistema la puesta en producción del mismo.

EXPERTO EN PROCESOS DE NEGOCIO Sus principales responsabilidades son:

- Brindar asesoramiento sobre el proceso impactado por la solución informática

- Analizar el impacto del proyecto en el proceso impactado

- Realizar el análisis de alto nivel de todos los nuevos proyectos, evaluando los impactos en los sistemas y en otros proyectos en curso

- Participar en la elaboración de los manuales de procesos.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

EXPERTO EN CALIDAD El experto en calidad es la persona responsable de asegurar la orientación del proyecto hacia los clientes Sus principales responsabilidades son:

- Colaborar en la definición de indicadores

- Colaborar en la elaboración del Plan de Calidad

- Asesorar en metodologías

- Introducir conceptos de aseguramiento de la calidad

- Realizar mediciones de satisfacción

EXPERTO ECONÓMICO/FINANCIERO Sus principales responsabilidades son:

- Colaborar en el Análisis Costo Beneficio y en el Business Plan de las alternativas de solución.

EXPERTO EN REDES Este rol estará llevado a cabo por un grupo de expertos de distintas especialidades. Sus principales responsabilidades son:

- Evaluar el impacto que produce incorporar un nuevo flujo de datos, en equipos y vínculos de comunicación.

- Definir los protocolos de comunicación, las rutas básicas y alternativas, los anchos de banda requeridos, los mecanismos de backup para routers y vínculos, y los sistemas de estadísticas para monitoreo del estado de salud de la red.

ADMINISTRADOR FUNCIONAL Las funciones y responsabilidades del Administrador Funcional están descriptas en el Manual de Normas y Procedimientos vigentes de la Compañía. En general, sus principales responsabilidades son:

- Asesorar acerca de la información que brinda el Sistema y sus funciones en general.

- Definir y habilitar nuevos perfiles y usuarios

- Controlar los Procesos Rutinarios inherentes al sistema

- Coordinar las actividades de capacitación necesarias una vez que el sistema está en producción.

SOPORTE USUARIOS Sus principales responsabilidades son:

- Recibir las consultas y reclamos del usuario

- Responsable del primer nivel de asistencia al usuario

- Diagnosticar el problema, resolver y/o derivar

SOPORTE FUNCIONAL Sus principales responsabilidades son:

- Recibir las consultas y reclamos sobre el funcionamiento de un sistema

- Diagnosticar el problema, resolver y/o derivar

- Identificar nuevos requerimientos y derivarlos al Administrador Funcional

SOPORTE TÉCNICO Normalmente, este rol estará soportado por un grupo de especialistas de distintas disciplinas y sectores. Sus principales responsabilidades son:

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

- Recibir las consultas e incidentes técnicos

- Diagnosticar el problema, resolver y/o derivar

- Verificar y velar por el mantenimiento operativo:

- Hardware

- Software de base

- Bases de Datos

- Conectividad

- Ambiente Operativo

SOPORTE APLICATIVO Sus principales responsabilidades son:

- Ejecutar las modificaciones necesarias sobre el aplicativo (como respuesta a incidentes o debido a nuevas funcionalidades)

- Realizar las pruebas correspondientes

- Mantener la gestión de configuración del aplicativo

- Documentar los cambios en los manuales de sistemas y de usuario

SOPORTE SEGURIDAD Este rol estará soportado por un grupo de especialistas de distintas disciplinas y sectores. Sus principales responsabilidades son:

- Asegurar la integridad y coherencia de los datos

- Asegurar la confidencialidad: identificación, autenticación y control de accesos.

- Recibir, resolver y derivar consultas de inherentes a seguridad

- Realizar el mantenimiento del sistema de solicitud de claves de accesos

ADMINISTRACIÓN Y CONTROL DEL PROYECTO Desde un punto de vista macro, se pueden identificar las siguientes pautas para la administración y control del Proyecto. 1

Cada proyecto definirá:

- La Composición del Grupo de Trabajo, esquema, responsabilidades

- Cronograma consensuado

- Periodicidad de reuniones de seguimiento

- Modalidad del informe de seguimiento que mínimamente deberá contener:

- Estado

- Puntos de atención

- Decisiones a tomar

- Acciones, indicando responsables y fechas

- Próximos Pasos

- Control Presupuestario

Notas:

1 La administración y control del proyecto deberán ser profundizados en la 2° etapa junto con la definición de las herramientas comunes a utilizar para la administración y control.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

INTODUCCIÓN A LA METODOLOGÍA

Definimos un proceso de software como un marco de trabajo de las fases, etapas y tareas que se requieren para construir software de alta calidad.

INGENIERÍA DEL SOFTWARE

Proceso, métodos y herramientas

La ingeniería del software es una tecnología multicapa. Los cimientos que son la base de la ingeniería del software están orientados hacia la calidad. El fundamento de la ingeniería del software es la capa proceso. El proceso define un marco de trabajo para un conjunto de áreas clave de proceso (ACPs) que se debe establecer para la entrega efectiva de la tecnología de la ingeniería del software. Los métodos de la ingeniería del software indican como construir técnicamente el software. Estos abarcan tareas que incluyen el análisis de requerimientos, diseño global, diseño detallado, construcción, pruebas, puesta en producción y mantenimiento. Las herramientas de la ingeniería del software proporcionan un soporte automático o semi- automático para el proceso y para los métodos. Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (Computer-aided software engineering CASE).

Una visión general de la ingeniería del software

El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas:

La fase de definición se centra sobre el qué. El que desarrolla el software intenta

identificar que información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfases van a ser establecidas, qué restricciones de diseño existen, y que criterios de validación se necesitan para definir un sistema correcto.

La fase de desarrollo se centra en el cómo. Definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función como una arquitectura del software, cómo han de caracterizarse las interfases, cómo ha de traducirse el diseño de un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba.

La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante esta fase se encuentran cuatro tipos de cambios:

Corrección. Mantenimiento correctivo para corregir los defectos.

Adaptación. El mantenimiento adaptativo para acomodarlo a los cambios de su entorno externo.

Mejora. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. Mantenimiento preventivo también llamado reingeniería del software, hace cambios en programas de computadoras a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

Las fases y los pasos relacionados descriptos se complementan con un número de actividades en las cuales se incluyen:

Seguimiento y control del proyecto del software

Revisiones técnicas formales

Garantía de calidad del software

Gestión y configuración del software

Preparación de producción de documentos

Gestión de reutilización

Mediciones

Gestión de riesgos

Las actividades se aplican a lo largo de todo el proyecto.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

EL PROCESO DEL SOFTWARE

Se establece:

Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo.

Un conjunto de tareas que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo de proyecto.

Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo de proceso. Estas son independientes de cualquier actividad del marco de trabajo.

Para determinar el estado actual de madurez del proceso, el SEI (Software Engineering Institute) utiliza un cuestionario de evaluación y esquema de cinco grados (Ver Cuestionario en anexo xx):

Nivel 1: Inicial.- Se definen pocos procesos, y el éxito depende del esfuerzo individual.

Nivel 2: Repetible.- Para repetir éxitos anteriores en proyectos con aplicaciones similares se aplica la disciplina necesaria para el proceso.

Nivel 3: Definido.- En este nivel se incluyen nivel 2.

todas las características definidas en el

Nivel 4: Gestionado.- Mediante la utilización de medidas detalladas, se comprenden y se controlan cuantitativamente tanto los productos como los procesos.

Nivel 5: Optimización.- Mediante un resultado cuantitativo del proceso y de las ideas y tecnologías innovadoras se posibilita una mejora del proceso.

El SEI ha asociado las ACP a cada uno de los niveles de madurez. Cada ACP se describe identificando las características siguientes:

Objetivos

Compromisos (requisitos para lograr los objetivos)

Capacidades (elementos que deben encontrarse)

Actividades (tareas especificas)

Métodos para supervisar la implementación

Métodos para verificar la implementación

MODELOS DE PROCESO DEL SOFTWARE

Para resolver los problemas reales en los proyectos de desarrollo de software, un ingeniero del software o un equipo de ingenieros deben aplicar una estrategia de desarrollo que acompañe al proceso, métodos, capas de herramientas y las fases genéricas. Esta estrategia se llama modelo de proceso o paradigma de ingeniería del software. En el presente trabajo se expondrá a nivel detallado los componentes de las fases, etapas, tareas y documentación del ciclo de vida de un proyecto. Todo el desarrollo del software se puede caracterizar como un bucle de resolución de problemas en el que se encuentran las siguientes cuatro etapas teóricas:

Estado Actual: estado actual del problema.

Definición de problemas: identifica el problema específico a resolver.

Desarrollo técnico: resuelve el problema a través de la aplicación de alguna tecnología.

Integración de soluciones: ofrece resultados a los que solicitan la solución en primer lugar.

EL MODELO LINEAL SECUENCIAL

Lo llamaremos “ciclo de vida básico” sugiere un enfoque sistemático, secuencial del desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño (global y

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

detallado),

mantenimiento de un sistema en producción. El ciclo de vida básico acompaña a las

actividades siguientes:

de

construcción

e

implementación.

En

este

trabajo

no

se

incluye

la

fase

Ingeniería y modelado de Sistemas/Información. Como el software siempre forma parte de un sistema más grande, el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos.

Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software.

Diseño (global y detallado). Es un proceso de muchos pasos que se centra en cuatro atributos distintos de un programa:

El diseño básicamente se resuelve mediante el estudio y la generación de herramientas orientadas a los siguientes aspectos:

Estructura de datos

Arquitectura del software

Representaciones de interfaz

Detalle procedimental (algoritmo)

La generación de las herramientas de trabajo (ej. DFD, DD, Diagramas de estructuras, Diagrama de Clases, Diagrama E-R, etc) traduce requisitos en una representación del software que se pueda evaluar por calidad antes de que comience la generación de código. El diseño se documenta. En esta fase, además se definen las estrategias de capacitación, pruebas (unitarias y globales) y de puesta en producción del sistema.

Desarrollo. La orientación del diseño debe alcanzar documentación que permita traducir los requerimientos funcionales a programas.

Implementación. Una vez que se ha generado un código, debe efectuarse las pruebas de los programas. El proceso de pruebas se centra en los procesos lógicos internos del software. Asimismo se incluye las actividades de capacitación e implementación, que se apoya en las estrategias diseñadas en la fase de diseño.

Problemas en el modelo lineal ciclo de vida básico:

1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.

2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos.

3. El cliente debe tener paciencia. Una versión de trabajo del (los) programa (s) no estará disponible hasta que el proyecto esté muy avanzado.

4. Los responsables del desarrollo del software siempre se retrasan respecto de los planes de trabajos concebidos.

EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS

Un cliente a menudo define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento, o salida. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

definición. Entonces aparece un “diseño rápido”. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que necesita hacer.

Problemas del modelo de construcción de prototipos:

1. El cliente ve lo que parece ser una versión de trabajo del software, sin saber que con la

prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo.

2. El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo funcione rápidamente.

EL MODELO DRA

El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una

adaptación a alta velocidad del modelo lineal secuencial utilizando un enfoque de construcción basado en componentes. Comprende las siguientes fases:

Modelado de gestión:

Responde: qué información conduce el proceso, qué información se genera, quién la genera, a dónde va y quién la procesa.

Modelado de datos:

Se definen las características de cada uno de los objetos y las relaciones entre los objetos

Modelado de proceso:

Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.

Generación de aplicaciones:

Trabaja para utilizar componentes ya existentes o a crear componentes reutilizables.

Pruebas y entrega:

Se deben probar todos los componentes nuevos y las interfaces.

Problemas del modelo DRA:

Para proyectos grandes, requiere recursos humanos suficientes para crear los equipos DRA.

Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias.

MODELOS DE PROCESOS EVOLUTIVOS DE SOFTWARE

Modelo incremental Combina elementos del modelo ciclo de vida básico con la filosofía interactiva de construcción de prototipos. Cada secuencia lineal produce un incremento del software. Cuando se utiliza un modelo incremental, el primer incremento es un producto esencial (núcleo). El plan afronta la modificación del producto central para cumplir las necesidades del cliente. Este proceso se repite hasta que se elabore el producto completo. A diferencia de la construcción de prototipos, se centra en la entrega de un producto operacional en cada incremento. Es útil cuando no está disponible el personal para una implementación completa en la fecha límite.

Modelo en espiral Es un modelo de proceso evolutivo que acompaña la naturaleza interactiva de la construcción de prototipos con los aspectos del modelo lineal secuencial. El modelo en espiral se divide en actividades estructurales, también llamadas regiones de tareas:

Comunicación con el cliente

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Planificación: definir recursos, tiempo y otras informaciones relacionadas con el proyecto.

Análisis de riesgos: evaluar riesgos técnicos y de gestión.

Ingeniería: construir una o más representaciones de la aplicación.

Construcción y adaptación: construir, probar, instalar y proporcionar soporte al usuario.

Evaluación del cliente: obtener la reacción del cliente. En todos los casos se aplican las actividades de protección.

Modelo de ensamblaje de componentes El modelo de ensamblaje de componentes configura aplicaciones desde componentes preparados de software(“clases”). Es un modelo evolutivo e interactivo. Se identifican las clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a aplicar para conseguir el tratamiento. Las clases creadas se almacenan en una biblioteca de clases. Una vez identificadas las clases candidatas se examina si ya existen y en ese caso se vuelven a utilizar. Se compone así la primera interacción de la aplicación a construirse. Este modelo lleva a la reutilización del software.

Modelo de desarrollo concurrente Define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Todas las actividades existen concurrentemente, pero residen en estados diferentes.

MODELO DE MÉTODOS FORMALES

El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la especificación matemática del software. La ambigüedad, lo incompleto y la inconsistencia se descubren y corrigen mediante el análisis matemático. Inconvenientes:

Caro y lleva mucho tiempo.

Los desarrolladores poseen pocos antecedentes necesarios.

Difícil comunicación con el cliente con pocos conocimientos técnicos.

TÉCNICAS DE CUARTA GENERACIÓN

El paradigma de las “técnicas de cuarta generación” (T4G) se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones gráficas que describan el problema que hay que resolver en términos que los entienda el cliente. Actualmente, incluye algunas de las siguientes herramientas: lenguajes no procedimentales de consulta de base de datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo.

TECNOLOGÍA DE PROCESOS

Los modelos de procesos tratados se deben adaptar para utilizarse por el equipo de proyecto. Para conseguirlo, se han desarrollado herramientas de tecnología de procesos que permiten que una organización de software construya un modelo automatizado de la estructura común del proceso, conjuntos de tareas y actividades de protección.

PRODUCTO Y PROCESO

Las personas obtienen tanta satisfacción del proceso creativo que del producto final. La dualidad de producto y proceso es un elemento importante para mantener ocupada a la gente creativa hasta que se finalice la transición de la programación a la ingeniería del software.

DIAGRAMA DE FASES Y ETAPAS

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Habiendo efectuado un repaso de los diferentes modelos de diseño de aplicaciones existentes, debemos elegir uno a fin de desarrollar detalladamente las actividades que los equipos de desarrollo deben realizar. Teniendo en cuenta lo anteriormente dicho, creemos conveniente desarrollar el modelo ciclo de vida básico, también conocido como “Modelo Lineal Secuencial”. Este modelo nos permitirá alcanzar el objetivo pedagógico que perseguimos que es saber hacer siguiendo un modelo formal e intuitivo.

DIAGRAMA RESUMEN

En esta primera aproximación del modelo, se presenta un esquema resumen con las fases generales y los hitos de continuación o detención (go no-go) del proyecto.

Es importante resaltar que un proyecto de sistemas se inicia con la identificación de las necesidades, y culmina con la implantación y la puesta en producción del sistema junto con el balance o cierre correspondiente. Desde el momento en que el sistema se pasa a producción, comienza una nueva fase que no está incluída en el ciclo de vida del proyecto: la fase de Producción. Ésta, tiene vida propia y finalizará cuando el sistema deje de operar.

Dentro del ciclo de vida del proyecto, se debe generar dos contratos:

1. Acuerdo de Servicio de Proyecto, suscripto entre el Owner del Proyecto y el Responsable Informático y que acompaña al proyecto durante todo su ciclo de vida

2. Contrato de Servicio de Producción entre el usuario del sistema y los proveedores (internos y externos) del servicio. Este contrato acompaña al sistema durante toda su vida de producción.

(internos y externos) del servicio. Este contrato acompaña al sistema durante toda su vida de producción.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DIAGRAMA DE FASES

A continuación, se presenta un diagrama completo con todas las fases de un proyecto, los hitos go, no-go, y de control y los acuerdos y contratos de servicio.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García 26 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DIAGRAMA DE ETAPAS, TAREAS Y ENTREGABLES POR FASE

Vamos describir el diagrama de las etapas, enunciaremos las tareas y entregables de cada una de las fases que compone la metodología que adoptamos.

DESCRIPCIÓN DE NECESIDADES Y ESTUDIO PRELIMINAR

adoptamos. DESCRIPCIÓN DE NECESIDADES Y ESTUDIO PRELIMINAR FASES D N E E S C C E

FASES

D N E E S C C E R S I I P D C
D
N
E
E
S
C
C
E
R
S
I
I
P
D
C
A
I
D
Ó
E
N
S
de

E

P

S

R

T

E

U

L

D

I

I

M

O

I

N

A

R

ETAPAS

DESCRIPCIÓN

NECESIDADES

ESTUDIO DE

FACTIBILIDAD

TAREAS

 

-

Identificar Necesidades

- Relevamiento Global

-

Relevamiento Global

-

Descripición de Objetivos y Alcance

 

-

Especificar Requerimiento

- Alineamiento Plan Maestro Sistemas

- Alineamiento Plan Tecnológico

-

Alineamiento Plan Estratégico

- Identificación de Alternativas

- Análisis Factibilidad Técnica

- Identificación Modalidad de Proyecto

- Análisis Impacto del Proyecto

- Análisis Impacto del Proyecto

- Análisis Costo Beneficio

- Business Plan

 

- Análisis DAFO

- Identificación Métricas

- Elaboración Inf. Ejecutivo Est. Factiblidad

- Actualización Plan Maestro

- Análisis de Presupuesto

- Confección del Acuerdo de Servicio

HITO 0: APROBACIÓN PROYECTO

del Acuerdo de Servicio HITO 0: APROBACIÓN PROYECTO ENTREGABLES - Descripción de la Necesidad - Estudio
del Acuerdo de Servicio HITO 0: APROBACIÓN PROYECTO ENTREGABLES - Descripción de la Necesidad - Estudio
del Acuerdo de Servicio HITO 0: APROBACIÓN PROYECTO ENTREGABLES - Descripción de la Necesidad - Estudio
del Acuerdo de Servicio HITO 0: APROBACIÓN PROYECTO ENTREGABLES - Descripción de la Necesidad - Estudio
del Acuerdo de Servicio HITO 0: APROBACIÓN PROYECTO ENTREGABLES - Descripción de la Necesidad - Estudio
del Acuerdo de Servicio HITO 0: APROBACIÓN PROYECTO ENTREGABLES - Descripción de la Necesidad - Estudio

ENTREGABLES

- Descripción de la Necesidad

- Estudio Factibilidad Técnico/

Funcional

- Estudio Factibilidad Económico

- Métricas Claves

- Informe Ejecutivo Estudio

Factiibilidad

- Plan Maestro Actualizado

- Acuerdo de Servicio (Borrador)

- Carta de Decisión

- Acuerdo de Servicio

COORDINADOR

Líder

Funcional

Líder

Funcional

de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional
de Servicio (Borrador) - Carta de Decisión - Acuerdo de Servicio COORDINADOR Líder Funcional Líder Funcional

El objetivo de las fases Descripción de las necesidades y el Estudio preliminar del Sistema es el análisis de un conjunto concreto de necesidades para proponer una solución a corto plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas.

La solución obtenida como resultado del estudio será la definición de uno o varios proyectos que afecten a uno o varios sistemas de información ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situación actual.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

A partir del estado inicial, la situación actual y los requisitos planteados, se estudian las alternativas de

solución.

Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en

la adquisición de productos software del mercado o soluciones mixtas. Se describe cada una de las

alternativas, indicando los requisitos que cubre.

Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organización, la inversión a realizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación.

Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al

sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso.

Las actividades que engloba este proceso se menciona a continuación:

Descripción de Necesidades

Identificar Necesidades

Relevamiento Global

Descripción de Objetivos y Alcances

Especificar Requerimientos.

Estudio Preliminar

Alineamiento al Plan Maestro de Sistemas

Alineamiento al Plan Tecnológico

Alineamiento al Plan Estrategico

Identificación de Alternativas

Análisis de Factibilidad Técnica

Identificación de la Modalidad del Proyecto

Análisis Impacto del Proyecto

Análisis de Costo Beneficio

Business Plan

Análisis DAFO (Debilidades y Fortalezas)

Identificación de Métricas

Elaboración del Informe Ejectivo del Estudio de Factibilidad

Actualización Plan Maestro

Análisis de Presupuesto

Confección del Acuerdo de Servicio.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DISEÑO GLOBAL Y PROCESO DE COMPRAS

Lic. Roberto García DISEÑO GLOBAL Y PROCESO DE COMPRAS FASES ETAPAS TAREAS ENTREGABLES COORDINADOR D G
FASES ETAPAS TAREAS ENTREGABLES COORDINADOR D G - Descripción Requerimientos Funcionales I - Especificación
FASES
ETAPAS
TAREAS
ENTREGABLES
COORDINADOR
D
G
- Descripción Requerimientos Funcionales
I
- Especificación Funcional
L
- Análisis de Requerimientos
- Plan Maestro Actualizado
S
O
- Impacto en Arquitectura Técnica
-
Arquitectura Técnica
E
- Realización de Especificación
B
Actualizada
Ñ
ESPECIFICACIÓN
- Plan General de Trabajo
A
Líder
-
Especificación Técnica
O
GENERAL
- Definición de Equipo de Trabajo
Funcional
L
-
Plan General de Trabajo
- Administración de Riesgo
- Equipo de Trabajo
- Quality Management
- Carta de Decisión Actualizada
- Revisión Modalidad de Proyecto
- Est Fact Económica Act.
-
Revisión de Business Plan
-
Especifiación Convalidada
HITO 1: CONVALIDACIÓN ESPECIFICACIÓN
P
C
-
Requerimiento de Compras
-
Requerimiento de Compras
R
O
-
Preparación Pliego
- Pliego
CONCURSO
Compras
O
Convalidación Pliego
-
- Circulares Aclaratorias
M
C
- Publicación
- Ofertas (Técnica y Económica)
P
E
R
S
A
- Análisis Ofertas
-
Preinforme Técnico
O
Líder
S
ANALÍSIS
-
Pruebas de Funcionamiento en Maqueta
- Preinforme Técnico de Pruebas
Informático
de
TÉCNICO
Emisión Dictamen Técnico
-
- Dictamen Técnico
ANÁLISIS
Análisis Económico
-
- Dictamen Económico
Compras
ECONÓMICO
-
Acta de Adjudicación
HITO 2: ADJUDICACIÓN
- - Dictamen Económico Compras ECONÓMICO - Acta de Adjudicación HITO 2: ADJUDICACIÓN - Documento de
- - Dictamen Económico Compras ECONÓMICO - Acta de Adjudicación HITO 2: ADJUDICACIÓN - Documento de

- Documento de Compra

- - Dictamen Económico Compras ECONÓMICO - Acta de Adjudicación HITO 2: ADJUDICACIÓN - Documento de

El objetivo de este proceso es la obtención de una especificación global del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño detallado del sistema. Se lleva a cabo la descripción inicial del sistema de información, a partir de los productos generados en el proceso Estudio Preliminar. Se delimita el alcance del sistema, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. También se identifican los usuarios que participan en el proceso de análisis, determinando sus perfiles, responsabilidades y dedicaciones necesarias. Así mismo se elabora el plan de trabajo a seguir. La definición de requisitos del nuevo sistema se realiza con el objetivo de elaborar el catálogo de requisitos detallado, que permita describir con precisión el sistema de información, y que además sirva de base para comprobar que es completa la especificación de los modelos obtenidos en las actividades Identificación de requerimientos

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Para la obtención de requisitos se toman como punto de partida el catálogo de requisitos y los modelos elaborados en la actividad Definición del Sistema, completándolos mediante sesiones de trabajo con los usuarios. Estas sesiones de trabajo tienen como objetivo reunir la información necesaria para obtener la especificación detallada del nuevo sistema. Las técnicas que ayudan a la recopilación de esta información pueden variar en función de las características del proyecto y los tipos de usuario a entrevistar. Entre ellas podemos citar las reuniones, entrevistas, Joint Application Design (JAD), etc. Durante estas sesiones de trabajo se propone utilizar la especificación de los casos de uso como ayuda y guía en el establecimiento de requisitos. Esta técnica facilita la comunicación con los usuarios y en el análisis orientado a objetos constituye la base de la especificación.

A continuación se identifican las facilidades que ha de proporcionar el sistema, y las restricciones a que

está sometido en cuanto a rendimiento, frecuencia de tratamiento, seguridad y control de accesos, etc. Toda esta información se incorpora al catálogo de requisitos. Con la información recopilada, se estructura el sistema de información en subsistemas, para facilitar la especificación de los distintos modelos y la traza de requisitos. En paralelo, se generan los distintos modelos que sirven de base para el diseño. En el caso de análisis

estructurado, se procede a la elaboración y descripción detallada del modelo de datos y de procesos, y en

el caso de un análisis orientado a objetos, se elaboran el modelo de clases y el de interacción de objetos,

mediante el análisis de los casos de uso. Se especifican, asimismo, todas las interfaces entre el sistema y el usuario, tales como formatos de

pantallas, diálogos, formatos de informes y formularios de entrada. En la actividad impacto de la arquitectura técnica se efectúa el Análisis de Consistencia y Especificación de Requisitos, se realiza la verificación y validación de los modelos, con el fin de asegurar que son:

- Completos, puesto que cada modelo obtenido contiene toda la información necesaria recogida en el catálogo de requisitos.

- Consistentes, ya que cada modelo es coherente con el resto de los modelos.

- Correctos, dado que cada modelo sigue unos criterios de calidad predeterminados en relación a la técnica utilizada, calidad de diagramas, elección de nombres, normas de calidad, etc.).

La participación activa de los usuarios es una condición imprescindible para el análisis del sistema de información, ya que dicha participación constituye una garantía de que los requisitos identificados son comprendidos e incorporados al sistema y, por tanto, de que éste será aceptado. Para facilitar la colaboración de los usuarios, se pueden utilizar técnicas interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DISEÑO DETALLADO Y CONSTRUCCIÓN

Prof. Lic. Roberto García DISEÑO DETALLADO Y CONSTRUCCIÓN FASES ETAPAS TAREAS ENTREGABLES COORDINADOR Líder
Prof. Lic. Roberto García DISEÑO DETALLADO Y CONSTRUCCIÓN FASES ETAPAS TAREAS ENTREGABLES COORDINADOR Líder

FASES

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

Líder

Informático

Líder

Funcional

     
   
   
    HITO 3: APROBACIÓN DISEÑO DETALLADO   Especificación Técnica de Detalle  

HITO 3: APROBACIÓN DISEÑO DETALLADO

HITO 3: APROBACIÓN DISEÑO DETALLADO
 

Especificación Técnica de Detalle

 
 
   

-

PARAMETRIZACIÓN Y DESARROLLO PRUEBAS PRUEBA PILOTO DEFINICIÓN PLAN DE IMPLANTACIÓN
PARAMETRIZACIÓN
Y DESARROLLO
PRUEBAS
PRUEBA PILOTO
DEFINICIÓN
PLAN DE
IMPLANTACIÓN
PRUEBAS PRUEBA PILOTO DEFINICIÓN PLAN DE IMPLANTACIÓN HITO 4: DECISIÓN DE IMPLANTACIÓN Acuerdo de Implantación

HITO 4: DECISIÓN DE IMPLANTACIÓN

PRUEBAS PRUEBA PILOTO DEFINICIÓN PLAN DE IMPLANTACIÓN HITO 4: DECISIÓN DE IMPLANTACIÓN Acuerdo de Implantación
Acuerdo de Implantación
Acuerdo de Implantación

Acuerdo de Implantación

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Fase de Diseño Detallado.

El objetivo de la Fase de Diseño Detallado es la definición de la arquitectura del sistema y del entorno

tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información.

A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio

sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda.

Las actividades de este proceso se agrupan en dos grandes bloques. 1.- En un primer bloque de actividades, que se llevan a cabo en paralelo, se obtiene el diseño de detalle del sistema de información. La realización de estas actividades exige una continua realimentación.

En general, el orden real de ejecución de las mismas depende de las particularidades del sistema de información y, por lo tanto, de generación de sus productos.

Se establece el particionamiento físico del sistema de información, así como su organización en subsistemas de diseño, la especificación del entorno tecnológico, y sus requisitos de operación, administración, seguridad y control de acceso.

Se completan los catálogos de requisitos y normas, en función de la definición del entorno tecnológico, con aquellos aspectos relativos al diseño y construcción que sea necesario contemplar.

Asimismo, se crea un catálogo de excepciones del sistema, en el que se registran las situaciones de funcionamiento secundario o anómalo que se estime oportuno considerar y, por lo tanto, diseñar y probar. Este catálogo de excepciones se utiliza como referencia en la especificación técnica de las pruebas del sistema.

El sistema de información se estructura en subsistemas de diseño. Éstos a su vez se clasifican como de

soporte o específicos, al responder a propósitos diferentes.

Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la instalación, y generalmente están originados por la interacción con la infraestructura técnica o la reutilización de otros sistemas, con un nivel de complejidad técnica mayor.

También se especifica en detalle el entorno tecnológico del sistema de información, junto con su planificación de capacidades (capacity planning), y sus requisitos de operación, administración, seguridad y control de acceso.

El diseño detallado del sistema de información, siguiendo un enfoque estructurado, comprende un conjunto de actividades que se llevan a cabo en paralelo a la Definición de la Arquitectura del Sistema.

El alcance de cada una de estas actividades se resume a continuación:

Diseño de la Arquitectura de Soporte

Diseño de la Arquitectura de Módulos del Sistema

Diseño Físico de Datos

En el caso de Diseño Orientado a Objetos, conviene señalar que el diseño de la persistencia de los objetos se lleva a cabo sobre bases de datos relacionales, y que el diseño detallado del sistema de información se realiza en paralelo con la actividad de Diseño de la Arquitectura de Soporte, y se corresponde con las siguientes actividades:

Diseño de Casos de Uso Reales.

Diseño de Clases

En el caso de que sea necesario, se realiza la definición de un plan de migración y carga inicial de datos.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Una vez que se tiene el modelo de clases, se comienza el diseño físico en la actividad Diseño Físico de Datos.

2.- El segundo bloque de actividades complementa el diseño del sistema de información. En él se generan todas las especificaciones necesarias para la construcción del sistema de información:

Generación de Especificaciones de Construcción.

Diseño de la Migración y Carga Inicial de Datos

Especificación Técnica del Plan de Pruebas

Establecimiento de Requisitos de Implantación

Fase de Construcción

En este proceso se genera el código de los componentes del Sistema de Información, se desarrollan todos los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de explotación con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantación.

Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las pruebas de integración de los subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas establecido.

Asimismo, se define la formación de usuario final y, si procede, se construyen los procedimientos de migración y carga inicial de datos.

El producto Especificaciones de Construcción del Sistema de Información, es la base para la construcción del sistema de información.

En dicho producto se recoge la información relativa al entorno de construcción del sistema de información, la especificación detallada de los componentes y la descripción de la estructura física de datos, tanto bases de datos como sistemas de ficheros. Opcionalmente, incluye un plan de integración del sistema de información, en el que se especifica la secuencia y organización de la construcción de los distintos componentes.

Se asegura la disponibilidad de la infraestructura necesaria para la generación del código de los componentes y procedimientos del sistema de información.

Una vez configurado el entorno de construcción, se realiza la codificación y las pruebas de los distintos componentes que conforman el sistema de información, mediante las siguientes actividades genericas:

Generación del Código de los Componentes y Procedimientos, que se hace según las especificaciones de construcción del sistema de información, y conforme al plan de integración del sistema de información.

Ejecución de las Pruebas Unitarias, dónde se llevan a cabo las verificaciones definidas en el plan de pruebas para cada uno de los componentes

Ejecución de las Pruebas de Integración, que incluye la ejecución de las verificaciones asociadas a los subsistemas y componentes, a partir de los componentes verificados individualmente, y la evaluación de los resultados.

Una vez construido el sistema de información y realizadas las verificaciones correspondientes, se lleva a cabo la integración final del sistema de información en la actividad de Pruebas globales (GST), comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema.

En la actividad Elaboración de los Manuales del sistema Usuario, se genera la documentación de usuario final o explotación, conforme a los requisitos definidos en el proceso Diseño del Sistema de Información.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

La formación necesaria para que los usuarios finales sean capaces de utilizar el sistema de forma satisfactoria se especifica en la actividad Plan de Capacitación.

Si se ha establecido la necesidad de realizar una migración de datos, la construcción y pruebas de los componentes y procedimientos relativos a dicha migración y a la carga inicial de datos se realiza en la actividad Estrategia de Conversión y Estrategia de Carga de Datos.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

IMPLANTACIÓN Y CIERRE DEL PROYECTO

Lic. Roberto García IMPLANTACIÓN Y CIERRE DEL PROYECTO FASES B P A R L O A

FASES

B P A R L O A Y N E C C E T O
B
P
A
R
L
O
A
Y
N
E
C
C
E
T
O
de

TAREAS

 

-

Ejecución de Confiabilización de Datos

-

Conversión de Datos

- Aprobación de Conversión de Datos

-

Aprobación de Conversión de Datos

-

Carga Inicial y Parametrización

 

-

Capacitación

- Comunicación

- Realización Implantación

- Realización Implantación

- Aceptación Implantación

 

- Contrato de Servicio de Producción

- Documentación Puesta en Producción

- Documentación Puesta en Producción

(Anexo el Proc. de Producción)

HITO 5: SISTEMA EN PRODUCCIÓN

ENTREGABLES

 
 

-

Aprobación Conversión Datos

 
- Recepción Provisoria

-

Recepción Provisoria

 

-

Contrato de Servicio Producción

- Doc. Soporte Mesa de Ayuda

-

Doc. Soporte Mesa de Ayuda

actualizado

-

Doc. Soporte a Operaciones/

 

Soporte actualizado

- Informe Sistema en Producción

-

Informe Sistema en Producción

Líder

Funcional

Líder

Informático

Administrador

Funcional

COORDINADOR

- Balance del Proyecto - Informe de Cierre del Proyecto Líder Funcional - Líder Informático

- Balance del Proyecto

- Balance del Proyecto - Informe de Cierre del Proyecto Líder Funcional - Líder Informático
- Informe de Cierre del Proyecto

-

- Informe de Cierre del Proyecto
- Informe de Cierre del Proyecto

Informe de Cierre del Proyecto

Líder

Funcional -

Líder

Informático

ETAPAS

PREPARACIÓN

IMPLANTACIÓN

PUESTA EN

PRODUCCIÓN

FORMALIZACIÓN

PUESTA EN

PRODUCCIÓN

EN PRODUCCIÓN FORMALIZACIÓN PUESTA EN PRODUCCIÓN COMIENZA FASE DE PRODUCCIÓN BALANCE DEL PROYECTO
COMIENZA FASE DE PRODUCCIÓN
COMIENZA FASE DE
PRODUCCIÓN

BALANCE DEL

PROYECTO

Este proceso tiene como objetivo principal la entrega y aceptación del sistema en su totalidad, y la realización de todas las actividades necesarias para el paso a producción del mismo.

En primer lugar, se revisa la estrategia de implantación que ya se determinó en la Fase de Estudio Preliminar. Se estudia su alcance y, en función de sus características, se define un plan de implantación y se especifica el equipo que lo va a llevar a cabo.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Conviene señalar la participación del usuario de operación en las pruebas de implantación, del usuario final en las pruebas de aceptación, y del responsable de mantenimiento.

Las actividades previas al inicio de la producción incluyen la preparación de la infraestructura necesaria para configurar el entorno, la instalación de los componentes, la activación de los procedimientos manuales y automáticos asociados y, cuando proceda, la migración o carga inicial de datos.

Para ello se toman como punto de partida los productos software probados, obtenidos en la fase de Construcción del Sistema de Información y su documentación asociada.

Se realizan las pruebas de implantación y de aceptación del sistema en su totalidad. Responden a los siguientes propósitos:

Las pruebas de implantación cubren un rango muy amplio, que va desde la comprobación de cualquier detalle de diseño interno hasta aspectos tales como las comunicaciones. Se debe comprobar que el sistema puede gestionar los volúmenes de información requeridos, se ajusta a los tiempos de respuesta deseados y que los procedimientos de respaldo, seguridad e interfaces con otros sistemas funcionan correctamente. Se debe verificar también el comportamiento del sistema bajo las condiciones más extremas.

Las pruebas de aceptación se realizan por y para los usuarios. Tienen como objetivo validar formalmente que el sistema se ajusta a sus necesidades.

Asimismo, se llevan a cabo las tareas necesarias para la preparación del mantenimiento, siempre y cuando se haya decidido que éste va a efectuarse. En cualquier caso, es necesario que la persona que vaya a asumir el mantenimiento conozca el sistema, antes de su incorporación al entorno de producción.

Además hay que determinar los servicios (y niveles para cada uno) que requiere el sistema que se va a implantar, y el acuerdo que se adquiere una vez que se inicie la producción. Hay que distinguir entre servicios de gestión de operaciones (servicios por lotes, seguridad, comunicaciones, etc.) y servicios al cliente (servicio de atención a usuario, mantenimiento, etc.) que se deben negociar en cuanto a recursos, horarios, costo, etc.

Se fija el nivel con el que se prestará el servicio como indicador de la calidad del mismo.

Conviene señalar que la implantación puede ser un proceso iterativo que se realiza de acuerdo al plan establecido para el comienzo de la producción del sistema en su entorno de operación. Para establecer este plan se tiene en cuenta:

El cumplimiento de los requisitos de implantación definidos en la fase de Descripción de las Necesidades.

La estrategia de transición del sistema antiguo al nuevo.

Finalmente, se realizan las acciones necesarias para el inicio de la producción.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

PRODUCCIÓN

Informáticos Prof. Lic. Roberto García PRODUCCIÓN FASES ETAPAS TAREAS ENTREGABLES COORDINADOR
Informáticos Prof. Lic. Roberto García PRODUCCIÓN FASES ETAPAS TAREAS ENTREGABLES COORDINADOR

FASES

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

ADMINISTRACIÓN

TÉCNICA

ADMINISTRACIÓN

FUNCIONAL

SOPORTE

EVOLUCIÓN

- Procesos Backup

- Procesos Seguridad
-- Procesos Seguridad

Procesos Performance

-

Control de Procesos Rutinarios

- Otros procesos

-

Administración de Usuarios y Perfiles

Parámetros- Otros procesos - Administración de Usuarios y Perfiles - Mantenimiento de Datos, Tablas y -

-

Mantenimiento de Datos, Tablas y

- Capacitación Nuevos Usuarios

-

Atención a Usuarios

Soporte Funcionaly - Capacitación Nuevos Usuarios - Atención a Usuarios - - Soporte Técnico - Soporte Aplicativo

-

-

Soporte Técnico

-

Soporte Aplicativo

Nuevos Requerimientos-

-

 
 

-

Tablero de Mando

 
  - Tablero de Mando   - Tablero de Mando   - Tablero de Mando  

-

Tablero de Mando

 
  - Tablero de Mando   - Tablero de Mando   - Tablero de Mando  

-

Tablero de Mando

 
  - Tablero de Mando   - Tablero de Mando   - Tablero de Mando  

-

Nuevo Proyecto

 

Soporte

Técnico

Administrador

Funcional

Administrador

Funcional

Administrador

Funcional

Es importante señalar, que en la fase de Producción las etapas no presentan una secuencialidad, ya que las tareas correspondientes a esta fase pueden realizarse en forma paralela independientemente de la etapa a la que pertenecen.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

DESCRIPCIÓN DE LAS FASES

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: ESTUDIO PRELIMINAR

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE: ESTUDIO FACTIBILIDAD

FASE ETAPAS TAREAS ENTREGABLES COORDINADOR - Alineamiento Plan Maestro Sistemas E P - Alineamiento Plan
FASE
ETAPAS
TAREAS
ENTREGABLES
COORDINADOR
- Alineamiento Plan Maestro Sistemas
E
P
- Alineamiento Plan Tecnológico
S
R
- Alineamiento Plan Estratégico
T
E
- Identificación de Alternativas
-
Estudio Factibilidad Técnico/
U
L
- Análisis Factibilidad Técnica
Funcional
D
I
- Identificación Modalidad de Proyecto
-
Estudio Factibilidad Económico
- Análisis Impacto del Proyecto
Líder
I
M
ESTUDIO DE
-
Métricas Claves
- Análisis Costo Beneficio
Funcional
O
I
FACTIBILIDAD
-
Informe Ejecutivo Estudio
- Business Plan
N
Factiibilidad
- Análisis DAFO
A
-
Plan Maestro Actualizado
- Identificación Métricas
-
Acuerdo de Servicio (Borrador)
R
-
Elaboración Inf. Ejecutivo Est. Factiblidad
- Actualización Plan Maestro
- Análisis de Presupuesto
-
Confección del Acuerdo de Servicio
- Carta de Decisión
HITO 0: APROBACIÓN PROYECTO
- Acuerdo de Servicio

1 ETAPA: ESTUDIO DE FACTIBILIDAD

El propósito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solución a corto plazo. Los criterios con los que se hace esta propuesta no serán estratégicos sino tácticos y relacionados con aspectos económicos, técnicos, legales y operativos.

Los resultados del Estudio de factibilidad del Sistema constituirán la base para tomar la decisión de seguir adelante o abandonar. Si se decide seguir adelante pueden surgir uno o varios proyectos que afecten a uno o varios sistemas de información. Dichos sistemas se desarrollarán según el resultado obtenido en el estudio de viabilidad y teniendo en cuenta la cartera de proyectos para la estrategia de implantación del sistema global.

Se ha considerado que este proceso es obligatorio, aunque el nivel de profundidad con el que se lleve a cabo dependerá de cada caso. La conveniencia de la realización del estudio de la situación actual depende del valor añadido previsto para la especificación de requisitos y para el planteamiento de alternativas de solución. En las alternativas se considerarán soluciones "a medida", soluciones basadas en la adquisición de productos software del mercado o soluciones mixtas.

Para valorar las alternativas planteadas y determinar una única solución, se estudiará el impacto en la organización de cada una de ellas, la inversión y los riesgos asociados.

El resultado final de este proceso son los productos relacionados con la solución que se propone para cubrir la necesidad concreta que se planteó en el proceso, y que depende de:

Si la solución conlleva desarrollo a medida o no:

Contexto del sistema (con la definición de las interfaces en función de la solución).

Impacto en la organización.

Coste/beneficio de la solución.

Valoración de riesgos de la solución.

Enfoque del plan de trabajo de la solución.

Planificación de la solución.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Solución propuesta:

Descripción de la solución.

Modelo de descomposición en subsistemas.

Matriz de procesos/localización geográfica.

Matriz datos/localización geográfica.

Entorno tecnológico y comunicaciones.

Estrategia de implantación global del sistema.

Descripción de los procesos manuales.

Si la alternativa incluye desarrollo:

Modelo abstracto de datos/Modelo de procesos.

Modelo de negocio/Modelo de dominio.

Si la alternativa incluye un producto software estándar de mercado:

Descripción del producto.

Evolución del producto.

Costes ocasionados por el producto.

Estándares del producto.

Descripción de adaptación si es necesaria.

Si en la organización se ha realizado con anterioridad un Plan de Sistemas de Información que afecte al sistema objeto de este estudio, se dispondrá de un conjunto de productos que proporcionarán información a tener en cuenta en todo el proceso.

2 Alineamiento Plan Maestro de Sistemas

Análisis de coherencia del proyecto con el Plan Maestro de Sistemas

 

INPUT

 

OUTPUT

ACTORES

RESPONSABLE

-

Descripción de la Necesidad (F1)

-

Validación

- Líder funcional

- Líder informático

alineamiento

- Líder Informático

-

Plan Maestro de Sistemas

 

- Experto tecnológico

3

Alineamiento Plan Tecnológico

 

Análisis de coherencia del proyecto con el Plan Tecnológico

INPUT

 

OUTPUT

ACTORES

RESPONSABLE

- Descripción de la Necesidad (F1)

-

Validación

- Experto tecnológico

- Experto tecnológico

alineamiento

- Líder informático

- Plan Tecnológico

 

- Líder funcional

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

4 Alineamiento Plan Estratégico

Análisis de coherencia del proyecto con los lineamientos estratégicos de la Compañía, y análisis de impacto en los procesos de negocio y / o en los clientes

 

INPUT

 

OUTPUT

ACTORES

 

RESPONSABLE

 

-

Descripción de la Necesidad (F1)

-

Validación

- Líder funcional

-

Líder funcional

alineamiento

- Experto tecnológico

 

-

Lineamientos Estratégicos

 

- Líder informático

- Experto en procesos

5

Identificación de Alternativas Análisis Factibilidad Técnica Identificación Modalidad del Proyecto

Se identifican y proponen las posibles alternativas técnicas, se analiza el impacto del proyecto sobre otros sistemas. Realización del análisis de factibilidad técnica. Evaluación técnica para identificar si el parque microinformático es el adecuado. Análisis de compatibilidad. Ver productos existentes en la empresa. Investigación de productos del mercado e identificación preliminar de modalidad del proyecto: producto off- the-shelf o desarrollo a medida. Propuesta de modalidad de adquisición (llave en mano, contratación de horas hombre, etc.)

 

INPUT

 

OUTPUT

ACTORES

RESPONSABLE

-

Descripción de la Necesidad (F1)

-

Estudio de

- Líder funcional

- Líder informático

Factibilidad

- Líder Informático

-

Plan Maestro

técnico/funcional

- Experto tecnológico

-

Lineamientos Tecnológicos

 

- Experto seguridad informática

6

Análisis de Impacto del Proyecto

 

Se identifican el impacto de cada alternativa en función de:

- Procesos

- Usuarios.

 

INPUT

 

OUTPUT

ACTORES

RESPONSABLE

-

Descripción de la Necesidad (F1)

-

Estudio de

- Líder funcional

- Líder funcional

Factibilidad

- Experto en procesos

-

Estudio de Factibilidad técnico/funcional

técnico/funcional

- Usuario

7

Análisis Costo Beneficio Business Plan

 

Evaluación económica/financiera del proyecto (Business Plan, cálculo de VAN, TIR, etc.). Preparación del presupuesto. Se considerará como horizonte del análisis todo el ciclo de vida del producto y se incluirá inversiones, gastos iniciales y upgrades, releases, capacitaciones, mantenimiento, otros. Además se considerarán costos de terceros, como también las horas del personal propio que se imputarán al proyecto.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

 

INPUT

 

OUTPUT

 

ACTORES

 

RESPONSABLE

-

Descripción de la Necesidad (F1)

-

Estudio de

-

Líder funcional

-

Líder funcional

Factibilidad

-

Experto

 

-

Estudio de Factibilidad técnico/funcional

económico

económico/financier

 

o

-

Experto informático

8

Análisis DAFO

Análisis DAFO. Identificación de Factores Claves de Éxito., riesgos, barreras/restricciones, aspectos legales (marco regulatorio).

 

INPUT

OUTPUT

 

ACTORES

 

RESPONSABLE

-

Descripción de la Necesidad (F1)

- Análisis DAFO

-

Líder funcional

-

Líder funcional

- Factores Claves de

-

Experto

 

-

Estudio de Factibilidad técnico/funcional

Éxito.

económico/financier

- Riesgos

o

-

Experto informático

-

Estudio de Factibilidad económico

 

9

Identificación de Métricas

 

Identificación de métricas operativas, funcionales y financieras, y sus objetivos, con las que se podrá evaluar los resultados de haber realizado el proyecto.

INPUT

OUTPUT

 

ACTORES

 

RESPONSABLE

- Descripción de la Necesidad (F1)

- Métricas clave para evaluación

-

Líder funcional

-

Líder funcional

-

Experto

 

- Estudio de Factibilidad técnico/funcional

- Valores objetivo de las métricas

económico/financier

o

 

-

Experto informático

- Estudio de Factibilidad económico

-

Experto en calidad

10 Elaboración del Informe Ejecutivo de Estudio de Factibilidad

En base a los Estudios de Factibilidad Técnico/Funcional y Económico se elabora un Resumen Ejecutivo para la presentación al Comité Director.

INPUT

 

OUTPUT

ACTORES

 

RESPONSABLE

- Estudio de Factibilidad Técnico/Funcional

- Estudio de Factibilidad Económica

-

Informe Ejecutivo de Estudio de Factibilidad

- Líder Informático

-

Líder funcional

- Líder Funcional

 

11 Actualización del Plan Maestro

Una vez aprobado el proyecto, se deberá actualizar el Plan Maestro de Sistemas incluyendo el nuevo proyecto, y sus impactos. Esta tarea se llevará a cabo después de la Aprobación del Proyecto (Hito 0)

43 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

 

INPUT

 

OUTPUT

 

ACTORES

RESPONSABLE

-

Plan Maestro de Sistemas

-

Plan Maestro

-

Líder Informático

- Líder Informático

Actualizado

 

12 Análisis de Presupuesto

Analizar y definir el presupuesto a asignar para las etapas del proyecto. Identificar y designar el o los owners de presupuesto.

INPUT

OUTPUT

ACTORES

RESPONSABLE

- Estudio de Factibilidad Técnica/Funcional

- Asignación

- Comité Director

- Comité Director

Presupuestaria

- Comité Ejecutivo

- Designación de

- Estudio de Factibilidad Económica

owner/s de

presupuesto

13 Confección de Acuerdo de Servicio

Confección del Borrador del Acuerdo de Servicio entre el Owner del Proyecto y el Responsable Informático para el Proyecto de Sistemas. En proyectos de gran envergadura, el responsable funcional y el responsable informático llevarán adelante la negociación de este acuerdo.

 

INPUT

 

OUTPUT

ACTORES

 

RESPONSABLE

-

Estudio de Factibilidad Técnica/Funcional

-

Acuerdo de Servicio (Borrador)

- Owner del Proyecto

-

Líder Funcional

- Líder Informático

 
 

- Líder Funcional

 

- Experto en Calidad

HITO 0: APROBACIÓN DEL PROYECTO

 

El Comité Director analizará la información generada en la Fase Estudio Preliminar y tomará la DECISIÓN de aprobación del proyecto en forma conjunta. Obtención asignación de partida presupuestaria. Revisión y firma del Acuerdo de Servicio

INPUT:

- Informe Ejecutivo Estudio de Factibilidad

- Acuerdo de Servicio (Borrador)

OUTPUT:

- Carta de Decisión (Proyecto Aprobado)

- Carta de Decisión (Proyecto Rechazado)

- Acuerdo de Servicio (Firmado)

ACTORES:

- Líder funcional

- Experto económico/financiero

- Responsable informático

- Responsable tecnológico

- Responsable procesos

- Owner del Proyecto

- Usuario

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

RESPONSABLE: - Comité Director 2 Check-list  Designación del Owner del Proyecto  Identificación del
RESPONSABLE:
- Comité Director 2
Check-list
 Designación del Owner del Proyecto
 Identificación del Owner del Presupuesto
 Documentos:
 Descripción de la Necesidad (F1)
 Estudio de Factibilidad Técnico/Funcional
 Estudio de Factibilidad Económica
 Métricas Claves
 Informe Ejecutivo de Estudio de Factibilidad
 Acuerdo de Servicio
 Presupuesto (monto y asignación)
 Plazos
 Modalidad del Proyecto
“APROBACIÓN DEL PROYECTO” constituye el HITO 0
de Validación del Owner del Proyecto.

Notas:

2 El Comité Director delegará su responsabilidad de acuerdo a la importancia del proyecto.

45 de 181

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

FASE

DESCRIPCIÓN DE NECESIDADES

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

0.- DESCRIPCIÓN

ETAPAS

TAREAS

ENTREGABLES

COORDINADOR

D N E E S C C E R S I I P D C
D
N
E
E
S
C
C
E
R
S
I
I
P
D
C
A
I
D
Ó
E
N
S
de

DESCRIPCIÓN

NECESIDADES

DESCRIPCIÓN NECESIDADES - Identificar Necesidades   - Relevamiento Global - Descripción de la Necesidad

- Identificar Necesidades

- Identificar Necesidades  
 

- Relevamiento Global

- Descripción de la Necesidad

- Descripición de Objetivos y Alcance

- Especificar Requerimiento

 

Líder

Funcional

1.- Análisis del Sistema de Información

El propósito de este proceso es conseguir la especificación detallada del sistema de información, a través de un catálogo de requisitos y una serie de modelos que cubran las necesidades de información de los usuarios para los que se desarrollará el sistema de información y que serán la entrada para el proceso de Diseño del Sistema de Información.

En primer lugar se describe inicialmente el sistema de información, a partir de los productos generados en el proceso Estudio de Factibilidad del Sistema. Se delimita su alcance, se genera un catálogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel.

Se recogen de forma detallada los requisitos funcionales que el sistema de información debe cubrir, catalogándolos, lo que permite hacer la traza a lo largo de los procesos de desarrollo. Además, se identifican los requisitos no funcionales del sistema, es decir, las facilidades que ha de proporcionar el sistema, y las restricciones a que estará sometido, en cuanto a rendimiento, frecuencia de tratamiento, seguridad, etc.

Para facilitar el análisis del sistema se identifican los subsistemas de análisis, y se elaboran los modelos de Casos de Uso y de Clases, en desarrollos orientados a objetos, y de Datos y Procesos en desarrollos estructurados. Se ha incorporado una actividad específica para la definición de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y los anteriores modelos. Se especificarán todas las interfaces entre el sistema y el usuario, como formatos de pantallas, diálogos, formatos de informes y formularios de entrada.

Finalizados los modelos, se realiza un análisis de consistencia, mediante una verificación y validación, lo que puede forzar la modificación de algunos de los modelos obtenidos.

Una vez realizado dicho análisis de consistencia se elabora el producto Especificación de Requisitos Software, que constituye un punto de referencia en el desarrollo del software y la línea base de referencia para las peticiones de cambio sobre los requisitos inicialmente especificados.

En este proceso se inicia también la especificación del Plan de Pruebas, que se completará en el proceso Diseño del Sistema de Información.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Los productos resultantes del Análisis del Sistema de Información, dependen del tipo de desarrollo de que se trate y se detallan a continuación especificando los que son distintos, según los dos tipos de desarrollo mencionados:

Descripción general del entorno tecnológico.

Glosario de términos.

Catálogo de normas.

Catálogo de requisitos.

Especificación de interfaz de usuario.

Además, en Análisis Estructurado.

Plan de migración y carga inicial de datos.

Contexto del sistema.

Matriz de procesos/localización geográfica.

Descripción de interfaz con otros sistemas.

Modelo de procesos.

Modelo lógico de datos normalizado.

Además, en Análisis Orientado a Objetos.

Descripción de subsistemas de análisis.

Descripción de interfaces entre subsistemas.

Modelo de clases de análisis.

Comportamiento de clases de análisis. / Diagramas híbridos

Análisis de la realización de los casos de uso.

En este proceso es muy importante la participación de los usuarios, a través de técnicas interactivas, como diseño de diálogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construcción y perfeccionamiento del mismo.

2.- ETAPA: DESCRIPCIÓN DE NECESIDADES

INPUT

OUTPUT

ACTORES

RESPONSABLE

- Necesidad

- Descripción de la Necesidad (F1)

- Líder funcional

- Líder funcional

- Owner del Proyecto

 

- Usuario Final

2.1 Identificar Necesidades - Relevamiento Global - Descripción de Objetivos y Alcance Especificar Requerimiento.

Ante una necesidad detectada (mejora de un proceso, nuevo proceso, introducción de un nuevo servicio), y una motivación clara y definida se lleva adelante un relevamiento global. Definir el objetivo y alcance del proyecto y realizar la especificación del requerimiento funcional.

Se realiza una descripción general de la necesidad planteada por el usuario, y se estudian las posibles restricciones de carácter económico, técnico, operativo y legal que puedan afectar al sistema. Antes de

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

iniciar el estudio de los requisitos del sistema se establecen los objetivos generales del Estudio de Viabilidad, teniendo en cuenta las restricciones identificadas anteriormente.

Si el sistema objeto de estudio se encuentra en el ámbito de un Plan de Sistemas de Información vigente, se debe de tomar como referencia el catálogo de requisitos y la arquitectura de información resultante del mismo, como información adicional para la descripción general del sistema y determinación de los requisitos iniciales.

3.- ESTABLECER EL ALCANCE DEL SISTEMA

Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronización con otros proyectos, que puedan interferir en la planificación y futura puesta a punto del sistema objeto del estudio. Esta información se recoge en el catálogo de requisitos.

Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, se debe tener en cuenta la arquitectura de información propuesta para analizar el alcance del sistema e identificar los sistemas de información que quedan fuera del ámbito del estudio. Además, se estudia el plan de proyectos, para determinar las posibles dependencias con otros proyectos.

Una vez establecido el alcance, se identifican las unidades organizativas afectadas por el sistema, así como su estructura y responsables de las mismas. Para determinar los responsables se tiene en cuenta a quiénes afecta directamente y quiénes pueden influir en el éxito o fracaso del mismo.

En función del alcance del sistema y los objetivos del Estudio de Viabilidad del Sistema, se determinan las actividades y tareas a realizar. En particular, hay que decidir si se realiza o no el estudio de la situación actual y, en el caso de considerarlo necesario, con qué objetivo.

Si el sistema pertenece al ámbito de un Plan de Sistemas de Información, los criterios que pueden orientar sobre la necesidad de llevar a cabo el estudio de la situación actual dependen de la arquitectura de información propuesta, en cuanto a la identificación de los sistemas de información actuales, implicados en el ámbito de este estudio, que se haya decidido conservar.

Se identifican los usuarios participantes de las distintas unidades organizativas afectadas para la realización del Estudio de Viabilidad del Sistema, determinando previamente sus perfiles y responsabilidades.

Debe comunicarse el plan de trabajo a los usuarios identificados como implicados en el Estudio de Viabilidad, solicitando su aceptación y esperado su confirmación.

4.- ESTUDIO DE LA SITUACIÓN ACTUAL

La situación actual es el estado en el que se encuentran los sistemas de información existentes en el momento en el que se inicia su estudio.

Teniendo en cuenta el objetivo del estudio de la situación actual, se realiza una valoración de la información existente acerca de los sistemas de información afectados. En función de dicha valoración, se especifica el nivel de detalle con que se debe llevar a cabo el estudio.

Si es necesario, se constituye un equipo de trabajo específico para su realización y se identifican los usuarios participantes en el mismo.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

Si se decide documentar la situación actual, normalmente es conveniente dividir el sistema actual en subsistemas. Si es posible se describirá cada uno de los subsistemas, valorando qué información puede ser relevante para la descripción.

Como resultado de esta actividad se genera un diagnóstico, estimando la eficiencia de los sistemas de información existentes e identificando los posibles problemas y las mejoras.

5.- DEFINICIÓN DE REQUISITOS DEL SISTEMA

Esta actividad incluye la determinación de los requisitos generales, mediante una serie de sesiones de trabajo con los usuarios participantes, que hay que planificar y realizar.

Una vez finalizadas, se analiza la información obtenida definiendo los requisitos y sus prioridades, que se añaden al catálogo de requisitos que servirá para el estudio y valoración de las distintas alternativas de solución que se propongan.

6.- CONCEPTOS Y PRINCIPIOS DEL ANALISIS

Tanto el desarrollador como el cliente tienen un papel activo en el análisis y especificación de los requisitos.

6.1 ANALISIS DE REQUISITOS

Es una tarea que permite al ingeniero de sistemas:

- Especificar la función y rendimiento del soft.

- Indicar la interfaz del soft con otros elementos del sistema

- Establecer las restricciones que debe cumplir el soft

- Construir los modelos de dominios de datos, funcional y comportamiento

- Proporciona al diseñador y al cliente los medios para valorar la calidad una vez que se ha construido el software.

El análisis de requisitos se puede dividir en 5 áreas:

1)

Reconocimiento del problema

2)

Evaluación y síntesis - qué ¿? -

3)

Modelado del sistema

4)

Especificación del software

5)

Revisión

El desarrollador puede no estar seguro de que un enfoque específico consiga apropiadamente el funcionamiento y rendimiento adecuados. Por esta y otras muchas razones, se puede llevar a cabo un enfoque alternativo del análisis de requisitos, denominado prototipato o creación de prototipos.

6.2 TECNICAS DE COMUNICACIÓN

6.2.1 Inicio del proceso

Para empezar la comunicación entre cliente y desarrollador se lleva a cabo una reunión o entrevista preliminar. Se sugiere que el analista empiece preguntando cuestiones de contexto libre, es decir un conjunto de preguntas que llevarán a un entendimiento básico del problema. Pero el formato de pregunta- respuesta de reunión tipo, no es un enfoque que haya tenido mucho éxito. Esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro y sustituírse después por una modalidad que combine elementos de resolución de problema, negociación y especificación.

6.2.2 técnicas para facilitar las especificaciones de una aplicación.

Sistemas de Información Gestión de Proyectos Informáticos Prof. Lic. Roberto García

El

creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución. TFEA DIRECTRICES BÁSICAS:

- La reunión se celebra en un lugar neutral y acuden tanto clientes como los desarrolladores.

- Se establecen normas de preparación y de participación.

enfoque de Técnicas para Facilitar las Especificaciones de la Aplicación (TFEA), es partidario de la

- Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes pero lo suficientemente informal como para animar el libre flujo de ideas.

- Un coordinador para coordinar la reunión.

- Se usa un mecanismo de definición gràficos, carteles, pizarra, hojas de trabajo

- Objetivo: identificar el problema, proponer elementos de solución.

6.2.3 Despliegue de la función de calidad

El Despliegue de la Función Calidad (DFC) es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnico del software. DFC identifica 3 tipos de requisitos:

- Requisitos normales: se declaran objetivos y metas para un producto o sistema durante reuniones con el cliente. Si estos requisitos están presentes el cliente estará satisfecho.

- Requisitos esperados: son implícitos al producto o sistema y pueden ser tan fundamentales que el cliente no los declara explícitamente. Su ausencia será motivo de una insatisfacción significativa.

- Requisitos innovadores: estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias. El producto entregado contiene ciertas capacidades no esperadas.

El despliegue de función se utiliza para determinar el valor de cada función requerida para el sistema.

7.- PRINCIPIOS DEL ANALISIS

Todos los métodos de análisis se relacionan por un conjunto de Principios operativos:

1)

Debe representarse y entenderse el dominio de información de un problema.

2)

Deben definirse las funciones que debe realizar el sotf.

3)

Debe representarse el comportamiento del soft (como consecuencia de acontecimientos externos)