CASOS DE USO

Un Caso de Uso describe un servicio provisto por un sistema, es decir un modo específico de usarlo.
El conjunto completo de Casos de Uso especifica todas las posibles maneras en las que el sistema puede ser usado, sin revelar cómo esto es implementado por el sistema. Esto hace a los Casos de Uso apropiados para definir requerimientos funcionales en etapas tempranas del desarrollo del sistema, donde la estructura interna de éste aún no fue definida.

Actores :

•Representan roles que humanos, dispositivos dehardware o sistemas externos juegan mientras interactúan con el sistema.

•No son parte del sistema y están situados fuera de suslímites.

•Pueden estar a la entrada o salida de un caso de uso.

Tipos de actores:

Primarios: interaccionan con el sistema para explotar su funcionalidad; trabajan directa y frecuentemente con el software.

Secundarios: soporte del sistema para que los primarios puedan trabajar.

Iniciadores: no utilizan directamente el sistema pero desencadenan el trabajo de otro actor. (No aparecen en UML pero sí los consideran otros autores).

Relaciones entre Casos de Uso 

Las principales relaciones consideradas por UML son:

• Generalización (generalization): es una relación que amplía la funcionalidad de un Caso de Uso o refina su funcionalidad original mediante el agregado de nuevas operaciones y/o atributos y/o secuencias de acciones.

• Inclusión (include): es una relación mediante la cual se re-usa un Caso de Uso encapsulado en distintos contextos a través de su invocación desde otros Casos de Uso.

• Extensión (extend): es una relación que amplía la funcionalidad de un Caso de Uso mediante   la extensión de sus secuencias de acciones.

Ventajas

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema.

Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.

A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento.

 

Limitaciones

Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema.

 

ENTREVISTA

Una entrevista es un dialogo en el que la persona (entrevistador), generalmente un periodista hace una serie de preguntas a otra persona (entrevistado), con el fin de conocer mejor sus ideas, sus sentimientos su forma de actuar. 

El entrevistado:

Deberá ser siempre una persona que interese a la comunidad. El entrevistado es la persona que tiene alguna idea o alguna experiencia importante que transmitir.

El entrevistador :

Es el que dirige la entrevista debe dominar el dialogo, presenta al entrevistado y el tema principal, hace preguntas adecuadas y cierra la entrevista.

La entrevista es también información y reportaje, las entrevistas pueden ser reales o imaginarias.

Las reales presentan a una o más personas reales que responden a una serie de preguntas formuladas por un entrevistador.

Las imaginarias son las que una persona adopta el papel del entrevistado artista, escritor y el otro el de entrevistado puede ser un personaje histórico o literario, y el entrevistador es el mismo o algún otro personaje.

Tipos de entrevistas:

Directiva o cerrada:

Se lleva a cabo siguiendo un esquema predeterminado, con preguntas concretas y definidas con precisión. Sigue un esquema que responde a: pregunta - respuesta.
El objetivo es que el entrevistado/a de respuestas concisas y concretas, sin dar lugar a divagaciones, explicaciones o extenderte. Se suele utilizar cuando se requiere una información objetiva. 

No directiva o abierta: 

Es una entrevista en la que se favorece la comunicación dejando hablar libremente y haciendo sentir al/a la entrevistado/a cómodo/a. El entrevistador/a formula pocas preguntas y se dedica a reconducir los temas de los que se habla.
Es un tipo de entrevista difícil y arriesgada ya que lo que dices no sabes si va a resultar positivo o negativo. Se utiliza cuando interesa información referente al carácter y/o la personalidad.  

Mixta o semidirectiva:

Resulta de la combinación de las dos anteriores. Pueden hacerte muchas preguntas, pero te dan margen para que intervengas en la dirección que desees.
Además de las descritas anteriormente podemos encontrarnos con otros tipos. Cada entrevistador/a tiene un estilo de llevarlas a cabo y nos podemos enfrentar a:  

Entrevista de choque o de tensión:

El entrevistador/a intentará ponerte en situaciones difíciles para poder comprobar cual es tu forma de responder ante momentos de tensión y tu capacidad de aguante en general. En estas hay que tener mucho cuidado con la manera de responder y de actuar, intentaremos no ponernos a la defensiva y no violentarnos, ya que le estaremos dando al entrevistador/a lo que el quiere, pero no lo que necesita para el puesto. 

Entrevista técnica:

El objetivo de esta entrevista es valorar los conocimientos técnicos que posees respecto a tu profesión.  

REQUERIMIENTO

• Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
• Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
• Una condición o capacidad que debe ser conformada por el sistema (RUP).
• Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson). 

Tipos de requerimientos:

Requerimiento funcional :

puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar o en otras palabras los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. 

Requerimiento no funcional: 

tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Características de los requerimientos  :

principales:
Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. 

Conciso:
Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.  

Completo:
Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.  

Consistente:
Un requerimiento es consistente si no es contradictorio con otro requerimiento. 

No ambiguo: 
Un requerimiento no es ambiguo cuando tiene una sola interpretación. 

Verificable: 

Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.  

Anexo Mapa mental:

ESTIMACIÓN DE COSTOS

Todo proyecto de ingeniería de software debe partir con un buen plan, pero lamentablemente, la planificación es una tarea nada trivial. Uno de los aspectos que dificultan la labor de administradores y jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y plazos realista.

La estimación es más arte que ciencia; también es parte de la etapa de la planificación y algunas actividades de la ingeniería. La diferencia en la estimación de costos entre ingeniería de software y otras disciplinas es que en ingeniería de software lo principal para las personas es el costo; y en otras disciplinas el costo de las cosas materiales depende de la actividad.

-MÉTRICAS PARA LA PRODUCTIVIDAD Y CALIDAD DEL SOFTWARE.

La medición es esencial para cualquier disciplina de ingeniería y la ingeniería de software no es una excepción.

Las métricas de software se refieren aun amplio rango de medidas para el software de computadoras dentro del contexto de la planificación del proyecto de software, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación de costos.

-ESTIMACION DEL PROYECTO DE SOFTWARE.

Para realizar estimaciones seguras de coste y esfuerzo surge un numero de posible de opciones como:

Retrasar la estimación mas adelante en el proyecto (obviamente se puede hacer una estimación cien por ciento fiable después de completar el proyecto)

Utilizar "técnicas de descomposición " relativamente simples para generar las estimaciones del proyecto de software (por ej. Estimación LDC y PF)

-MODELOS DE ESTIMACIÓN EMPÍRICA.

Un modelo de estimación para el software por computadora utiliza formulas derivadas empíricamente para predecir los datos.

Los datos empíricos que soportan la mayoría de los modelos se obtienen de una muestra limitada de proyectos. Tomando en cuenta los recursos se tienen los modelos recursos y consisten en una o más ecuaciones obtenidas empíricamente que predicen el esfuerzo (personas-mes), la duración del proyecto (meses cronológicos) o otros datos pertinentes al proyecto. Según Basili describe cuatro modelos de recurso:

modelos simple-variable estáticos (ej. COCOMO), modelos multi-variables estáticos, modelos multi-dinámicos variables y modelos teóricos.

MODELO COCOMO

Es una moderna alternativa para el tradicional modelo cascada de el desarrollo de procesos de software.

El modelo de desarrollo Incremental COCOMO permite una variedad de desarrollo de procesos. En vez de modelar el software como a esfuerzo simple para obtener un producto simple; el modelo incremental COCOMO permite desarrollar una serie de proyectos de software concurrente y producir un producto intermedio.

Esta estrategia reduce risk y permite entregar un producto inicial más fácilmente al cliente.

También existen algunas derivaciones de COCOMO como ser:

• Cocots, (Constructive Cost)
• Cossemo, (Constructive Staged Schedule & Effort Model).
• Copromo, (Constructive Productivity Improvement Model).
• Coqualmo
• Coradmo

MICROSOFT VISUAL STUDIO

 

Este es un entorno que ha sido empaquetado como un programa de aplicación; es decir, consiste en un editor de código (programa donde se escribe el código fuente), un depurador (programa que corrige errores en el código fuente para que pueda ser bien compilado), un compilador (programa que traduce el código fuente a lenguaje de máquina), y un constructor de interfaz gráfica o GUI (es una forma de programar en la que no es necesario escribir el código para la parte gráfica del programa, sino que se puede hacer de forma visual).

Compilador

El compilador de Visual Basic x.0 genera ejecutables que requieren una DLL para que funcionen, en algunos casos llamada MSVBVMxy.DLL (acrónimo de "MicroSoft Visual Basic Virtual Machine x.y", siendo x.y la versión) y en otros VBRUNXXX.

Versiones

Las versiones actuales de Visual Basic se basan en la plataforma .NET, que se desligan de las anteriores versiones.

Cabe mencionar que aunque menos conocido, existió también una versión gratuita de Visual Basic 5.0 dedicada en su práctica al desarrollo de controles y componentes, su nombre en concreto era Microsoft Visual Basic 5.0 Control Creation Edition (Visual Basic 5 CCE). También hubo versiones orientadas al desarrollo de aplicaciones para dispositivos móviles basados en Windows CE y Pocket PC, conocido como Embedded (Visual Basic).

DIAGRAMA PERT-CPM

Un proyecto define una combinación de actividades interrelacionadas que deben ejecutarse en un cierto orden antes que el trabajo completo pueda terminarse. Las actividades están interrelacionadas en una secuencia lógica en el sentido que algunas de ellas no pueden comenzar hasta que otras se hayan terminado. Una actividad en un proyecto, usualmente se ve como un trabajo que requiere tiempo y recursos para su terminación. En general, un proyecto es esfuerzo de un solo periodo; esto es, la misma sucesión de actividades puede no repetirse en el futuro.

Ruta critica.

Una ruta crítica es la secuencia de los elementos terminales de la red de proyectos con la mayor duración entre ellos, determinando el tiempo más corto en el que es posible completar el proyecto. La duración de la ruta crítica determina la duración del proyecto entero. Cualquier retraso en un elemento de la ruta crítica afecta a la fecha de término planeada del proyecto, y se dice que no hay holgura en la ruta crítica.

Un proyecto puede tener varias rutas críticas paralelas. Una ruta paralela adicional a través de la red con las duraciones totales menos cortas que la ruta crítica es llamada una sub-ruta crítica.

Originalmente, el método de la ruta crítica consideró solamente dependencias entre los elementos terminales. 

El método de ruta crítica es un proceso administrativo (planeación, organización, dirección y control) de todas y cada una de las actividades componentes de un proyecto que debe desarrollarse drante un tiempo crítico y al costo óptimo.
La aplicación potencial del método de la ruta crítica, debido a su gran flexibilidad y adaptación, abarca desde los estudios inciales para un proyecto determinado, hasta la planeación y operación de sus instalaciones.

A esto se puede añadir una lista indeterminable de posibles aplicaciones de tipo específico. Así, podemos afirmar que el método de la ruta crítica es aplicable y útil en cualquier situación en la que se tenga que llevar a cabo una serie de actividades relacionadas entre sí para alcanzar un objetivo determinado.

Metodologia.

El método de la ruta crítica consta básicamente de dos ciclos:

1. Planeación y programación
2. Ejecución y Control

El primer ciclo termina hasta que todas las personas directoras o responsables de los diversos procesos que intervienen en el proyecto están plenamente de acuerdo con el desarrollo, tiempos, costos, elementos utilizados, coordinación, etc., tomando como base la red de camino crítico diseñada al efecto.

Holguras

Para poder tomar decisiones efectivas y rápidas durante la ejecución del proyecto es necesario tener a la mano los datos de las probabilidades de retraso o adelanto de trabajo de cada una de las actividades, o sea la elasticidad de las mismas. Examinemos primero el procedimiento para calcular las holguras que nos proporciona la posibilidad de retrasar una actividad sin consecuencias para otros trabajos
Se llama holgura a la libertad que tiene una actividad para alargar su tiempo de ejecución sin perjudicar otras actividades o el proyecto total. Se distinguen tres clases de holguras:

a) Holgura total; no afecta la terminación del proyecto;
b) Holgura libre; no modifica la terminación del proceso; y
c) Holgura independiente; no afecta la terminación de actividades anteriores ni la iniciación de actividades posteriores.