SlideShare una empresa de Scribd logo
1 de 37
Descargar para leer sin conexión
REQUERIMIENTOS DEL SOFTWARE

INDICE

INTRODUCCION
REQUERIMIENTOS DEL SOFTWARE
CARACTERÍSTICAS DE LOS REQUERIMIENTOS
DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS
CARACTERÍSTICAS DE UN REQUERIMIENTO
FUNDAMENTOS DEL ANÁLISIS DE REQUERIMIENTOS
TAREAS DEL ANÁLISIS
ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS)
CLASIFICACIÓN DE LOS REQUERIMIENTOS
ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS
PRINCIPIOS DE ESPECIFICACIÓN
MANEJO DE REQUERIMIENTOS
ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO
REQUERIMIENTOS DEL SISTEMA
ESTRATEGIA DEL FLUJO DE DATOS
ESTRATEGIA DEL ANÁLISIS DE DECISIONES
ETAPAS EN LA ESTRATEGIA DEL ANÁLISIS DEL FLUJO DE DATOS
UTILIZACIÓN DE LOS DATOS DE REQUERIMIENTOS
DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE
MÉTODOS DE ANÁLISIS ORIENTADOS AL FLUJO DE DATOS
DIAGRAMAS DE FLUJOS DE DATOS
DICCIONARIO DE DATOS
DESCRIPCIONES FUNCIONALES
MÉTODOS ORIENTADOS A LA ESTRUCTURA DE DATOS
BIBLIOGRAFÍA


ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE


INTRODUCCION


¿Qué son Requerimientos?


Normalmente, un tema de la Ingeniería de Software tiene diferentes
significados. De las muchas definiciones que existen para requerimiento, ha
continuación se presenta la definición que aparece en el glosario de la IEEE:


(1) Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.

(2) Una condición o capacidad que debe estar presente en un sistema o
componentes      de   sistema    para   satisfacer   un   contrato,   estándar,
especificación u otro documento formal.

(3) Una representación documentada de una condición o capacidad como
en (1) o (2).

Los requerimientos puedes dividirse        en requerimientos funcionales        y
requerimientos no funcionales.

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.



Los requerimientos no funcionales 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



Las características de un requerimiento son sus propiedades principales. Un
conjunto de requerimientos en estado de madurez, deben presentar una serie
de características tanto individualmente como en grupo. A continuación se
presentan las más importantes.



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.



* Dificultades para definir los requerimientos *

• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más
importantes o más estables que otros.

• Los requerimientos están relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.

• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales
específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es
particular para cada proyecto.
* Ingeniería de Requerimientos vs. Administración de Requerimientos *


El proceso de recopilar, analizar y verificar las necesidades del cliente para
un sistema es llamado Ingeniería de Requerimientos. La meta de la
ingeniería de requerimientos (IR) es entregar una especificación de requisitos
de software correcta y completa.

Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de
software, es ellos se basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto
usan los requerimientos como una base para la estimación del esfuerzo
necesario en un proyecto.

Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por
ejemplo: cuando se está tratando de alinearse a cierta norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los
requerimientos son la base sobre la cual se decide si un caso de prueba fue
ejecutado exitosamente por el sistema o no.

Son el fundamento del ciclo de vida del proyecto. Los requerimientos
documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y
manejados de la forma mas adecuada posible.



Características de un requerimiento



Ya que visualizamos la importancia de los requerimientos en un sistema de
software entonces debemos de definir que características deben de poseer los
requerimientos adecuadamente formulados.



Los requerimientos deben ser:

Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Posibles de probar o verificar. Si un requerimiento no se puede comprobar,
entonces        ¿cómo     sabemos       si    cumplimos       con     él    o   no?
Descritos como una característica del sistema a entregar. Esto es: que es lo
que   el   sistema      debe   de    hacer   (y   no   como    debe    de   hacerlo)
Lo más abstracto y conciso posible. Para evitar malas interpretaciones.




* Fundamentos del Análisis de Requerimientos *



Definición: Es el conjunto de técnicas y procedimientos que nos permiten
conocer los elementos necesarios para definir un proyecto de software.
Es la etapa más crucial del desarrollo de un proyecto de software.



La IEEE los divide en funcionales y no funcionales:



Funcionales: Condición o capacidad de un sistema requerida por el usuario
para resolver un problema o alcanzar un objetivo.



No Funcionales: Condición o capacidad que debe poseer un sistema para
satisfacer un contrato, un estándar, una especificación u otro documento
formalmente impuesto.



Para realizar bien el desarrollo de software es esencial realizar una
especificación     completa     de    los    requerimientos     de    los   mismos.
Independientemente de lo bien diseñado o codificado que esté, un programa
pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.



La tarea de análisis de los requerimientos es un proceso de
descubrimiento y refinamiento, El ámbito del programa, establecido
inicialmente durante la ingeniería del sistema, es refinado en detalle. Se
analizan y asignan a los distintos elementos de los programas las soluciones
alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel activo
en la especificación de requerimientos. El cliente intenta reformular su
concepto, algo nebuloso, de la función y comportamiento de los programas en
detalles concretos, El que desarrolla el software actúa como interrogador,
consultor y el que resuelve los problemas.



El análisis y especificación de requerimientos puede parecer una tarea
relativamente sencilla, pero las apariencias engañan. Puesto que el contenido
de comunicación es muy alto, abundan los cambios por mala interpretación
o falta de información. El dilema con el que se enfrenta un ingeniero de
software puede ser comprendido repitiendo la sentencia de un cliente anónimo:
"Sé que crees que comprendes lo que piensas que he dicho, pero no
estoy seguro de que lo que creíste oír sea lo que yo quise decir".



Los requerimientos de un sistema de software, cuando se ven en su conjunto
son extensos y detallados, y además contienen múltiples relaciones entre sí. Lo
que nos da a concluir, que el conjunto de requerimientos de un sistema
computacional es complejo.



Obtenemos la posibilidad de especificar sistemas complejos al documentar
especificaciones simples y concisas para el sistema. Esto se logra mediante al
clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras
palabras al analizar sus requerimientos.

El análisis de requerimientos es la tarea que plantea la asignación de software
a nivel de sistema y el diseño de programas. El análisis de requerimientos
facilita al ingeniero de sistemas especificar:

      la función y comportamiento de los programas,
      indicar la interfaz con otros elementos del sistema y
      establecer las ligaduras de diseño que debe cumplir el programa.

El análisis de requerimientos permite al ingeniero:
refinar la asignación de software y
      representar el dominio de la información que será tratada por el
      programa.

El análisis de requerimientos da al diseñador:

      la representación de la información y
      las funciones que pueden ser traducidas en datos, arquitectura y diseño
      procedimental.

Finalmente, la especificación de requerimientos suministra al técnico y al
cliente:

      los medios para valorar la calidad de los programas, una vez que se
      haya construido.




    * Tareas del Análisis *




    El análisis de requerimientos puede dividirse en cuatro áreas:

    1.- Reconocimiento del problema

    2.- Evaluación y síntesis

    3.- Especificación

    4.- Revisión.

    Inicialmente, el analista estudia la especificación del sistema (si existe) y el
    plan de proyecto. Es importante comprender el contexto del sistema y
    revisar el ámbito de los programas que se usó para generar las
    estimaciones de la planificación. A continuación, debe establecerse la
    comunicación necesaria para el análisis, de forma que se asegure el
    reconocimiento del problema.


    El analista debe establecer contacto con el equipo técnico y de gestión del
usuario / cliente y con la empresa que vaya a desarrollar el software. El
gestor del programa puede servir como coordinador para facilitar el
establecimiento de los caminos de comunicación. El objetivo del analista es
reconocer los elementos básicos del programa tal como lo percibe el
usuario / cliente.


La evaluación del problema y la síntesis de la solución es la siguiente
área principal de trabajo del análisis. El analista debe evaluar el flujo y
estructura de la información, refinar en detalle todas las funciones del
programa, establecer las características de la interfase del sistema y
descubrir las ligaduras del diseño, Cada una de las tareas sirven para
descubrir el problema de forma que pueda sintetizarse un enfoque o
solución global.


Las tareas asociadas con el análisis y especificación existen para dar una
representación del programa que pueda ser revisada y aprobada por el
cliente. En un mundo ideal el cliente desarrolla una especificación de
requerimientos del software completamente por sí mismo. Esto se presenta
raramente en el mundo real. En el mejor de los casos, la especificación se
desarrolla conjuntamente entre el cliente y el técnico.



Una    vez    que    se   hayan   descrito   las   funcionalidades    básicas,
comportamiento, interfase e información, se especifican los criterios de
validación    para   demostrar    una    comprensión       de   una   correcta
implementación de los programas. Estos criterios sirven como base para
hacer una prueba durante el desarrollo de los programas. Para definir las
características y atributos del software se escribe una especificación de
requerimientos formal. Además, para los casos en los que se desarrolle
un prototipo se realiza un manual de usuario preliminar.



Puede parecer innecesario realizar un manual de usuario en una etapa tan
temprana del proceso de desarrollo, Pero de hecho, este borrador del
manual de usuario fuerza al analista a tomar el punto de vista del usuario
del software. El manual permite al usuario / cliente revisar el software
desde una perspectiva de ingeniería humana y frecuentemente produce el
comentario: "La idea es correcta pero esta no es la forma en que pensé
que se podría hacer esto". Es mejor descubrir tales comentarios lo más
tempranamente posible en el proceso.

Los documentos del análisis de requerimiento (especificación y manual de
usuario) sirven como base para una revisión conducida por el cliente y el
técnico. La revisión de los requerimientos casi siempre produce
modificaciones en la función, comportamiento, representación de la
información, ligaduras o criterios de validación. Además, se realiza una
nueva apreciación del plan del proyecto de software para determinar si las
primeras estimaciones siguen siendo validas después del conocimiento
adicional obtenido durante el análisis.



* Obteniendo de la información *



Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de
desarrollo de software, este entendimiento es necesario para poder
construir software que satisfaga las necesidades de nuestro cliente.

Si los requerimientos se enfocan a describir las necesidades del cliente,
entonces es lógico que para recabarlos haya que obtener la información de
primera mano. Esto es, mediante entrevistas con el cliente o recabando
documentación que describa la manera que el cliente desea que funcione
el sistema de software.



Las necesidades y / o requerimientos del cliente evolucionan con el tiempo
y cada cambio involucra un costo. Por eso es necesario tener archivada
una copia de la documentación original del cliente, así como cada revisión
o cambio que se haga a esta documentación. Como cada necesidad del
cliente es tratada de diferente forma, es necesario clasificar estas
necesidades para saber cuáles de ellas serán satisfechas por el software y
cuales por algún otro producto del sistema.



* Especificación de Requisitos de Software *(SRS)



La especificación de requisitos de software es la actividad en la cual se
genera el documento, con el mismo nombre, que contiene una descripción
completa de las necesidades y funcionalidades del sistema que será
desarrollado; describe el alcance del sistema y la forma en cómo hará sus
funciones, definiendo los requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software,
diagramas, modelos de sistemas y cualquier otra información que sirva de
soporte y guía para fases posteriores.

Es importante destacar que la especificación de requisitos es el resultado
final de las actividades de análisis y evaluación de requerimientos; este
documento resultante será utilizado como fuente básica de comunicación
entre los clientes, usuarios finales, analistas de sistema, personal de
pruebas, y todo aquel involucrado en la implementación del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está
proponiendo, coincide con las necesidades de la empresa. Los analistas y
programadores la utilizan para determinar el producto que debe
desarrollarse. El personal de pruebas elaborará las pruebas funcionales y
de sistemas en base a este documento. Para el administrador del proyecto
sirve   como    referencia    y    control   de       la    evolución   del   sistema.
La SRS posee las mismas características de los requerimientos: completa,
consistente, verificable, no ambigua, factible, modificable, rastreable,
precisa, entre otras. Para que cada característica de la SRS sea
considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo,
para que una SRS se considere verificable, cada requerimiento definido en
ella debe ser verificable; para que una SRS se considere modificable, cada
requerimiento    debe   ser       modificable     y        así   sucesivamente.   Las
características de la SRS son verificadas en la actividad de Validación,
descrita en el punto.

La estandarización de la SRS es fundamental pues ayudará, entre otras
cosas, a facilitar la lectura y escritura de la misma. Será un documento
familiar para todos los involucrados, además de asegurar que se cubren
todos los tópicos importantes.

Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la
potestad de crear su propia plantilla.




Clasificación de los requerimientos

El   clasificar    requerimientos   es   una   forma   de   organizarlos,   hay
requerimientos que por sus características no pueden ser tratados iguales.
La siguiente es una recomendación de como pueden ser clasificados los
requerimientos aunque cada proyecto de software pueda usar sus propias
clasificaciones.



• Requerimientos del "entorno"

El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el
entorno, existen cierto tipo de requerimientos que se clasifican en esta
categoría porque:

El sistema usa el entorno y lo necesita como una fuente de los servicios
necesarios para que funcione. Ejemplos del entorno podemos mencionar:
sistemas operativos, sistema de archivos, bases de datos.

El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en
el entorno, tales como congestión en los dispositivos y errores de entrada
de datos, por lo tanto el entorno se debe de considerar dentro de los
requerimientos.
• Requerimientos ergonómicos"

Él más conocido de los requerimientos ergonómicos es la interfase con el
usuario o GUI (Graphic User Interface). En otras palabras, los
requerimientos ergonómicos son la forma en que el ser humano interactúa
con el ser sistema.




• Requerimientos de Interfase

La interfase es como interactúa el sistema con el ser humano o con otros
sistemas (el enfoque es prácticamente el opuesto a los requerimientos
ergonómicos), La interfase es la especificación formal de los datos que el
sistema recibe o manda al exterior. Usualmente se especifica el protocolo,
el tipo de información, el medio para comunicarse y el formato de los datos
que se van a comunicar.




* Actividades de la Ingeniería de Requerimientos *



En el proceso de IR son esenciales diversas actividades. En este
documento serán presentadas, sin embargo, en un proceso de ingeniería
de requerimientos efectivo, estas actividades son aplicadas de manera
continua y en orden variado.



Dependiendo del tamaño del proyecto y del modelo de proceso de software
utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en
número como en nombres. La tabla #1 muestra algunos ejemplos de las
actividades identificadas para cada proceso.

A pesar de las diferentes interpretaciones que cada desarrollador tenga
sobre el conjunto de actividades mostradas en la tabla anterior, podemos
identificar   y   extraer   cinco    actividades     principales   que    son:
• Análisis del Problema


• Evaluación y Negociación


• Especificación


• Validación


• Evolución




* Principios de Especificación *



La especificación, independientemente del modo en que se realice, puede
ser vista como un proceso de representación. Los requerimientos se
representan de forma que conduzcan finalmente a una correcta
implementación del software.

Baltzer   y    Goldman    proponen   ocho   principios   para   una   buena
especificación:


PRINCIPIO         #1.   Separar    funcionalidad   de     implementación.



Una especificación es una descripción de lo que se desea, en vez de cómo
se realiza (implementa). Las especificaciones pueden adoptar dos formas
muy diferentes. La primera forma es la de funciones matemáticas: dado
algún conjunto de entrada, producir un conjunto particular de salida. La
forma general de tales especificaciones es encontrar [un/el/todos] resultado
tal que P (entrada), donde P representa un predicado arbitrario. En tales
especificaciones, el resultado a ser obtenido ha sido expresado
enteramente en una forma sobre el que (en vez de cómo). En parte, esto
es debido a que el resultado es una función matemática de la entrada (la
operación tiene puntos de comienzo y parada bien definidos) y no está
afectado por el entorno que le rodea.



PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas
orientado al proceso.



Considerar una situación en la que el entorno sea dinámico y sus cambios
afecten al comportamiento de alguna entidad que interactúe con dicho
entorno. Su comportamiento no puede ser expresado como una función
matemática de su entrada. En vez de ello, debe emplearse una descripción
orientada al proceso, en la cual la especificación del que se consigue
mediante la especificación de un modelo del comportamiento deseado en
términos de respuestas funcionales, a distintos estímulos del entorno.



PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el
software es una componente.



Un sistema está compuesto de componentes que interactúan. Solo dentro
del contexto del sistema completo y de la interacción entre sus partes
puede ser definido el comportamiento de una componente específica. En
general, un sistema puede ser modelado como una colección de objetos
pasivos y activos. Estos objetos están interrelacionados y dichas relaciones
entre los objetos cambian con el tiempo. Estas relaciones dinámicas
suministran los estímulos a los cuales los objetos activos, llamados
agentes, responden. Las respuestas pueden causar posteriormente
cambios y, por tanto, estímulos adicionales a los cuales los agentes deben
responder.



PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el
sistema opera.
Similarmente, el entorno en el que opera el sistema y con el que interactúa
debe ser especificado.

Afortunadamente, esto tan solo necesita reconocer que el propio entorno
es un sistema compuesto de objetos que interactúan, pasivos y activos, de
los cuales el sistema especificado es una agente, Los otros agentes, los
cuales son por definición inalterables debido a que son parte del entorno,
limitan el ámbito del diseño subsecuente y de la implementación. De hecho,
la única diferencia entre el sistema y su entorno es que el esfuerzo de
diseño e implementación subsecuente opera exclusivamente sobre la
especificación del sistema. La especificación del entorno facilita que se
especifique la interfaz del sistema de la misma forma que el propio sistema,
en vez de introducir otro formalismo.




PRINCIPIO #5. Una especificación de sistema debe ser un modelo
cognitivo.



La especificación de un sistema debe ser un modelo cognitivo, en vez de
un modelo de diseño o implementación. Debe describir un sistema tal como
es percibido por su comunidad de usuario. Los objetivos que manipula
deben corresponderse con objetos reales de dicho dominio; los agentes
deben modelar los individuos, organizaciones y equipo de ese dominio; y
las acciones que ejecutan deben modelar lo que realmente ocurre en el
dominio. Además, debe ser posible incorporar en la especificación las
reglas o leyes que gobiernan los objetos del dominio. Algunas de estas
leyes proscriben ciertos estados del sistema (tal como "dos objetos no
pueden estar en el mismo lugar al mismo tiempo"), y por tanto limitan el
comportamiento de los agentes o indican la necesidad de una posterior
elaboración     para     prevenir       que   surjan     estos     estados.



PRINCIPIO      #6.     Una   especificación    debe     ser   operacional.
La especificación debe ser completa y lo bastante formal para que pueda
usarse para determinar si una implementación propuesta satisface la
especificación de pruebas elegidas arbitrariamente. Esto es, dado el
resultado de una implementación sobre algún conjunto arbitrario de datos
elegibles, debe ser posible usar la especificación para validar estos
resultados. Esto implica que la especificación, aunque no sea una
especificación completa del como, pueda actuar como un generador de
posibles comportamientos, entre los que debe estar la implementación
propuesta. Por tanto, en un sentido extenso, la especificación debe ser
operacional.



PRINCIPIO #7. La especificación del sistema debe ser tolerante con la
incompletitud y aumentable.

Ninguna especificación puede ser siempre totalmente completa. El entorno
en el que existe es demasiado complejo para ello. Una especificación es
siempre un modelo, una abstracción, de alguna situación real (o
imaginada). Por tanto, será incompleta. Además, al ser formulad existirán
muchos niveles de detalle. La operacionalidad requerida anteriormente no
necesita ser completa. Las herramientas de análisis empleadas para
ayudar a los especificadores y para probar las especificaciones, deben ser
capaces de tratar con la incompletitud. Naturalmente esto debilita el
análisis,   el   cual   puede   ser   ejecutado   ampliando   el   rango   de
comportamiento aceptables, los cuales satisfacen la especificación, pero tal
degradación debe reflejar los restantes niveles de incertidumbre.
PRINCIPIO #8. Una especificación debe ser localizada y débilmente
acoplada.
Los principios anteriores tratan con la especificación como una entidad
estática. Esta surge de la dinámica de la especificación. Debe ser
reconocido que aunque el principal propósito de una especificación sea
servir como base para el diseño e implementación de algún sistema, no es
un objeto estático precompuesto, sino un objeto dinámico que sufre
considerables modificaciones. Tales modificaciones se presentan en tres
actividades principales: formulación, cuando se está creando una
especificación inicial; desarrollo, cuando la especificación se esta
elaborando durante el proceso iterativo de diseño e implementación; y
mantenimiento, cuando la especificación se cambia para reflejar un entorno
modificado y / o requerimientos funcionales adicionales.



• Requerimientos funcionales



Estos son los que describen lo que el sistema debe de hacer. Es
importante que se describa él ¿Qué? Y no él ¿Cómo?. Estos
requerimientos al tiempo que avanza el proyecto de software se convierten
en los algoritmos, la lógica y gran parte del código del sistema.



• Requerimientos de desempeño



Estos requerimientos nos informan las características de desempeño que
deben de tener el sistema. ¿Qué tan rápido?, ¿Que tan seguido?,

¿Cuántos recursos?, ¿Cuantas transacciones?



Este tipo de requerimientos es de especial importancia en los sistemas de
tiempo real en donde el desempeño de un sistema es tan crítico como su
funcionamiento.



• Disponibilidad (en un determinado periodo de tiempo)



Este tipo de requerimientos se refiere a la durabilidad, degradación,
potabilidad, flexibilidad, contabilidad y capacidad de actualización. Este tipo
de requerimientos es también muy importante en sistemas de tiempo real
puesto que estos sistemas manejan aplicaciones críticas que no deben de
estar   fuera   de   servicio   por   periodos    prolongados    de    tiempo.
• Entrenamiento



Este tipo de requerimientos se enfoca a las personas que van usar el
sistema. ¿Qué tipo de usuarios son?, ¿Que tipo de operadores?, ¿Que
manuales se entregarán y en que idioma?

Este tipo de requerimientos, aunque muchas veces no termina en un
pedazo de código dentro del sistema, son muy importantes en el proceso
de diseño ya que facilitan la introducción y aceptación del sistema en
donde será implementado.



• Restricciones de diseño



Muchas veces las soluciones de un sistema de software son normadas por
leyes o estándares, este tipo de normas caen como "restricciones de
diseño".



• Materiales



Aquí se especifica en que medio se entregara el sistema y como esta
empaquetado. Es importante para definir los costos de industrialización del
sistema.


* Manejo de requerimientos *




De acuerdo con el "Capability Maturity Model" (CMM), el manejo de
requerimientos involucra:



"Establecer y mantener un acuerdo con el cliente sobre los requerimientos
del proyecto de software. Este acuerdo son los requerimientos del sistema
alojados al software." … ". Este acuerdo cubre requerimientos técnicos y no
técnicos (como fechas de entrega). El acuerdo forma las bases para
estimar, planear, ejecutar y monitorear el proyecto de desarrollo de
software a través de todo su ciclo de vida." … "Bajo las restricciones del
proyecto, el grupo de manejo de requerimientos toma las medidas
necesarias para que los requerimientos que están bajo su responsabilidad
estén documentados y controlados"



¿De que manera podemos controlar los requerimientos de software si estos
siempre evolucionan con el tiempo?. El CMM nos proporciona las guías
para lograrlo.



"Para lograr el control de los requerimientos, el grupo de requerimientos
revisa los requerimientos antes de que estos sean incorporados al proyecto
de software y cada vez que los requerimientos cambian los planes,
productos, y actividades son ajustadas para quedar en línea con los nuevos
requerimientos de software".



En otras palabras, para obtener el nivel que requiere el CMM en manejo de
requerimientos    débenos      de   tomar    en    cuenta    dos    cosas.
• Que los requerimientos deben de ser revisados (y aprobados) por el
grupo de requerimientos, y no son impuestos por en su totalidad por
presiones externas ajenas al proyecto.



El requerimiento técnico podrá ser impuesto por el mercado o presiones de
la competencia, pero entonces los requerimientos no técnicos (Calidad,
Costo y Tiempo de entrega) deberán estar especificados de común
acuerdo con el grupo de requerimientos del proyecto de software.
• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si
cambia uno forzosamente deberán cambiar los demás. Esto es: más
contenido técnico implica o más costo, o menos calidad o más tiempo
estimado de entrega. De modo que los cambios técnicos deberán ser
aprobados por el grupo de requerimientos y este grupo estimará los
impactos en tiempo, costo, calidad. El resultado de la estimación es la
entrada a los líderes del proyecto para decidir si el cambio se acepta o no.


* ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO *




Para prosperar en el mercado, cualquier producto debe satisfacer las
necesidades de los usuarios, lo cual no resulta posible si no integra y pone
al alcance del consumidor de forma comprensible los fundamentos de
todos los aspectos del desarrollo. Para captar las necesidades específicas
de los usuarios es indispensable que los documentos que recogen los
requerimientos     se    redacten     utilizando   métodos      pragmáticos.
Se debe utilizar una metodología detallada de definición de los
requerimientos de usuario. Organizar entrevistas destinadas a obtener la
máxima información posible acerca de los requerimientos de los usuarios.
Traducir las oportunidades / necesidades en requerimientos del proyecto.
Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear
un documento de requerimientos generales. Conseguir la participación y
confirmación del usuario.



Los gerentes y usuarios del sistema también poseen un papel importante
en le diseño del sistema; no es solamente el proyecto del analista. Durante
el diseño, a algunos se les pide que revisen los borradores de los informes,
que examinen los formatos de entrada y que ayuden en la escritura de los
procedimientos para decirles a otras personas como utilizar el sistema en
forma apropiada.



La participación del usuario proporciona al analista una retroalimentación
importante conforme avanza en el diseño; además asegura a los usuarios
tengan un conocimiento no técnico de lo realizara o no el nuevo sistema.
Esta visión general del diseño de sistemas subraya los aspectos de diseño
que se verán mas adelante en el diseño de la salida de sistema.


* REQUERIMIENTOS DEL SISTEMA *



Los Sistemas de Información por computadora normalmente están
integrados por muchos componentes. En la mayor parte de los casos, es
difícil para los analistas entender todos estos componentes aún mismo
tiempo; por lo tanto los investigadores tienen que comenzar con preguntas
de tipo general con relación al propósito del sistema sus entradas y salidas
de los procesos incluidos.



En los grandes proyectos de sistema varios analistas llevan a cabo una
investigación en forma seccionada que la distribuye entre ellos mismos, de
manera    que    cada   uno   pueda    trabajar   en   forma    independiente.
Existen dos estrategias ampliamente utilizadas para determinar los
requerimientos    de    información.    Se    clasifican   en     dos   tipos:



1.- Flujo de Datos.



2.- Estrategias de Análisis de Decisión para el Conocimiento para los
Sistema de Información.




* Estrategia del Flujo de Datos *




Cuando se siguen un flujo a través de los procesos de negocio, que es el
propósito del análisis del flujo de datos, le indica a los analistas una gran
cantidad de datos sobre como sé esta llevando a cabo los objetivos de la
compañía. Al manejar las transacciones y completar las tareas, los datos
de entrada se procesan, almacenan, consultan, utiliza, modifica y se
emiten.
El análisis de flujo de datos que muestra el estudio y el uso de cada
actividad, documenta los hallazgos en los diagramas de flujo de datos.


* Estrategia del Análisis de Decisiones *




La estrategia del análisis de decisiones es un complemento del análisis del
flujo de datos. Esta estrategia realza el estudio de los objetivos de una
operación y de las decisiones que deben realizarse para cumplir con los
objetivos.
Las decisiones se presentan tanto en los niveles operativos como en los de
alto nivel gerencial, la estrategia de análisis de decisión con frecuencia
utiliza por parte de alta gerencia para desarrollar la toma de decisiones.
La alternativa que selecciona los gerentes responsables en la toma de
decisiones, en cuanto a una estrategia de precios entre un conjunto de
alternativas, se maneja de forma diferente a la opción que toma un
supervisor   de   departamento     para     aceptar   o   rechazar   pedidos.
La decisión de rechazar pedidos generalmente ocurre con más frecuencia,
de manera que las condiciones y acciones normalmente se conocen como
un aspecto importante.




* Etapas en la Estrategia del Análisis del Flujo de Datos *



1. - Estudiar las operaciones y procesos en marcha.



2. - Identificar cómo se procesan los datos al manejar transacciones y
terminar las tareas.
3. - Seguir el flujo de datos:



* Proceso



* Almacenamiento



* Recuperación



* Salida



4. - Añadir gradualmente detalles a los niveles inferiores.



Etapas en la Estrategia del Análisis de Decisión



1. -Estudiar los objetivos y decisiones necesarias.



2. - Desarrollar un modelo del proceso de decisión.



3. - Probar el modelo con datos de prueba.



4.   -   Identificar   los   requerimientos   del   proceso   para   los   datos.


* Requerimientos De Entrada *




Es el enlace que une al sistema de información con el mundo y sus
usuarios, en esta existen aspectos generales que todos los analistas deben
tener en cuenta estos son:



• Objetivos del Diseño de Entrada.



• Captura de Datos para la Entrada.




Objetivo del Diseño de Entrada



Consiste en el desarrollo de especificaciones y procedimientos para la
preparación de datos, la realización de los procesos necesarios para poner
los datos de transacción en una forma utilizable para su procesamiento así
como la entrada de los datos se logra al instruir a la computadora para que
lea ya sea documentos escritos, impresos ó por personas que los escriben
directamente al sistema.



Existen cinco objetivos que controlan la cantidad de entrada requerida, a
enviar los retrasos, controlar los errores y mantener la sencillez de los
pasos necesarios, estos son:



• Control de la Calidad de Entrada



• Evitar los Retrasos



• Evitar los errores en los datos



• Evitar los pasos adicionales
• Mantener la Sencillez del Proceso



Control de la Calidad de Entrada:



Existen varias razones por las cuales un buen diseñador debe controlar la
cantidad de datos en la entrada:



- Las Operaciones de preparación y entrada dependen de las personas
dado que los costos de mano de obra son altos y la preparación de ingreso
de los datos también lo son.



-
La fase de entrada puede ser un proceso lento que toma mucho más
tiempo que el que necesitan las computadoras para realizar sus tareas.




Evitar los Retrasos:



También conocido con el nombre de cuello de botella son siempre uno de
los objetivos que el analista evita al diseñar la entrada, una forma de
evitarle es utilizar los documentos de retorno.




Evitar los errores en los datos:



La tasa de errores depende de la cantidad de datos, ya que entre más
pequeña sea esta menores serán las oportunidades para cometer errores.
Es común encontrar en las operaciones de ventas por lo menos un 3% de
errores en las operaciones de entrada de datos.
Evitar los Pasos Adicionales:



Algunas veces el volumen de transacciones y la cantidad de datos en
preparación es algo que no se puede controlar por ello el analista
experimentado, evitara diseños para la entrada que traigan una mayor
cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se
alimenta   un   proceso     muchas   veces   al   transcurso   de   un   día.


Mantener la sencillez del Proceso:



El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al
mismo tiempo proporcionarán métodos para el control de los errores, la
simplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajo
que los usuarios acepten sistemas complejos o confusos y que no exista
ninguna garantía para el éxito al instalar un sistema complejo y que
domine.



Captura de Datos para la Entrada:



En una transacción existen datos importantes y otros que no, el analista
debe saber cuáles utilizará y cuales en realidad deben formar la entrada.
Existen dos tipos de datos:



• Datos variables



• Datos de identificación



Datos Variables:
Son aquellos que cambian para cada transacción o toman de decisión.
Datos de Identificación:



Estos son los que identifican en forma única el artículo que esta siendo
procesado.


* Requerimientos De Salida *




Niveles de diseño



El diseño de sistema se representa a través de dos fases: el diseño lógico y
el diseño físico.



Cuando      los     analistas   formulan    un    diseño    lógico;    escriben    las
especificaciones detalladas del nuevo sistema; esto es, describen sus
características: las salidas, entradas, archivos y bases de datos y
procedimientos; todos de manera que cubran los requerimientos del
proyecto.
El diseño lógico de un sistema de información es como el plano de un
ingeniero    para       armar   un   automóvil:     muestra    las     características
principales(motor, transmisión y área para los pasajeros)y como se
relacionan unas con otras(donde se conectan entre sí los componentes del
sistema,     o    por     ejemplo,   cuan       separadas     están    las   puertas.
Los informes y la producción del analista son los componentes de todo el
mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y
entonces          se       produce         un       sistema          que      trabaje.
El diseño lógico también especifica las formas de entrada y las
descripciones de las pantallas de todas las transacciones y archivos a fin
de mantener los datos de inventario, los detalles de las transacciones y los
datos del proveedor. Las especificaciones de los procedimientos describen
métodos para introducir los datos, corridas de informes copiados de
archivos y detección de problemas.



El diseño físico, actividad que sigue el diseño lógico, produce programas de
software, archivos y un sistema en marcha, las especificaciones del diseño
indican    a    los   programadores   que     debe   hacer   el   sistema.   Los
programadores a su vez escriben los programas que aceptan entradas por
parte de los usuarios, procesan los datos, producen los informes y
almacenan estos datos en los archivos.



Utilización de los Datos de Requerimientos:



El alcance del diseño de sistemas se guía por el marco de referencia para
el nuevo sistema desarrollado durante el análisis. Los datos de los
requerimientos, recopilados durante la investigación, conforman las
actividades y componentes del sistema. Los analistas formulan un diseño
lógico que apoya los procesos y decisiones, los contenidos del sistema
pueden         cambiar    como    resultado     de     un     nuevo     diseño.
El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de
requerimientos.
En primer lugar se identifican las características generales, como informes
y entradas; en el diseño de la salida por ejemplo, los analistas deben
conocer la longitud de campo de un dato específico para establecer cuanto
espacio dejar en la información, en la pantalla de despliegue visual o
archivo.
A lo largo de los años hemos visto una evolución de ideas y técnicas en el
campo del análisis de sistemas. La cual cabe en tres períodos amplios
según Yourdon:



1. El análisis de sistema convencional, anterior a los años 70´s,
caracterizado por especificaciones tipo novela victoriana que eran difíciles
de leer y entender, y casi imposibles de mantener.



2. El análisis estructurado clásico, de mediados de los años 70´s, a
mediados de los años 80´s. Esto se caracterizó por primeras versiones de
modelos gráficos, y énfasis en el modelado de las implementaciones
actuales de un sistema antes de modelar el nuevo.



3. El análisis estructurado moderno, en el cual se introducen mejoras sobre
todo para modelar sistemas de tiempo real y relaciones de situaciones
complejas. Aumentando por ende la comunicación entre el analista y el
sistema.
En la actualidad las técnicas modernas están siendo fusionadas, para así
lograr un mejor método que pueda hacerle frente a las necesidades de las
diferentes fases del ciclo de vida del sistema, incluyendo a la fase de
análisis. Obteniendo de está manera mejores resultados que pueda
interpretar el analista en forma rápida y precisa.



En primera instancia debemos decir que el análisis estructurado según
Senn "permite al analista conocer un sistema o proceso (actividad) en una
forma lógica y manejable al mismo tiempo que proporciona la base para
asegurar que no se omite ningún detalle pertinente". El objetivo que
persigue el análisis estructurado es organizar las tareas asociadas con la
determinación de requerimientos para obtener la comprensión completa y
exacta de una situación dada. Se puede decir adicionalmente que los
componentes del análisis estructurado son los siguientes: símbolos
gráficos,   diccionarios   de    datos,   descripciones   de   procesos   y
procedimientos, reglas.



Después de relacionarnos brevemente con la terminología básica,
podemos entrar en aspectos relacionados con los cambios del análisis
estructurado.
Podemos decir que para finales de los años 60´s e inicios de los 70´s el
análisis estructurado surge de la necesidad de buscar una forma
interpretativa más rápida y eficiente, de tal manera que se pudiesen definir
los requerimientos del usuario y las especificaciones funcionales del
sistema. Pero esto no se daba porque lo que existía eran grandes
volúmenes de información que había que leer por completo y que
acarreaban una serie de problemas de: monolitismo, redundancia,
ambigüedad e imposibilidad de mantener. Es por ello que surge una amplia
variedad de diagramas que permiten representar las especificaciones
funcionales en forma sencilla y rápida, aumentando por ende el grado de
comunicación entre las especificaciones funcionales y el usuario final
(analista, programador, diseñador).



Posteriormente, a mediados de los años 70´s estando el análisis
estructurado clásico en su apogeo aparecen una serie de dificultades que
limitan al analista hacer un buen desempeño de sus actividades. Entre
estos problemas según Yourdon podemos mencionar:



• Distinción difusa y poca, definida entre los modelos lógicos y los modelos
físicos.
• Limitación para modelar sistemas en tiempo real.



• El modelo de datos se hacía de una manera primitiva.




Estas y otras razones dieron nacimiento a ciertas mejoras en el análisis
estructurado clásico tales como: diagramas de entidad-relación, diagramas
de transición de estados, división de eventos, modelos esenciales y
modelos de implantación. Pero a pesar de esto según Yourdon se siguieron
dando más problemas como los siguientes:
• Tras la segunda y tercera correcciones de un diagrama, el analista se
volvía cada vez más apuesto y renuente a hacer más cambios.
• Debido a la cantidad de trabajo requerido, el analista dejaba a veces de
dividir el modelo del sistema en modelos de menor nivel, quedando por
ende, funciones primitivas.



• A menudo no se incorporaban en el modelo del sistema los cambios en
los requerimientos del usuario sino hasta después de la fase de análisis del
proyecto.
Inclusive las correcciones de los diagramas había que hacerlas en forma
manual, para asegurar que fuesen consistentes y estuviesen completas; lo
cual era bastante tedioso y dejaba por fuera muchos errores que debían de
encontrarse. Pero para mediados de los 80´s aparecieron las herramientas
CASE que trataron de subsanar estos problemas. Las herramientas CASE
(Ingeniería de software auxiliada por computadora) se utilizan para dibujar
diagramas de flujo de datos y otros además de llevar a cabo una variedad
de labores de revisión de errores.



Finalmente, algunos usuarios tenían dificultades al tratar con los modelos
gráficos del análisis estructurado y preferían alguna otra forma de modelar
los requerimientos y comportamiento del sistema; es por ello que aparecen
las herramientas de generación de prototipos (mediados de los 80´s) que
son considerados como una alternativa al análisis estructurado para tales
usuarios. También se utiliza para recordar en forma breve y precisa lo que
se ha hecho a lo largo de todo el desarrollo del sistema, para no perder la
secuencia de lo que se está realizando.



En la actualidad muchas de estas herramientas se están utilizando para
facilitar la fase de análisis, e inclusive se están elaborando o fusionando lo
mejor de cada una de las técnicas que atienden las necesidades de todas
las fases del ciclo de vida del sistema; para así obtener un mejor
aprovechamiento, entendimiento, y rendimiento al momento que se ponga
a correr el sistema. Disminuyendo de esta manera la serie de errores que
se cometían anteriormente, con la introducción de herramientas más
especializadas y fáciles de utilizar.



Diversos aspectos del análisis estructurado han cambiado gradualmente a
lo largo de los últimos años. Las principales áreas de cambio incluyen lo
siguiente según Yourdon:



• Cambios de terminología.



• Partición de acontecimientos.



• La desenfatización del modelado físico actual.



• Herramientas de modelado en tiempo real.



• Integración más cercana del modelado de procesos y datos.



En un futuro no muy lejano se piensa que se darán, si es que ya no se
están dando, los siguientes cambios o pautas en el ámbito total en lo que
se refiere a análisis según Yourdon:



• Mayor difusión del análisis de sistemas, sobre todo en los siguientes
grupos: los niveles superiores de administración en organizaciones
gubernamentales y de negocios, los niños, y profesionales de la
computación en los países del tercer mundo.



• Impacto sobre la industria de software del tercer mundo.
• Proliferación de las herramientas automatizadas, aunque no todos los
analistas tienen acceso a las últimas herramientas de análisis.



• Impacto de los desastres de mantenimiento.



• Integración del análisis estructurado con la inteligencia artificial.



Podemos adicionar que el futuro del análisis estructurado va a depender
mucho también de que tan rápido pueda ajustarse el mismo a los cambios
tecnológicos que se viven hoy en día. Debido a que han estado surgiendo
otras técnicas en otras áreas como lo es la orientada a objetos, la cual
prevé un buen futuro y muchas mejoras para los sistemas actuales.




* DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE*




Fue la aparición del diseño y la programación estructurada alrededor de los
años 60´s la que dieron cabida al surgimiento del análisis estructurado, ya
que existía la necesidad de utilizar una notación gráfica para representar
los datos y los procesos que los transforman". Es por ello que surgen una
serie de temas afines tales como: herramientas automatizadas (CASE),
prototipos, diagramas de entidad-relación etc.



Índice de Términos relacionados: CASE (Ingeniería de Software auxiliada
por   computadora),      elaboración    de    prototipos,   símbolos      gráficos,
diccionarios de datos, descripciones de procesos y procedimientos, reglas,
diagramas de estados, diagramas de entidad-relación, diagramas de
transición de eventos, división de eventos, modelos esenciales y modelos
de implantación.
* Métodos de Análisis Orientados al Flujo de Datos *




La información se transforma como un flujo a través de un sistema basado
en computadora. El sistema acepta entrada de distintas formas; aplica un
hardware, software y elementos humanos para transformar la entrada en
salida; y produce una salida en distintas formas. La entrada puede ser una
señal de control transmitida por un transductor, una serie de números
escritos por un operador humano, un paquete de información transmitido
por un enlace a red, o un voluminoso archivo de datos almacenado en
memoria secundaria. La transformación puede comprender una sencilla
comparación lógica, un complejo algoritmo numérico, o un método de
inferencia basado en regla de un sistema experto. La salida puede
encender un sencillo led o producir un informe de 200 páginas. En efecto,
un modelo de flujo de datos puede aplicarse a cualquier sistema basado en
computadora independientemente del tamaño o complejidad.




La función global del sistema se representa como una transformación
sencilla de la información, representada en la figura como una burbuja. Una
o más entradas. Representadas como flechas con etiqueta, conducen la
transformación para producir la información de salida. Puede observarse
que el modelo puede aplicarse a todo el sistema o solo a un elemento de
software. La clave es representar la información dada y producida por la
transformación.


* Diagramas de Flujos de Datos *




Conforme con la información se mueve a través del software, se modifica
mediante una serie de transformaciones. Un diagrama de flujos de datos
(DFD), es una técnica grafica que describe el flujo de información y las
transformaciones que se aplican a los datos, conforme se mueven de la
entrada a la salida. El diagrama es similar en la forma a otros diagramas de
flujo de actividades, y ha sido incorporado en técnicas de análisis y diseños
propuesto por Yourdon y Constantine, DeMarco y Gane y Sarson. También
se le conoce como un grafo de flujo de datos o un diagrama de burbujas.




* Diccionario de Datos *



Un análisis del dominio de la información puede ser incompleto si solo se
considera el flujo de datos. Cada flecha de un diagrama de flujo de datos
representa uno o más elementos de información. Por tanto, el analista debe
disponer de algún otro método para representar el contenido de cada
flecha de un DFD.



Se ha propuesto el diccionario de datos como una gramática casi formal
para describir el contenido de los elementos de información y ha sido
definido da la siguiente forma:

El diccionario de datos contiene las definiciones de todos los datos
mencionados en el DFD, en una especificación del proceso y en el propio
diccionario de datos. Los datos compuestos (datos que pueden ser además
divididos) se definen en términos de sus componentes; los datos
elementales (datos que no pueden ser divididos) se definen en términos del
significado de cada uno de los valores que puede asumir. Por tanto, el
diccionario de datos esta compuesto de definiciones de flujo de datos,
archivos   [datos   almacenados]    y   datos   usados   en   los   procesos
[transformaciones]...


* Descripciones Funcionales *
Una vez que ha sido representado el dominio de la información (usando un
DFD y un diccionario de datos), el analista describe cada función
(transformación) representada, usando el lenguaje natural o alguna otra
notación estilizada. Una de tales notaciones se llama ingles estructurado
(también llamado lenguaje de diseño del programa o proceso (LDP)). El
inglés estructurado incorpora construcciones procedimentales básicas –
secuencia, selección y repetición- junto con frases del lenguaje natural, de
forma que pueden desarrollarse descripciones procedimentales precisas de
las funciones representadas dentro de un DFD.



* Métodos Orientados a la Estructura de Datos *



Hemos ya observado que el dominio de la información para un problema de
software comprende el flujo de datos, el contenido de datos y la estructura
de datos. Los métodos de análisis orientados a la estructura de datos
representan los requerimientos del software enfocándose hacia la
estructura de datos en vez de al flujo de datos. Aunque cada método
orientado a la estructura de datos tiene un enfoque y notación distinta,
todos tienen algunas características en común: 1) todos asisten al analista
en la identificación de los objetos de información clave (también llamados
entidades o ítems) y operaciones (también llamadas acciones o procesos);
2)todos suponen que la estructura de la información es jerárquica; 3)todos
requiere que la estructura de datos se represente usando la secuencia,
selección y repetición; y 4) todos dan una conjunto de pasos para
transformar una estructura de datos jerárquica en una estructura de
programa.
Como los métodos orientados al flujo de datos, los métodos de análisis
orientados a la estructura de datos proporcionan la base para el diseño de
software. Siempre puede extenderse un método de análisis para que
abarque el diseño arquitectural y procedimental del software.
BIBLIOGRAFÍA




Senn, James A. "Análisis y Diseño de Sistemas de Información". Segunda
Edición. McGraw Hill. 1992.




JAMES A SENN, Análisis y Diseño de Sistema de Información, Mc Graw Hill,
Enero 1990




JAMES A. SENN, Análisis y Diseño de Sistemas de Información, Segunda
Edición, Mc Graw Hill, Abril 2000.




IEEE Task Force on Requirements Engineering. Software Engineering
Resources         by       Roger     S.      Pressman         &      Associates
Edward - Yourdon (1993) - Análisis Estructurado Moderno, Prentice Hall
Hispanoamericana, S. A., pp. 136-147, 500-511.



Roger - S. P. (1993) - Ingeniería del Software, Mc. Graw-Hill, pp. 217-218, 247.



Pressman, R.S., "Ingeniería del Software. Un enfoque práctico.", McGraw-Hill.



Larman, C. "UML y patrones: Introducción al análisis y diseño orientado a
objetos". Prentice halll

Más contenido relacionado

La actualidad más candente

Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftChuyito Alvarado
 
Conceptos Unidad 1 Lenguajes Automatas Introducción a la Teoría de Lenguaje...
Conceptos Unidad 1 Lenguajes Automatas Introducción  a  la Teoría de Lenguaje...Conceptos Unidad 1 Lenguajes Automatas Introducción  a  la Teoría de Lenguaje...
Conceptos Unidad 1 Lenguajes Automatas Introducción a la Teoría de Lenguaje...Hugo Alberto Rivera Diaz
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de usoSaul Mamani
 
Requerimientos de Usabilidad
Requerimientos de  UsabilidadRequerimientos de  Usabilidad
Requerimientos de Usabilidadgcaicedo
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareNelson Guanipa
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareKelvin Abdiel Alvarado
 
Análisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAnálisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAngel Reyes
 
 Diagramas uml de sistema de cajero automático
 Diagramas uml de sistema de cajero automático Diagramas uml de sistema de cajero automático
 Diagramas uml de sistema de cajero automáticoItzel656131
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de softwareGuillermo Lemus
 
Ejemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdenciesEjemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdenciesMICProductivity
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareAdes27
 

La actualidad más candente (20)

Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Estimación de Proyectos de Software
Estimación de Proyectos de SoftwareEstimación de Proyectos de Software
Estimación de Proyectos de Software
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Conceptos Unidad 1 Lenguajes Automatas Introducción a la Teoría de Lenguaje...
Conceptos Unidad 1 Lenguajes Automatas Introducción  a  la Teoría de Lenguaje...Conceptos Unidad 1 Lenguajes Automatas Introducción  a  la Teoría de Lenguaje...
Conceptos Unidad 1 Lenguajes Automatas Introducción a la Teoría de Lenguaje...
 
2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso2. Casos de uso y diagramas de casos de uso
2. Casos de uso y diagramas de casos de uso
 
Requerimientos de Usabilidad
Requerimientos de  UsabilidadRequerimientos de  Usabilidad
Requerimientos de Usabilidad
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de Software
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de Software
 
HA2NV50 EQ8-StarUML
HA2NV50 EQ8-StarUMLHA2NV50 EQ8-StarUML
HA2NV50 EQ8-StarUML
 
Análisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de softwareAnálisis de riesgos de un proyecto de software
Análisis de riesgos de un proyecto de software
 
Roles desarrollo del software
Roles desarrollo del softwareRoles desarrollo del software
Roles desarrollo del software
 
 Diagramas uml de sistema de cajero automático
 Diagramas uml de sistema de cajero automático Diagramas uml de sistema de cajero automático
 Diagramas uml de sistema de cajero automático
 
Tipos de pruebas de software
Tipos de pruebas de softwareTipos de pruebas de software
Tipos de pruebas de software
 
Plan de desarrollo software
Plan de desarrollo softwarePlan de desarrollo software
Plan de desarrollo software
 
Calidad de software
Calidad de softwareCalidad de software
Calidad de software
 
Ejemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdenciesEjemplos práctios de calidad en el software tecdencies
Ejemplos práctios de calidad en el software tecdencies
 
Fases del rup
Fases del rupFases del rup
Fases del rup
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 

Similar a 2. requerimientos del software

Analisis de requerimientos luis castellan0 s
Analisis de requerimientos luis castellan0 sAnalisis de requerimientos luis castellan0 s
Analisis de requerimientos luis castellan0 sCiro Polanco
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASAlcoverify
 
Unidad I Requerimientos
Unidad I RequerimientosUnidad I Requerimientos
Unidad I Requerimientosguest409adc
 
Análisis de requerimientos
Análisis de requerimientosAnálisis de requerimientos
Análisis de requerimientosGustavo Araque
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitosSergio Ramos
 
Ing de req
Ing de reqIng de req
Ing de reqwhymber
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosmezcalote
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientosTensor
 
Importancia del Análisis de Requerimientos
Importancia del Análisis de RequerimientosImportancia del Análisis de Requerimientos
Importancia del Análisis de Requerimientospedro tovar
 
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfNinoskaChuraLlojlla1
 

Similar a 2. requerimientos del software (20)

Analisis de requerimientos luis castellan0 s
Analisis de requerimientos luis castellan0 sAnalisis de requerimientos luis castellan0 s
Analisis de requerimientos luis castellan0 s
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
 
Unidad I Requerimientos
Unidad I RequerimientosUnidad I Requerimientos
Unidad I Requerimientos
 
Análisis de requerimientos
Análisis de requerimientosAnálisis de requerimientos
Análisis de requerimientos
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 
REQUI
REQUIREQUI
REQUI
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitos
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
 
Sistemas requerimientos
Sistemas requerimientosSistemas requerimientos
Sistemas requerimientos
 
Ing de req
Ing de reqIng de req
Ing de req
 
Ingenieria de Requerimientos
Ingenieria de RequerimientosIngenieria de Requerimientos
Ingenieria de Requerimientos
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
REQUISITOS
REQUISITOSREQUISITOS
REQUISITOS
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientos
 
Requerimiento
RequerimientoRequerimiento
Requerimiento
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
Importancia del Análisis de Requerimientos
Importancia del Análisis de RequerimientosImportancia del Análisis de Requerimientos
Importancia del Análisis de Requerimientos
 
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
 
Proyecto
ProyectoProyecto
Proyecto
 

Más de univ of pamplona

Exposicion unidad 1 ing software
Exposicion unidad 1 ing softwareExposicion unidad 1 ing software
Exposicion unidad 1 ing softwareuniv of pamplona
 
2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidad2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidaduniv of pamplona
 
1. modelo entidad relacion ejemplo
1. modelo entidad relacion   ejemplo1. modelo entidad relacion   ejemplo
1. modelo entidad relacion ejemplouniv of pamplona
 
Arquitectura de una aplicación
Arquitectura de una aplicaciónArquitectura de una aplicación
Arquitectura de una aplicaciónuniv of pamplona
 
Ejemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con accessEjemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con accessuniv of pamplona
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_softwareuniv of pamplona
 
1 lectura inicial - que es ingenieria de software
1  lectura inicial - que es ingenieria de software1  lectura inicial - que es ingenieria de software
1 lectura inicial - que es ingenieria de softwareuniv of pamplona
 

Más de univ of pamplona (14)

Entidad relacion
Entidad relacionEntidad relacion
Entidad relacion
 
Exposicion unidad 1 ing software
Exposicion unidad 1 ing softwareExposicion unidad 1 ing software
Exposicion unidad 1 ing software
 
2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidad2. presentacion acis calidad software basado en normas calidad
2. presentacion acis calidad software basado en normas calidad
 
1. modelo entidad relacion ejemplo
1. modelo entidad relacion   ejemplo1. modelo entidad relacion   ejemplo
1. modelo entidad relacion ejemplo
 
Arquitectura de una aplicación
Arquitectura de una aplicaciónArquitectura de una aplicación
Arquitectura de una aplicación
 
Ejemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con accessEjemplo arquitectura 3 capas con access
Ejemplo arquitectura 3 capas con access
 
Arquitectura multicapa
Arquitectura multicapaArquitectura multicapa
Arquitectura multicapa
 
4 ppt tema1
4 ppt tema14 ppt tema1
4 ppt tema1
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software
 
1. curso unal cap1
1. curso unal cap11. curso unal cap1
1. curso unal cap1
 
1 lectura inicial - que es ingenieria de software
1  lectura inicial - que es ingenieria de software1  lectura inicial - que es ingenieria de software
1 lectura inicial - que es ingenieria de software
 
Espe tecnicas siia_2
Espe tecnicas siia_2Espe tecnicas siia_2
Espe tecnicas siia_2
 
Entrevistas
EntrevistasEntrevistas
Entrevistas
 
1. curso unal cap1
1. curso unal cap11. curso unal cap1
1. curso unal cap1
 

2. requerimientos del software

  • 1. REQUERIMIENTOS DEL SOFTWARE INDICE INTRODUCCION REQUERIMIENTOS DEL SOFTWARE CARACTERÍSTICAS DE LOS REQUERIMIENTOS DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS CARACTERÍSTICAS DE UN REQUERIMIENTO FUNDAMENTOS DEL ANÁLISIS DE REQUERIMIENTOS TAREAS DEL ANÁLISIS ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS) CLASIFICACIÓN DE LOS REQUERIMIENTOS ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS PRINCIPIOS DE ESPECIFICACIÓN MANEJO DE REQUERIMIENTOS ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO REQUERIMIENTOS DEL SISTEMA ESTRATEGIA DEL FLUJO DE DATOS ESTRATEGIA DEL ANÁLISIS DE DECISIONES ETAPAS EN LA ESTRATEGIA DEL ANÁLISIS DEL FLUJO DE DATOS UTILIZACIÓN DE LOS DATOS DE REQUERIMIENTOS DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE MÉTODOS DE ANÁLISIS ORIENTADOS AL FLUJO DE DATOS DIAGRAMAS DE FLUJOS DE DATOS DICCIONARIO DE DATOS DESCRIPCIONES FUNCIONALES MÉTODOS ORIENTADOS A LA ESTRUCTURA DE DATOS BIBLIOGRAFÍA ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE INTRODUCCION ¿Qué son Requerimientos? Normalmente, un tema de la Ingeniería de Software tiene diferentes
  • 2. significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE: (1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2). Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. 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. Los requerimientos no funcionales 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 Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes. Necesario: Un requerimiento es necesario si su omisión provoca una
  • 3. 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. * Dificultades para definir los requerimientos * • Los requerimientos no son obvios y vienen de muchas fuentes. • Son difíciles de expresar en palabras (el lenguaje es ambiguo). • Existen muchos tipos de requerimientos y diferentes niveles de detalle. • La cantidad de requerimientos en un proyecto puede ser difícil de manejar. • Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros. • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. • Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas. • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. • Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
  • 4. * Ingeniería de Requerimientos vs. Administración de Requerimientos * El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa. Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, es ellos se basan muchos participantes del proyecto para: Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto usan los requerimientos como una base para la estimación del esfuerzo necesario en un proyecto. Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por ejemplo: cuando se está tratando de alinearse a cierta norma oficial o estándar. Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no. Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la documentación del sistema De ahí su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible. Características de un requerimiento Ya que visualizamos la importancia de los requerimientos en un sistema de software entonces debemos de definir que características deben de poseer los requerimientos adecuadamente formulados. Los requerimientos deben ser: Especificados por escrito. Como todo contrato o acuerdo entre dos partes Posibles de probar o verificar. Si un requerimiento no se puede comprobar,
  • 5. entonces ¿cómo sabemos si cumplimos con él o no? Descritos como una característica del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no como debe de hacerlo) Lo más abstracto y conciso posible. Para evitar malas interpretaciones. * Fundamentos del Análisis de Requerimientos * Definición: Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software. Es la etapa más crucial del desarrollo de un proyecto de software. La IEEE los divide en funcionales y no funcionales: Funcionales: Condición o capacidad de un sistema requerida por el usuario para resolver un problema o alcanzar un objetivo. No Funcionales: Condición o capacidad que debe poseer un sistema para satisfacer un contrato, un estándar, una especificación u otro documento formalmente impuesto. Para realizar bien el desarrollo de software es esencial realizar una especificación completa de los requerimientos de los mismos. Independientemente de lo bien diseñado o codificado que esté, un programa pobremente especificado decepcionará al usuario y hará fracasar el desarrollo. La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento, El ámbito del programa, establecido inicialmente durante la ingeniería del sistema, es refinado en detalle. Se analizan y asignan a los distintos elementos de los programas las soluciones alternativas.
  • 6. Tanto el que desarrolla el software como el cliente tienen un papel activo en la especificación de requerimientos. El cliente intenta reformular su concepto, algo nebuloso, de la función y comportamiento de los programas en detalles concretos, El que desarrolla el software actúa como interrogador, consultor y el que resuelve los problemas. El análisis y especificación de requerimientos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. Puesto que el contenido de comunicación es muy alto, abundan los cambios por mala interpretación o falta de información. El dilema con el que se enfrenta un ingeniero de software puede ser comprendido repitiendo la sentencia de un cliente anónimo: "Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que lo que creíste oír sea lo que yo quise decir". Los requerimientos de un sistema de software, cuando se ven en su conjunto son extensos y detallados, y además contienen múltiples relaciones entre sí. Lo que nos da a concluir, que el conjunto de requerimientos de un sistema computacional es complejo. Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos. El análisis de requerimientos es la tarea que plantea la asignación de software a nivel de sistema y el diseño de programas. El análisis de requerimientos facilita al ingeniero de sistemas especificar: la función y comportamiento de los programas, indicar la interfaz con otros elementos del sistema y establecer las ligaduras de diseño que debe cumplir el programa. El análisis de requerimientos permite al ingeniero:
  • 7. refinar la asignación de software y representar el dominio de la información que será tratada por el programa. El análisis de requerimientos da al diseñador: la representación de la información y las funciones que pueden ser traducidas en datos, arquitectura y diseño procedimental. Finalmente, la especificación de requerimientos suministra al técnico y al cliente: los medios para valorar la calidad de los programas, una vez que se haya construido. * Tareas del Análisis * El análisis de requerimientos puede dividirse en cuatro áreas: 1.- Reconocimiento del problema 2.- Evaluación y síntesis 3.- Especificación 4.- Revisión. Inicialmente, el analista estudia la especificación del sistema (si existe) y el plan de proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los programas que se usó para generar las estimaciones de la planificación. A continuación, debe establecerse la comunicación necesaria para el análisis, de forma que se asegure el reconocimiento del problema. El analista debe establecer contacto con el equipo técnico y de gestión del
  • 8. usuario / cliente y con la empresa que vaya a desarrollar el software. El gestor del programa puede servir como coordinador para facilitar el establecimiento de los caminos de comunicación. El objetivo del analista es reconocer los elementos básicos del programa tal como lo percibe el usuario / cliente. La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del análisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todas las funciones del programa, establecer las características de la interfase del sistema y descubrir las ligaduras del diseño, Cada una de las tareas sirven para descubrir el problema de forma que pueda sintetizarse un enfoque o solución global. Las tareas asociadas con el análisis y especificación existen para dar una representación del programa que pueda ser revisada y aprobada por el cliente. En un mundo ideal el cliente desarrolla una especificación de requerimientos del software completamente por sí mismo. Esto se presenta raramente en el mundo real. En el mejor de los casos, la especificación se desarrolla conjuntamente entre el cliente y el técnico. Una vez que se hayan descrito las funcionalidades básicas, comportamiento, interfase e información, se especifican los criterios de validación para demostrar una comprensión de una correcta implementación de los programas. Estos criterios sirven como base para hacer una prueba durante el desarrollo de los programas. Para definir las características y atributos del software se escribe una especificación de requerimientos formal. Además, para los casos en los que se desarrolle un prototipo se realiza un manual de usuario preliminar. Puede parecer innecesario realizar un manual de usuario en una etapa tan temprana del proceso de desarrollo, Pero de hecho, este borrador del manual de usuario fuerza al analista a tomar el punto de vista del usuario
  • 9. del software. El manual permite al usuario / cliente revisar el software desde una perspectiva de ingeniería humana y frecuentemente produce el comentario: "La idea es correcta pero esta no es la forma en que pensé que se podría hacer esto". Es mejor descubrir tales comentarios lo más tempranamente posible en el proceso. Los documentos del análisis de requerimiento (especificación y manual de usuario) sirven como base para una revisión conducida por el cliente y el técnico. La revisión de los requerimientos casi siempre produce modificaciones en la función, comportamiento, representación de la información, ligaduras o criterios de validación. Además, se realiza una nueva apreciación del plan del proyecto de software para determinar si las primeras estimaciones siguen siendo validas después del conocimiento adicional obtenido durante el análisis. * Obteniendo de la información * Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente. Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que para recabarlos haya que obtener la información de primera mano. Esto es, mediante entrevistas con el cliente o recabando documentación que describa la manera que el cliente desea que funcione el sistema de software. Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentación original del cliente, así como cada revisión o cambio que se haga a esta documentación. Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas
  • 10. necesidades para saber cuáles de ellas serán satisfechas por el software y cuales por algún otro producto del sistema. * Especificación de Requisitos de Software *(SRS) La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en cómo hará sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores. Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolución del sistema. La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente. Las
  • 11. características de la SRS son verificadas en la actividad de Validación, descrita en el punto. La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados, además de asegurar que se cubren todos los tópicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. Clasificación de los requerimientos El clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus características no pueden ser tratados iguales. La siguiente es una recomendación de como pueden ser clasificados los requerimientos aunque cada proyecto de software pueda usar sus propias clasificaciones. • Requerimientos del "entorno" El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto tipo de requerimientos que se clasifican en esta categoría porque: El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione. Ejemplos del entorno podemos mencionar: sistemas operativos, sistema de archivos, bases de datos. El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno, tales como congestión en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de considerar dentro de los requerimientos.
  • 12. • Requerimientos ergonómicos" Él más conocido de los requerimientos ergonómicos es la interfase con el usuario o GUI (Graphic User Interface). En otras palabras, los requerimientos ergonómicos son la forma en que el ser humano interactúa con el ser sistema. • Requerimientos de Interfase La interfase es como interactúa el sistema con el ser humano o con otros sistemas (el enfoque es prácticamente el opuesto a los requerimientos ergonómicos), La interfase es la especificación formal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica el protocolo, el tipo de información, el medio para comunicarse y el formato de los datos que se van a comunicar. * Actividades de la Ingeniería de Requerimientos * En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado. Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en número como en nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso. A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son:
  • 13. • Análisis del Problema • Evaluación y Negociación • Especificación • Validación • Evolución * Principios de Especificación * La especificación, independientemente del modo en que se realice, puede ser vista como un proceso de representación. Los requerimientos se representan de forma que conduzcan finalmente a una correcta implementación del software. Baltzer y Goldman proponen ocho principios para una buena especificación: PRINCIPIO #1. Separar funcionalidad de implementación. Una especificación es una descripción de lo que se desea, en vez de cómo se realiza (implementa). Las especificaciones pueden adoptar dos formas muy diferentes. La primera forma es la de funciones matemáticas: dado algún conjunto de entrada, producir un conjunto particular de salida. La forma general de tales especificaciones es encontrar [un/el/todos] resultado tal que P (entrada), donde P representa un predicado arbitrario. En tales especificaciones, el resultado a ser obtenido ha sido expresado enteramente en una forma sobre el que (en vez de cómo). En parte, esto es debido a que el resultado es una función matemática de la entrada (la
  • 14. operación tiene puntos de comienzo y parada bien definidos) y no está afectado por el entorno que le rodea. PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas orientado al proceso. Considerar una situación en la que el entorno sea dinámico y sus cambios afecten al comportamiento de alguna entidad que interactúe con dicho entorno. Su comportamiento no puede ser expresado como una función matemática de su entrada. En vez de ello, debe emplearse una descripción orientada al proceso, en la cual la especificación del que se consigue mediante la especificación de un modelo del comportamiento deseado en términos de respuestas funcionales, a distintos estímulos del entorno. PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el software es una componente. Un sistema está compuesto de componentes que interactúan. Solo dentro del contexto del sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de una componente específica. En general, un sistema puede ser modelado como una colección de objetos pasivos y activos. Estos objetos están interrelacionados y dichas relaciones entre los objetos cambian con el tiempo. Estas relaciones dinámicas suministran los estímulos a los cuales los objetos activos, llamados agentes, responden. Las respuestas pueden causar posteriormente cambios y, por tanto, estímulos adicionales a los cuales los agentes deben responder. PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el sistema opera.
  • 15. Similarmente, el entorno en el que opera el sistema y con el que interactúa debe ser especificado. Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un sistema compuesto de objetos que interactúan, pasivos y activos, de los cuales el sistema especificado es una agente, Los otros agentes, los cuales son por definición inalterables debido a que son parte del entorno, limitan el ámbito del diseño subsecuente y de la implementación. De hecho, la única diferencia entre el sistema y su entorno es que el esfuerzo de diseño e implementación subsecuente opera exclusivamente sobre la especificación del sistema. La especificación del entorno facilita que se especifique la interfaz del sistema de la misma forma que el propio sistema, en vez de introducir otro formalismo. PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo. La especificación de un sistema debe ser un modelo cognitivo, en vez de un modelo de diseño o implementación. Debe describir un sistema tal como es percibido por su comunidad de usuario. Los objetivos que manipula deben corresponderse con objetos reales de dicho dominio; los agentes deben modelar los individuos, organizaciones y equipo de ese dominio; y las acciones que ejecutan deben modelar lo que realmente ocurre en el dominio. Además, debe ser posible incorporar en la especificación las reglas o leyes que gobiernan los objetos del dominio. Algunas de estas leyes proscriben ciertos estados del sistema (tal como "dos objetos no pueden estar en el mismo lugar al mismo tiempo"), y por tanto limitan el comportamiento de los agentes o indican la necesidad de una posterior elaboración para prevenir que surjan estos estados. PRINCIPIO #6. Una especificación debe ser operacional.
  • 16. La especificación debe ser completa y lo bastante formal para que pueda usarse para determinar si una implementación propuesta satisface la especificación de pruebas elegidas arbitrariamente. Esto es, dado el resultado de una implementación sobre algún conjunto arbitrario de datos elegibles, debe ser posible usar la especificación para validar estos resultados. Esto implica que la especificación, aunque no sea una especificación completa del como, pueda actuar como un generador de posibles comportamientos, entre los que debe estar la implementación propuesta. Por tanto, en un sentido extenso, la especificación debe ser operacional. PRINCIPIO #7. La especificación del sistema debe ser tolerante con la incompletitud y aumentable. Ninguna especificación puede ser siempre totalmente completa. El entorno en el que existe es demasiado complejo para ello. Una especificación es siempre un modelo, una abstracción, de alguna situación real (o imaginada). Por tanto, será incompleta. Además, al ser formulad existirán muchos niveles de detalle. La operacionalidad requerida anteriormente no necesita ser completa. Las herramientas de análisis empleadas para ayudar a los especificadores y para probar las especificaciones, deben ser capaces de tratar con la incompletitud. Naturalmente esto debilita el análisis, el cual puede ser ejecutado ampliando el rango de comportamiento aceptables, los cuales satisfacen la especificación, pero tal degradación debe reflejar los restantes niveles de incertidumbre. PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada. Los principios anteriores tratan con la especificación como una entidad estática. Esta surge de la dinámica de la especificación. Debe ser reconocido que aunque el principal propósito de una especificación sea servir como base para el diseño e implementación de algún sistema, no es un objeto estático precompuesto, sino un objeto dinámico que sufre considerables modificaciones. Tales modificaciones se presentan en tres actividades principales: formulación, cuando se está creando una
  • 17. especificación inicial; desarrollo, cuando la especificación se esta elaborando durante el proceso iterativo de diseño e implementación; y mantenimiento, cuando la especificación se cambia para reflejar un entorno modificado y / o requerimientos funcionales adicionales. • Requerimientos funcionales Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa él ¿Qué? Y no él ¿Cómo?. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lógica y gran parte del código del sistema. • Requerimientos de desempeño Estos requerimientos nos informan las características de desempeño que deben de tener el sistema. ¿Qué tan rápido?, ¿Que tan seguido?, ¿Cuántos recursos?, ¿Cuantas transacciones? Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeño de un sistema es tan crítico como su funcionamiento. • Disponibilidad (en un determinado periodo de tiempo) Este tipo de requerimientos se refiere a la durabilidad, degradación, potabilidad, flexibilidad, contabilidad y capacidad de actualización. Este tipo de requerimientos es también muy importante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones críticas que no deben de estar fuera de servicio por periodos prolongados de tiempo.
  • 18. • Entrenamiento Este tipo de requerimientos se enfoca a las personas que van usar el sistema. ¿Qué tipo de usuarios son?, ¿Que tipo de operadores?, ¿Que manuales se entregarán y en que idioma? Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de código dentro del sistema, son muy importantes en el proceso de diseño ya que facilitan la introducción y aceptación del sistema en donde será implementado. • Restricciones de diseño Muchas veces las soluciones de un sistema de software son normadas por leyes o estándares, este tipo de normas caen como "restricciones de diseño". • Materiales Aquí se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir los costos de industrialización del sistema. * Manejo de requerimientos * De acuerdo con el "Capability Maturity Model" (CMM), el manejo de requerimientos involucra: "Establecer y mantener un acuerdo con el cliente sobre los requerimientos
  • 19. del proyecto de software. Este acuerdo son los requerimientos del sistema alojados al software." … ". Este acuerdo cubre requerimientos técnicos y no técnicos (como fechas de entrega). El acuerdo forma las bases para estimar, planear, ejecutar y monitorear el proyecto de desarrollo de software a través de todo su ciclo de vida." … "Bajo las restricciones del proyecto, el grupo de manejo de requerimientos toma las medidas necesarias para que los requerimientos que están bajo su responsabilidad estén documentados y controlados" ¿De que manera podemos controlar los requerimientos de software si estos siempre evolucionan con el tiempo?. El CMM nos proporciona las guías para lograrlo. "Para lograr el control de los requerimientos, el grupo de requerimientos revisa los requerimientos antes de que estos sean incorporados al proyecto de software y cada vez que los requerimientos cambian los planes, productos, y actividades son ajustadas para quedar en línea con los nuevos requerimientos de software". En otras palabras, para obtener el nivel que requiere el CMM en manejo de requerimientos débenos de tomar en cuenta dos cosas. • Que los requerimientos deben de ser revisados (y aprobados) por el grupo de requerimientos, y no son impuestos por en su totalidad por presiones externas ajenas al proyecto. El requerimiento técnico podrá ser impuesto por el mercado o presiones de la competencia, pero entonces los requerimientos no técnicos (Calidad, Costo y Tiempo de entrega) deberán estar especificados de común acuerdo con el grupo de requerimientos del proyecto de software. • Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si cambia uno forzosamente deberán cambiar los demás. Esto es: más contenido técnico implica o más costo, o menos calidad o más tiempo
  • 20. estimado de entrega. De modo que los cambios técnicos deberán ser aprobados por el grupo de requerimientos y este grupo estimará los impactos en tiempo, costo, calidad. El resultado de la estimación es la entrada a los líderes del proyecto para decidir si el cambio se acepta o no. * ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO * Para prosperar en el mercado, cualquier producto debe satisfacer las necesidades de los usuarios, lo cual no resulta posible si no integra y pone al alcance del consumidor de forma comprensible los fundamentos de todos los aspectos del desarrollo. Para captar las necesidades específicas de los usuarios es indispensable que los documentos que recogen los requerimientos se redacten utilizando métodos pragmáticos. Se debe utilizar una metodología detallada de definición de los requerimientos de usuario. Organizar entrevistas destinadas a obtener la máxima información posible acerca de los requerimientos de los usuarios. Traducir las oportunidades / necesidades en requerimientos del proyecto. Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear un documento de requerimientos generales. Conseguir la participación y confirmación del usuario. Los gerentes y usuarios del sistema también poseen un papel importante en le diseño del sistema; no es solamente el proyecto del analista. Durante el diseño, a algunos se les pide que revisen los borradores de los informes, que examinen los formatos de entrada y que ayuden en la escritura de los procedimientos para decirles a otras personas como utilizar el sistema en forma apropiada. La participación del usuario proporciona al analista una retroalimentación importante conforme avanza en el diseño; además asegura a los usuarios tengan un conocimiento no técnico de lo realizara o no el nuevo sistema.
  • 21. Esta visión general del diseño de sistemas subraya los aspectos de diseño que se verán mas adelante en el diseño de la salida de sistema. * REQUERIMIENTOS DEL SISTEMA * Los Sistemas de Información por computadora normalmente están integrados por muchos componentes. En la mayor parte de los casos, es difícil para los analistas entender todos estos componentes aún mismo tiempo; por lo tanto los investigadores tienen que comenzar con preguntas de tipo general con relación al propósito del sistema sus entradas y salidas de los procesos incluidos. En los grandes proyectos de sistema varios analistas llevan a cabo una investigación en forma seccionada que la distribuye entre ellos mismos, de manera que cada uno pueda trabajar en forma independiente. Existen dos estrategias ampliamente utilizadas para determinar los requerimientos de información. Se clasifican en dos tipos: 1.- Flujo de Datos. 2.- Estrategias de Análisis de Decisión para el Conocimiento para los Sistema de Información. * Estrategia del Flujo de Datos * Cuando se siguen un flujo a través de los procesos de negocio, que es el propósito del análisis del flujo de datos, le indica a los analistas una gran cantidad de datos sobre como sé esta llevando a cabo los objetivos de la compañía. Al manejar las transacciones y completar las tareas, los datos
  • 22. de entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten. El análisis de flujo de datos que muestra el estudio y el uso de cada actividad, documenta los hallazgos en los diagramas de flujo de datos. * Estrategia del Análisis de Decisiones * La estrategia del análisis de decisiones es un complemento del análisis del flujo de datos. Esta estrategia realza el estudio de los objetivos de una operación y de las decisiones que deben realizarse para cumplir con los objetivos. Las decisiones se presentan tanto en los niveles operativos como en los de alto nivel gerencial, la estrategia de análisis de decisión con frecuencia utiliza por parte de alta gerencia para desarrollar la toma de decisiones. La alternativa que selecciona los gerentes responsables en la toma de decisiones, en cuanto a una estrategia de precios entre un conjunto de alternativas, se maneja de forma diferente a la opción que toma un supervisor de departamento para aceptar o rechazar pedidos. La decisión de rechazar pedidos generalmente ocurre con más frecuencia, de manera que las condiciones y acciones normalmente se conocen como un aspecto importante. * Etapas en la Estrategia del Análisis del Flujo de Datos * 1. - Estudiar las operaciones y procesos en marcha. 2. - Identificar cómo se procesan los datos al manejar transacciones y terminar las tareas.
  • 23. 3. - Seguir el flujo de datos: * Proceso * Almacenamiento * Recuperación * Salida 4. - Añadir gradualmente detalles a los niveles inferiores. Etapas en la Estrategia del Análisis de Decisión 1. -Estudiar los objetivos y decisiones necesarias. 2. - Desarrollar un modelo del proceso de decisión. 3. - Probar el modelo con datos de prueba. 4. - Identificar los requerimientos del proceso para los datos. * Requerimientos De Entrada * Es el enlace que une al sistema de información con el mundo y sus
  • 24. usuarios, en esta existen aspectos generales que todos los analistas deben tener en cuenta estos son: • Objetivos del Diseño de Entrada. • Captura de Datos para la Entrada. Objetivo del Diseño de Entrada Consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los procesos necesarios para poner los datos de transacción en una forma utilizable para su procesamiento así como la entrada de los datos se logra al instruir a la computadora para que lea ya sea documentos escritos, impresos ó por personas que los escriben directamente al sistema. Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos, controlar los errores y mantener la sencillez de los pasos necesarios, estos son: • Control de la Calidad de Entrada • Evitar los Retrasos • Evitar los errores en los datos • Evitar los pasos adicionales
  • 25. • Mantener la Sencillez del Proceso Control de la Calidad de Entrada: Existen varias razones por las cuales un buen diseñador debe controlar la cantidad de datos en la entrada: - Las Operaciones de preparación y entrada dependen de las personas dado que los costos de mano de obra son altos y la preparación de ingreso de los datos también lo son. - La fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitan las computadoras para realizar sus tareas. Evitar los Retrasos: También conocido con el nombre de cuello de botella son siempre uno de los objetivos que el analista evita al diseñar la entrada, una forma de evitarle es utilizar los documentos de retorno. Evitar los errores en los datos: La tasa de errores depende de la cantidad de datos, ya que entre más pequeña sea esta menores serán las oportunidades para cometer errores. Es común encontrar en las operaciones de ventas por lo menos un 3% de errores en las operaciones de entrada de datos.
  • 26. Evitar los Pasos Adicionales: Algunas veces el volumen de transacciones y la cantidad de datos en preparación es algo que no se puede controlar por ello el analista experimentado, evitara diseños para la entrada que traigan una mayor cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se alimenta un proceso muchas veces al transcurso de un día. Mantener la sencillez del Proceso: El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo proporcionarán métodos para el control de los errores, la simplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajo que los usuarios acepten sistemas complejos o confusos y que no exista ninguna garantía para el éxito al instalar un sistema complejo y que domine. Captura de Datos para la Entrada: En una transacción existen datos importantes y otros que no, el analista debe saber cuáles utilizará y cuales en realidad deben formar la entrada. Existen dos tipos de datos: • Datos variables • Datos de identificación Datos Variables:
  • 27. Son aquellos que cambian para cada transacción o toman de decisión. Datos de Identificación: Estos son los que identifican en forma única el artículo que esta siendo procesado. * Requerimientos De Salida * Niveles de diseño El diseño de sistema se representa a través de dos fases: el diseño lógico y el diseño físico. Cuando los analistas formulan un diseño lógico; escriben las especificaciones detalladas del nuevo sistema; esto es, describen sus características: las salidas, entradas, archivos y bases de datos y procedimientos; todos de manera que cubran los requerimientos del proyecto. El diseño lógico de un sistema de información es como el plano de un ingeniero para armar un automóvil: muestra las características principales(motor, transmisión y área para los pasajeros)y como se relacionan unas con otras(donde se conectan entre sí los componentes del sistema, o por ejemplo, cuan separadas están las puertas. Los informes y la producción del analista son los componentes de todo el mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y entonces se produce un sistema que trabaje. El diseño lógico también especifica las formas de entrada y las descripciones de las pantallas de todas las transacciones y archivos a fin de mantener los datos de inventario, los detalles de las transacciones y los
  • 28. datos del proveedor. Las especificaciones de los procedimientos describen métodos para introducir los datos, corridas de informes copiados de archivos y detección de problemas. El diseño físico, actividad que sigue el diseño lógico, produce programas de software, archivos y un sistema en marcha, las especificaciones del diseño indican a los programadores que debe hacer el sistema. Los programadores a su vez escriben los programas que aceptan entradas por parte de los usuarios, procesan los datos, producen los informes y almacenan estos datos en los archivos. Utilización de los Datos de Requerimientos: El alcance del diseño de sistemas se guía por el marco de referencia para el nuevo sistema desarrollado durante el análisis. Los datos de los requerimientos, recopilados durante la investigación, conforman las actividades y componentes del sistema. Los analistas formulan un diseño lógico que apoya los procesos y decisiones, los contenidos del sistema pueden cambiar como resultado de un nuevo diseño. El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de requerimientos. En primer lugar se identifican las características generales, como informes y entradas; en el diseño de la salida por ejemplo, los analistas deben conocer la longitud de campo de un dato específico para establecer cuanto espacio dejar en la información, en la pantalla de despliegue visual o archivo. A lo largo de los años hemos visto una evolución de ideas y técnicas en el campo del análisis de sistemas. La cual cabe en tres períodos amplios según Yourdon: 1. El análisis de sistema convencional, anterior a los años 70´s,
  • 29. caracterizado por especificaciones tipo novela victoriana que eran difíciles de leer y entender, y casi imposibles de mantener. 2. El análisis estructurado clásico, de mediados de los años 70´s, a mediados de los años 80´s. Esto se caracterizó por primeras versiones de modelos gráficos, y énfasis en el modelado de las implementaciones actuales de un sistema antes de modelar el nuevo. 3. El análisis estructurado moderno, en el cual se introducen mejoras sobre todo para modelar sistemas de tiempo real y relaciones de situaciones complejas. Aumentando por ende la comunicación entre el analista y el sistema. En la actualidad las técnicas modernas están siendo fusionadas, para así lograr un mejor método que pueda hacerle frente a las necesidades de las diferentes fases del ciclo de vida del sistema, incluyendo a la fase de análisis. Obteniendo de está manera mejores resultados que pueda interpretar el analista en forma rápida y precisa. En primera instancia debemos decir que el análisis estructurado según Senn "permite al analista conocer un sistema o proceso (actividad) en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente". El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. Se puede decir adicionalmente que los componentes del análisis estructurado son los siguientes: símbolos gráficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas. Después de relacionarnos brevemente con la terminología básica, podemos entrar en aspectos relacionados con los cambios del análisis estructurado.
  • 30. Podemos decir que para finales de los años 60´s e inicios de los 70´s el análisis estructurado surge de la necesidad de buscar una forma interpretativa más rápida y eficiente, de tal manera que se pudiesen definir los requerimientos del usuario y las especificaciones funcionales del sistema. Pero esto no se daba porque lo que existía eran grandes volúmenes de información que había que leer por completo y que acarreaban una serie de problemas de: monolitismo, redundancia, ambigüedad e imposibilidad de mantener. Es por ello que surge una amplia variedad de diagramas que permiten representar las especificaciones funcionales en forma sencilla y rápida, aumentando por ende el grado de comunicación entre las especificaciones funcionales y el usuario final (analista, programador, diseñador). Posteriormente, a mediados de los años 70´s estando el análisis estructurado clásico en su apogeo aparecen una serie de dificultades que limitan al analista hacer un buen desempeño de sus actividades. Entre estos problemas según Yourdon podemos mencionar: • Distinción difusa y poca, definida entre los modelos lógicos y los modelos físicos. • Limitación para modelar sistemas en tiempo real. • El modelo de datos se hacía de una manera primitiva. Estas y otras razones dieron nacimiento a ciertas mejoras en el análisis estructurado clásico tales como: diagramas de entidad-relación, diagramas de transición de estados, división de eventos, modelos esenciales y modelos de implantación. Pero a pesar de esto según Yourdon se siguieron dando más problemas como los siguientes:
  • 31. • Tras la segunda y tercera correcciones de un diagrama, el analista se volvía cada vez más apuesto y renuente a hacer más cambios. • Debido a la cantidad de trabajo requerido, el analista dejaba a veces de dividir el modelo del sistema en modelos de menor nivel, quedando por ende, funciones primitivas. • A menudo no se incorporaban en el modelo del sistema los cambios en los requerimientos del usuario sino hasta después de la fase de análisis del proyecto. Inclusive las correcciones de los diagramas había que hacerlas en forma manual, para asegurar que fuesen consistentes y estuviesen completas; lo cual era bastante tedioso y dejaba por fuera muchos errores que debían de encontrarse. Pero para mediados de los 80´s aparecieron las herramientas CASE que trataron de subsanar estos problemas. Las herramientas CASE (Ingeniería de software auxiliada por computadora) se utilizan para dibujar diagramas de flujo de datos y otros además de llevar a cabo una variedad de labores de revisión de errores. Finalmente, algunos usuarios tenían dificultades al tratar con los modelos gráficos del análisis estructurado y preferían alguna otra forma de modelar los requerimientos y comportamiento del sistema; es por ello que aparecen las herramientas de generación de prototipos (mediados de los 80´s) que son considerados como una alternativa al análisis estructurado para tales usuarios. También se utiliza para recordar en forma breve y precisa lo que se ha hecho a lo largo de todo el desarrollo del sistema, para no perder la secuencia de lo que se está realizando. En la actualidad muchas de estas herramientas se están utilizando para facilitar la fase de análisis, e inclusive se están elaborando o fusionando lo mejor de cada una de las técnicas que atienden las necesidades de todas las fases del ciclo de vida del sistema; para así obtener un mejor
  • 32. aprovechamiento, entendimiento, y rendimiento al momento que se ponga a correr el sistema. Disminuyendo de esta manera la serie de errores que se cometían anteriormente, con la introducción de herramientas más especializadas y fáciles de utilizar. Diversos aspectos del análisis estructurado han cambiado gradualmente a lo largo de los últimos años. Las principales áreas de cambio incluyen lo siguiente según Yourdon: • Cambios de terminología. • Partición de acontecimientos. • La desenfatización del modelado físico actual. • Herramientas de modelado en tiempo real. • Integración más cercana del modelado de procesos y datos. En un futuro no muy lejano se piensa que se darán, si es que ya no se están dando, los siguientes cambios o pautas en el ámbito total en lo que se refiere a análisis según Yourdon: • Mayor difusión del análisis de sistemas, sobre todo en los siguientes grupos: los niveles superiores de administración en organizaciones gubernamentales y de negocios, los niños, y profesionales de la computación en los países del tercer mundo. • Impacto sobre la industria de software del tercer mundo.
  • 33. • Proliferación de las herramientas automatizadas, aunque no todos los analistas tienen acceso a las últimas herramientas de análisis. • Impacto de los desastres de mantenimiento. • Integración del análisis estructurado con la inteligencia artificial. Podemos adicionar que el futuro del análisis estructurado va a depender mucho también de que tan rápido pueda ajustarse el mismo a los cambios tecnológicos que se viven hoy en día. Debido a que han estado surgiendo otras técnicas en otras áreas como lo es la orientada a objetos, la cual prevé un buen futuro y muchas mejoras para los sistemas actuales. * DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE* Fue la aparición del diseño y la programación estructurada alrededor de los años 60´s la que dieron cabida al surgimiento del análisis estructurado, ya que existía la necesidad de utilizar una notación gráfica para representar los datos y los procesos que los transforman". Es por ello que surgen una serie de temas afines tales como: herramientas automatizadas (CASE), prototipos, diagramas de entidad-relación etc. Índice de Términos relacionados: CASE (Ingeniería de Software auxiliada por computadora), elaboración de prototipos, símbolos gráficos, diccionarios de datos, descripciones de procesos y procedimientos, reglas, diagramas de estados, diagramas de entidad-relación, diagramas de transición de eventos, división de eventos, modelos esenciales y modelos de implantación.
  • 34. * Métodos de Análisis Orientados al Flujo de Datos * La información se transforma como un flujo a través de un sistema basado en computadora. El sistema acepta entrada de distintas formas; aplica un hardware, software y elementos humanos para transformar la entrada en salida; y produce una salida en distintas formas. La entrada puede ser una señal de control transmitida por un transductor, una serie de números escritos por un operador humano, un paquete de información transmitido por un enlace a red, o un voluminoso archivo de datos almacenado en memoria secundaria. La transformación puede comprender una sencilla comparación lógica, un complejo algoritmo numérico, o un método de inferencia basado en regla de un sistema experto. La salida puede encender un sencillo led o producir un informe de 200 páginas. En efecto, un modelo de flujo de datos puede aplicarse a cualquier sistema basado en computadora independientemente del tamaño o complejidad. La función global del sistema se representa como una transformación sencilla de la información, representada en la figura como una burbuja. Una o más entradas. Representadas como flechas con etiqueta, conducen la transformación para producir la información de salida. Puede observarse que el modelo puede aplicarse a todo el sistema o solo a un elemento de software. La clave es representar la información dada y producida por la transformación. * Diagramas de Flujos de Datos * Conforme con la información se mueve a través del software, se modifica mediante una serie de transformaciones. Un diagrama de flujos de datos
  • 35. (DFD), es una técnica grafica que describe el flujo de información y las transformaciones que se aplican a los datos, conforme se mueven de la entrada a la salida. El diagrama es similar en la forma a otros diagramas de flujo de actividades, y ha sido incorporado en técnicas de análisis y diseños propuesto por Yourdon y Constantine, DeMarco y Gane y Sarson. También se le conoce como un grafo de flujo de datos o un diagrama de burbujas. * Diccionario de Datos * Un análisis del dominio de la información puede ser incompleto si solo se considera el flujo de datos. Cada flecha de un diagrama de flujo de datos representa uno o más elementos de información. Por tanto, el analista debe disponer de algún otro método para representar el contenido de cada flecha de un DFD. Se ha propuesto el diccionario de datos como una gramática casi formal para describir el contenido de los elementos de información y ha sido definido da la siguiente forma: El diccionario de datos contiene las definiciones de todos los datos mencionados en el DFD, en una especificación del proceso y en el propio diccionario de datos. Los datos compuestos (datos que pueden ser además divididos) se definen en términos de sus componentes; los datos elementales (datos que no pueden ser divididos) se definen en términos del significado de cada uno de los valores que puede asumir. Por tanto, el diccionario de datos esta compuesto de definiciones de flujo de datos, archivos [datos almacenados] y datos usados en los procesos [transformaciones]... * Descripciones Funcionales *
  • 36. Una vez que ha sido representado el dominio de la información (usando un DFD y un diccionario de datos), el analista describe cada función (transformación) representada, usando el lenguaje natural o alguna otra notación estilizada. Una de tales notaciones se llama ingles estructurado (también llamado lenguaje de diseño del programa o proceso (LDP)). El inglés estructurado incorpora construcciones procedimentales básicas – secuencia, selección y repetición- junto con frases del lenguaje natural, de forma que pueden desarrollarse descripciones procedimentales precisas de las funciones representadas dentro de un DFD. * Métodos Orientados a la Estructura de Datos * Hemos ya observado que el dominio de la información para un problema de software comprende el flujo de datos, el contenido de datos y la estructura de datos. Los métodos de análisis orientados a la estructura de datos representan los requerimientos del software enfocándose hacia la estructura de datos en vez de al flujo de datos. Aunque cada método orientado a la estructura de datos tiene un enfoque y notación distinta, todos tienen algunas características en común: 1) todos asisten al analista en la identificación de los objetos de información clave (también llamados entidades o ítems) y operaciones (también llamadas acciones o procesos); 2)todos suponen que la estructura de la información es jerárquica; 3)todos requiere que la estructura de datos se represente usando la secuencia, selección y repetición; y 4) todos dan una conjunto de pasos para transformar una estructura de datos jerárquica en una estructura de programa. Como los métodos orientados al flujo de datos, los métodos de análisis orientados a la estructura de datos proporcionan la base para el diseño de software. Siempre puede extenderse un método de análisis para que abarque el diseño arquitectural y procedimental del software.
  • 37. BIBLIOGRAFÍA Senn, James A. "Análisis y Diseño de Sistemas de Información". Segunda Edición. McGraw Hill. 1992. JAMES A SENN, Análisis y Diseño de Sistema de Información, Mc Graw Hill, Enero 1990 JAMES A. SENN, Análisis y Diseño de Sistemas de Información, Segunda Edición, Mc Graw Hill, Abril 2000. IEEE Task Force on Requirements Engineering. Software Engineering Resources by Roger S. Pressman & Associates Edward - Yourdon (1993) - Análisis Estructurado Moderno, Prentice Hall Hispanoamericana, S. A., pp. 136-147, 500-511. Roger - S. P. (1993) - Ingeniería del Software, Mc. Graw-Hill, pp. 217-218, 247. Pressman, R.S., "Ingeniería del Software. Un enfoque práctico.", McGraw-Hill. Larman, C. "UML y patrones: Introducción al análisis y diseño orientado a objetos". Prentice halll