Descargar

Planificación de Sistemas de Información


  1. Planificación de proyectos de Software

Consta de 3 fases distintas que son:

a.- Fase de Estudio

b.- Fase de Definición c.- Fase de Análisis

Los mismos que estudian los bloques elementales:

PERSONAS, DATOS, ACTIVIDADES, REDES Y TECNOLOGIA

a.- Fase de estudio

1.- Formar el equipo de planificación.- La primera actividad en la fase de estudio consiste en formar el equipo de planificación.

Normalmente, los nombramientos los hace el directivo que patrocina el proyecto. El directivo patrocinador es el ejecutivo de máximo nivel dentro de la empresa.

Los participantes requeridos, y los papeles que desempeña en la mayoría de las metodologías de planificación, están normalizados por la metodología o por la compañía de consultaría de gestión que se utiliza. En términos ideales, los primeros nombramientos deberían ser los de director ejecutivo y director de información.

2.- Definir el ámbito y las expectativas de la planificación.- Esta seria la primera actividad en "equipo" y llevarlo a la práctica resulta difícil en algunas ocasiones debido a motivos geográficos, a la envergadura y la complejidad de la empresa, a cuestiones políticas o la falta de un compromiso por parte de los directivos de alto rango. Es particularmente importante definir el ámbito cuando no cubre todo el sistema.

Una de las formas más sencillas de definir el ámbito de planificación es trazar modelos de contexto, simples imágenes que reflejan los límites y el ámbito del sistema.

3.- Identificar las medidas de rendimiento de la empresa.- La mejor manera de desarrollar esta actividad es mediante reuniones de tipo DCA entre el equipo de planificación.

4.- Desarrollar un plan de Proyecto.- El plan y el presupuesto del proyecto es desarrollado por el equipo de planificación. Su entrada es el ámbito del proyecto. La técnica básica requerida para completar esta actividad es la gestión de proyectos.

5.- Revisar los descubrimientos y comunicar las aspiraciones de la planificación.- El equipo de planificación es el encargado de llevar a cabo esta actividad.

Sus entradas incluyen toda documentación extraída del diccionario; la salida final es un informe de proyecto de planificación.

b.- Fase de definición

1.- Definir un modelo de la empresa.- ¿Qué es un modelo? Un modelo es una representación de la realidad. En la tradición clásica de que "una imagen vale mas que mil palabras", los modelos son en su mayor parte representaciones graficas de la realidad.

Los modelos desarrollados en la fase de definición describen el sistema de empresa en un nivel general de detalle adecuado para los directores ejecutivos que ayudaron a desarrollar los modelos. Estos modelos reciben a veces el nombre de modelos de empresa.

El modelo en pirámide ofrece una estructura para el desarrollo de los modelos de empresa. Entre los modelos apropiados de sistemas de empresas susceptibles de ser añadidos al diccionario pueden incluirse los siguientes: personas, actividades, datos, redes y tecnología.

2.- Evaluar las estrategias actuales de la empresa.- Algunas estrategias de la empresa pueden evaluarse antes de la modelización de empresa. Así esta actividad puede iniciarse al mismo tiempo que la actividad 1.

Las técnicas y los conocimientos básicos que se requieren para completar esta actividad son las entrevistas, las observaciones, el muestreo, el estudio y el diseño conjunto de aplicaciones.

Estas técnicas matriciales son relativamente sencillas; por tanto, no se volverán a tratar en este texto.

3.- Evaluar las estrategias y los servicios actuales de información.- El equipo de planificación lleva a cabo normalmente estudios de la comunidad de gestión para recoger las opiniones y los datos necesarios. El instrumento de estudio (Por lo general un cuestionario) debe ser cuidadosamente diseñado para evitar que dirija o condicione las investigaciones. Los resultados tabulados son recopilados y revisados por el equipo de planificación.

También pueden elaborarse matrices de asociaciones para esta actividad. Estas matrices sugieren las relaciones existentes entre sistemas de información, tecnología de información y medidas de rendimiento de la empresa.

4.- Identificar áreas de empresa y establecer prioridades.- Las áreas de empresa poseen

"funciones cruzadas".

Por tanto, derriban las barreras de las aplicaciones construidas entorno a una unidad organizativa. Por ejemplo, un área de empresa de pedidos puede incluir a personas, datos, procesos, lugares y tecnologías pertenecientes a varios departamentos (como ventas, almacenes, fabricación, expediciones y cobro de cuentas). En vez de fabricar sistemas independientes para cada departamento, se construye un sistema integrado y simplificado que cubra las necesidades y los departamentos implicados en dicha área de empresa.

5.- Completar la nueva arquitectura de información.- Definir la arquitectura de servicios de información (bloque elemental de PERSONAS) requiere del equipo de planificación que determine la mejor manera de organizar los servicios de información.

La combinación de los modelos de empresa (divididos en áreas de empresa), la arquitectura tecnológica y la organización de los servicios de información completan nuestra arquitectura de información propuesta.

6.- Identificar y planear proyectos posteriores.- En esta función de la metodología de planificación utilizada, la siguiente actividad tendrá lugar en una de las dos direcciones siguientes: Identificar y planear proyectos subsiguientes de desarrollo de aplicaciones.- Estos proyectos deberían enviarse directamente a la etapa de desarrollo de sistemas para su análisis y diseño. Identificar y planear proyectos subsiguientes de análisis de áreas de empresa.- Este es el planteamiento requerido en los métodos basados en la ingeniería de la información.

7.- Revisar las conclusiones y aprobar el plan.- Son posibles dos niveles de revisión:

• Una revisión de calidad que asegure que las fases se terminaron conforme a la metodología y que la documentación resultante (en el diccionario) es completa, consiste y acorde con las normas.

• Una revisión de viabilidad que reevalúe la viabilidad de continuar con el proyecto.

c.- Fase de Análisis

1.- Formar el equipo de análisis.- Algunos centros de sistemas de información forman equipos de especialistas en herramientas automatizadas para los análisis de áreas de empresa.

Los especialistas en herramientas automatizadas son miembros de equipos altamente integrados que incluyen expertos en coordinación de sesiones DCA, al menos un analista o consultor conocedor de la metodología aplicada, usuarios experimentados en herramientas CASE, miembros especialistas en modelización de datos, analistas de datos, analistas de redes y otros.

2.- Identificar medidas de rendimiento del área de la empresa.- Esta tarea es realizada por el equipo de análisis con la ayuda adicional apropiada de otros directivos del área de empresa. El resultado de esta actividad es un conjunto de medidas de rendimiento del área de empresa. Las áreas de empresa obtienen sus metas y objetivos de la empresa en su conjunto, condicionados por el propio cometido del área de la empresa.

3.- Elaborar un modelo de área de empresa.- Nuestro modelo de pirámide ofrece una estructura para los modelos de áreas de empresa que van a desarrollarse. Los modelos más característicos son: Actividades, Datos y Redes.

4.- Evaluar el rendimiento actual de empresa y de los sistemas de información.- Este análisis es llevado a cabo normalmente mediante la construcción y el análisis de diversas matrices d asociaciones. Mediante la construcción y el análisis de matrices de asociaciones, el equipo de análisis conoce cual es la calidad del soporte dado por los bloques elementales existentes a las medidas del área d empresa.

5.- Identificar proyectos de desarrollo y establecer prioridades.- Esta actividad es relativamente sencilla. Los modelos de áreas de empresa ya ilustran la integración de los procesos, los datos y las redes de empresa. El equipo de análisis simplemente identifica o divide los proyectos de desarrollo adecuados en los modelos y define prioridades entre ellos en una secuencia razonable.

6.- Planear una estrategia y proyectos de desarrollo de aplicaciones.- El plan deberá incluir un calendario general o una secuencia de todos los proyectos de desarrollo en el área de empresa. Este calendario podrá abarcar varios años ya que un área de empresa puede generar muchos proyectos. Los expertos en ingeniería de información y herramientas CASE esperan una reducción sustancial en este lapso de tiempo mediante el uso de técnicas de desarrollo rápido de aplicaciones (DRA) y de tecnología CASE.

7.- Revisar las conclusiones y aprobar el plan.- Como siempre son posibles dos niveles:

• Una revisión de calidad, para asegurar que la fase de análisis se ha completado en concordancia con la metodología y que la documentación resultante (en el diccionario) es completa, consistente y acorde con las normas.

• Una revisión de viabilidad, que reevalué la viabilidad de iniciar los proyectos de desarrollo de prioridad más alta.

En ambos casos, el analista de sistemas o el propietario de sistemas reúnen la documentación apropiada desde el diccionario.

Planificación de proyectos de Software

  • Que es un proyecto de Sistema o Software. ?

Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software.

La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.

  • Objetivos de la Planificación del Proyecto.

El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.

El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

  • Actividades asociadas al proyecto de software.

  • Ámbito del Software.

Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software.

En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos

Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

El Ámbito se define como un pre-requisito para la estimación y existen algunos elementos que se debe tomar en cuenta como es:

• La Obtención de la Información necesaria para el software. Para esto el analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés para su desarrollo.

  • RECURSOS:

La Segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables.

Y en la parte más alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano).

Cada recurso queda especificado mediante cuatro características:

Descripción del Recurso.

Informes de disponibilidad.

• Fecha cronológica en la que se requiere el recurso.

• Tiempo durante el que será aplicado el recurso.

  • Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñara cada profesional.

  • Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, esto es la creación y la reutilización de bloques de construcción de Software.

Tales bloques se deben establecer en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para la también fácil integración.

El Autor Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a medida que se avanza con la planificación:

• Componentes ya desarrollados.

• Componentes ya experimentados.

• Componentes con experiencia Parcial.

• Componentes nuevos.

  • Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de

Ingeniería de Software, incorpora Hardware y Software.

El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles. Muchas veces el desarrollo de las pruebas de validación de un proyecto de software para la composición automatizada puede necesitar un compositor de fotografías en algún punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software.

  • ESTIMACION DEL PROYECTO DE SOFTWARE.

En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento más caro de la mayoría de los sistemas informáticos.

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:

• Deje la estimación para más adelante (obviamente podemos realizar una estimación al cien por cien fiable después de haber terminado el proyecto.

• Base las estimaciones en proyectos similares ya terminados.

• Utilice técnicas de descomposición relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto.

• Desarrolle un modelo empírico para él cálculo de costos y esfuerzos del Software. Desdichadamente la primera opción, aunque atractiva no es práctica.

La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son métodos viables para la estimación del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas como comprobación de las otras.

Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a construir y generar una estimación de su tamaño.

  • Estimación basada en el Proceso.

Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea.

Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software.

  • DIFERENTES MODELOS DE ESTIMACION.

Existen diferentes modelos de estimación como son:

  • Los Modelos Empíricos:

Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia.

  • El Modelo COCOMO.

Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su nombre en Inglés (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm está constituida por los siguientes:

• Modelo I. El Modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de

Software en función del tamaño del programa, expresado en las líneas estimadas.

• Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

• Modelo III. El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.) del proceso de ingeniería de Software.

  • Herramientas Automáticas De Estimación.

Las herramientas automáticas de estimación permiten al planificador estimar costos y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren de una o más clases de datos.

A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de desarrollo y riesgos asociados.

En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará implicada. Además el planificador debe predecir los recursos de hardware y software que va a requerir y el riesgo implicado.

Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una estimación más exacta. La estimación del proyecto de software nunca será una ciencia exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la precisión de la estimación.

 

 

Autor:

Jorge Luis Loor Párraga