martes, 8 de marzo de 2011

POO

POO:
 La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.
Ejm: dado un plano para construir sillas (una clase de nombre clase_silla), entonces una silla concreta, en la que podemos sentarnos, construida a partir de este plano, sería un objeto de clase_silla. Es posible crear (construir) múltiples objetos (sillas) utilizando la definición de la clase (plano) anterior
Clase:
 Una clase es una construcción que permite crear tipos personalizados propios mediante la agrupación de variables de otros tipos, métodos y eventos. Una clase es como un plano. Define los datos y el comportamiento de un tipo. Si la clase no se declara como estática, el código de cliente puede utilizarla mediante la creación de objetos o instancias que se asignan a una variable. La variable permanece en memoria hasta todas las referencias a ella están fuera del ámbito. En ese momento, CLR la marca como apta para la recolección de elementos no utilizados. Si la clase se declara como estática, solo existe una copia en memoria y el código de cliente solo puede tener acceso a ella a través de la propia clase y no de una variable de instancia. Para obtener más información, vea Clases estáticas y sus miembros (Guía de programación de C#).
Ejm: || ruby> class Perro
ruby| def ladra
ruby| print "guau guau\n"
ruby| end
ruby| end
nil
||

INSTANCIA:
 Una instancia de un programa es una copia de una versión ejecutable del programa que ha sido escrito en la memoria del computador.
Una instancia de un programa es creada típicamente por el click de usuario en un icono de una interfaz Gráfica para usuarios GUI o por la entrada de un comando en una interfaz de línea de comandos CLI y presionando la tecla ENTER. Instancias de programas pueden ser creadas por otros programas
Ejm: Un ejemplo de instancia en un lenguaje de programación visual, sería tomar o arrastrar un objeto de la barra de herramientas o de la lista de librerías y colocarlo en el escritorio o escenario de trabajo (estamos creando una instancia de ese objeto, una copia).
objeto: En el paradigma de programación orientada a objetos (POO, o bien OOP en inglés), un objeto se define como la unidad que en tiempo de ejecución realiza las tareas de un programa. También a un nivel más básico se define como la instancia de una clase.
Estos objetos interactúan unos con otros, en contraposición a la visión tradicional en la cual un programa es una colección de subrutinas (funciones o procedimientos), o simplemente una lista de instrucciones para el computador. Cada objeto es capaz de recibir mensajes, procesar datos y enviar mensajes a otros objetos de manera similar a un servicio.

HERENCIA:
La herencia es específica de la programación orientada a objetos, donde una clase nueva se crea a partir de una clase existente. La herencia (a la que habitualmente se denomina subclases) proviene del hecho de que la subclase (la nueva clase creada) contiene las atributos y métodos de la clase primaria. La principal ventaja de la herencia es la capacidad para definir atributos y métodos nuevos para la subclase, que luego se aplican a los atributos y métodos heredados.
Esta particularidad permite crear una estructura jerárquica de clases cada vez más especializada. La gran ventaja es que uno ya no debe comenzar desde cero cuando desea especializar una clase existente. Como resultado, se pueden adquirir bibliotecas de clases que ofrecen una base que puede especializarse a voluntad (la compañía que vende estas clases tiende a proteger las datos miembro usando la encapsulación).
Ejm: || ruby> class Mamifero
ruby| def respira
ruby| print "inhalar y exhalar\n"
ruby| end
ruby| end
nil
ruby> class Gato<Mamifero
ruby| def maulla
ruby| print "miau \n"
ruby| end
ruby| end
nil
||

POLIMORFISMO (INFORMÁTICA)
La exactitud de la información en este artículo o sección está discutida.
En la página de discusión puedes consultar el debate al respecto.
En programación orientada a objetos el polimorfismo se refiere a la capacidad para que varias clases derivadas de una antecesora utilicen un mismo método de forma diferente.
Por ejemplo, podemos crear dos clases distintas: Pez y Ave que heredan de la superclase Animal. La clase Animal tiene el método abstracto mover que se implementa de forma distinta en cada una de las subclases (peces y aves se mueven de forma distinta).
Como se mencionó anteriormente, el concepto de polimorfismo se puede aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de funciones polimórficas y tipos polimórficos. Las primeras son aquellas funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de forma indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos que contienen al menos un elemento cuyo tipo no está especificado.
CLASIFICACIÓN
Se puede clasificar el polimorfismo en dos grandes clases:
Polimorfismo dinámico (o polimorfismo paramétrico) es aquél en el que el código no incluye ningún tipo de especificación sobre el tipo de datos sobre el que se trabaja. Así, puede ser utilizado a todo tipo de datos compatible.
Polimorfismo estático (o polimorfismo ad hoc) es aquél en el que los tipos a los que se aplica el polimorfismo deben ser explicitados y declarados uno por uno antes de poder ser utilizados.
El polimorfismo dinámico unido a la herencia es lo que en ocasiones se conoce como programación genérica.
También se clasifica en herencia por redefinición de métodos abstractos y por método sobrecargado. El segundo hace referencia al mismo método con diferentes parámetros.
Otra clasificación agrupa los polimorfismo en dos tipos: Ad-Hoc que incluye a su vez sobrecarga de operadores y coerción, Universal (inclusión o controlado por la herencia, paramétrico o genericidad).
EJEMPLO DE POLIMORFISMO
En este ejemplo haremos uso del lenguaje C++ para mostrar el polimorfismo. También se hará uso de las funciones virtuales puras de este lenguaje, aunque para que el polimorfismo funcione no es necesario que las funciones sean virtuales puras, es decir, perfectamente el código de la clase "superior" (en nuestro caso Empleado) podría tener código
#include<iostream>
using namespace std;

class figura {
      public:
             float base;
             float altura;    
     public:
            float captura();
            virtual unsigned float perimetro()=0;
            virtual unsigned float area()=0;
};

class rectangulo: public figura{
      public:
             void imprime();
             unsigned float perimetro(){return 2*(base+altura);}
             unsigned float area(){return base*altura;}
      };

class triangulo: public figura{
      public:
             void muestra();
             unsigned float perimetro(){return 2*altura+base}
             unsigned float area(){return (base*altura)/2;}
      };

void figura::captura(){
      cout<<"CALCULO DEL AREA Y PERIMETRO DE UN TRIANGULO ISÓSCELES Y UN RECTANGULO:" <<endl;
      cout<<"escribe la altura: ";
      cin>>altura;
      cout<<"escribe la base: ";
      cin>>base;
      cout<<"EL PERIMETRO ES:" << perimetro();
      cout<<"EL AREA ES:" << area();
};

ATRIBUTO
En computación, un atributo es una especificación que define una propiedad de un Objeto, elemento o archivo. También puede referirse o establecer el valor específico para una instancia determinada de los mismos.
Sin embargo, actualmente, el término atributo puede y con frecuencia se considera como si fuera una propiedad dependiendo de la tecnología que se use.
Para mayor claridad, los atributos deben ser considerados más correctamente como metadatos. Un atributo es con frecuencia y en general una característica de una propiedad.
Un buen ejemplo es el proceso de asignación de valores XML a las propiedades (elementos). Tenga en cuenta que el valor del elemento se encuentra antes de la etiqueta de cierre (por separado), no en el propio elemento. El mismo elemento puede tener una serie de atributos establecidos (Nombre = "estoesunapropiedad").
Si el elemento en cuestión puede ser considerado una propiedad (Nombre_Cliente) de otra entidad (digamos "cliente"), el elemento puede tener cero o más atributos (propiedades) de su propio (Nombre_Cliente es de Tipo = "tipotexto").
Un atributo de un objeto por lo general consiste de un nombre y un valor; de un elemento, un tipo o nombre de clase; de un archivo, un nombre y extensión.
Cada atributo nombrado tiene asociado un conjunto de reglas denominadas operaciones: uno no agrega caracteres o manipula y procesa una matriz de enteros como una imagen ni procesa texto como tipo de coma flotante (números decimales).
Por tanto, una definición de objeto se puede ampliar mediante la imposición de tipos de datos: un formato de representación, un valor por defecto, y las operaciones legales (normas) y restricciones ("¡División por cero no esta permitida!") Son todos los que podrían participar en la definición un atributo, o por el contrario, se puede decir que son atributos de ese tipo de objeto. Un archivo JPEG no es decodificado por las mismas operaciones (por muy similares que sean, estos son todos formatos de datos de gráficos) como un archivo BMP o PNG, ni es un número de coma flotante operado por las normas aplicadas al los enteros largos.
EJEMPLO
en computación gráfica los objetos de planos pueden tener atributos tales como espesor (con valores reales), color (con valores descriptivos como el marrón o verde o los valores definidos en un cierto modelo de color, como RGB), etc Un objeto círculo se puede definir con atributos similares, como un origen y radio.
Lenguajes de marca, como HTML y XML, utilizan los atributos para describir los datos y el formato de los datos.

MÉTODO (INFORMÁTICA)
En la programación orientada a objetos, un método es una subrutina asociada exclusivamente a una clase (llamados métodos de clase o métodos estáticos) o a un objeto (llamados métodos de instancia). Análogamente a los procedimientos en los lenguajes imperativos, un método consiste generalmente de una serie de sentencias para llevar a cabo una acción, un juego de parámetros de entrada que regularán dicha acción y, posiblemente, un valor de salida (o valor de retorno) de algún tipo.
Algunos lenguajes de programación asumen que un método debe de mantener el invariante del objeto al que está asociado asumiendo también que éste es válido cuando el método es invocado. En lenguajes compilados dinámicamente, los métodos pueden ser objetos de primera clase, y en este caso se puede compilar un método sin asociarse a ninguna clase en particular, y luego asociar el vínculo o contrato entre el objeto y el método en tiempo de ejecución. En cambio en lenguajes no compilados dinámicamente o tipados estáticamente, se acude a precondiciones para regular los parámetros del método y postcondiciones para regular su salida (en caso de tenerla). Si alguna de las precondiciones o postcondiciones es falsa el método genera una excepción. Si el estado del objeto no satisface la invariante de su clase al comenzar o finalizar un método, se considera que el programa tiene un error de programación.
La diferencia entre un procedimiento (generalmente llamado función si devuelve un valor) y un método es que éste último, al estar asociado con un objeto o clase en particular, puede acceder y modificar los datos privados del objeto correspondiente de forma tal que sea consistente con el comportamiento deseado para el mismo. Así, es recomendable entender a un método no como una secuencia de instrucciones sino como la forma en que el objeto es útil (el método para hacer su trabajo). Por lo tanto, podemos considerar al método como el pedido a un objeto para que realice una tarea determinada o como la vía para enviar un mensaje al objeto y que éste reaccione acorde a dicho mensaje.

TIPOS DE MÉTODOS
-cientifico -mental -psicotecnico y de maicon -Como ya se mencionó, los métodos de instancia están relacionados con un objeto en particular, mientras que los métodos estáticos o de clase (también denominados métodos compartidos) están asociados a una clase en particular. En una implementación típica, a los métodos de instancia se les pasa una referencia oculta al objeto al que pertenecen, comúnmente denominada this o self (referencias a sí mismo por sus significados en inglés), para que puedan acceder a los datos asociados con el mismo. Un ejemplo típico de un método de clase sería uno que mantuviera la cuenta de la cantidad de objetos creados dentro de esa clase.
Los llamados métodos obtener y métodos establecer (en inglés get y set) proveen un mecanismo para leer y modificar (respectivamente) los datos privados que se encuentran almacenados en un objeto o clase.
Algunos lenguajes de programación requieren la definición de constructores, siendo estos métodos de instancia especiales llamados automáticamente cuando se crea una instancia de alguna clase. En Java y C++ se distinguen por tener el mismo nombre de la clases a la que están asociados.

ACCESORES
Las variables instancia de un objeto son sus atributos, eso que diferencia a un objeto de otro dentro de la misma clase. Es importante poder modificar y leer estos atributos; lo que supone definir métodos denominados //accesores de atributos//. Veremos en un momento que no siempre hay que definir los métodos accesores explícitamente, pero vayamos paso a paso. Los dos tipos de accesores son los de //escritura// y los de //lectura//.
|| ruby> class Fruta
ruby| def set_kind(k) # escritor
ruby| @kind = k
ruby| end
ruby| def get_kind # lector
ruby| @kind
ruby| end
ruby| end
nilx
ruby> f1 = Fruta.new
#<Fruta:0x401c4410>
ruby> f1.set_kind("melocotón") #utilizamos el escritor
"melocotón"
ruby> f1.get_kind #utilizamos el lector
"melocotón"
ruby> f1 #inspeccionamos el objeto
#<Fruta:0x401c4410 @kind="melocotón">
||

Sencillo; podemos almacenar y recuperar información sobre la clase de fruta que queremos tener en cuenta. Pero los nombres de nuestros métodos son un poco largos. Los siguientes son más breves y convencionales:
|| ruby> class Fruta
ruby| def kind=(k)
ruby| @kind = k
ruby| end
ruby| def kind
ruby| @kind
ruby| end
ruby| end
nil
ruby> f2 = Fruta.new
#<Fruta:0x401c30c4>
ruby> f2.kind = "banana"
"banana"
ruby> f2.kind
"banana"
||

PARAMETRO
Un parámetro es un método para pasar información (valores a variables) del programa principal a un procedimiento y viceversa.
Un parámetro es, prácticamente, una variable cuyo valor debe ser ya sea proporcionado por el programa principal al procedimiento o ser devuelto desde el procedimiento hasta el programa principal. Por consiguiente, existen dos tipos de parámetros:
-         Parámetros de entrada: Sus valores deben ser proporcionados por el programa principal.
-         Parámetros de salida: Son parámetros cuyos valores se calcularán en el procedimiento y se deben devolver al programa principal para su proceso posterior.

 Transferencia de información desde y/o hasta los procedimientos
Existen dos tipos de procedimientos:
-         Procedimientos sin parámetros: No existe comunicación entre el programa principal y los procedimientos ni viceversa.
-         Procedimientos con parámetros: Existe comunicación entre el programa principal y los procedimientos o entre dos procedimientos.
Ejemplo 1:
(Parámetros de entrada)
Procedure RecuadroDos (N : Integer);
Var
            J : Integer;
Begin
            For J := 1 to  N do
                        Write(`*´)
End;
Ejemplo 2:
(Parámetros de entrada/salida)
El procedimiento Geometria recibe la longitud y anchura de un rectángulo, calcula el área y perímetro del rectángulo y devuelve los valores obtenidos al programa principal.
Procedure Geometria (Longitud, Anchura : Real; Var Area, Perímetro : Real);
Begin
            Area := Longitud * Anchura;
            Perimetro := 2 * (Longitud + Anchura)
End;

ENCAPSULAMIENTO (INFORMÁTICA)
En programación modular, y más específicamente en programación orientada a objetos, se denomina encapsulamiento al ocultamiento del estado, es decir, de los datos miembro, de un objeto de manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto.
Cada objeto está aislado del exterior, es un módulo natural, y la aplicación entera se reduce a un agregado o rompecabezas de objetos. El aislamiento protege a los datos asociados a un objeto contra su modificación por quien no tenga derecho a acceder a ellos, eliminando efectos secundarios e interacciones.
De esta forma el usuario de la clase puede obviar la implementación de los métodos y propiedades para concentrarse sólo en cómo usarlos. Por otro lado se evita que el usuario pueda cambiar su estado de maneras imprevistas e incontroladas.
Encapsulamiento
Se dice que es el empaquetado de métodos y atributos dentro de un objeto, mediante una interfaz grafica. La clave está precisamente en el envoltorio del objeto .
Como se puede observar de los diagramas, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la protección de sus métodos se le llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa.

miércoles, 23 de febrero de 2011

SISTEMA DE REQUISITOS DE SOFWARE


SISTEMA DE GESTION DE REQUISITOS
En la ingeniería de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas o la ingeniería de software.
En la ingeniería clásica, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.
La fase del desarrollo de requerimientos puede estar precedida por una fase de análisis conceptual del proyecto. Esta fase puede dividirse en recolección de requerimientos de los inversores, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo.
 ¿Que es un 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).
Requerimientos en ingeniería de software y sistemas
En ingeniería de sistemas existen tres tipos de requerimientos.
Un 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.
Un requerimiento no funcional: de rendimiento, de calidad, etc; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto
Una colección de requerimientos describe las características o atributos del sistema deseado. Se omite el cómo debe lograrse su implementación, ya que esto debe ser decidido en la etapa de diseño por los diseñadores.
En la ingeniería de software se aplica el mismo significado, sólo que el énfasis está puesto en el propio software.
Características
Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.
Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.
Estas características suelen ser subjetivas, es decir, no pueden ser calculadas de forma automática por ningún sistema. Por ello, se tiende a medir otras métricas o indicadores que sí que pueden ser calculados de forma automática y que, de algún modo, pueden sustituir o mapear con esta lista de características.
Análisis de requerimientos
Artículo principal: Ingeniería de requerimientos
La etapa en que se estudian los requerimientos para verificar que estén correctamente adecuados a las características mencionadas es conocida como Análisis de Requerimientos. En la misma se enfocan e intentan solucionar las deficiencias que los requerimientos puedan tener.

ALGO MAS RELACIONADO CON EL TEMA:
En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.
Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.
El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.
 Implicaciones
La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:
La elicitación de los requisitos de usuario
Al análisis y negociación de requisitos para derivar requisitos adicionales
A la documentación de los requisitos como especificación
A la validación de los requisitos documentados contra las necesidades de usuario
Así como los procesos que apoyan estas actividades.
Fases de implementación
Desde un punto de vista conceptual, las actividades son de cinco clases.
Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados.
Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación.
Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.
Técnicas principales
La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.
Entrevistas
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores más afectados o que harán un uso más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallos.
Las entrevistas pueden ser personales o grupales.
Talleres
Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.
Forma de contrato
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.
Objetivos medibles
Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.
Prototipos
Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.
Casos de uso
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.
A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.
Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.
Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.
Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.
Especificación de requisitos del software

Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).
Las estrategias recomendadas para la especificación de los requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles, contenido deseable, y calidades de una especificación de requisitos del software.
Los requisitos se dividen en tres:
Funcionales: son los que el usuario necesita que efectúe el software. Ej: el sistema debe emitir un comprobante al asentar la entrega de mercadería.
No funcionales: son los "recursos" para que trabaje el sistema de información (redes, tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.
Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej: abaratar costos de expedición.
Identificación de las personas involucradas
Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de un tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los implicados para que se obtengan y depuren sus requisitos de la forma más fidedigna posible. Entre las personas implicadas hay que considerar:
Organizaciones que integran la organización del analista que está diseñando el sistema
Organizaciones o sistemas de respaldo
Dirección
Usuarios
Problemas
Relacionados con las personas involucradas
Vías que pueden dificultar la determinación de los requisitos son:
Los usuarios no tienen claro lo que desean
Los usuarios no se involucran en la elaboración de requisitos escritos
Los usuarios insisten en nuevos requisitos después de que el coste y la programación se hayan fijado.
La comunicación con los usuarios es lenta
Los usuarios no participan en revisiones o son incapaces de hacerlo.
Los usuarios no comprenden los problemas técnicos
Los usuarios no entienden el proceso del desarrollo
Esto puede conducir a la situación donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya está en marcha.
Relacionados con los analistas
La correcta redacción de las Especificaciones de requisitos Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redacción hay que evitar:
Uso de terminología ambigua en la redacción de los documentos de requisitos
Sobreespecificación de los requisitos
Escritura poco legible, voz pasiva, abuso de negaciones
Uso de verbos en condicional, expresiones subjetivas
Ausencia de términos y verbos del dominio de la aplicación
Relacionados con los desarrolladores
Los problemas posibles causados por los desarrolladores durante análisis de requisitos son:
El personal técnico y los usuarios finales pueden tener diversos vocabularios y pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta del desacuerdo hasta que se provee el producto final.
Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente.
El análisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las habilidades de relación con la gente y el conocimiento apropiados para entender las necesidades de un cliente correctamente.
Soluciones aplicadas
Una solución aplicada en los problemas de comunicaciones ha sido emplear a especialistas en análisis del negocio o del sistema.
Las técnicas introducidas en los años 90 tienden al uso de prototipos, lenguaje unificado de modelado, casos de uso, y el desarrollo ágil de software.
Otros tipos de herramientas aplicadas para salvar las diferencias entre los usuarios y las organizaciones de tecnología de la información y que permiten la comprobación de las aplicaciones son:
pizarras electrónicas para bosquejar los algoritmos y para probar alternativas
capacidad de capturar la lógica del negocio y los datos necesarios
capacidad de generar los prototipos que imitan fielmente el producto final
interactividad
la capacidad para agregar requisitos contextuales y otro comentarios
capacidad para que usuarios remotos y distribuidos operen con el prototipo
Por último, se requieren herramientas que permitan medir, de forma objetiva, la calidad de una especificación de requisitos.