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.