Modelo de formulación y evaluación financiera de proyectos de desarrollo de tecnologías de...

279
Sistema de Estudios de Posgrado Maestría en Administración de Tecnología de Información Proyecto Integrado II Proyecto de Aplicación Práctica de Tecnología de Información Modelo de Formulación y Evaluación Financiera de Proyectos de Desarrollo de Tecnologías de Información para el Ministerio de Hacienda Tutor: Ismael Mora Camacho Xinia Madrigal Chaves M A T i U N A

description

Modelo de formulación y evaluación financiera de proyectos de desarrollo de tecnologías de información para el Ministerio de Hacienda

Transcript of Modelo de formulación y evaluación financiera de proyectos de desarrollo de tecnologías de...

Sistema de Estudios de Posgrado

Sistema de Estudios de Posgrado

Maestra en Administracin de Tecnologa de Informacin

Proyecto Integrado II

Proyecto de Aplicacin Prctica de Tecnologa de Informacin

Grfico No. 5

OPINION SOBRE LAS NORMAS

Malas

16,7%

Buenas

16,7%

Desactu-

alizadas

66,7%

Modelo de Formulacin y Evaluacin Financiera

de Proyectos de Desarrollo

de Tecnologas de Informacin para

el Ministerio de Hacienda

Tutor:

Ismael Mora Camacho

Xinia Madrigal Chaves

Alberto Araya Herrera

Heredia, Costa Rica

Agosto, 2001

NDICE GENERAL

PGINA

ndice General ............................................................................................................

I

ndice de Cuadros.......................................................................................................

V

ndice de Grficos........................................................................................................

Vii

ndice de Anexos.........................................................................................................

Viii

Resumen Ejecutivo......................................................................................................

Ix

CAPTULO I: Introduccin e importancia

1

Introduccin....................

2

2

Importancia.................

2

3

Justificacin................

3

4

Beneficios...............

4

5

Metodologa............

5

6

Objetivo general.............

6

7

Objetivos especficos............

6

8

Limitaciones................................................

7

CAPTULO II: Aspectos tericos, metodolgicos y conceptuales

1

Conceptos......................

9

2

Planificacin estratgica..........................

10

3

Planificacin informtica...................................................

12

3.1

Plan informtico (nivel estratgico).........................................................

13

3.2

Plan de desarrollo de los sistemas de informacin (nivel tctico)..........

14

3.3

Plan de proyectos (nivel operativo)....................

14

4

Fases de la planificacin de un proyecto..................

14

4.1

Estudio preliminar...............

16

4.2

Estudio de factibilidad.....

17

4.3

Contratacin.....

18

4.4

Plan de preinstalacin....

18

5

Definicin de los objetivos............

20

6

Seleccin y asignacin de los miembros del equipo y sus roles......................

20

7

Criterios de evaluacin y seleccin de proyectos informticos.........................

20

PGINA

8

Estudio de viabilidad del sistema.....

23

8.1

EVS 1: Establecimiento del alcance del sistema......

25

8.1.1

EVS 1.1: Estudio de la solicitud..

26

8.1.2

EVS 1.2: Identificacin del alcance del sistema...

27

8.1.3

EVS 1.3: Especificaciones del alcance del EVS..

28

8.2

EVS 2: Estudio de la situacin actual.....

29

8.2.1

EVS 2.1: Valoracin del estudio de la situacin actual...

31

8.2.2

EVS 2.2: Identificacin de los usuarios participantes en el estudio de la situacin actual.....................................................

32

8.2.3

EVS 2.3: Descripcin de los sistemas de informacin existentes....

33

8.2.4

EVS 2.4: Realizacin del diagnstico de la situacin actual.......

34

8.3

EVS 3: Definicin de requisitos del sistema......

35

8.3.1

EVS 3.1: Identificacin de las directrices tcnicas y de gestin.......................

36

8.3.2

EVS 3.2: Identificacin de requisitos.......................

37

8.3.3

EVS 3.3: Catalogacin de requisitos.......................

38

8.4

EVS 4: Estudio de alternativas de solucin.......

38

8.4.1

EVS 4.1: Preseleccin de alternativas de solucin.....

40

8.4.2

EVS 4.2: Descripcin de las alternativas de solucin.....

40

8.5

EVS 5: Valoracin de las alternativas.....

42

8.5.1

EVS 5.1: Estudio de la inversin....

43

8.5.2

EVS 5.2: Estudio de los riesgos.....

44

8.5.3

EVS 5.3: Planificacin de alternativas...

44

8.6

EVS 6: Seleccin de la solucin......

45

8.6.1

EVS 6.1: Convocatoria a la presentacin.....

46

8.6.2

EVS 6.2: Evaluacin de las alternativas y seleccin...

47

8.6.3

EVS 6.3: Aprobacin de la solucin..........

49

9

Criterios para la evaluacin y seleccin de proyectos de TI.......

50

9.1

Medicin del software.........

52

9.2

Medicin del hardware.......

59

PGINA

9.3

Evaluacin del riesgo en proyectos de TI...........

60

9.3.1

Probabilidad de un riesgo..........................................................

64

9.3.2

Impacto del riesgo en beneficios...............................................

64

9.3.3

Impacto del riesgo en costos.....................................................

65

9.4

Anlisis costo-beneficio......

65

9.4.1

Los costos...

65

9.4.2

Los beneficios....

66

9.4.3

Los instrumentos financieros...

67

9.4.4

El flujo de caja proyectado...

67

9.4.5

Periodo de recuperacin (PER)..

67

9.4.6

Valor actual neto (VAN).......

68

9.4.7

Tasa interna de retorno....

68

9.4.8

Indice de deseabilidad..

69

9.4.9

Indice de costo-beneficio.....

70

10

Costo Total de Propiedad (TCO)......................................................................

70

10.1

Costos presupuestados directos............................................................

71

10.1.1

Hardware y software..............................

71

10.1.2

Administracin...........

75

10.1.3

Soporte....

81

10.1.4

Desarrollo...........

84

10.2

Costos indirectos sin presupuestar.........................................................

86

10.2.1

Los costos del sistema de usuario final.....................................

87

10.2.2

Tiempo sin sistema....................................................................

91

CAPTULO III: Descripcin y anlisis del problema

1

Antecedentes organizacionales.......

95

2

Anlisis de informacin documental........

100

2.1

Primer estudio.........

100

2.2

Emisin de normas tcnicas de la Contralora General de la Repblica................................................................................................

104

2.3

Segundo estudio ........

104

3

Anlisis de la informacin recopilada por medio de la entrevista aplicada....

110

PGINA

CAPTULO IV: Modelo propuesto

1

Estimacin del tamao del proyecto.................................................................

118

2.

Identificacin de variables.................................................................................

123

2.1

Metodologa de estimacin de variables de costo y beneficio para el desarrollo de proyectos de TI.................................................................

123

2.1.1

Recurso humano.....................................................................

124

2.1.2

Servicios .................................................................................

134

2.1.3

Materiales y suministros..........................................................

143

2.1.4

Equipo... .................................................................................

150

3

Anlisis de los sistemas ...................................................................................

150

3.1

Anlisis del sistema actual ....................................................................

151

3.2

Desarrollo de un proyecto de TI, con sus diferentes alternativas de solucin ..................................................................................................

154

3.3

Anlisis del sistema propuesto...............................................................

156

4

Requerimientos funcionales..............................................................................

159

CONCLUSIONES Y RECOMENDACIONES

1

Conclusiones.....................

163

2

Recomendaciones....................

168

Glosario de trminos.........

171

Bibliografa. ........

173

ANEXOS

NDICE DE CUADROS

PGINA

Cuadro N 1

Modelo propuesto...................

4

Cuadro N 2

Actividades del estudio de viabilidad...................

24

Cuadro N 3

Tareas EVS 1..................

26

Cuadro N 4

Productos EVS 1.1..................

27

Cuadro N 5

Productos EVS 1.2..................

28

Cuadro N 6

Productos EVS 1.3..................

29

Cuadro N 7

Tareas EVS 2..................

30

Cuadro N 8

Productos EVS 2.1..................

32

Cuadro N 9

Productos EVS 2.2..................

32

Cuadro N 10

Productos EVS 2.3..................

34

Cuadro N 11

Productos EVS 2.4..................

35

Cuadro N 12

Tareas EVS 3..................

35

Cuadro N 13

Productos EVS 3.1..................

36

Cuadro N 14

Productos EVS 3.2..................

37

Cuadro N 15

Productos EVS 3.3..................

38

Cuadro N 16

Tareas EVS 4..................

39

Cuadro N 17

Productos EVS 4.1..................

40

Cuadro N 18

Productos EVS 4.2..................

42

Cuadro N 19

Tareas EVS 5..................

43

Cuadro N 20

Productos EVS 5.1..................

44

Cuadro N 21

Productos EVS 5.2..................

44

Cuadro N 22

Productos EVS 5.3..................

45

Cuadro N 23

Tareas EVS 6..................

46

Cuadro N 24

Productos EVS 6.1..................

47

PGINA

Cuadro N 25

Productos EVS 6.2..................

48

Cuadro N 26

Productos EVS 6.3..................

49

Cuadro N 27

Participantes en las actividades del proceso EVS....................

49

Cuadro N 28

Tcnicas/Prcticas utilizadas en las actividades del proceso EVS..

50

Cuadro N 29

Medicin del software: Factor humano..................

52

Cuadro N 30

Medicin del software: Factor econmico..................

53

Cuadro N 31

Medicin del software: Factor funcional.................

54

Cuadro N 32

Valores de ajuste de complejidad....................

54

Cuadro N 33

Caractersticas para evaluar.................

55

Cuadro N 34

Criterios para evaluar el acceso a datos.................

57

Cuadro N 35

Medicin del factor tcnico....................

57

Cuadro N 36

Atributos para medir el grado de autonoma..................

58

Cuadro N 37

Medidas del factor temporal..................

58

Cuadro N 38

Identificacin de factores de riesgo......................................................

63

Cuadro N 39

Nivel de complejidad............................................................................

119

Cuadro N 40

Entradas externas................................................................................

120

Cuadro N 41

Salidas Externas..................................................................................

120

Cuadro N 42

Archivos lgicos internos.....................................................................

120

Cuadro N 43

Archivos de Interfaz externos...............................................................

121

Cuadro N 44

Consultas del lado de Entradas...........................................................

121

Cuadro N 45

Consultas del lado de Salidas..............................................................

121

NDICE DE GRFICOS

PGINA

Grfico N 1

Tiempo de laborar para la Institucin...........

111

Grfico N 2

Tiempo de laborar en desarrollo de proyectos informticos.....

112

Grfico N 3

Conocimiento de metodologas de desarrollo............

112

Grfico N 4

Conocimiento del Manual de Normas Tcnicas de la Contralora General de la Repblica............

113

Grfico N 5

Opinin sobre las Normas.................

114

NDICE DE ANEXOS

Anexo N 1

Entrevista

Anexo N 2

Pantallas para el Modelo

RESUMEN EJECUTIVO

El presente documento contiene un estudio preliminar para determinar la problemtica existente en el Ministerio de Hacienda, con respecto al desarrollo de los proyectos de desarrollo de tecnologas de informacin, e incluye una propuesta de solucin, como herramienta para la determinacin de costos y beneficios (o ahorros), que permita facilitar la toma de decisiones institucionales en esta materia.

En el primer captulo se introduce el tema y se explica su importancia, as como la justificacin, la metodologa utilizada, las limitaciones encontradas y se especifican el objetivo general y los objetivos especficos del estudio. Asimismo, se hace referencia a los beneficios que se obtendran de una propuesta de evaluacin financiera a priori, que les permita a las autoridades ministeriales tomar decisiones ms acertadas en este sentido, reduciendo as el grado de incertidumbre existente en todo proyecto de desarrollo.

El Captulo II expone una serie de aspectos tericos, metodolgicos y conceptuales sobre el tema, necesarios para abordar la problemtica. Se menciona aqu aspectos desde la planificacin estratgica, un modelo metodolgico de un proceso para la evaluacin y seleccin de proyectos informticos. Por ltimo, se hace mencin de las variables financieras a considerar para la propuesta de solucin al problema, y se expone la metodologa de Costo Total de Propiedad, para la estimacin de costos de operacin de los sistemas de informacin.

El Captulo III, describe la problemtica existente, en la cual se analiz, tanto informacin documental de estudios realizados con respecto a desarrollo de dos sistemas institucionales. Adems, se recopil informacin mediante una entrevista aplicada a diferentes funcionarios con responsabilidad en el desarrollo de proyectos de tecnologa de informacin, as como en la toma de decisiones en este sentido. Se analiza tambin la normativa existente sobre las diferentes responsabilidades y funciones asignadas a entidades creadas en el Ministerio de Hacienda, para la rectora y la toma de decisiones en el campo tecnolgico.

El Captulo IV consiste en la propuesta de solucin, la cual consiste en un modelo de evaluacin financiera a priori para la determinacin de costos de desarrollo de un proyecto de TI, adems, de la estimacin de costos tanto del sistemas actuales, como propuestos, a fin de realizar la comparacin y apoyar la toma de decisiones.

Las conclusiones y recomendaciones que se presentan se derivan de un anlisis, tanto de la teora existente, como de la problemtica institucional encontrada y expone una serie de requisitos necesarios, para que el instrumento propuesto, realmente constituya un apoyo para la evaluacin financiera a priori de cualquier desarrollo que pretenda hacerse a futuro, a efecto de que las autoridades cuenten con mecanismos que brinden transparencia en las decisiones que se toman en este sentido.

CAPTULO I

INTRODUCCIN E IMPORTANCIA

1. INTRODUCCIN

El Ministerio de Hacienda ha venido desarrollando proyectos de Sistemas de Informacin en sus diferentes reas sustantivas, en los cuales la decisin de implementarlos no ha obedecido a estudios previos de factibilidad, sean estos de carcter econmico, operativo y tcnico, lo cual ha hecho que estos sistemas se desarrollen de acuerdo con el criterio de las empresas que se contratan para ello. En otras palabras, se han realizado con el nico criterio de la necesidad de contar con ellos, sin una evaluacin de costos y beneficios, ni la posibilidad de escoger entre varias alternativas, tanto financieras como tcnicas.

2. IMPORTANCIA

Al no contarse con un modelo que permita una evaluacin a priori, para determinar si es viable tcnica y econmicamente un determinado proyecto de desarrollo informtico, o bien, que permita elegir entre varias alternativas de inversin para la institucin, los proyectos han sobrepasado, tanto los presupuestos, como de los tiempos estimados para tal desarrollo.

Por todo lo anterior, un modelo administrativo-financiero para la evaluacin a priori de los proyectos de desarrollo de TI, contribuir para que stos adems de cumplir con las normas tcnicas emitidas por la Contralora General de la Repblica sirva como una base fundamental para la toma de decisiones por parte de las autoridades ministeriales.

3. JUSTIFICACIN

Un modelo de formulacin y evaluacin financiera de proyectos informticos, a nuestro juicio, constituye una herramienta muy valiosa para quienes toman las decisiones de desarrollo de proyectos, ya que de este modelo depende el establecimiento de diferentes parmetros para determinar la viabilidad financiera de los mismos.

El presente estudio pretende establecer la necesidad que se tiene actualmente en la Institucin de valorar a priori los proyectos de desarrollo de tecnologas de informacin. As, al establecer la necesidad y a sabiendas de que existen mtodos financieros y tecnologas adecuadas se disear un modelo administrativo-financiero para la evaluacin de proyectos de TI.

Se estudiar la teora existente en materia financiera y tecnolgica, para que a partir de ello se establezca una metodologa que permita valorar las diferentes variables a considerar en el desarrollo de un proyecto informtico.

Una vez establecido dicho modelo, ste servir de base para la construccin futura de una herramienta automatizada, para realizar los diferentes clculos y estimaciones necesarias para la toma de decisiones.

El modelo propuesto para este efecto, que se relaciona directamente con las etapas previas al inicio, se resume a continuacin:

Cuadro 1

MODELO PROPUESTO

PASOS

ETAPA

1. Identificar los beneficios y su momento

1.1 Reduccin de costos

1.2Incremento de Utilidades

Anlisis y Diseo

2. Identificar los desembolsos y su momento

2.1 Costos del sistema actual

2.2 Inversin inicial

2.3 Costos de Desarrollo

2.4 Costos de Operacin

Anlisis y Diseo

3. Determinacin de la vida til del sistema

Anlisis y Diseo

4. Identificacin de valores de rescate (Deshecho)

4.1 Hardware

4.2 Software

4.3 Mobiliario y Equipo

4.4 Terreno y edificios

Anlisis y Diseo

5. Elaborar el flujo de caja proyectado

Pre-Factibilidad y Factibilidad

6. Calcular los indicadores financieros

6.1 Perodo de recuperacin (PER)

6.2 Valor Actual Neto (VAN)

6.3 Tasa Interna de Retorno (TIR)

6.4 ndice de Deseabilidad (ID)

6.5 ndice de Costo-Beneficio (CB)

Pre-Factibilidad y Factibilidad

7. Tomar la decisin de si se desarrolla o no (Comparacin con otras alternativas)

Pre-Factibilidad y Factibilidad

4. BENEFICIOS

Al contar con un modelo que le permita a la Institucin determinar la viabilidad financiera de un proyecto, los beneficios se vern reflejados en una mejor administracin de los recursos que, de por s, son escasos, y en la transparencia para la toma de decisiones, de manera que los proyectos no slo se desarrollen con el criterio de necesidad institucional, sino que cuenten, adems, con un criterio tcnico financiero, que permita explicar y rendir cuentas sobre los recursos que se destinan a la inversin en desarrollo de proyectos de tecnologas de informacin

Adems, un modelo de este tipo, permitir contar con varios escenarios financieros, que permitan tambin tomar decisiones ms acertadas, entre diferentes alternativas de inversin, claro est, que todas estas alternativas contarn siempre con un cierto grado de incertidumbre, no obstante, sta ser mucho menor que en la actualidad, en que no se cuenta con ningn tipo de estudio en este sentido.

5. METODOLOGA

Para la realizacin del presente estudio, se hizo un anlisis del marco terico existente en la materia, que incluye tanto aspectos de Planificacin Estratgica Institucional, Planificacin Estratgica Informtica, as como de los procesos existentes necesarios para un adecuado desarrollo de proyectos de TI, haciendo especial nfasis en los estudios de viabilidad tcnica, operativa y financiera, siendo estos ltimos el objeto de nuestro estudio.

Para la determinacin del problema, se revis informacin documental, de dos informes de auditora practicados en la Institucin, partiendo de las normas tcnicas emitidas por la Contralora General de la Repblica, que an se encuentran vigentes, las cuales detallan el proceso a seguir en todo desarrollo de proyectos de TI. Asimismo, se estudi y analiz la normativa existente en cuanto a las funciones que por Decreto le han sido asignadas, tanto a la Direccin General de Informtica como al Consejo de Informtica del Ministerio de Hacienda, revisndose las actas existentes del ao 2000, de las diferentes sesiones efectuadas por dicho Consejo.

Por otra parte, se efectu un estudio de campo concerniente a una entrevista aplicada a diferentes autoridades relacionadas con el desarrollo de sistemas y proyectos de TI, para determinar, en forma preliminar, cul es el criterio y el conocimiento de estas personas con experiencia en la materia, acerca del objeto de estudio.

6. OBJETIVO GENERAL

Dotar al Ministerio de Hacienda de un modelo administrativo-financiero, que le permita a los que toman las decisiones en cuanto al desarrollo de proyectos de Tecnologas de Informacin, contar con la informacin necesaria y oportuna sobre la viabilidad financiera de un proyecto determinado, minimizando con esto la incertidumbre existente actualmente.

7. OBJETIVOS ESPECIFICOS

a) Ofrecer un mecanismo que permita la valoracin financiera a priori de proyectos de desarrollo de sistemas de informacin.

b) Proponer un modelo que permita identificar los costos los beneficios, en trminos de ahorro de costos o beneficios tangibles.

c) Proponer un mecanismo para la identificacin de los desembolsos y su momento.

d) Ofrecer un modelo que permita estimar la vida til de un proyecto de desarrollo de sistemas de informacin

e) Definir un mecanismo que permita la determinacin de valores de rescate, as como los indicadores financieros.

f) Proponer un modelo para la elaboracin de flujos de caja durante la etapa de desarrollo de un proyecto.

g) Proporcionar los requerimientos funcionales para que pueda construirse una herramienta automatizada, que contribuya en la funcin de la evaluacin y valoracin financiera de proyectos de desarrollo de sistemas de informacin.

8. LIMITACIONES

El presente documento presenta el resultado de la investigacin preliminar realizada, con la documentacin e informacin a la que se tuvo acceso, y por lo tanto, constituye un documento que evidencia en forma parcial el problema.

Deseamos recalcar que una de las principales limitaciones encontradas, es que no existe documentacin de proyectos anteriores que contengan la informacin necesaria para la realizacin de este estudio. Por otra parte, result muy difcil contar con la informacin de campo en forma oportuna y completa.

Adems de esto, realizada la investigacin a nivel institucional no existen indicadores financieros que permitan, desde ahora, realizar estimaciones ms certeras acerca de los costos y beneficios que pueden derivarse de un desarrollo de TI, por lo tanto, la propuesta est limitada al conocimiento de algunos funcionarios involucrados en esta rea, debiendo recurrirse al juicio experto en muchos casos, lo cual hace que muchas de las variables deban estimarse en un principio, con indicadores tentativos, hasta tanto no se cuente en la institucin con informacin histrica que permita realizar estimaciones ms exactas.

CAPTULO II

ASPECTOS TERICOS,

METODOLGICOS Y CONCEPTUALES

1. CONCEPTOS

Un proyecto de desarrollo de TI, debe cumplir una serie de etapas que permitan asegurar su xito. Para efectos del presente estudio, iniciaremos con la definicin de un proyecto:

"Un proyecto es un conjunto de actividades no repetitivas claramente definidas para alcanzar uno o varios objetivos, en un tiempo definido y con recursos limitados.

Esta definicin de proyecto es general, justifica por qu las actividades del plan informtico se han definido como proyectos. Adems, nos ayuda a identificar y verificar cuando nos encontramos ante un proyecto, lo cual se logra mediante la relacin del objetivo u objetivos con las caractersticas que definen un proyecto:

Actividades nicas

Actividades no repetitivas

Actividades temporales"

La rapidez con que se han venido dando cambios en la tecnologa, no ha permitido documentar muchos de los proyectos desarrollados en las dcadas anteriores. Se habla de que la mayora de los proyectos fracasan por una serie de razones, entre ellas, que cada una de las etapas de su desarrollo no han sido ejecutadas adecuadamente, y segn Stephen P. Keider, debido a que "dichos proyectos no estn definidos inicialmente"

Cualquier proyecto de desarrollo de TI que pretenda ejecutarse, debe cumplir una serie de etapas previas a su inicio:

2.PLANIFICACIN ESTRATGICA

Segn Nuria Rodrguez y William Martnez, la planificacin estratgica de la informacin es una disciplina que no se practica comnmente en las organizaciones. Prueba de ello fue el impacto que tuvo en los sistemas informticos a nivel mundial, el cambio de siglo, cuando la limitacin de almacenar y procesar el ao 2000 es sus cuatro dgitos, amenaz con llevar al fracaso a aquellas empresas que no precisamente haban realizado la planificacin estratgica que les permitiera preparar sus sistemas de informacin.

La poca cultura informtica existente no les permite a las organizaciones percatarse de la funcin estratgica de la informacin y menos de incorporar, en el proceso de planificacin estratgica, al proceso de planificacin estratgica de la informacin. Lo comn es ms bien ignorarla al principio, y no es sino hasta el final de los proyectos, que la organizacin se da cuenta de la necesidad de contar con los sistemas informticos que soporten esos proyectos.

Se nos dice que el nuevo capital de las empresas es la informacin, porque es a travs de ella que producimos la riqueza de la organizacin, pero se nos olvida o ignoramos el papel estratgico del recurso informtico: no se involucra oportunamente a los responsables de la gestin informtica y se trivializa el proceso de seleccin del hardware y software. En este sentido es una concertacin entre la gestin institucional y la gestin informtica. Es un esfuerzo por cerrar la brecha y un medio para buscar la sinergia que debe existir entre esos dos frentes de accin.

La accin de planificacin estratgica se centra en establecer el futuro deseado, la identificacin y seleccin de las formas de cmo lograrlo, en cuanto tiempo ha de lograrse, determinndose quienes son los participantes en la elaboracin del futuro, as como el costo que implica desarrollarla.

A pesar de que existen muy buenos resultados sobre la aplicacin de la planificacin estratgica, muchas organizaciones han considerado que esta metodologa no ha contribuido significativamente en su permanencia, desarrollo y utilidades. Algunas consideraciones para justificar el porqu las organizaciones requieren sacarle el mayor provecho a sus recursos por medio de la planificacin estratgica, son las siguientes:

a) La informacin se convierte en una herramienta para la supervivencia, para desarrollar ventaja competitiva, reestructurar las organizaciones que requieren de grandes transformaciones, y para adaptarse al nuevo paradigma que descansa en la informacin y en la administracin de los recursos de informacin.

b) El foco de atencin en las empresas se centra en la disminucin de costos, mejoramiento del servicio al cliente y disminucin de los tiempos para mercadear nuevos productos, y es aqu donde los sistemas de informacin son los vehculos que ayudan a mejorar la productividad y desempeo de las organizaciones.

c) Adems, la tecnologa informtica se debe orientar para que tome en cuenta los siguientes aspectos, que sern de gran ayuda para administrar la organizacin:

El anlisis del medio, en especial el de la competencia, proveedores y todas aquellas variables a las que sea susceptible la organizacin.

El anlisis de los recursos y capacidades que actualmente controla la organizacin.

La evaluacin permanente de la aceptacin y uso de la tecnologa informtica por parte del personal.

d) Las pequeas y medianas organizaciones compiten con multinacionales que tienen mayores recursos y formas de organizacin; si quieren permanecer en el mercado, deben poner un nuevo nfasis en la promesa que hace la tecnologa informtica y hacer efectiva la integracin de sta en las funciones organizacionales. Para lograr estos objetivos, la tecnologa informtica debe adquirir las siguientes caractersticas:

estas organizaciones son dependientes de recursos limitados, por lo que los profesionales en tecnologa informtica deben hacer un uso ms eficiente de estos recursos.

la tecnologa informtica debe ser una estrategia natural y crucial para el logro de la estrategia corporativa. Debe permitir, adems, lograr un mejor uso de otros recursos de carcter delicado, en los cuales las organizaciones deben tambin poner su atencin tales como: el recurso humano, financiero, infraestructura, e incluso otras tecnologas asociadas.

En estos momentos, las grandes organizaciones son cada vez ms fuertes, pues establecen alianzas que les permiten penetrar en nuevos mercados en una forma ms fcil y competir con menores costos. La expansin requiere contar con gran nmero de recursos y, en algunos casos, un mejor uso de stos, en especial de tecnologa informtica, que en definitiva no es posible comparar con las pequeas y medianas empresas.

Por tanto, las medianas y pequeas empresas deben sacarle ventaja y mayor aprovechamiento a los recursos invertidos, en especial en el rea de tecnologa informtica; los sistemas de informacin deben disearse con caractersticas de flexibilidad, integracin e interactividad, para que adquieran un verdadero valor para el apoyo en la toma de decisiones. Tambin los administradores de estas organizaciones deben evaluar y aprender de las formas de administracin que tienen las grandes empresas.

3.PLANIFICACIN INFORMTICA

La planificacin informtica no debe nacer como un hecho aislado dentro de la organizacin, sino como una necesidad de desarrollo de la estrategia corporativa; forma parte de un objetivo comn en la organizacin, donde la tecnologa informtica ha sido considerada como una oportunidad para desarrollar una ventaja competitiva en el mercado. Las nuevas tecnologas nos ofrecen ventajas tan significativas para los negocios, como es el rompimiento de fronteras y la capacidad de poner mltiples servicios al cliente mediante las telecomunicaciones.

Como se ha comentado anteriormente, en la planificacin de la estrategia hay que considerar aspectos externos e internos de la organizacin (FODA), pero especficamente en el rea de tecnologa informtica. Para realizar ste anlisis se deben considerar tres grandes reas:

A nivel global o nacional, que incluye principalmente los aspectos polticos, sociales y econmicos del ambiente.

A nivel del sector de mercado, donde se enfatizan las regulaciones, tecnologa utilizada y elementos competitivos.

A nivel organizacional, que analiza la cultura organizacional, estructura organizacional, capacitacin del personal, capacidad de las instalaciones fsicas, las relaciones sociopolticas, las estrategias, la tecnologa adquirida y su uso.

Un plan informtico debe contemplarse en tres niveles: el nivel estratgico, el tctico y el operativo.

3.1PLAN INFORMTICO (NIVEL ESTRATGICO)

"El plan informtico es el documento que contiene las especificaciones, polticas y directrices generales que delimitan la estrategia tecnolgica. Este documento nos servir para la administracin activa del plan."

El plan informtico debe crearse con la participacin de un grupo interdisciplinario, que est muy relacionado con la modelacin de la estrategia corporativa, que tenga conocimientos y experiencia en la organizacin; debe constituirse en una herramienta efectiva para el seguimiento y el control, y no se debe convertir en un documento ms de la organizacin, que se archiva y se saca cuando llegan visitas.

3.2PLAN DE DESARROLLO DE LOS SISTEMAS DE INFORMACIN (NIVEL TCTICO)

El plan de desarrollo de los sistemas de informacin est dentro de la planificacin tctica. La planificacin tctica tiene como propsito determinar planes eficientes de desarrollo de los sistemas de informacin, as como la adquisicin de los recursos necesarios (materiales, humanos, financieros) para el desarrollo coordinado de la planificacin informtica y la estrategia corporativa.

Este proceso debe hacerse en forma sistemtica y detallada. El nivel de detalle est proporcionalmente relacionado con el costo, la complejidad y el tiempo que se va a invertir; adems de la capacitacin que tiene el personal para realizar esa labor.

3.3 PLAN DE PROYECTOS (NIVEL OPERATIVO)

El plan de proyectos pertenece al nivel operativo, el cual tiene como objetivo ejecutar los proyectos ya definidos segn las prioridades establecidas en el nivel anterior. En esta etapa se asigna el equipo de trabajo, el director de proyecto, los recursos necesarios, y se pone en marcha el proyecto.

4.FASES DE LA PLANIFICACIN DE UN PROYECTO

Para efectos del presente estudio, se exponen a continuacin dos metodologas, la primera, estipulada por la Contralora General de la Repblica, y la segunda, basada en la teora consultada.

Las fases de la planificacin de un proyecto tienen como objetivo definir las actividades, recursos, criterios de aceptacin o evaluacin y tipo de control que tendr el proyecto en s.

A pesar de que existen naturalezas diferentes de los proyectos, podemos definir fases comunes a cualquier proyecto.

Para garantizar la mejor utilizacin de los recursos asignados al desarrollo de SIC, la Contralora General de la Repblica (CGR), ha emitido un manual sobre normas tcnicas de control interno, que adems de constituir un documento de acatamiento obligatorio para las entidades y rganos de la Hacienda Pblica, constituyen una gua para la Administracin para establecer, mantener y perfeccionar sus sistemas de control interno.

Estas normas procuran que los SIC se lleven a cabo en un ambiente razonablemente controlado y comprenden las actividades de preinstalacin, administracin, desarrollo, documentacin y operacin.

De acuerdo con el Manual sobre normas tcnicas de control interno relativas a los sistemas de informacin computadorizados, el desarrollo de un proyecto se divide en las siguientes etapas:

a) Preinstalacin

b) Administracin

c) Desarrollo de sistemas

d) Documentacin

e) Operacin

Para efectos del presente estudio, nos abocaremos a investigar sobre el problema nicamente a lo que se refiere a la etapa de "Preinstalacin" con sus diferentes componentes, que constituyen la etapa previa al inicio de un proyecto de desarrollo

La preinstalacin se refiere a los procedimientos necesarios para lograr una orientacin fundamentada y organizada de todas las actividades previas a la adquisicin e instalacin de software y desarrollo de los SIC, esto implica el estudio preliminar, el estudio de factibilidad, la contratacin y el plan de preinstalacin.

4.1ESTUDIO PRELIMINAR

El objeto del estudio preliminar es determinar si el uso del Hardware y la adquisicin o desarrollo de un SIC es viable tcnica y econmicamente, y que por lo tanto se justifica un estudio de factibilidad. Se recomienda que este estudio sea realizado por personal interno que este familiarizado con las operaciones y necesidades identificadas.

Deben establecerse las especificaciones necesarias para el estudio preliminar, esto implica definir lo siguiente:

i. Las personas responsables de llevar a cabo el estudio.

ii. El tiempo de ejecucin estimado, y las reas o problemas especficos que abarcar el estudio.

iii. La informacin que deber obtenerse para cada rea o problema indicado.

Procedimientos actuales, volumen de informacin, fuentes de datos, clases y destinos de los documentos de salida.

Tiempos entre la entrada de datos y la salida de los reportes y las horas pico.

Diagramas de relaciones entre las diferentes operaciones del procesamiento.

Costo actual de personal y equipos necesarios, y nuevo costo de recursos utilizando el computador.

Probable impacto en la entidad u rgano y requerimientos de comunicacin y transmisin de datos.

Beneficios y ahorros que puedan preverse.

4.2ESTUDIO DE FACTIBILIDAD

De acuerdo con los resultados del estudio preliminar debe elaborarse un estudio de factibilidad, en atencin a las recomendaciones emitidas y cuyo propsito es determinar los alcances del proyecto de desarrollo del SIC, las reas de aplicacin, las alternativas de solucin a los problemas existentes y la factibilidad tcnica y econmica para su desarrollo e implantacin.

Este estudio debe suministrar un grado mucho mayor de detalle en la descripcin del problema, en la definicin del sistema por desarrollar y en los costos y beneficios que se espera obtener. Debe ofrecer un panorama claro de las opciones y de las soluciones recomendadas para satisfacer las necesidades existentes.

El estudio de factibilidad debe determinar si el SIC es congruente con el plan estratgico y si es prioritario con relacin a otros SIC proyectados.

El informe de estudio de factibilidad debe contener las conclusiones y recomendaciones necesarias. En algunos casos algunos proyectos pueden no resultar econmicamente factibles, sin embargo por conveniencia institucional u otra razn, su desarrollo e implantacin debe llevarse acabo, lo cual debe quedar debidamente documentado y sustentado.

Deben establecerse las especificaciones necesarias para el estudio de factibilidad.

Esto implica:

i. Las personas asignadas para efectuar el estudio, quienes deben poseer suficiente experiencia y conocimiento en sistemas, mtodos y equipo de procesamiento de datos, as como en anlisis econmicos de proyectos.

ii. Las reas que debern revisarse.

iii. La amplitud de la informacin y la documentacin requerida.

iv. Estimacin de las horas hombre y del costo requerido para completar el estudio.

v. El tiempo de ejecucin estimado y la fecha en que se iniciar el estudio y las intermedias en que se deber revisar el avance.

vi. El contenido del informe resultante:

Descripcin general del SIC por desarrollarse.

Costos y beneficios esperados de cada opcin identificada, con su factibilidad tcnica y econmica.

Caractersticas del software y hardware requeridos.

La calendarizacin y presupuestacin de los recursos humanos, materiales, financieros y tecnolgicos requeridos.

4.3CONTRATACIN

La contratacin del hardware y software requeridos deber hacerse de acuerdo con el ordenamiento jurdico vigente y los convenios contractuales debern revisarse cuidadosamente en forma previa a la adjudicacin y firma del contrato.

4.4PLAN DE PREINSTALACIN

Deben definirse todas las tareas o actividades previas a la instalacin de un SIC. Un plan de preinstalacin debe contener una estimacin de tiempo para cada actividad que permita medir el grado de avance conforme se ejecuta. Algunas de las actividades que pueden incluirse dentro del plan son:

Determinar las necesidades del personal.

Reclutar seleccionar y contratar personal cuando sea necesario.

Entrenar al personal.

Completar los requerimientos y el diseo.

Preparar los programas de prueba.

Recepcin y revisin del equipo contratado.

Una vez completada la etapa de Preinstalacin, la CGR, establece normas para las etapas subsiguientes, a las cuales no nos referiremos en detalla, ya que no constituyen el objeto del presente estudio. Estas etapas son:

i. Administracin: las normas tienen como propsito establecer una adecuada planificacin, organizacin, direccin, control y evaluacin de los SIC.

Comprende normas relacionadas con el Sistema de Informacin Gerencial (SICG), la estructura conceptual, planificacin, polticas, estructura de la organizacin del SICG, la ubicacin de las unidades de informtica, las segregaciones de funciones, el comit gerencial de informtica y a los estudios de auditorias internas y externas.

ii. Desarrollo de sistemas: las normas estn orientadas a lograr un desarrollo y mantenimiento eficiente, eficaz y controlado de los SIC. Se refiere a la concordancia con los planes y polticas del SICG, a los manuales de estndares para el desarrollo de los SICG, a los proyectos de desarrollo de SIC, a la administracin de los proyectos, al ciclo de vida para el desarrollo de sistemas, a los procedimientos de control de transacciones, a la participacin de los usuarios y de los auditores y a las modificaciones a los SICG.

iii. Documentacin: las normas tienen como objetivo bsico mantener una descripcin eficiente y oportuna de los SIC, necesaria para la comprensin, operacin, mantenimiento y control eficiente y efectivo de los mismos. Comprende normas relativas al desarrollo de la documentacin de conformidad con los manuales de estndares, a la documentacin del sistema, a la documentacin del programa, a la documentacin del usuario, a la documentacin de las operaciones del computador, y a la documentacin de otros procedimientos.

iv. Operacin: contempla mtodos y procedimientos para la operacin del equipo de los SIC. Comprende normas relacionadas con; procedimientos adecuados para la recepcin de datos, seguridad fsica, seguridad lgica, supervisin adecuada, administracin de archivos, respaldo de archivos, planes de contingencia, controles de equipo y mantenimiento del equipo.

Por su parte, Nuria Rodrguez y William Martnez, describen las fases que se deben realizar como mnimo en la planificacin de proyectos:

5.DEFINICIN DE LOS OBJETIVOS

Esta actividad debe definir cul es el producto final del proyecto, nos permite identificar el campo de accin, eliminar falsas expectativas, no realizar lo que no se quiere. Es fundamental entonces, contar con una clara definicin de los objetivos para alcanzar el xito del proyecto.

Los principales riesgos de no definir los objetivos son:

El proyecto no termina nunca, puesto que los miembros pueden adicionar nuevas funciones o necesidades a medida que progresa el proyecto;

Se disea algo que no cumple con las necesidades o gustos del usuario o cliente.

Los objetivos deben quedar escritos y ratificados en un documento que debe tener el mismo efecto que un contrato entre las partes involucradas en el proyecto.

6.SELECCIN Y ASIGNACIN DE LOS MIEMBROS DEL EQUIPO Y SUS ROLES

El equipo de trabajo seleccionado y asignado al equipo del proyecto, estar formado por las personas que participan directa o indirectamente en su desarrollo. La experiencia ha demostrado que, dentro de un equipo de trabajo se deben asignar roles con el fin de ordenar y organizar la ejecucin del proyecto.

7.CRITERIOS DE EVALUACIN Y SELECCIN DE PROYECTOS INFORMTICOS

"Todas las decisiones importantes o trascendentales en nuestra vida tienen un riesgo, pero el riesgo se incrementa si no planificamos la evaluacin de nuestra eleccin final

El tema de criterios de evaluacin y seleccin de proyectos informticos tiene el propsito el establecimiento de metodologas coherentes y claras que permitan generar la informacin oportuna para la toma de decisiones sobre la ejecucin de un proyecto informtico.

Para tomar una decisin sobre si ejecutamos un proyecto informtico es necesario seguir los siguientes pasos:

i. Justificar el proyecto a parir de la estrategia tecnolgica y la planificacin informtica que lo respalda (planificacin estratgica).

ii. Establecer los criterios de seleccin y mtodo que se utilizarn para tomar la decisin sobre la ejecucin del proyecto. Este proceso nos permitir clasificar y ordenar los datos por recolectar para las diferentes alternativas.

iii. Realizar estudios de factibilidad, calidad tcnica, riesgo y costo-beneficio de las diferentes alternativas.

iv. Con base en los datos recolectados, ordenados y clasificados segn los criterios de seleccin, se renen las personas responsables de tomar la decisin para ejecutar o no el proyecto informtico.

El primer paso nos obliga a retomar el tema de la planificacin estratgica de la organizacin, donde la justificacin del proyecto est condicionada e indicada por un proceso integral. Es importante indicar que el documento que recolectar la informacin que dar sustento a la decisin sobre la ejecucin del proyecto, debe contener una breve, pero clara relacin y especificacin de ese proyecto dentro del plan informtico.

El segundo paso es la etapa ms elaborada e importante del proceso, porque es aqu donde se definen los criterios de seleccin, es decir, los valores esperados sobre el proyecto, antepuestos a variables inevitables como: el riesgo, los costos, la capacitacin, etc. Adems, se hace la recoleccin de los datos y se establece el mtodo que ser el sustento para tomar la decisin.

En el tercer paso, se confecciona formalmente el documento con los estudios de factibilidad, calidad tcnica, evaluacin del riesgo, estudio de costo-beneficio de las diferentes alternativas para desarrollar el proyecto informtico. En este paso es necesario no centrar la atencin de la solucin en una sola alternativa; esto perjudica la calidad y ejecucin del proyecto.

El cuarto paso es aplicar el mtodo de evaluacin seleccionado en el paso dos, es aqu donde las personas responsables han de tomar la decisin. No siempre se toma la decisin que los tcnicos recomiendan, pero ante tales casos, la razn de la decisin debe quedar justificada en el papel.

Para lograr abordar el proceso de evaluacin de proyectos, es necesario comprender qu es la medicin y por qu sta va acompaada de la determinacin de criterios o parmetros. Es as que, en el momento en que vamos a decidir si realizamos un proyecto informtico, hay que contar con herramientas que permitan hacer una evaluacin lo ms objetiva posible; por lo tanto, los procesos sistematizados nos facilitan la organizacin y anlisis de la informacin recolectada para la toma de decisiones.

Para tomar una decisin, prevalecen tres grandes consideraciones que deben sopesarse, las cuales son: tcnica (calidad, productividad, eficiencia), riesgo y costo-beneficio.

A efecto de ahondar en aspectos tericos relacionados directamente con el objetivo de este estudio, conviene describir el proceso de un estudio de viabilidad de un sistema, como una fase previa a la toma de decisiones sobre el desarrollo de TI.

8.ESTUDIO DE VIABILIDAD DEL SISTEMA

Mientras que la Planificacin Estratgica Informtica tiene como objetivo proporcionar un marco estratgico que sirva de referencia para los Sistemas de Informacin de un mbito concreto de una organizacin, el objetivo del Estudio de Viabilidad del Sistema (EVS) es el anlisis de un conjunto concreto de necesidades para proponer una solucin a corto plazo, que tenga en cuenta restricciones econmicas, tcnicas, legales y operativas. La solucin obtenida como resultado del estudio puede ser la definicin de uno o varios proyectos que afecten a uno o varios sistemas de informacin ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia, si procede, la situacin actual.

A partir del estado inicial, la situacin actual y los requisitos planteados se estudian las alternativas de solucin. Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en la adquisicin 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 organizacin, la inversin a realizar en cada caso y los riesgos asociados. Esta informacin se analiza con el fin de evaluar las distintas alternativas y seleccionar la ms adecuada, definiendo y estableciendo su planificacin.

Si en la organizacin se ha realizado con anterioridad un plan estratgico informtico que afecte el sistema objeto de este estudio, se dispondr de un conjunto de productos que proporcionarn informacin a tener en cuenta en todo el proceso.

Las actividades que engloba este proceso, se recogen en la siguiente figura, en la que se indican las actividades que pueden ejecutarse en paralelo y las que precisan para su realizacin resultados originados en actividades anteriores.

Cuadro 2

ACTIVIDADES DEL ESTUDIO DE VIABILIDAD

100,0%

0,0%

0,0%

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%

P

o

r

c

e

n

t

a

j

e

S

No

Muy poco

Grfico No. 4

CONOCIMIENTO DEL MANUAL DE

NORMAS TECNICAS DE LA C.G.R

Grfico No. 3

CONOCIMIENTO DE

METODOLOGIAS DE DESARROLLO

S

83,3%

No

16,7%

Muy poco

0,0%

8.1EVS1: Establecimiento del alcance del sistema

En esta actividad se estudia el alcance de la necesidad planteada por el cliente usuario o como consecuencia de la realizacin de un Plan de Sistemas de Informacin (PSI), realizando una descripcin general de la misma. Se determinan los objetivos, se inicia el estudio de los requisitos y se identifican las unidades organizativas afectadas estableciendo su estructura.

Se analizan las posibles restricciones, tanto generales como especficas, que puedan condicionar el estudio y la planificacin de las alternativas de solucin que se propongan.

Si la justificacin econmica es obvia, el riesgo tcnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoracin y evaluacin de las mismas, sino que ste se orientar a la especificacin de requisitos, descripcin del nuevo sistema y planificacin.

Se detalla la composicin del equipo de trabajo, necesario para este proceso y su planificacin. Finalmente, con el fin de facilitar la implicacin activa de los usuarios en la definicin del sistema, se identifican sus perfiles, dejando claras sus tareas y responsabilidades.

Cuadro 3

TAREAS EVS 1

TAREA

PRODUCTOS

TCNICAS Y

PRCTICAS

PARTICIPANTES

EVS1.1

Estudio de la solicitud

Descripcin general del sistema

Catlogo objetivos EVS

Catlogo Requisitos

Catalogacin

Sesiones de Trabajo

Comit Direccin

Jefe de Proyecto

Analistas

EVS1.2

Identificacin del alcance del sistema

Descripcin general del sistema

Contexto del sistema

Estructura organizativa

Catlogo de requisitos

Catlogo de usuarios

Diagrama de flujo de datos

Diagrama de descomposicin funcional

Catalogacin

Sesiones de trabajo

Comit de direccin

Jefe de Proyecto

Analistas

EVS1.3

Especificacin del alcance del EVS

Catlogo de objetivos del EVS

Catlogo de usuarios

Plan de trabajo

Catalogacin

Sesiones de trabajo

Comit de direccin

Jefe de Proyecto

Analistas

8.1.1EVS1.1: Estudio de la solicitud

Se realiza una descripcin general de la necesidad planteada por el usuario, y se estudian las posibles restricciones de carcter econmico, tcnico, operativo y legal que pueden afectar el sistema. Antes de 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 PSI vigente, se debe de tomar como referencia el catlogo de requisitos y la arquitectura de informacin resultante del mismo. Como informacin adicional para la descripcin general del sistema y determinacin de los requisitos iniciales.

Cuadro 4

PRODUCTOS EVS 1.1

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Catlogo de requisitos del PSI

Arquitectura de informacin

Solicitud (externo)

Descripcin general del sistema

Catlogo de objetivos del EVS

Catlogo de requisitos

Catalogacin

Sesiones de trabajo

Comit de direccin

Jefe de Proyecto

Analistas

8.1.2EVS 1.2 Identificacin del alcance del sistema

Se analiza el alcance de la necesidad planteada y se identifican las restricciones relativas a la sincronizacin con otros proyectos, que puedan interferir en la planificacin y futura puesta a punto del sistema objeto del estudio. Esta informacin se recoge en el catlogo de requisitos.

Si el sistema pertenece al mbito de un Plan de Sistemas de Informacin, se debe tener en cuenta la arquitectura de informacin propuesta para analizar el alcance del sistema e identificar los sistemas de informacin que quedan fuera del mbito del estudio. Adems, 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 quienes afecta directamente y a quienes pueden influir en el xito y fracaso del mismo.

Cuadro 5

PRODUCTOS EVS 1.2

PRODUCTOS

TCNICAS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Plan de Proyectos

Arquitectura de informacin

Descripcin general del sistema (EVS 1.1)

Catlogo de objetivos del EVS (EVS 1.1)

Catlogo de requistos (EVS 1.1)

Descripcin general del sistema:

- Contexto del sistema

- Estructura

organizativa

Catlogo de requisitos:

- Requisitos relativos a restricciones o dependencias con otros proyectos.

Catlogo de usuarios

Diagrama de flujos de datos

Diagrama de descomposicin funcional

Catalogacin

Sesiones de trabajo

Comit de direccin

Jefe de Proyecto

Analistas

8.1.3EVS 1.3: Especificacin del alcance del EVS

En funcin 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 situacin actual y, en el caso de considerarlo necesario, con qu objetivo. Si el sistema pertenece al mbito de un PSI, los criterios que pueden orientar sobre la necesidad de llevar a cabo el estudio de la situacin actual dependen de la arquitectura de informacin propuesta, en cuanto a la identificacin de los sistemas de informacin 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 realizacin 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 aceptacin y esperando su confirmacin.

Cuadro 6

PRODUCTOS EVS 1.3

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Arquitectura de informacin

Catlogo de objetivos (EVS 1.1)

Descripcin general del sistema (EVS 1.2)

Catlogo de usuarios (EVS 1.2)

Catlogo de objetivos del EVS

- Objetivos del estudio de la situacin actual

Catlogo de usuarios

Plan de trabajo

Catalogacin

Sesiones de trabajo

Comit de direccin

Jefe de Proyecto

Analistas

8.2EVS 2: ESTUDIO DE LA SITUACIN ACTUAL

La situacin actual es el estado en que se encuentran los sistemas de informacin existentes en el momento en que se inicia su estudio.

Teniendo en cuenta el objetivo del estudio de la situacin actual, se realiza una valoracin de la informacin existente acerca de los sistemas de informacin afectados. En funcin de dicha valoracin, se especifica el nivel de detalle con que se debe levar a cabo el estudio. Si es necesario, se constituye un equipo de trabajo especfico para su realizacin y se identifican los usuarios participantes en el mismo.

Si se decide documentar la situacin actual, normalmente es conveniente dividir el sistema actual en subsistemas. Si es posible se describir cada uno de los subsistemas, valorando que informacin puede ser relevante para la descripcin.

Como resultado de esta actividad se genera un diagnstico, estimando la eficiencia de los sistemas de informacin existentes e identificando los posibles problemas y mejoras.

Cuadro 7

TAREAS EVS 2

TAREA

PRODUCTOS

TCNICAS Y

PRCTICAS

PARTICIPANTES

EVS2.1

Valoracin del estudio de la situacin actual

Descripcin de la

situacin actual:

- Contexto del sistema actual

- Descripcin de los sistemas de informacin actuales

Diagrama de los flujos de datos

Diagrama de representacin

Sesiones de trabajo

Jefe de Proyecto

Analistas

Directores de usuarios

EVS2.2

Identificacin de los usuarios participantes en el estudio de la situacin actual

Catlogo de usuarios

Catalogacin

Sesiones de trabajo

Jefe de Proyecto

Directores de usuarios

EVS2.3

Descripcin de los sistemas de informacin existentes

Descripcin de la

situacin actual:

- Descripcin lgica del sistema actual

- Modelo fsico del sistema actual (opcional)

- Matriz localizacin mdulos y datos

Modelo entidad/relacin extendido

Diagrama de flujo de datos

Diagrama de clases

Diagrama de interaccin de objetos

Matricial

Diagrama de representacin

Sesiones de trabajo

Analistas

Usuarios expertos

Equipo de soporte tcnico

EVS2.4

Realizacin del diagnstico de la situacin actual

Descripcin de la

Situacin actual:

- Diagnstico de la situacin actual

Analistas

Responsable de mantenimiento

8.2.1EVS 2.1: Valoracin del estudio de la situacin actual

En funcin de los objetivos establecidos para el estudio de la situacin actual, y considerando el contexto del sistema especificado en la descripcin general del mismo, se identifican los sistemas de informacin existentes que es necesario analizar con el fin de determinar el alcance del sistema actual. Asimismo, se decide el nivel de detalle con el que se va a llevar a cabo el estudio de cada uno de los sistemas de informacin implicados. En el caso de haber realizado un PSI que afecte a dicho sistema, se toma como punto de partida para este anlisis la arquitectura de informacin propuesta.

Para poder abordar el estudio, se realiza previamente una valoracin de la informacin existente acerca de los sistemas de informacin afectados por el EVS. Se debe decidir si se realizan o no los modelas lgicos del sistema actual o si se describe el modelo fsico en funcin de los siguientes criterios:

Si existen los modelos lgicos, y son fiables, se utilizan en la tarea Descripcin de los sistemas de informacin existentes (EVS 2.3).

Si no existen dichos modelos, o no son fiables, se considera el tiempo de vida estimado para el sistema de informacin en funcin de la antigedad, la obsolescencia de la tecnologa o la falta de adecuacin funcional para determinar si se obtienen los modelos lgicos y fsicos del sistema actual o por el contrario no se elabora ningn modelo.

La informacin relativa a los sistemas de informacin que se decida a analizar, se obtiene mediante sesiones de trabajo con los directores de usuarios y el apoyo de los profesionales de sistemas y tecnologas de informacin y comunicaciones que se considere necesarios.

Cuadro 8

PRODUCTOS EVS 2.1

PRODUCTOS

TCNICAS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Informacin existente del sistema actual (externo)

Arquitectura de informacin

Catlogo de objetivos del EVS (EVS 1.3)

Descripcin general del sistema (EVS 1.2)

Descripcin de la situacin actual:

Contexto del sistema actual

Descripcin de los sistemas de informacin actuales

Diagrama de flujos de datos

Diagrama de representacin

Sesiones de trabajo

Jefe de Proyecto

Analistas

Directores de usuarios

8.2.2EVS 2.2: Identificacin de los usuarios participantes en el estudio de la situacin actual

En funcin del nivel de detalle establecido para el estudio de la situacin actual, se identifican los usuarios de cada una de la unidades organizativas afectadas por dicho estudio. Se informa a los usuarios identificados como implicados en el estudio de la situacin actual, se solicita su aceptacin y se espera su confirmacin.

Cuadro 9

PRODUCTOS EVS 2.2

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Descripcin general del sistema (EVS 1.2)

Catlogo de usuarios (EVS 1.3)

Descripcin de la situacin actual

Catlogo de usuarios

Catalogacin

Sesiones de trabajo

Jefe de Proyecto

Directores de usuarios

8.2.3EVS 2.3: Descripcin de los sistemas de informacin existentes

En esta tarea se describen los sistemas de informacin existentes afectados, segn el alcance y nivel de detalle establecido en la tarea Valoracin del Estudio de la Situacin Actual (EVS 2.1), mediante sesiones de trabajo con los usuarios designados para este estudio.

Si se ha decidido describir los sistemas a nivel lgico, y si existe un conocimiento suficiente de los sistemas de informacin a especificar, puede hacerse directamente, aplicndolas tcnicas de modelizacin y siguiendo un mtodo descendente. Si no se dispone del conocimiento suficiente, se construyen los modelos a partir de la descripcin del modelo fsico, es decir, en forma ascendente.

Si se tiene que describir el modelo fsico, se puede hacer mediante un Diagrama de Representacin en el que se recojan todos los componentes fsicos y su referencias cruzadas. Otra opcin es describir el modelo fsico de forma ms detallada, para lo que es necesaria la utilizacin de herramientas de tipo scanner.

Es conveniente indicar la localizacin geogrfica y fsica actual de los mdulos y datos de los sistemas de informacin afectados, evaluando al mismo tiempo la redundancia en las distintas unidades organizativas.

Cuadro 10

PRODUCTOS EVS 2.3

PRODUCTOS

TCNICAS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Descripcin de la situacin actual (EVS 2.1)

Catlogo de usuarios (EVS 2.2)

Descripcin de la situacin actual:

Descripcin lgica del sistema actual

Modelo Fsico del Sistema actual (opcional)

Matriz de localizacin geogrfica y fsica de mdulos y datos, incluidas las redundancias.

Diagrama de flujos de datos

Modelo Entidad/Relacin extendido

Diagrama de clases

Diagrama de Interaccin de objetos

Matricial

Diagrama de representacin

Sesiones de trabajo

Analistas

Usuarios Expertos

Equipo de soporte tcnico.

8.2.4EVS 2.4: Realizacin del diagnstico de la situacin actual

Con el fin de elaborar el diagnstico de la situacin actual se analiza la informacin de los sistemas de informacin existentes, obtenida en la tarea anterior y se identifican problemas, deficiencias y mejoras. Estas ltimas deben tenerse en cuenta en la definicin de los requisitos.

En el caso de haber realizado un Plan de Sistemas de Informacin, se considera la valoracin realizada sobre los sistemas de informacin actuales que pertenecen al mbito de este estudio.

Si se ha tomado la decisin de no describir la situacin actual, se realiza un diagnstico global justificando esa decisin.

Cuadro 11

PRODUCTOS EVS 2.4

PRODUCTOS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Descripcin de la Situacin Actual (EVS 2.3)

Catlogo de Objetivos del EVS (EVS 1.3)

Valoracin de la situacin actual (PSI 5.3)

Descripcin de la situacin actual:

Diagnstico de la Situacin Actual

Analistas

Responsable de Mantenimiento

8.3EVS 3: DEFINICIN DE REQUISITOS DEL SISTEMA

Esta actividad incluye la determinacin 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 informacin obtenida definiendo los requisitos y sus prioridades, que se aaden al catlogo de requisitos que servir para el estudio y valoracin de las distintas alternativas de solucin que se propongan.

Cuadro 12

TAREAS EVS 3

TAREA

PRODUCTOS

TCNICAS Y

PRCTICAS

PARTICIPANTES

EVS 3.1

Identificacin de las directrices tcnicas y de gestin

Catlogo de normas

Catalogacin

Jefe de Proyecto

Analistas

Usuarios expertos

EVS 3.2

Identificacin de Requisitos situacin actual

Identificacin de requisitos

Sesiones de trabajo

Jefe de Proyecto

Analistas

Usuarios expertos

EVS 3.3

Catalogacin de Requisitos

Catlogo de Requisitos

Catalogacin

Jefe de Proyecto

Analistas

Usuarios Expertos

8.3.1EVS 3.1: Identificacin de las directrices tcnicas y de gestin

La realizacin de esta tarea permite considerar los trminos de referencia para el sistema en estudio desde el punto de vista de directrices tanto tcnicas como de gestin. Si el sistema en estudio pertenece al mbito de un Plan de Sistemas de Informacin vigente, ste proporciona un marco de referencia a considerar en esta tarea.

Con este fin, se recoge informacin sobre los estndares y procedimientos que deben considerarse al proponer una solucin, relativos a:

Polticas tcnicas:

Gestin de Proyectos (seguimiento, revisin y aprobacin final).

Desarrollo de Sistemas (existencia de normativas, metodologas y tcnicas de programacin).

Arquitectura de Sistemas (centralizada, distribuida).

Poltica de Seguridad (control de accesos, integridad de datos, disponibilidad de aplicaciones).

Directrices de Planificacin.

Directrices de Gestin de Cambios.

Directrices de Gestin de Calidad.

Cuadro 13

PRODUCTOS EVS 3.1

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Catlogo de Normas del PSI (PSI 3.2)

Recopilacin de Directrices Tcnicas y de Gestin (externo)

Catlogo de normas

Catalogacin

Jefe de Proyecto

Analistas

Usuarios Expertos

8.3.2EVS 3.2: Identificacin de Requisitos

Para la obtencin de las necesidades que ha de cubrir el sistema en estudio, se debe decidir qu tipo de sesiones de trabajo se realizarn y con qu frecuencia tendrn lugar, en funcin de la disponibilidad de los usuarios participantes.

Si se ha realizado el Estudio de la Situacin Actual (EVS 2), puede ser conveniente seleccionar la informacin de los sistemas de informacin existentes que resulte de inters para el desarrollo de dichas sesiones de trabajo.

Una vez establecidos los puntos anteriores, se planifican las sesiones de trabajo con los usuarios participantes identificados al estudiar el alcance del Estudio de Viabilidad del Sistema (EVS 1.3), y se realizan de acuerdo al plan previsto. La informacin obtenida depende del tipo de sesin de trabajo seleccionado.

Cuadro 14

PRODUCTOS EVS 3.2

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Descripcin General del Sistema (EVS 1.2)

Catlogo de Requisitos (EVS 1.2)

Equipo de Trabajo del EVS (EVS 1.3)

Catlogo de Usuarios (EVS 2.2/1.3)

Descripcin de la Situacin Actual (EVS 2.4)

Identificacin de Requisitos

Sesiones de Trabajo

Jefe de Proyecto

Analistas

Usuarios Expertos

8.3.3.EVS 3.3: Catalogacin de Requisitos

Se analiza la informacin obtenida en las sesiones de trabajo para la Identificacin de Requisitos, definiendo y catalogando los requisitos (funcionales y no funcionales) que debe satisfacer el sistema, indicando sus prioridades. Se incluirn tambin requisitos relativos a distribucin geogrfica y entorno tecnolgico.

Cuadro 15

PRODUCTOS EVS 3.3

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Identificacin de Requisitos (EVS 3.2)

Catlogo de Requisitos (EVS 1.2)

Catlogo de Requisitos

Catalogacin

Jefe de Proyecto

Analistas

Usuarios Expertos

8.4EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIN

Este estudio se centra en proponer diversas alternativas que respondan satisfactoriamente a los requisitos planteados, considerando tambin los resultados obtenidos en el Estudio de la Situacin Actual (EVS 2), en el caso de que se haya realizado.

Teniendo en cuenta el mbito y funcionalidad que debe cubrir el sistema, puede ser conveniente realizar, previamente a la definicin de cada alternativa, una descomposicin del sistema en subsistemas.

En la descripcin de las distintas alternativas de solucin propuestas, se debe especificar si alguna de ellas est basada, total o parcialmente, en un producto existente en el mercado. Si la alternativa incluye un desarrollo a medida, se debe incorporar en la descripcin de la misma un modelo abstracto de datos y un modelo de procesos, y en orientacin a objetos, un modelo de negocio y un modelo de dominio.

Cuadro 16

TAREAS EVS 4

TAREA

PRODUCTOS

TCNICAS Y

PRCTICAS

PARTICIPANTES

EVS 4.1

Preseleccin de

Alternativas de

Solucin

Descomposicin Inicial del Sistema en Subsistemas (opcional)

Alternativas de Solucin a Estudiar

Diagrama de representacin

Jefe de Proyecto

Analistas

Tcnicos de sistemas

EVS 4.2

Descripcin de las Alternativas de Solucin

Catlogo de Requisitos

Alternativas de solucin a estudiar:

Catlogo de Requisitos (cobertura)

Modelo de Descomposicin en Sub-sistemas

Matriz Procesos/ Localizacin Geogrfica

Matriz Datos/Localizacin Geogrfica

Entorno Tecnolgico y Comunicaciones

Estrategia de Implantacin Global del Sistema

Si la alternativa requiere desarrollo:

Modelo Abstracto de Datos/Modelo de Procesos (En caso de Estructurado)

Modelo de Negocio/Modelo de Dominio (En caso de Orientacin a Objetos)

Si la alternativa incluye producto software estndar:

Descripcin del Producto

Previsin de Evolucin del Producto

Costes Ocasionados por producto

Estndares del Producto

Descripcin de Adaptacin (si es necesaria)

Matricial

Modelo Entidad/

Relacin extendido

Diagrama de Flujo de Datos

Casos de Uso

Diagrama de Clases

Catalogacin

Diagrama de Repre-sentacin

Jefe de Proyecto

Analistas

Usuarios Expertos

Tcnicos de sistemas

Responsables de Seguridad

Especialistas en Comunicaciones

8.4.1EVS 4.1: Preseleccin de Alternativas de Solucin

Una vez definidos los requisitos a cubrir por el sistema, se estudian las diferentes opciones que hay para configurar la solucin. Entre ellas, hay que considerar la adquisicin de productos software estndar del mercado, desarrollos a medida o soluciones mixtas.

Dependiendo del alcance del sistema y las posibles opciones, puede ser conveniente realizar inicialmente una descomposicin del sistema en subsistemas. Se establecen las posibles alternativas sobre las que se va a centrar el estudio de la solucin, combinando las opciones que se consideren ms adecuadas.

Cuadro 17

PRODUCTOS EVS 4.1

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Informacin de Productos Software del Mercado (externo)

Descripcin General del Sistema (EVS 1.2)

Descripcin de la Situacin Actual (EVS 2.4)

Catlogo de Requisitos (EVS 3.3)

Descomposicin Inicial del Sistema en Subsistemas (opcional)

Alternativas de Solucin a Estudiar

Diagrama de Representacin

Jefe de Proyecto

Analistas

Tcnicos de Sistemas

8.4.2EVS 4.2: Descripcin de las Alternativas de Solucin

Para cada alternativa propuesta, se identifican los subsistemas que cubre y los requisitos a los que se da respuesta.

Se deben considerar tambin aspectos relativos a la cobertura geogrfica (mbito y limitaciones) de procesos y datos, teniendo en cuenta a su vez la gestin de comunicaciones y control de red.

En la definicin de cada alternativa, se propone una estrategia de implantacin teniendo en cuenta tanto la cobertura global del sistema como la cobertura geogrfica.

Si la alternativa incluye desarrollo se describe el modelo abstracto de datos y el modelo de procesos, y en el caso de Orientacin a Objetos, el modelo de negocio y, opcionalmente, el modelo de dominio. Se propone el entorno tecnolgico que se considera ms apropiado para la parte del sistema basada en desarrollo y se describen los procesos manuales.

Si la alternativa incluye una solucin basada en producto se analiza su evolucin prevista, adaptabilidad y portabilidad, as como los costes ocasionados por licencias, y los estndares del producto. Igualmente se valora y determina su entorno tecnolgico.

Cuadro 18

PRODUCTOS EVS 4.2

PRODUCTOS

TCNICAS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Descripcin General del Sistema (EVS 1.2)

Descripcin de la Situacin Actual (EVS 2.4)

Catlogo de Requisitos (EVS 3.3)

Descomposicin Inicial del Sistema en Subsistemas (EVS 4.1) (opcional)

Alternativas de Solucin a Estudiar (EVS 4.1)

Catlogo de Requisitos (actualizado)

Alternativas de Solucin a Estudiar:

Catlogo de Requisitos (cobertura)

Modelo de Descomposicin en Subsistemas

Matriz Procesos / Localizacin Geogrfica

Matriz Datos / Localizacin Geogrfica

Entorno Tecnolgico y Comunicaciones

Estrategia de Implantacin Global del Sistema

Descripcin de Procesos Manuales

Si la alternativa incluye desarrollo:

Modelo Abstracto de Datos / Modelo de Procesos

Modelo de Negocio / Modelo de Dominio (en caso de Orientacin a Objetos)

Si la alternativa incluye un producto software estndar de mercado:

Descripcin del Producto

Evolucin del Producto

Costes Ocasionados por Producto

Estndares del Producto

Descripcin de Adaptacin (si es necesaria)

Matricial

Diagrama de Flujo de Datos

Modelo Entidad/ Relacin extendido

Diagrama de Clases

Casos de Uso

Catalogacin

Diagrama de Representa-cin

Jefe de Proyecto

Analistas

Usuarios Expertos

Tcnicos de Sistemas

Responsable de Seguridad

Especialistas en Comunica-ciones

8.5EVS 5: VALORACIN DE LAS ALTERNATIVAS

Una vez descritas las alternativas se realiza una valoracin de las mismas, considerando el impacto en la organizacin, tanto desde el punto de vista tecnolgico y organizativo como de operacin, y los posibles beneficios que se esperan contrastados con los costes asociados. Se realiza tambin un anlisis de los riesgos, decidiendo cmo enfocar el plan de accin para minimizar los mismos y cuantificando los recursos y plazos precisos para planificar cada alternativa.

Cuadro 19

TAREAS EVS 5

TAREA

PRODUCTOS

TCNICAS Y

PRCTICAS

PARTICIPANTES

EVS 5.1

Estudio de la

Inversin

Valoracin de Alternativas:

Impacto en la Organizacin de Alternativas

Coste / Beneficio de Alternativas

Anlisis Coste/Beneficio

Jefe de Proyecto

Analistas

EVS 5.2

Estudio de los

Riesgos

Valoracin de Alternativas:

Valoracin de Riesgos

Impacto en la Organizacin

Jefe de Proyecto

Analistas

EVS 5.3

Planificacin de

Alternativas

Plan de Trabajo de Cada

Alternativa:

Enfoque del Plan de Trabajo de Cada

Alternativa o Planificacin de cada Alternativa

Planificacin

Jefe de Proyecto

Analistas

8.5.1EVS 5.1: Estudio de la Inversin

Para cada alternativa de solucin propuesta, se valora el impacto en la organizacin y se establece su viabilidad econmica. Para ello, se realiza un anlisis coste/beneficio que determina los costes del sistema y los pondera con los beneficios tangibles, cuantificables directamente, y con los beneficios intangibles, buscando el modo de cuantificarlos.

Cuadro 20

PRODUCTOS EVS 5.1

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Alternativas de Solucin a Estudiar (EVS 4.2)

Valoracin de Alternativas:

Impacto en la Organizacin de Alternativas

Coste / beneficio de Alternativas

Anlisis Coste / Beneficio

Jefe de Proyecto

Analistas

8.5.2EVS 5.2: Estudio de los Riesgos

Para cada alternativa se seleccionan los factores de situacin que habr que considerar, relativos tanto a la incertidumbre como a la complejidad del sistema. Se identifican y valoran los riesgos asociados y se determinan las medidas a tomar para minimizarlos.

Cuadro 21

PRODUCTOS EVS 5.2

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Alternativas de Solucin a Estudiar (EVS 4.2)

Valoracin de Alternativas (EVS 5.1)

Valoracin de Alternativas:

Valoracin de Riesgos

Impacto en la Organizacin

Jefe de Proyecto

Analistas

8.5.3EVS 5.3: Planificacin de Alternativas

En funcin del anlisis de riesgos realizado en la tarea anterior, y para cada una de las alternativas existentes:

Se determina el enfoque ms adecuado para llevar a buen fin la solucin propuesta en cada alternativa.

Se realiza una planificacin, teniendo en cuenta los puntos de sincronismo con otros proyectos en desarrollo o que est previsto desarrollar, segn se ha recogido en el catlogo de requisitos.

De esta manera se garantiza el cumplimiento del plan de trabajo en los restantes procesos del ciclo de vida.

Cuadro 22

PRODUCTOS EVS 5.3

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Catlogo de Requisitos (EVS 4.2)

Alternativas de Solucin a Estudiar (EVS 4.2)

Valoracin de Alternativas (EVS 5.2)

Plan de Trabajo de Cada Alternativa:

Enfoque del Plan de Trabajo de Cada Alternativa

Planificacin de Cada Alternativa

Planificacin

Jefe de Proyecto

Analistas

8.6EVS 6: SELECCIN DE LA SOLUCIN

Antes de finalizar el Estudio de Viabilidad del Sistema, se convoca al Comit de Direccin para la presentacin de las distintas alternativas de solucin, resultantes de la actividad anterior. En dicha presentacin, se debaten las ventajas de cada una de ellas, incorporando las modificaciones que se consideren oportunas, con el fin de seleccionar la ms adecuada. Finalmente, se aprueba la solucin o se determina su inviabilidad.

Cuadro 23

TAREAS EVS 6

TAREA

PRODUCTOS

TCNICAS Y

PRCTICAS

PARTICIPANTES

EVS 6.1

Convocatoria de

Presentacin

Plan de Presentacin de Alternativas

Presentacin

Jefe de Proyecto

EVS 6.2

Evaluacin de

Alternativas y

Seleccin

Plan de Presentacin de Alternativas

Catlogo de Requisitos

Solucin Propuesta:

Descripcin de la Solucin Contexto del Sistema con la definicin de las interfaces)

Impacto en Organizacin de la Solucin

Coste / Beneficio de la Solucin

Valoracin de Riesgos de la Solucin

Enfoque del Plan de Trabajo de la Solucin

Planificacin de la Solucin

Presentacin

Sesiones de Trabajo

Comit de Direccin

Jefe de Proyecto

Analistas

EVS 6.3

Aprobacin de la

Solucin

Aprobacin de la Solucin

Comit de Direccin

Jefe de Proyecto

8.6.1EVS 6.1: Convocatoria de la Presentacin

Se efecta la convocatoria de la presentacin de las distintas alternativas propuestas, adjuntando los productos de la actividad anterior con el fin de que el Comit de Direccin pueda estudiar previamente su contenido. Se espera confirmacin por parte del Comit de Direccin de las alternativas a presentar.

Cuadro 24

PRODUCTOS EVS 6.1

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Catlogo de Usuarios (EVS 2.2/1.3)

Alternativas de Solucin a Estudiar (EVS 4.2)

Valoracin de Alternativas (EVS 5.2)

Plan de Trabajo de Cada Alternativa (EVS 5.3)

Plan de Presentacin de Alternativas

Presentacin

Jefe de Proyecto

8.6.2EVS 6.2: Evaluacin de las Alternativas y Seleccin

Una vez recibida la confirmacin de qu alternativas van a ser presentadas para su valoracin, se efecta su presentacin al Comit de Direccin, debatiendo sobre las ventajas e inconvenientes de cada una de ellas y realizando las modificaciones que sugiera dicho Comit, hasta la seleccin de la solucin final.

Cuadro 25

PRODUCTOS EVS 6.2

PRODUCTOS

PRCTICAS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Descripcin General del Sistema (Contexto del Sistema) (EVS 1.2)

Catlogo de Requisitos (EVS 4.2)

Alternativas de Solucin a Estudiar (EVS 4.2)

Valoracin de Alternativas (EVS 5.2)

Plan de Trabajo de Cada Alternativa (EVS 5.3)

Plan de Presentacin de Alternativas (EVS 6.1)

Plan de Presentacin de Alternativas

Catlogo de Requisitos (Actualizado en Funcin de la Cobertura de la Solucin)

Solucin Propuesta:

Descripcin de la Solucin

Modelo de Descomposicin

en Subsistemas

Matriz Procesos / Localiza-

cin Geogrfica

Matriz Datos / Localizacin

Geogrfica

Entorno Tecnolgico y Comu-

nicaciones

Estrategia de Implantacin

Global del Sistema

Descripcin de 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 estndar de mercado:

Descripcin del Producto

Evolucin del Producto

Costes Ocasionados por

Producto

Estndares del Producto

Descripcin de Adaptacin (si

es necesaria)

Contexto del Sistema (con la Definicin de las Interfaces en Funcin de la Solucin)

Impacto en la Organizacin de la Solucin

Coste / Beneficio de la Solucin

Valoracin de Riesgos de la Solucin

Enfoque del Plan de Trabajo de la Solucin

Planificacin de la Solucin

Presentacin

Sesiones de Trabajo

Comit de Direccin

Jefe de Proyecto

Analistas

8.6.3EVS 6.3: Aprobacin de la Solucin

El Comit de Direccin da su aprobacin formal o determina la inviabilidad del sistema, por motivos econmicos, de funcionalidad como resultado del incumplimiento de los requisitos identificados en plazos razonables o de cobertura de los mismos, etc.

Cuadro 26

PRODUCTOS EVS 6.3

PRODUCTOS

PARTICIPANTES

DE ENTRADA

DE SALIDA

Catlogo de Requisitos (EVS 6.2)

Solucin Propuesta (EVS 6.2)

Aprobacin de la Solucin

Comit de Direccin

Jefe de Proyecto

Cuadro 27

PARTICIPANTES EN LAS ACTIVIDADES DEL PROCESO EVS

ESTUDIO DE VIABILIDAD

DEL SISTEMA

ACTIVIDADES

EVS1

EVS2

EVS3

EVS4

EVS5

EVS6

Analistas

x

x

x

x

x

x

Comit de Direccin

x

x

Directores Usuarios

x

Equipo de soporte tcnico

x

Especialistas en comunicaciones

x

Jefe de Proyecto

x

x

x

x

x

x

Responsable de Mantenimiento

x

Responsable de Seguridad

x

Tcnicos del Sistema

x

Usuarios Expertos

x

x

x

Cuadro 28

TCNICAS/PRCTICAS UTILIZADAS EN LAS

ACTIVIDADES DEL PROCESO EVS

ESTUDIO DE VIABILIDAD

DEL SISTEMA

ACTIVIDADES

EVS1

EVS2

EVS3

EVS4

EVS5

EVS6

Anlisis coste-beneficio

x

Casos de uso

x

Catalogacin

X

x

x

x

Diagrama de clases

x

x

Diagrama de descomposicin funcional

X

Diagrama de Flujo de Datos

X

x

x

Diagrama de Interaccin de Objetos

x

Diagrama de Representacin

x

x

Impacto en la organizacin

x

Matricial

x

x

Modelo Entidad-Relacin Extendido

x

x

Planificacin

x

Presentacin

x

Sesiones de trabajo

X

x

x

x

ACTIVIDADES

EVS 1Establecimiento del alcance del sistema

EVS 2Estudio de la Situacin actual

EVS 3Definicin de requisitos del sistema

EVS 4Estudio de alternativas de solucin

EVS 5Valoracin de las alternativas

EVS 6Seleccin de la solucin

9.CRITERIOS PARA LA EVALUACIN Y SELECCIN DE PROYECTOS DE TI

Para tomar una decisin sobre si ejecutamos un proyecto, es necesario seguir los siguientes pasos:

a) Justificar el proyecto a partir de la estrategia tecnolgica y la planificacin informtica que lo respalda (planificacin estratgica)

b) Establecer los criterios de seleccin y mtodo que se utilizarn para tomar la decisin sobre la ejecucin del proyecto. Este proceso nos permitir clasificar y ordenar los datos por recolectar para las diferentes alternativas.

c) Realizar estudios de factibilidad, calidad tcnica, riesgo y costo beneficio de las diferentes alternativas.

d) Con base en los datos recolectados, ordenados y clasificados, segn los criterios de seleccin, se renen las personas responsables de tomar la decisin para ejecutar o no el proyecto.

Para nuestros efectos, nos centraremos en los pasos b) y c), que constituyen el objeto del estudio, en el cual se definen las variables que darn forma al modelo.

Debemos insistir, en primera instancia en la necesidad de medir y cuantificar, con nmeros, todos los datos que debemos recolectar para cada una de las alternativas.

Existen dos formas de hacer una medicin: la subjetiva y la objetiva. Este aspecto es importante de considerar debido a que en todo proyecto siempre habr un grado de incertidumbre y, al