REQUERIMIENTOS DE LA INGENIERIA

La ingenieria de requerimiento se trata de entender los requerimientos de una solucion basada de software es una de las tareas mas dificiles para un ingeniero de software, la ing de requerimiento provee de un mecanismo apropiado para entender que quiere el consumidor, analizar sus necesidades, valorar la factibilidad de construccion, negociar una solucion razonable,especificar de manera no ambigua una solucion y validar la especificacion y administrar los requerimientos conforme se transforman.

La ingenieria de requerimientos se clasifica en:

Requerimientos funcionales: que es todo lo que denota accion

ejemplo: imprimir una factura, guadar etc.

Requerimientos no funcionales: es persivir el momento en que se esta levantando la informacion, que ayude al mejoramiento de mi software.


La ingenieria de requerimiento tiene varias tareas que son:

Iniciacion: se trata es de como se empieza un proyecto, puede ser por conversaciones informales o puede ser de manera mas formal;

normalmente como resultado de una necesidad importante. Esto se hace a traves de preguntas lbres de contexto para establecer un entendimiento basico del problema.

Obtencion de requerimientos: Se refiere a definir normalmente los requerimientos de la solucion 

debido a que hay problemas de definicion de alcances, problemas de entendimiento entre los involucrados o problemas  de volatilidad.

Elaboracion: se enfoca en realizar modelos tecnicos refinado de las funciones del software, caracteristicas y lñimites.

es basicamente una funcion de modelado. Se conduce a trves de la definicion de escenarios del usuario que describe la interaccion del usuario final con el sistema.

Negociacion: Esto seda debido a que los usuarios piden normalmente mas de lo que se puede hacercon los recursos que se cuentan, casi siempre diferentes involucrados piden cosas diferentes por lo que hay que conciliar intereses a trves de negociacion.

Especificacion: Describe la funcion y desempeño deun sistema y la restriccion que tiene.

Hay muchas tecnicas para escribir especificaciones: como diagramas, naraciones en prosa, modelos matematicos, dibujos etc.

Validacion: El producto generado por la ingenieria de requerimientos debe ser evaluado en termino de congruencia y calidad, esto se hace a traves de revisiones tecnicas formales.

Administracion de requerimientos: Son las actividades que ayudan al equipo de trabajo a identificar,controlar,seguir los requerimientos y cambios que ocurren en ellos a traves de todo el proseso de desrrollo.

Caracteristicas de un buen ing de requerimientos:

1.Habilidad para captar conceptos abstractos sintetizandolos y reorganizandolos en divisiones logicas

2.Habilidad para obtener hechos importantes de situaciones confusas

3.Habilidad para entender el medio ambiente

4.Habilidad para comunicarse bien en forma verbal y escrita

5.Habilidad para ver el bosque a traves de las hojas


Herramientas para obtener las nececidades del cliente:

1.Cuestionarios

2.Entrevistas

3Estudio de campo

4.Autoaprendizaje

Cuestionario: Los cuestionarios son utiles especialmente cuando hay una cantidad de usuarios finales

Entrevista: la entrevista se realiza para recolectar informacion de forma verbal, a traves de preguntas que propone el analista.
La entrevista puede ser de forma abierta o de forma cerrada, tambien puede ser estructurada y no 
estucturada.

acontinuacion un mapa conceptual:


Casos de uso: Es un mecanismo ampliamente utilizado para descubrir y registrar requerimientos en especial los funcionales, tambien es el mecanismo el cual ayuda a que los involucrados entiendan de una forma mas simple y sencilla las necesidades que se presenten.

Los casos de uso se componen por:

Un actor: El cual es algo con comportamiento, como una persona con un rol determinado, o un sistema informatizado u organizacion por ej: un cajero o un banco

los actores se clasifican en:

Actor principal: Tiene objetivo de usuario que se satiface mediante el uso de los servicios

Actor de apoyo: Proporciona un servicio por ej: informacion

Actor pasivo: Esta interesado en el comportamiento del caso de uso, pero no es principal ni de apóyo

ej: la agencia tributaria del gobierno esta se asegura que todos los intereses sean identificados y sastifechos.

Un escenario: Es una secuencia especifica de acciones e interacciones entre los actores y el sistema objeto de estudio

Un caso de uso: Es una coleccion de escenario con exito y fallos relacionados que describen a los actores utilizando un sistema para sastifacer un objetivo

Tipos de relaciones 

comunica: Relación (asociación) entre un actor y un caso de uso que denota la participación del actor en dicho caso de uso. 

usa: ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro. 

extiende: (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura

Ej:

 

ESTIMACION DE COSTO Y PLAZO

La estimación de costo de un proyecto consiste en estimar los costos de los recursos necesarios (humanos y materiales) para completar las actividades del proyecto. En la aproximación de costos la persona que estima considera las posibles variaciones del estimado final con propósito de mejorar la administración del presupuesto del proyecto.

Cuando un proyecto se realiza bajo contrato se debe tener cuidado en distinguir el costo estimado del precio:

1. Costo estimado: ¿cuánto le costará a la organización que realiza el proyecto proveer el producto o servicio?. El costo estimado es un cálculo económico.

2. Precio: ¿cuánto recargará la organización que realiza el proyecto por el producto o servicio? El precio es una decisión de negocios.

La estimación de costos incluye la identificación y consideración de varias alternativas de costo, y esto es una decisión gerencial. Por ejemplo realizar trabajo adicional durante la fase de diseño debido a que esto tiene el potencial de reducir el costo en la fase de ejecución.

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)

Desarrollar un modelo empírico para el coste y el esfuerzo de software.

Adquirir una o más herramientas automáticas de estimación.

Desdichadamente la primera opción, aunque atractiva no es practica, porque las estimaciones del coste deben ser proporcionadas de antemano. Las tres opciones restantes son aproximaciones viables para la estimación del proyecto de software. Las técnicas de descomposición utilizan una aproximación de "divide y vencerás " para la estimación del proyecto de software. Los modelos de estimación empíricos pueden utilizarse para completar las técnicas de descomposición y ofrecer una aproximación de la estimación potencialmente evaluable por ella misma. Las herramientas automáticas de estimación implementan una o mas técnicas de descomposición o modelos empíricos.

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 un modelo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software .

COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).

El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.

El modelo básico:

se extiende para considerar un conjunto de atributos de guías de costo que pueden agruparse en cuatro categorías principales:

Producto ( por ej. Requerimientos de software, confiabilidad, tamaño de la base de datos, y complejidad del producto).

Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).

Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en lenguajes de programación y capacidad del programador)

Proyecto :Uso de practicas modernas de programación, uso de herramientas de software y requerimiento de un plan de desarrollo).

En cada nivel de aplicación están definidos para tres tipos de proyectos de software: 

Modo orgánico:proyectos de software relativamente pequeños y sencillos en los que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto de requerimiento poco rígidos.

Modo semi-acoplado:un proyecto de software intermedio en tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer requerimientos poco y medio rígidos

Modo acoplado: un proyecto de software que debe ser desarrollado dentro un conjunto estricto de hardware, software y de restricciones operativas.

Modos que están basados en la complejidad de la aplicación y el desarrollo del ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicación y modos está dado por:

 

Donde:

E = es el esfuerzo estimado expresado en hombres-mes

EDSI es el número estimado de líneas de código distribuidas en miles para el proyecto

a, h son constantes determinadas por el modo del desarrollo, ambos incrementados por la complejidad de la aplicación.

EAF es el factor de ajuste de esfuerzo, es igual a 1 para la modelo básica e igual al producto de 15 factores de costo para la modelo intermedia y avanzada. Cada factor de costo multiplicativo es reflexivo de un incremento proporcional (> 1) o decremento (<1) en costo.

CSHARP

C SHARP es un lenguaje de programacion orientado a abjetos desarrollados y estandarizados por microsoft como parte de su plataforma.

tenemos los tipos de datos de C# los cuales son los siguientes:

INT {short,long, unsigeed
INT 32
INT 64

Conversiones de tipo de datos
	byte	sbyte	short	ushort	int	uint	long	ulong	float	double	decimal	char	bool
byte		E	A	A	A	A	A	A	E	E	E	E	I
sbyte	E		A	E	A	E	A	A	E	E	E	E	I
short	E	E		E	A	A	A	A	E	E	E	E	I
ushort	E	E	E		A	A	A	A	E	E	E	E	I
int	E	E	E	E		E	A	A	E	E	E	E	I
uint	E	E	E	E	E		A	A	E	E	E	E	I
long	E	E	E	E	E	E		E	E	E	E	E	I
ulong	E	E	E	E	E	E	E		E	E	E	E	I
float	E	E	E	E	E	E	E	E		A	E	I	I
double	E	E	E	E	E	E	E	E	E		E	I	I
decimal	E	E	E	E	E	E	E	E	E	E		I	I
char	E	E	E	A	A	A	A	A	A	A	A		I
bool	I	I	I	I	I	I	I	I	I	I	I	I

EJEMPLO:

CHAR C;

INT ALFA, BETA, GAMMA;

ALFA=80;

BETA=40;

GAMMA=ALFA*BETA;

CONSOLE.WRITELINE("LA OPERACION"+ALFA+"*"+BETA+"="GAMMA);

CONSOLE.WRITE("PULSE ENTER");

c=(char)console.read();

DIAGRAMA PERT

Los digramas pert es una representacion grafica dela relacion que existe entre las tareas del proyecto que se encarga de calcular los tiempos del proyecto de una forma mas sencilla.

acontinuacion expondremos algunas caracteristicas para asi comprender de una forma mejor

CARACTERISTICAS

1.es un grafo.osea un conjunto de puntos o nodos, unidos por fecha

2.representa las relacionez entre las tareas del ´royecto, y no su distribucion temporal

3. las flechas del grafo coresponden a las tareas del proyecto

4.es una herramienta de calculo, y una representacion visual de las dependencias entre las tareas del proyecto

El diagrama PERT permite calcular los inicios mínimos y los finales máximos de todas las tareas del proyecto. En cada nodo obtendremos el inicio mínimo de todas las tareas que tengan origen en ese nodo y el final máximo de todas las tareas que lleguen a él. En todas las ilustraciones y ejemplos de este curso situaremos los inicios mínimos en la parte superior del nodo y los finales máximos en la parte inferior.  

EJ: