Planear un proyectos de Software. ¡Volví más académico que nunca!

academico

Este es un post especial, ya que la mayoría salieron a vacaciones de diciembre, aproveché para hacer (Copy & Paste) un post especial “Académico”.

En “Ingeniería de Software I“, se ve temas de cómo crear un proyecto de software y las distintas opciones para elegir el mejor método para desarrollarlo. Así que hoy veremos un artículo tomado de internet el cual me pareció genial y resume todos los pasos para la planeación de un nuevo proyecto. se los organicé con títulos y  toda la vaina para que puedan identificarlo bien.

Ahhh y por si acaso, lo tomé de: http://www.wikilearning.com/articulo/planificacion_de_proyectos-planeacion_y_estimacion_de_proyectos_informaticos/9597-1

1. Qué es un proyecto de Software.

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

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

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

2. Planeación del Proyecto.

La planeación efectiva de un proyectode software depende de la planeación detallada de su avance,anticipando problemas que puedan surgir y preparando con anticipaciónsoluciones tentativas a ellos. Se supondrá que el administrador delproyecto es responsable de la Planeación desde la definición derequisitos hasta la entrega del sistema terminado.

Los puntos analizados posteriormentegeneralmente son requeridos por grandes sistemas de

programación, sin embargo estos puntosson validos también para sistemas pequeños.

  • Panorama. Hace una descripcióngeneral del proyecto detalle de la organización del plan y resumeel resto del documento.
  • Plan de fases. Se analiza el ciclode desarrollo del proyecto como es: análisis de requisitos, fase dediseño de alto nivel, fase de diseño de bajo nivel, etc. Asociadacon cada fase debe de haber una fecha que especifique cuando se debeterminar estas fases y una indicación de como se pueden solapar lasdistintas fases del proyecto.
  • Plan de organización. Se definenlas responsabilidades especificas de los grupos que intervienen enel proyecto.
  • Plan de pruebas. Se hace un esbozogeneral de las pruebas y de las herramientas, procedimientos yresponsabilidades para realizar las pruebas del sistema.
  • Plan de control de modificaciones.Se establece un mecanismo para aplicar las modificaciones que serequieran a medida que se desarrolle el sistema.
  • Plan de documentación. Su funciónes definir y controlar la documentación asociada con el proyecto.
  • Plan de capacitación. Se describela preparación de los programadores que participan en el proyecto ylas instrucciones a los usuarios para la utilización del sistemaque se les entregue.
  • Plan de revisión e informes. Seanaliza como se informa del estado del proyecto y se definen lasrevisiones formales asociadas con el avance de proyecto.
  • Plan de instalación y operación.Se describe el procedimiento para instalar el sistema en lalocalidad del usuario.
  • Plan de recursos y entregas. Seresume los detalles críticos del proyecto como fechas programadas,marcas de logros y todos los artículos que deben entrar bajocontrato.
  • Índice. Se muestra en dondeencontrar las cosas dentro del plan.
  • Plan de mantenimiento. Seestablece un bosquejo de los posibles tipos de mantenimiento que setienen que dar para futuras versiones del sistema.

3. Objetivos de la Planificación del Proyecto.

El objetivo de la Planificación delproyecto de Software es proporcionar un marco de trabajo que permitaal gestor de planificación hacer estimaciones razonables derecursos, costos y planificación temporal.

Estas estimaciones se hacen dentro deun marco de tiempo limitado al comienzo de un proyecto de software, ydeberían actualizarse regularmente a medida que progresa elproyecto. Además las estimaciones deberían definir los escenariosdel mejor caso, y peor caso, de modo que los resultados del proyectopueden limitarse.

El Objetivo de la planificación selogra mediante un proceso de descubrimiento de la información quelleve a estimaciones razonables.

4. Actividades asociadas al proyecto de software.

4.1 Ámbito del Software.

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

En esta etapa se deben evaluar lafunción y el rendimiento que le asignaron al Software durante laIngeniería del Sistema de Computadora para establecer un ámbito deproyecto que no sea ambiguo, e incomprensible para directivos ytécnicos

Describe la función, el rendimiento,las restricciones, las interfaces y la fiabilidad, se evalúan lasfunciones del ámbito y en algunos casos se refinan para dar masdetalles antes del comienzo de la estimación. Las restricciones derendimiento abarcan los requisitos de tiempo de respuesta yprocesamiento, identifican los límites del software originados porel hardware externo, por la memoria disponible y por otros sistemasexistentes.

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

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

4.2 Recursos.

La Segunda tarea de la planificacióndel desarrollo de Software es la estimación de los recursosrequeridos para acometer el esfuerzo de desarrollo de Software, estosimula a una pirámide donde las Herramientas (hardware y Software),son la base proporcional de soporte al esfuerzo de desarrollo, ensegundo nivel de la pirámide se encuentran los Componentesreutilizables.

Y en la parte mas alta de la pirámidese encuentra el recurso primario, las personas (el recurso humano).

  • Recursos Humanos
  • Componentes Reutilizables
  • Herramientas de Software yHardware

Cada recurso queda especificadomediante cuatro características:

Descripción del Recurso.

  • Informes de disponibilidad.
  • Fecha cronológica en la que serequiere el recurso.
  • Tiempo durante el que seráaplicado el recurso.

4.3 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óndentro de la organización y la especialidad que desempeñara cadaprofesional.

4.4 Recursos o componentes de softwarere utilizables.

Cualquier estudio sobre recursos desoftware estaría incompleto sin estudiar la reutilización, esto esla creación y la reutilización de bloques de construcción deSoftware.

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

El Autor Bennatan sugiere cuatrocategorías de recursos de software que se deberían tener en cuentaa medida que se avanza con la planificación:

Componentes ya desarrollados.

  • Componentes ya experimentados.
  • Componentes con experienciaParcial.
  • Componentes nuevos.

4.5 Recursos de entorno.

El entorno es donde se apoya elproyecto de Software, llamado a menudo entorno de Ingeniería deSoftware, incorpora Hardware y Software.

El Hardware proporciona una plataformacon las herramientas (Software) requeridas para producir losproductos que son el resultado de la buena practica de la Ingenieríadel Software, un planificador de proyectos debe determinar la ventanatemporal requerida para el Hardware y el Software, y verificar queestos recursos estén disponibles. Muchas veces el desarrollo de laspruebas de validación de un proyecto de software para la composiciónautomatizada puede necesitar un compositor de fotografías en algúnpunto durante el desarrollo. Cada elemento de hardware debe serespecificado por el planificador del Proyecto de Software.

5. Estimación del proyecto de Software.

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

Es una pequeña planeación sobre quees lo que va a ser mi proyecto. Una de las actividades cruciales delproceso de gestión del proyecto del software es la planificación.Cuando se planifica un proyecto de software se tiene que obtenerestimaciones de esfuerzo humano requerido, de la duracióncronológica del esfuerzo humano requerido, de la duracióncronológica del proyecto y del costo. Pero en muchos de los casoslas estimaciones se hacen valiéndose de la experiencia pasada comoúnica guía. Si un proyecto es bastante similar en tamaño yfunciona un proyecto es bastante similar en tamaño y funciona unproyecto pasado es probable que el nuevo proyecto requieraaproximadamente la misma cantidad de esfuerzo, que dureaproximadamente lo mismo que el trabajo anterior. Pero que pasa si elproyecto es totalmente distinto entonces puede que las experienciasobtenida no sean suficientes.

Se han desarrollado varias técnicas deestimación para el desarrollo de software, aunque cada una tiene suspuntos fuertes y sus puntos débiles, todas tienen en común lossiguientes atributos.

  1. Se han de establecer de antemanoel ámbito del proyecto.
  2. Como bases para la realización deestimaciones se usan métricas del software de proyectos pasados.
  3. El proyecto se desglosa en partesmás pequeñas que se estiman individualmente.

Algunas de estas técnicas son:

Modelado del algoritmo de costos

Se desarrolla un modelo utilizandoinformación histórica de costos que relaciona alguna métrica desoftware (por lo general, su tamaño) con el costo del proyecto. Sehace una estimación de esa métrica y el modelo predice el esfuerzorequerido.

http://www.monografias.com/trabajos15/algoritmos/algoritmos.shtml

Opinión de expertos

Se consultan varios expertos en lastécnicas de desarrollo de software propuestas y en el dominio deaplicación. Cada uno de ellos estima el costo del proyecto. Estasestimaciones se comparan y discuten. El proceso de estimación seitera hasta que se acuerda una estimación.

Estimación por analogía

Esta técnica es aplicable cuando otrosproyectos en el mismo dominio de aplicación se han completado. Seestima el costo de un nuevo proyecto por analogía con estosproyectos completados. Myers (1989) da una descripción muy clara deeste enfoque.

Ley de Parkinson

La Ley de Parkinson establece que eltrabajo se extiende para llenar el tiempo disponible. El costo sedetermina por los recursos disponibles más que por los objetivoslogrados. Si el software se tiene que entregar en 12 meses y sedispone de cinco personas, el esfuerzo requerido se estima en 60personas-mes.

http://www.monografias.com/trabajos4/leyes/leyes.shtml

Asignar costos para ganar

El costo del software se estimadependiendo de lo que el cliente esté dispuesto a pagar por elproyecto. El esfuerzo estimado depende del presupuesto del cliente yno de la funcionalidad del software.

Cada técnica de estimación tiene suspropias fortalezas y debilidades. Para proyectos grandes, se debenutilizar varias técnicas de estimación de costos y comparar susresultados. Si éstos predicen costos radicalmente diferentes, estoindica que no se tiene suficiente información para generar loscostos. Se debe buscar más informaciones y repetir el proceso hastaque la estimación converja.

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

Para realizar estimaciones seguras decostos y esfuerzos tienen varias opciones posibles:

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

  • Base las estimaciones en proyectossimilares ya terminados.
  • Utilice técnicas dedescomposición relativamente sencillas para generar lasestimaciones de costos y esfuerzo del proyecto.
  • Desarrolle un modelo empíricopara é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 funcionarrazonablemente bien si el proyecto actual es bastante similar a losesfuerzos pasados y si otras influencias del proyecto son similares.Las opciones restantes son métodos viables para la estimación delproyecto de software. Desde el punto de vista ideal, se deben aplicarconjuntamente las técnicas indicadas usando cada una de ellas comocomprobación de las otras.

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

5.1 Estimación basada en el Proceso.

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

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

6. Diferentes modelos de estimación.

Existen diferentes modelos deestimación como son:

6.1 Los Modelos Empíricos:

Donde los datos que soportan la mayoríade los modelos de estimación obtienen una muestra limitada deproyectos. Por esta razón, el modelo de estimación no es adecuadopara todas las clases de software y en todos los entornos dedesarrollo. Por lo tanto los resultados obtenidos de dichos modelosse deben utilizar con prudencia.

6.2 El Modelo COCOMO.

Barry Boehm, en su libro clásico sobreeconomía de la Ingeniería del Software, introduce una jerarquía demodelos de estimación de Software con el nombre de COCOMO, por sunombre en Ingles (Constructive, Cost, Model) modelo constructivo decostos. La jerarquía de modelos de Boehm esta constituida por lossiguientes:

  • Modelo I. El Modelo COCOMO básicocalcula el esfuerzo y el costo del desarrollo de Software en funcióndel tamaño del programa, expresado en las líneas estimadas.
  • Modelo II. El Modelo COCOMOintermedio calcula el esfuerzo del desarrollo de software en funcióndel tamaño del programa y de un conjunto de conductores de costosque incluyen la evaluación subjetiva del producto, del hardware,del personal y de los atributos del proyecto.
  • Modelo III. El modelo COCOMOavanzado incorpora todas las características de la versiónintermedia y lleva a cabo una evaluación del impacto de losconductores de costos en cada caso (análisis, diseño, etc.) delproceso de ingeniería de Software.

6.3 Herramientas Automáticas De Estimación.

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

A partir de estos datos, el modeloimplementado por la herramienta automática de estimaciónproporciona estimaciones del esfuerzo requerido para llevar a cabo elproyecto, los costos, la carga de personal, la duración, y enalgunos casos la planificación temporal de desarrollo y riesgosasociados.

En resumen el planificador del Proyectode Software tiene que estimar tres cosas antes de que comience elproyecto: cuanto durará, cuanto esfuerzo requerirá y cuanta genteestará implicada. Además el planificador debe predecir los recursosde hardware y software que va a requerir y el riesgo implicado.

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

7. Errores

  1. Errores clásicos en un proyectode software
  2. Mal análisis en losrequerimientos.
  3. Una mala planeación.
  4. No tener una negociación(documento, contrato) con el cliente.
  5. No hacer un análisis costobeneficio.
  6. Desconocer el ambiente de trabajode los usuarios.
  7. Desconocer los usuarios quetrabajan con el sistema.
  8. Mala elección de recursos(hardware, software, humanos).
  9. Herramientas para la planificacióny Gestión de productos Software.

Para poder completar con éxito unproyecto de software, se necesita tener un control riguroso sobre eltiempo, las personas o los imprevistos que puedan surgir, como porejemplo cambios en el software. Para ayudarnos en la planificación ygestión de proyectos, Microsoft nos proporciona dos herramientasbásicas: Microsoft Project y Microsoft Solutions Framework.

Microsoft Solutions Framework (MSF): esuna flexible e interrelacionada serie de conceptos, modelos yprácticas de uso que controlan la planificación, el desarrollo y lagestión de proyectos tecnológicos. MSF se centra en los modelos deproceso y de equipo dejando en un segundo plano las eleccionestecnológicas. Originalmente creado en 1994 para conseguir resolverlos problemas a los que se enfrentaban las empresas en susrespectivos proyectos, se ha convertido posteriormente en un modelopráctico que facilita el éxito de los proyectos tecnológico.

Anuncios
Acerca de

Programador, usuario Linux e hincha de Millonarios de Colombia

Publicado en General
One comment on “Planear un proyectos de Software. ¡Volví más académico que nunca!
  1. Luis Miranda dice:

    Gracias, que buen trabajo

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Sígueme en Twitter
Categorías
Flickr Photos
¡Apareció Linux!

Mirando de lado

Café

Más fotos
A %d blogueros les gusta esto: