Ejemplo Fases de un proyecto informático PDF

Preview

Summary

PROYECTO INFORMÁTICO”
DEFINICIÓN DE UN PROYECTO INFORMÁTICO...

Description

“PROYECTO INFORMÁTICO” DEFINICION DE UN PROYECTO INFORMATICO Para llevar a cabo un buen proyecto informático, debemos comprender el ámbito del trabajo a realizar, los recursos requeridos, las tareas a ejecutar, las referencias a tener en cuenta, el esfuerzo (coste) a emplear y la agenda a seguir. La planificación del proyecto informático; el primer paso en el proceso de la ingeniería del software, nos proporciona ese conocimiento. La planificación del proyecto de software combina dos tareas: investigación y estimación. La investigación nos permite definir el alcance del elemento software de un sistema informático. Usando la especificación del sistema como guía, cada función principal del software puede ser descrita de un modo determinado. Una descripción funcional concreta, junto con otros datos que discutiremos más adelante, nos proporcionan el objetivo para la estimación. Cuando se han hecho las estimaciones, miramos hacia adelante y aceptamos como normal cierto grado de incertidumbre. La segunda faceta de la planificación del software es la estimación, y por tanto, una característica de la planificación es la incertidumbre. Citando a Frederick Brooks: ... Nuestras técnicas de estimación están pobremente desarrolladas. Mas seriamente, reflejan un socavado supuesto que es bastante incierto, o sea. de que todo irá bien. ... Como dudamos de nuestras estimaciones, a los directores del proyecto frecuentemente les falta cierta obstinación cortés que haga esperar a la gente un buen producto. Aunque la estimación es más arte que ciencia, la planificación del software no ha de llevarse a cabo de una forma fortuita. Existen técnicas útiles para la estimación de costes y agendas. Se pueden conseguir útiles aproximaciones para la planificación del proyecto de software. La planificación proporciona un plano guía para el desarrollo del software. No es aconsejable embarcarse sin él.

OBSERVACIONES SOBRE LA ESTIMACION A un destacado ejecutivo se le preguntó una vez por la característica más importante de un director de proyecto. Respondió: “...Una persona con la habilidad de saber qué es lo que fallará antes de que realmente falle...”. Debemos añadir: “... y con el coraje para hacer estimaciones cuando el Futuro no está claro...” La estimación de recursos, de costes, y de agendas para el esfuerzo de desarrollo de software requiere experiencia, acceso a una buena información histórica, y coraje para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos. La estimación conlleva un riesgo inherente. En la Figura 1.1 se ilustran los factores que aumentan el riesgo. Los ejes de la figura representan las características del proyecto a estimar. La complejidad del proyecto tiene un gran efecto en la incertidumbre inherente de la planificación. La complejidad, sin embargo, es una medida relativa que se ve afectada por la familiaridad con anteriores esfuerzos. Una aplicación en tiempo real debe ser intuida como “excesivamente compleja” para un equipo de desarrollo de software que previamente sólo ha desarrollado aplicaciones no interactivas. La misma aplicación en tiempo real debe verse como un paseo para un equipo de desarrollo de software que haya estado metido de lleno en controles de procesos de alta

velocidad. Se han propuesto ciertas medidas cuantitativas de la complejidad del software. Tales medidas se aplican en el diseño o a nivel de código y son por tanto difíciles de usar durante la planificación del software (antes de que exista el diseño y el código). Sin embargo, se pueden establecer otras evaluaciones mas objetivas de la complejidad al principio del proceso de planificación.

Grado de estructuración, definición, variabilidad. Dominio de bajo riesgo.

Complejidad basada En anteriores esfuerzos. Tamaño del esfuerzo. Figura 1.1

El tamaño del proyecto es otro factor importante que puede afectar la precisión y eficacia de las estimaciones. A medida que crece el tamaño. la interdependencia entre los distintos elementos del software crece rápidamente. La descomposición del problema, una importante técnica para la estimación, se hace mas difícil dado que los elementos descompuestos pueden seguir siendo todavía enormes. Se puede añadir un corolario a la ley de Murphy: “Si pueden fallar más cosas, más cosas fallarán". El grado de estructuración del proyecto también tiene efecto en el riesgo de la estimación. En este contexto la estructuración se refiere a la facilidad con la que las funciones pueden ser compartimentalizadas y a la naturaleza jerárquica de la información que debe ser procesada. La Figura 1.1 utiliza la medida recíproca a la estructuración, o sea, que a medida que el grado de la estructuración crece, la posibilidad de estimar con precisión mejora, y el riesgo decrece. El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para los recursos, costes y métodos. Si el alcance del proyecto se vislumbra pobremente o los requerimientos del proyectos están sujetos a cambio, la incertidumbre y el riesgo llegan a ser peligrosamente altos. El planificador del software debe exigir completa información de la función, rendimiento y definiciones de interfaz contenidas en la especificación del sistema. El planificador y, más importante, el cliente deben reconocer que cualquier cambio en los requerimientos del software, significa inestabilidad en el coste y en el método.

OBJETIVOS DE LA PLANIFICACION DEL PROYECTO El director del proyecto de software se enfrenta con un dilema al comienzo del esfuerzo del desarrollo. Se requieren estimaciones cuantitativas, pero no hay disponible ninguna información sólida. Un análisis detallado de los requerimientos del software proporcionaría la información necesaria para las estimaciones, pero el análisis a menudo lleva semanas o meses. Las estimaciones son necesarias “ahora”. El objetivo de la planificación del proyecto de software es el de suministrar un área de trabajo que permita al director hacer razonables estimaciones de recursos, costes, y métodos. Estas estimaciones se hacen sin un marco de tiempo limitado al principio de un proyecto de software y deben ser actualizadas regularmente al progresar el proyecto. Como ya se ha dicho, el objetivo de la planificación se alcanza a través de un proceso de descubrimiento de información que lleve a estimaciones razonables.

ALCANCE DEL SOFTWARE La primera actividad en la planificación del proyecto de software es determinar el alcance del software. La función y el rendimiento asignados al software durante la ingeniería del sistema de computadora deben ser valorados para establecer un alcance del proyecto que no sea ambiguo ni incomprensible a nivel de directivos y técnicos. La declaración del alcance del software debe estar delimitada. Por tanto, los datos cuantitativos (por ejemplo, número de usuarios simultáneos, tamaño de las listas de correo, tiempo máximo de respuesta posible) estarán explícitamente establecidos; las restricciones y/o limitaciones (por ejemplo el coste del producto restringe el tamaño de la memoria), han de ser señaladas; y los factores de mitigación (por ejemplo, los algoritmos deseados son bien entendidos y disponibles en Ada) han de ser descritos.

RECURSOS La segunda tarea de la planificación del desarrollo de software es la estimación de los recursos requeridos para acometer el esfuerzo del desarrollo de software. La Figura 1.2 ilustra los recursos de desarrollo como una pirámide. En la base, deben existir las herramientas hardware y software que soporten el esfuerzo de desarrollo. En el nivel más alto, siempre se requiere el recurso primario la gente. Cada recurso se especifica con cuatro características: descripción del recurso: informe de disponibilidad; fecha cronológica en la que se requiere el recurso: tiempo que será aplicado el recurso. Las dos últimas características pueden ser vistas como una ventana temporal. La disponibilidad del recurso para una ventana específica tiene que ser establecida lo más pronto posible.

gente Especificar:  Descripción  Disponibilidad  Duración  Fecha de emisión

Herramientas Hardware/Software

Figura 1.2

Especificar:  Habilidad requerida  Disponibilidad  Duración  Fecha de comienzo

RECURSOS HUMANOS Entre los principales problemas planteados por la crisis del software, ninguno es mas inquietante que la relativa escasez de recursos humanos capaces para el desarrollo del software. La gente es el requerimiento primario del desarrollo del software. El planificador comienza evaluando el alcance y seleccionando las técnicas requeridas para completar el desarrollo. Se ha de especificar tanto la posición en la organización (por ejemplo: director, ingeniero senior de software, etc.) como la especialidad por ejemplo: telecomunicaciones; base de datos; microprocesadores).

PLANIFICACION TEMPORAL DEL PROYECTO DE SOFTWARE. La planificación temporal para proyectos de desarrollo de software puede ser vista desde dos perspectivas bastante diferentes. En la primera, la fecha final de lanzamiento del sistema basado en computadora ya ha sido (irrevocablemente) establecida. La organización del software se ve forzada a distribuir el esfuerzo dentro del marco prescrito. El segundo enfoque de la planificación temporal del software asume que se han discutido unos límites cronológicos aproximados, pero que la fecha final es fijada por la organización del software. El esfuerzo se distribuye para hacer un mejor uso de los recursos y la fecha final se define después de un cuidado análisis del elemento del software. Desafortunadamente, la primera perspectiva se encuentra bastante más frecuentemente que la segunda. La precisión en la planificación puede a veces ser más importante que la precisión en los cálculos de costes. En un entorno orientado al producto, los costes añadidos pueden ser absorbidos por la inflación o la amortización sobre un amplio número de ventas. Sin embargo, una falta de programación puede reducir el impacto de mercado, generar clientes insatisfechos y aumentar los costes internos por la existencia de problemas adicionales durante la integración del sistema. Al enfocar la planificación temporal del proyecto de software se deben plantear ciertas cuestiones. ¿Cómo correlacionamos el tiempo cronológico con el esfuerzo humano? ¿Qué tareas y qué paralelismo se pueden esperar? ¿Qué puntos de referencia se pueden utilizar para mostrar el progreso? ¿ Hay disponibles métodos de análisis de la planificación temporal y cómo se representa físicamente una agenda?, etc.

EJEMPLO DE UN PROYECTO DE SISTEMA DE INFORMACION 1.- Conocer el problema    

Objetivos estratégicos de la informática Metas Factores críticos de éxito Estrategia de administración de la función informática.

2.- Levantar Requerimientos      

Organizar usuarios (conocer la jerarquía, designar usuarios lideres y expertos) Conocer la organización. Difundir el proyecto. Revisar documentación. Instruir al usuario de cómo entregar requerimientos (DFD, prototipos). Aplicación de instrumentos (entrevistas, reuniones, cuestionarios).

3.- Diseño Conceptual:      

Especificación de pantallas, diseño interfaz usuaria. Especificación de base de datos. Especificación de informes. Modificación de procedimientos administrativos. Requerimientos de auditoría. Especificación de comunicaciones.

4.- Diseño detallado:     

Diseño de todas las interfaces usuarias. Modelamiento del modelo de datos. Base de datos normalizado. Diseño de informes. Diseño de comunicaciones.

5.- Construcción:   

Modelo de datos de producción. Construcción de interfaces entre sistemas. Construcción de aplicaciones.

6.- Prueba: 

Alfa Test: Prueba de las aplicaciones individuales.



Beta Test: Pruebas de las aplicaciones integradas.

7.- Puesta en Marcha:   

Capacitación y difusión. Instalación de software. Marcha blanca.

OTRO EJEMPLO DE FASES Y ACTIVIDADES DE UN PROYECTO DE SOFTWARE...