DIAGRAMA DE SECUENCIA

DIAGRAMA DE SECUENCIA

En un diagrama de secuencia se indicarán los módulos o clases que forman parte del programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada.

Se realizan diagramas de secuencia para definir acciones que se pueden realizar en la aplicación  en cuestión. Así, en el caso de una aplicación para jugar al ajedrez, se podrían realizar diagramas de secuencia para “jugar una partida” o bien para acciones más específicas como “mover pieza”.

El detalle que se muestre en el diagrama de secuencia debe estar en consonancia con lo que se  intenta mostrar o bien con la fase de desarrollo en la que esté el proyecto, no es lo mismo un diagrama de secuencia que muestre la acción de “mover pieza” a otro que sea “mover caballo”, o bien no es lo mismo un diagrama de secuencia “mover pieza” que verifique ciertos parámetros antes de mover como la viabilidad del movimiento con respecto a una estrategia marcada a una diagrama que no muestre este nivel de detalle por estar en una fase inicial de diseño del sistema.

El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.

Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases o módulos que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métodos van a implementar, qué deben llamar de la clase o módulo del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qué datos y en qué orden los tiene que meter en el programa y vea qué salidas y resultados le va a dar el programa.

El siguiente puede ser un diagrama de secuencia del ejemplo del ajedrez a un nivel de diseño 

muy preliminar

Aquí ya se ha decidido que se van a desarrollar tres librerías/paquetes/módulos, una para la 

interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y 

demás) y otra para el algoritmo de juego del ordenador. En el ejemplo se ha utilizado una clase 

representando cada uno de los paquetes y se ha representado el caso de uso "mover pieza".

En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, 

etc.) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o 

difícil de leer. El diagrama puede acompañarse con un texto en el que se detallen todas estas 

situaciones erróneas y particularidades.

LOS SABIOS Y EL ELEFANTO

Erase una vez seis hombres sabios que vivían en una pequeña aldea. Los seis sabios eran ciegos. Un día alguien llevó un elefante a la aldea. Los seis sabios buscaban la manera de saber como era un elefante, ya que no lo podían ver. ¡Ya sé, palpémoslo! Dijo uno de ellos, ¡Buena idea! dijeron los otros. El primero tocó las orejas del elefante, notaba como se movían de un lado a otro, así que dijo: “un elefante es como un gran abanico”. El segundo tocó las patas del elefante ” es como un árbol”. “Los dos estáis equivocados”,  dijo el tercero, “el elefante es como una soga”, le estaba tocando la cola. Justamente entonces el cuarto, que estaba tocando los colmillos dijo “el elefante es como una lanza”. “No, no” gritó el quinto sabio, “es como un muro alto”, había estado tocando el costado. El sexto sabio, que estaba tocando la trompa dijo “no, estáis todos equivocados, el elefante es como una serpiente”. “No, como una soga”, “no, como un árbol”, “no, como un abanico”…. Siguieron discutiendo durante días y días sin llegar a un acuerdo.

Así nos pasa muchas veces que vemos ” la verdad” desde nuestra percepción limitada e intentamos imponiéndosela a los demás, sin escucharles, sin buscar otras ideas o soluciones, sin pensar que quizás todos tenemos una parte de “la verdad”, pero no toda la verdad

APRENDIENDO A USAR LA HERRAMIENTA

Recientemente he encontrado una curiosa herramienta online para realizar diagramas UML. La herramienta en cuestión se llama yUML y permite crear los diagramas a partir de unos comandos escritos en texto plano. Los diferentes tipos de diagramas que podemos dibujar son diagramas de casos de uso, diagramas de clases y diagramas de actividad.

Esta herramienta es ideal para casos en los que necesitamos realizar de manera rápida unos sencillos diagramas para enviarlos a alguien o guardarlos. Los diagramas generados tienen una apariencia bastante juvenil e informal. Lo bueno de esta herramienta es que al interpretar texto plano nosotros podemos generar y almacenar este texto y crear tantas modificaciones o copias como queramos.

Como punto negativo no podemos decidir la ubicación o lugar de un elemento ya que busca la mejor distribución según el diagrama implementado. Por ello, no es recomendable utilizarlo como herramienta habitual en el caso de querer resultados más profesionales o personalizados.

Casos de uso

Una de las posibilidades que permite es la creación de casos de uso. Es posible indicar cuantos actores, casos de uso y dependencias existen. En el texto plano, los actores se deben indicar entre corchetes [ ] y los casos de uso entre paréntesis ( ).

Para crear una dependencia de uso tan solo hay que poner un guión entre ambos -. Por ejemplo, poner en el texto plano [Cliente] – (Login) significa que un cliente puede hacer login. Existen más operaciones como ^ Derivar, < Extends > Include.

Veamos un sencillo ejemplo con el siguiente texto.

[Administrador]-(Gestionar Usuarios) 

[Usuario]-(Login) 

[Cliente]-(Comprar productos) 

[Cliente]^[Usuario]

[Administrador]^[Usuario]

(Comprar productos)>(Buscar productos)

Diagramas de clases

Un segundo tipo de diagramas que podemos realizar son los diagramas de clases. Estos diagramas solo tienen un tipo de elemento que serían las clases. Estas clases se deben escribir entre corchetes [ ]. Es posible colorear una clase poniendo dentro unas llaves indicando bg:color. Ejemplo:[Clase{bg:green}]. Si se desea elaborar más cada clase y no quedarse únicamente con el nombre, se pueden indicar atributos y métodos.

Aunque hay pocos tipos de elementos, las relaciones entre estas son muy variadas. Estas relaciones son: > asociación simple, -texto> asociación direccional, 1-0..* cardinalidad, <>-1> Agregación, ++-1>composición, ^- herencia, ^-.- implementación y .> uso.

Veamos otro sencillo ejemplo con el siguiente texto.

[Vehiculo]<>-*>[Pasajeros]

[Vehiculo]^-[Coche]

[Vehiculo]^-[Moto]

[Conductor]-.->[Vehiculo]

[< <Desplazable>>]^-.-[Vehiculo]

Diagramas de actividad

Finalmente, el tercer tipo de diagramas que podemos realizar son los de actividad. Estos son un poco más complejos (no mucho) que los anteriores ya que deben ser iguales las etiquetas de inicio o fin de bifurcación para iniciar o acabar en el mismo punto y crear varias secuencias de flujo de actividad.

Todas las líneas deben iniciarse por un inicio de bifurcación utilizando <etiqueta> y un finalizado de bifurcación |etiqueta|. Esto siempre será así excepto que quieras iniciar desde el punto inicial (start) o acabar en el final (end). Para enlazar una actividad a otra utilizar el símbolo ->.

Veamos un último ejemplo:

(start)-><ini1>Validarse->(Mostrar presentación)->|fin1|->(end)

<ini1>No validarse->(Mostrar login)->|fin1|

Conclusión

En ocasiones es más sencillo “dibujar” o generar automáticamente un diagrama creando en texto plano los comandos. Por ello esta herramienta es bastante socorrida para un caso excepcional en el que se necesita realizar un diagrama y no se desea instalar una herramienta para ello. Tan solo escribes en un texto plano las relaciones y generas el diagrama sencillamente y en un momento.

Programa online | yUML

PROFUNDIZACIÓN SOBRE LOS CASOS DE USOS

http://www.codecompiling.net/files/slides/UML_clase_02_UML_casos_de_uso.pdf

Diagrama de Casos de Uso 

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

Actores

Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.

Casos de Uso

Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.

Relaciones entre Casos de Uso

Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura 16 se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

Extiende():Cuando un caso de uso base tiene ciertos puntos (puntos de extensión) en los cuales, dependiendo de ciertos criterios, se va a realizar una interacción adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relación incluye que se da siempre que se realiza la interacción descrita) En la Figura 17 se muestra como el caso de uso Comprar Producto permite explicitamente extensiones en el siguiente punto de extensión: info regalo. La interacción correspondiente a establecer los detalles sobre un producto que se envía como regalo están descritos en el caso de uso Detalles Regalo.

Ambos tipos de relación se representan como una dependencia etiquetada con el estereotipo correspondiente ( o ), de tal forma que la flecha indique el sentido en el que debe leerse la etiqueta. Junto a la etiqueta se puede detallar el/los puntos de extensión del caso de uso base en los que se aplica la extensión. • Generalización ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso más específico. Se representa por una línea continua entre los dos casos de uso, con el triángulo que simboliza generalización en UML (usado también para denotar la herencia entre clases) pegado al extremo del caso de uso más general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y características del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no está definido completamente. Este tipo de relación se utiliza mucho menos que las dos anteriores.

Diagramas de Interacción

En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.

Diagrama de Secuencia

Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren

Diagrama de Colaboración

Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.

En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que “circulan”, y con el nombre del mensaje y los parámetros (si los tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por ejemplo 3 [condición_de_test] : nombre_de_método() ), tal y como aparece en el ejemplo de la Figura 19. También se puede mostrar el anidamiento de mensajes con números de secuencia como 2.1, que significa que el mensaje con número de secuencia 2 no acaba de ejecutarse hasta que no se han ejecutado todos los 2. x .

Diagramas de Estado

Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera.

En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transición se representa como una flecha desde el estado origen al estado destino.

La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas. Una acción de entrada aparece en la forma entrada/acción_asociada donde acción_asociada es el nombre de la acción que se realiza al entrar en ese estado. Cada vez que se entra al estado por medio de una transición la acción de entrada se ejecuta. Una acción de salida aparece en la forma salida/acción_asociada. Cada vez que se sale del estado por una transición de salida la acción de salida se ejecuta. Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transición a otro estado. Se indica en la forma nombre_de_evento/acción_asociada.

QUE SON LOS REQUERIMIENTOS DEL SISTEMA

Requerimientos de procesos

Requerimientos de procesos son la especificación de los estándares de calidad que se deben utilizar en el proceso, una especificación que el diseño debe producir con una herramienta CASE particular y una descripción del proceso a seguir.

Requerimientos funcionales

Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas también pueden declarar explícitamente lo que el sistema no debe hacer. Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organización al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etcétera. Los requerimientos funcionales para un sistema software se pueden expresar de diferentes formas. A continuación se presentan algunos ejemplos de estos requerimientos funcionales para un sistema de biblioteca universitaria, denominada LIBSYS, utilizada por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas.1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos.3. A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. Estos requerimientos funcionales del usuario definen los recursos específicos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales (contraste los requerimientos l y 3). El sistema LIBSYS es una interfaz única para diferentes bases de datos de artículos. Esto permite a los usuarios descargar copias de artículos publicados en revistas. Periódicos y publicaciones científicas. Una descripción más detallada de los requerimientos para el sistema en el cual se basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre ingeniería de requerimientos (Kontonya y Sommerville, 1998). La impresión en la especificación de requerimientos es la causa de muchos de los problemas de la ingeniería del software. Para un desarrollador de sistema es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo a menudo no es lo que el cliente desea. Se deben establecer nuevos requerimientos y hacer cambios en el sistema. Por supuesto. Esto retrasa la entrega de éste e incrementa los costes. En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. La consistencia significa que los requerimientos no deben tener definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es prácticamente imposible alcanzar los requerimientos de consistencia y completitud. Una razón de esto es que es fácil cometer errores y omisiones cuando se redactan especificaciones para sistemas grandes y complejos. Otra razón es que los stakeholders del sistema (véase el Capítulo 7) tienen necesidades diferentes, ya menudo contradictorias. Estas contradicciones pueden no ser obvias cuando los requerimientos se especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la especificación. Es posible que los problemas surjan solamente después de un análisis más profundo.

Requerimientos no funcionales 

Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a características o servicios individuales del sistema. Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones específicas que proporciona el sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema. Los requerimientos no funcionales rara vez se asocian con características particulares del sistema. Más bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Como se explicó en el Capítulo 2. Por lo tanto, pueden especificar el rendimiento del sistema, la protección, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son más críticos que los requerimientos funcionales particulares. Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una función del sistema que realmente no cumple sus necesidades. Sin embargo. El incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, lafunciones de control no funcionarán correctamente.  requerimientos de interoperabilidad que definen la manera en queel sistema interactúa con sistemas de otras organizaciones; losrequerimientos legislativos que deben seguirse para asegurar queel sistema funcione dentro de la ley. y los requerimientos éticos.Estos últimos son puestos en un sistema para asegurar que seráaceptado por sus usuarios y por el público en general.

PLANIFICANDO UN PROYECTO

Que 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 de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptar 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.

2. Planeación del Proyecto

La planeación efectiva de un proyecto de software depende de la planeación detallada de su

avance, anticipando problemas que puedan surgir y preparando con anticipación soluciones

tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la

Planeación desde la definición de requisitos hasta la entrega del sistema terminado.

Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de

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

~- Panorama. Hace una descripción general del proyecto detalle de la organización del plan y

resume el resto del documento.

~- Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos, fase

de diseño de alto nivel, fase de diseño de bajo nivel, etc. Asociada con cada fase debe de haber

una fecha que especifique cuando se debe terminar estas fases y una indicación de como se

pueden solapar las distintas fases del proyecto.

~- Plan de organización//. //Se definen las responsabilidades especificas de los grupos que

intervienen en el proyecto.

~- Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas,

procedimientos y responsabilidades para realizar las pruebas del sistema.

~- Plan de control de modificaciones. Se establece un mecanismo para aplicar las

modificaciones que se requieran a medida que se desarrolle el sistema.

~- Plan de documentación. Su función es definir y controlar la documentación asociada con el

proyecto.

~- Plan de capacitación. Se describe la preparación de los programadores que participan en el

proyecto y las instrucciones a los usuarios para la utilización del sistema que se les entregue.

~- Plan de revisión e informes. Se analiza como se informa del estado del proyecto y se definen

las revisiones formales asociadas con el avance de proyecto.

~- Plan de instalación y operación//. //Se describe el procedimiento para instalar el sistema en la

localidad del usuario.

~- Plan de recursos y entregas//. //Se resume los detalles críticos del proyecto como fechas

programadas, marcas de logros y todos los artículos que deben entrar bajo contrato.

~ Indice. Se muestra en donde encontrar las cosas dentro del plan.

// //

~- //Plan de mantenimiento. //Se establece un bosquejo de los posibles tipos de mantenimiento que

se tienen que dar para futuras versiones del sistema.

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 de planificación 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 a 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.

4. Actividades asociadas al proyecto de software.

4.1 Á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 le 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 límites 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.//

4.2 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 proporcional de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables.

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

|| Recursos Humanos ||

|| Componentes Reutilizables ||

|| Herramientas de Software y Hardware ||

Fig. 1.1

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.//

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ón dentro de la organización y la especialidad que desempeñara cada profesional.

4.4 Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilizacion, esto es la creación y la reutilizacion 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.//

4.5 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.

5. Estimación 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.

Es una pequeña planeación sobre que es lo que va a ser mi proyecto. Una de las actividades

cruciales del proceso de gestión del proyecto del software es la planificación. Cuando se planifica

un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido, de la

duración cronológica del esfuerzo humano requerido, de la duración cronológica del proyecto y

del costo. Pero en muchos de los casos las estimaciones se hacen valiéndose de la experiencia

pasada como única guía. Si un proyecto es bastante similar en tamaño y funciona un proyecto es

bastante similar en tamaño y funciona un proyecto pasado es probable que el nuevo proyecto

requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior. Pero que pasa si el proyecto es totalmente distinto entonces puede que las experiencias obtenida no sean suficientes.

Se han desarrollado varias técnicas de estimación para el desarrollo de software, aunque cada

una tiene sus puntos fuertes y sus puntos débiles, todas tienen en común los siguientes

atributos.

1. Se han de establecer de antemano el ámbito del proyecto.

2. Como bases para la realización de estimaciones se usan métricas del software de

proyectos pasados.

3. El proyecto se desglosa en partes más pequeñas que se estiman individualmente.

Algunas de estas técnicas son:

|| Técnica || Descripción ||

|| Modelado del http://www.monografias.com/trabajos15/algoritmos/algoritmos.shtml algoritmo de costos || Se desarrolla un modelo utilizando información histórica de costos que relaciona alguna métrica de software (por lo general, su tamaño) con el costo del proyecto. Se hace una estimación de esa métrica y el modelo predice el esfuerzo requerido. ||

|| Opinión de expertos || Se consultan varios expertos en las técnicas de desarrollo de software propuestas y en el dominio de aplicación. Cada uno de ellos estima el costo del proyecto. Estas estimaciones se comparan y discuten. El proceso de estimación se itera hasta que se acuerda una estimación. ||

|| Estimación por analogía || Esta técnica es aplicable cuando otros proyectos en el mismo dominio de aplicación se han completado. Se estima el costo de un nuevo proyecto por analogía con estos proyectos completados. Myers (1989) da una descripción muy clara de este enfoque. ||

|| Ley de Parkinson || La http://www.monografias.com/trabajos4/leyes/leyes.shtml Ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles más que por los objetivos logrados. Si el software se tiene que entregar en 12 meses y se dispone de cinco personas, el esfuerzo requerido se estima en 60 personas-mes. ||

|| Asignar costos para ganar || El costo del software se estima dependiendo de lo que el cliente esté dispuesto a pagar por el proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software. ||

Cada técnica de estimación tiene sus propias fortalezas y debilidades. Para proyectos grandes, se deben utilizar varias técnicas de estimación de costos y comparar sus resultados. Si éstos predicen costos radicalmente diferentes, esto indica que no se tiene suficiente información para generar los costos. Se debe buscar más informaciones y repetir el proceso hasta que la estimación converja.

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.

5.1 Estimación basada en el http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE Proceso.

Es la técnica más común para estimar un proyecto es basar la estimación en el http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE proceso que se va a utilizar, es decir, el http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE 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 http://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtml#PLANT problemas, la estimación basada en el proceso comienza en una delineación de las http://www.monografias.com/trabajos7/mafu/mafu.shtml funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las http://www.monografias.com/trabajos7/mafu/mafu.shtml 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.

6. Diferentes modelos de estimación.

Existen diferentes modelos de estimación como son:

6.1 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.

6.2 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 Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm esta 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.//

·

6.3 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, 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 durará, 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.

7. Errores

ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE

1. Mal análisis en los requerimientos.

2. Una mala planeación.

3. No tener una negociación (documento, contrato) con el cliente.

4. No hacer un análisis costo beneficio.

5. Desconocer el ambiente de trabajo de los usuarios.

6. Desconocer los usuarios que trabajan con el sistema.

7. Mala elección de recursos (hardware, software, humanos).

8. Herramientas para la planificación y Gestión de productos Software.

Para poder completar con éxito un proyecto de software, se necesita tener un control riguroso sobre el tiempo, las personas o los imprevistos que puedan surgir, como por ejemplo cambios en el software. Para ayudarnos en la planificación y gestión de proyectos, Microsoft nos proporciona dos herramientas básicas: Microsoft Project y Microsoft Solutions Framework.

· Microsoft Solutions Framework (MSF): es una flexible e interrelacionada serie de conceptos, modelos y prácticas de uso que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas. Originalmente creado en 1994 para conseguir resolver los problemas a los que se enfrentaban las empresas en sus respectivos proyectos, se ha convertido posteriormente en un modelo práctico que facilita el éxito de los proyectos tecnológico.