CAPITULO II

FUNDAMENTO TEORICO
En el presente captulo presentamos la base terica fundamental en el desarrollo del presente
proyecto, pero antes de presentar la metodologa de aplicacin y el empleo de las tcnicas en el
desarrollo de la misma, iniciaremos con el reconocimiento de algunas trminos generales de
comprensin como lo es: sistema, sistema de informacin, enfoque de sistemas, con el fin de
familiarizar en una visin orientada a la concepcin de los sistemas en la administrativos, y su
importancia en el proceso de cambio y adaptacin tecnolgica y administrativa de acuerdo al
cumplimiento a los objetivos planteados. Adems de comprender el enfoque aplicado en la
elaboracin de la misma.
2.1. ENFOQUE DE SISTEMAS.
La visin integral considera al mundo desde el punto de vista de las relaciones y las
integraciones. Los sistemas estn todos integrados y sus propiedades no pueden reducirse a las
unidades ms pequeas. En ves de concentrarse en los componentes bsicos o en las substancias
fundamentales, el enfoque integral hace hincapi en los principios bsicos de la organizacin.1
Thome y Willard describen el enfoque de sistemas en los siguientes trminos: El enfoque de
sistemas es una forma ordenada de evaluar una necesidad humana de ndole compleja y consiste
en observar la situacin desde todos los ngulos y preguntarse: Cuntos elementos distinguibles
hay en este problema aparente?, Qu relaciones de causa y efecto existen entre ellos?, Qu
funciones es preciso cumplir en cada caso?, Qu intercambios se requerirn entre los recursos
una vez que se definan?
Por lo tanto el enfoque de sistemas tiene una visin integral, es una disciplina para ver
totalidades, es decir un marco para ver relaciones entre cosas, este pone nfasis en los aspectos
generales y en las interacciones entre las partes que la integran.

Depto. de Informtica: ENCUENTRO DE TEORIA DE SISTEMAS, Univ. Tcnica Federico Santa Maria, 2001

2.2. SISTEMA DE INFORMACION.

Un sistema de informacin dentro una organizacin, es aquel que permite que determinada
informacin fluya para coordinar sus acciones operativas, para llevar a cabo las funciones de la
organizacin de manera coherente con los objetivos de la misma. Aqu una definicin: Un
Sistema de Informacin, es un conjunto de procesamientos ordenados que, al ser ejecutados,
proporcionan informacin para apoyar la toma de decisiones y control de la organizacin.2
Otra definicin es la siguiente: Un Sistema de Informacin es una disposicin de personas,
actividades, datos, redes y tecnologa integrados entre si con el propsito de apoyar y mejorar las
operaciones cotidianas de una empresa, as como satisfacer las necesidades de informacin para
la resolucin de problemas y la toma de decisiones por parte de los directivos de la empresa.3

2.3. TECNICAS DE DESARROLLO DEL PRECENTE PROYECTO

La metodologa aplicada en este proyecto es el Anlisis y Diseo de Sistemas con Interfaz
Grafica de Usuario, aplicando un enfoque de sistemas en el desarrollo de la misma, obteniendo
un sistema Distribuido.
Se inicia realizando una fase de Inspeccin del Anlisis usando una estructura PIECES, siguiendo
con la determinacin de Requisitos del Sistema, Requerimientos Funcionales y no Funcionales.
El desarrollo del Sistema de Informaciones lo realiza bajo un paradigma moderno como es el
Espiral y en un entorno de Anlisis y Diseo Estructurado Moderno. Inicia al Fase de Anlisis de
Sistemas, a partir de los DFDs, DER. y DD. Seguidamente inicia la fase de Diseo de Sistemas,
a partir del diseo: Lgico (Estructura de Datos), Fsico (Entrada y Salidas del Sistema).
Posteriormente se inicia con la Implementacin del Sistema y las pruebas correspondientes
mediante las pruebas de Caja Negra y Blanca.
Las tcnicas de anlisis y diseo han tenido un fuerte fundamento terico, estas pueden usarse
empleando diversa filosofas de administracin de proyecto. Para ilustrar las tcnicas y/o
metodologas, se ha presentado una pirmide de desarrollo del Software (figura 2.1), con una
metfora geomtrica principal para organizar las actividades del desarrollo de sistemas, ya que
permite recordar que el cdigo que se construye es simplemente la base de una estructura que
est especificada para el alcance de un conjunto de objetivos del negocio.

2
3

Senn & Jourdain: ANALISIS Y DISEO DE SISTEMAS DE INFORMACION, Mxico, McGraw Hill, 1992
Whitten y Bentley y Barlow: ANALISIS Y DISEO DE SISTEMAS, 3ra Ed.,Espaa, Irwin, 1996, p.39

PLAN
GENERAL

RECOLECCION
DE INFORMACION

INSPECCION
DEL SISTEMA
REQUISITOS
DEL SISTEMA
MODELO DE
CONTEXTO Y PROCESOS

MODELO DE INFORMACION
DICCIONARIO DE DATOS

LOGICO

MODELO
ARQUITECTONICO
DISEO DE ENTRADAS
DISEO DE SALIDAS

FISICO

CREACION DE LA BASE DE DATOS

CREACION DE INTERFACES EXTERNAS
CODIFICACION Y PRUEBAS

Figura.2.1. Pirmide de desarrollo de Software.4

2.4. TECNICAS PARA OBTENCION DE REQUERIMIETOS.

Es un aspecto muy importante para determinar los requerimientos de informacin, pues se cuenta
con una serie de mtodos los cules tienen ventajas como tambin restricciones. Los cuales no
llega a ser completo, por lo cul se propone de tres mtodos los cuales sern ms completos en su
aplicacin para nuestro estudio de manera conjunta. Tales son La Revisin de Documentacin,
Las Entrevistas, la Observacin, Puntos de Vista.
Para poder comprender mas los requerimientos del sistema y ordenarlos los llevaremos estos a un
lenguaje formal por el mtodo de Definicion de Requerimientos Orientado a Puntos de Vista
(VORD).
2.4.1. ENTREVISTA.
El propsito de la entrevista es la recoleccin de informacin acerca de un proceso en particular,
tomando en cuenta los conocimientos de la situacin en estudio por parte de los usuarios.

Elaboracin propia, tomando como base la Pirmide propuesta por: David A. Ruble: Anlisis y Diseo Practico de
Sistemas Cliente Servidor con GUI.

Una entrevista para recoleccin de informacin es una conversacin dirigida con un propsito
especfico que usa un formato de preguntas y respuestas.5
Los objetivos son informacin importante que puede ser recogida de las entrevistas. A partir de
esto decidimos a quien entrevistar, y la forma de encarar la entrevista tomando en cuenta la
estructura y el tipo de preguntas elegidas, adems de enterarnos de tanta informacin sea posible
del proceso de administracin y mantenimiento vial, respecto a los datos que se maneja.
2.4.2. REVISIN DE DOCUMENTACIN.
La Revisin de Documentacin es una tcnica para recolectar informacin respecto al registro de
informacin, volmenes de informacin, atributos de las entidades de datos, organigramas que
nos permiten conocer como operan sus procesos y objetivos de la organizacin. Comenzamos a
Revisar los documentos registrados, los procesos mas frecuentes, el tipo de informacin los
procedimientos de operacin escrito. Todo ello nos servir para encarar un modelado de datos.
2.4.3. OBSERVACIN.
Este mtodo consiste en observar los diferentes procesos, identificando falencias en el
desenvolvimiento en las actividades cotidianas en el negocio. La observacin es muy til cuando
el analista necesita ver de primera mano cmo se manejan los documentos, como se llevan acabo
los procesos y si ocurren los pasos especificados. La observacin es un arte en si misma. Cuando
termina el proceso, se cuenta con informacin adicional que no estara disponible por medio de
otros mtodos de recopilacin de datos.
2.5. FASE DE INSPECCION DEL ANALISIS.
Tambin se conoce con el nombre de Investigacin Preliminar, Estudio Inicial o estudio de
viabilidad, para este caso ilustraremos en una estructura PIECES de James Wetherbe. Esta
estructura propone una plantilla que muestra su utilidad en el momento de registrar el anlisis de
problemas y oportunidades, y el registro de los objetivos del nuevo sistema.
2.6. INGENIERIA DE REQUERIMIENTOS.
Una de las primeras etapas del proceso de desarrollo de Software es la Ingeniera de
Requerimientos, en esta fase se definen y especifican los requerimientos de los clientes y
usuarios. Las actividades involucradas en la Ingeniera de Requerimientos son: la obtencin, el

Kendall & Kendall: ANALISIS Y DISEO DE SISTEMAS, 3ra. Ed., Mxico, Prentice Hall Hispanoamericana
S.A.,1997, p.109

anlisis, la especificacin, la validacin y la administracin de los requerimientos de software.

Los requerimientos de software se definen como las necesidades de los clientes, los servicios que
el usuario desea que proporcione el sistema y las restricciones sobre las que el software debe
operar. El resultado del proceso de requerimientos es la base para el diseo, la implementacin y
la evaluacin del software. De esta forma, si no se descubren y especifican todos los
requerimientos del sistema en desarrollo, podra conducirnos a la entrega de un producto de
software incompleto, con alto ndice de riesgos y poco funcional.
La determinacin de requerimientos es el estudio de un sistema para conocer como trabaja y
donde es necesario efectuar mejoras.
Un requerimiento es una caracterstica que debe incluirse en un nuevo sistema.6
2.7. PROCESO DE LA INGENIERIA DE REQUERIMIENTOS
El proceso de Ingeniera de Requerimientos, involucra a todas las actividades necesarias para
crear y mantener el documento de requerimientos del sistema.
Las actividades que se definen en el proceso de la Ingeniera de Requerimientos son las
siguientes:
1. Obtencin de los requerimientos
2. Anlisis de requerimientos
3. Especificacin de requerimientos
4. Validacin de documento de especificacin
5. Administracin de requerimientos
Una manera de desarrollar el proceso de Ingeniera de Requerimientos es mediante el paradigma
del espiral, donde las actividades son repetidas hasta cuando se obtenga un documento de
requerimientos aceptable, como se muestra en la figura 2. Mientras existan problemas en una
versin previa del documento de requerimientos (borrador), se reingresa a las etapas del espiral,
el proceso finaliza cuando se produzca un documento aceptable, de la misma forma, el proceso
puede terminar por factores externos como la presin del cliente la falta de recursos. Despus
de que el documento sea producido satisfactoriamente, cualquier cambio futuro en los
requerimientos es parte de la administracin de los requerimientos.
6

James A. Senn: DISEO DE SITEMAS DE INFORMACION, 2da. Ed., Mexico, McGraw Hill, 1992, p.122

Figura 2.2 El modelo espiral del proceso de Ingeniera de Requerimientos.

2.8. ACTIVIDADES DEL PROCESO DE INGENIERIA DE REQUERIMIENTOS
El objetivo de la Ingeniera de Requerimientos es obtener un documento formal donde se
especifiquen las caractersticas que debe cumplir el sistema que se va a desarrollar. Estas
caractersticas y restricciones son definidas en comn acuerdo por los usuarios del sistema y el
analista. La especificacin de los requerimientos debe cumplir con ciertas caractersticas de
calidad, como las siguientes: entendibles, necesarios, consistentes, no ambiguos, completos,
verificables, correctos, reales, rastreables y modificables.
En cada una de las actividades del proceso de la Ingeniera de Requerimientos se llevan a cabo
tareas especficas utilizando tcnicas de requerimientos, modelos de especificacin y
herramientas para la administracin del documento de requerimientos.

2.8.1. OBTENCION DE REQUERIMIENTOS

En esta actividad se determina el dominio de la aplicacin, se especifican los servicios que deben
proveer el sistema, la funcionalidad requerida del sistema, y las restricciones de hardware y
software. Es indispensable la participacin de los usuarios y clientes para la identificacin de los
requerimientos del sistema.
Se debe obtener como resultado de esta actividad, un documento de definicin de los
requerimientos, donde se definen las necesidades inicialmente encontradas, esto no significa que
estos requerimientos sean los definitivos, pueden ser agregados nuevos requerimientos conforme
se vayan encontrando o incluso los requerimientos establecidos pueden modificarse o eliminarse.
Para lograr la obtencin de los requerimientos se definen tareas a seguir y son las siguientes.
1. Comprender el problema que se esta resolviendo, es necesario estudiar el dominio o
entorno en el que el sistema va a operar.
2. Buscar y recolectar informacin de manuales de operacin y mantenimiento, de manuales
organizacionales y polticas de operacin.
3. Definir los lmites y restricciones del sistema, para determinar con exactitud que es lo que
el sistema va hacer y tambin especificar lo que no va hacer.
4. Identificar a las personas o usuarios interesados por el sistema, ya que ellos conocen el
medio ambiente en que operar el sistema y pueden ayudar describiendo sus necesidades.
5. Recolectar y clasificar requerimientos, de esta manera los desarrolladores pueden iniciar
definiendo un bosquejo del sistema, su funcionamiento bsico y estableciendo el alcance
del sistema
El desarrollo de estas tareas en la obtencin de requerimientos es realizado secuencialmente, pero
es necesario que cada tarea puede regresarnos a la anterior, sobretodo si no se descubre la
informacin necesaria en el primer recorrido del diagrama. La figura 2.3 muestra esta relacin.
La salida de esta actividad nos conduce hacia el anlisis de requerimientos.

Figura 2.3 El proceso de obtencin de requerimientos.

2.8.2. ANALISIS DE REQUERIMIENTOS
Los requerimientos definidos en el documento de definicin son analizados detalladamente por el
analista y negociados con el usuarios, para decidir los requerimientos que sern aceptados y
definirlos de manera conjunta con el fin de homogenizar su interpretacin.
El anlisis del documento de definicin de requerimientos (DDR) se lleva a cabo mediante
tcnicas de revisin y verificacin de los criterios de calidad de cada requerimiento definido, este
estudio es realizado por el desarrolador y el usuarios.
En el anlisis se llevan a cabo las siguientes actividades:
1. Priorizar los requerimientos debido a que pueden existir requerimientos ms importantes
que otros para los clientes y usuarios, por lo que deben ser clasificados e implementados
de acuerdo a su prioridad en el sistema.
2. Encontrar dependencias entre requerimientos y etiquetar los requerimientos con un
identificador nico, con el fin de poderlos identificar o rastrear en el futuro.
8

3. Resolver conflictos entre los requerimientos, se pueden encontrar conflictos entre

requerimientos mediante la revisin de los criterios de calidad que debe cumplir cada
requerimiento del sistema.
4. Negociar con flexibilidad con los dems elementos del equipo que intervienen en el
proceso de desarrollo de software, para homogenizar su comprensin y de esta forma
tanto desarrolladores como usuarios tengan la misma interpretacin al momento de leer el
documento de requerimientos.
El resultado del anlisis es el Documento de Definicin de Requerimientos (DDR), donde se
encuentran descritos los requerimientos iniciales del sistema que se va a desarrollar en lenguaje
natural; este documento sirve como seguimiento a las actividades del proceso de la Ingeniera de
Requerimientos, por lo que es necesario de que no existan requerimientos en conflictos y estn
bien escritos. La figura 2.4 describe este proceso, muestra la interaccin de las tareas realizadas y
la salida de esta actividad es la entrada a la actividad de especificacin de los requerimientos.

Figura 2.4 El proceso de anlisis de requerimientos.

2.8.3. ESPECIFICACIONES DE REQUERIMIENTOS

En esta actividad se obtiene como resultado el documento de especificacin de requerimientos.
Este documento contiene la descripcin precisa de los requerimientos, incluye modelos de
representacin que agregan detalles al sistema mostrndolo desde diferentes perspectivas.
Para el desarrollo de esta actividad se realizan las siguientes tareas:
1. Especificar los requerimientos funcionales y no funcionales, ambos requerimientos
deben ser descritos a detalles para su mejor comprensin.
2. Determinar el tipo de estndar a utilizar para la definicin del Documento de
Especificacin de Requerimientos (DER). Se define el esquema del contenido del DER en
base al estndar definido por la IEEE.
3. Elegir la herramienta de especificacin, en caso de utilizar alguna para automatizar el
proceso.
4. Utilizar modelos y diagramas para explicar con mayor detalle y diferentes perspectivas el
comportamiento del sistema.
5. Utilizar cualquier informacin de soporte o gua para etapas posteriores y que amplen la
comprensin del sistema.
Todas estas tareas van encaminadas a obtener el Documento de Especificacin de
Requerimientos, en donde se especifican las funciones, restricciones o caractersticas del sistema
en desarrollo. Es necesario contar con toda la informacin disponible para formar un documento
completo y que sirva como base de partida hacia las otras etapas del desarrollo del sistema. En la
figura 2.5 se muestran las actividades de la especificacin de los requerimientos del sistema.

10

Figura 2.5 Las actividades de la especificacin de requerimientos.

2.8.4. VALIDACION DE REQUERIMIENTOS
La validacin permite detectar problemas en el documento de requerimientos, y se lleva a cabo
verificando cuidadosamente la consistencia y completitud del DER, antes de que sea usado como
base en etapas posteriores del proceso de desarrollo del sistema.
La validacin es un proceso importante debido a que permite detectar errores en el documento de
requerimientos, de forma que puedan ser corregidos a tiempo. Estos errores si no son
descubiertos en esta actividad pueden conducir a errores en el diseo, ya que producen que se
repita el trabajo cuando los errores sean descubiertos en etapas posteriores del desarrollo del
sistema o en caso drsticos, si llegan a ser detectados cuando el sistema este en servicio.
Los criterios que son revisados para validar el documento de especificacin de requerimientos
son los siguientes:
1. Verificar validez. Los requerimientos satisfacen a las necesidades de los usuarios y son
necesarios.
11

2. Verificar consistencia. Los requerimientos en el documento no deben contradecirse, ya

que esto generara conflictos en el momento de implementarse.
3. Verificar integridad, es decir, deben estar todos los requerimientos que describan todas las
funciones y las restricciones propuestas por el usuario del sistema.
4. Verificar realismo, asegurar que los requerimientos puedan implementarse con la
tecnologa existente, considerando tambin el presupuesto y la calendarizacin del
desarrollo del sistema.
5. Generar casos de prueba para los requerimientos.
Todos estos criterios deben ser orientados hacia la aplicacin en el Documento de Especificacin
de Requerimientos, a fin de lograr su certificacin y validacin. Esta actividad es importante y
debe tomarse en cuenta en cualquier proceso de desarrollo de software porque garantiza que lo
expresado en el documento detallada las caractersticas del sistema que se va a desarrollar y
puede servir de base para las etapas de diseo, implementacin y pruebas del software. En la
figura 2.6 se muestra esta actividad.

Figura 2.6 Las actividades de la validacin del DER.

12

2.8.5. ADMINISTRACION DE REQUERIMIENTOS

La administracin de los requerimientos describe el proceso de comprender y controlar los
cambios en los requerimientos del sistema, Esta actividad comienza en cuanto existe la primera
versin del documento de requerimientos cuando se planea darle mantenimiento a un sistema
existente. Especficamente, en esta actividad se requiere lo siguiente:
1. Administrar los cambios de los requerimientos. Esto implica el anlisis del problema y
su propuesta de cambio, valorar el costo del cambio propuesto y finalmente implementar
los cambios en los documentos que lo requieran.
2. Establecer polticas de rastreo. Es necesario conocer el origen de los requerimientos o
los efectos que tendrn los cambios en los requerimientos relacionados.
3. Control de versiones del documento de requerimientos cuando implique algn cambio
para referencias futuras.
2.9. TECNICAS DE ANALISIS DE REQUERIMIENTOS
Los requerimientos deben ser analizados detalladamente tanto por el equipo de desarrollo como
por los usuarios para resolver conflictos de ambigedad y consistencia entre requerimientos,
priorizando los requerimientos que han de ser inicialmente implementados en el sistema, adems
de negociarlos con flexibilidad para homogenizar su comprensin y de esta forma obtener una
lista consistente de requerimientos. Para realizar el anlisis se cuenta con diversas tcnicas, como
las que se mencionan a continuacin.
2.9.1. LA IDENTIFICACION DE LOS REQUERIMIENTOS
Se debe identificar a cada requerimiento de manera nica, de tal forma que puedan permitir una
referencia cruzada con otros requerimientos, y as utilizarse en las evaluaciones de rastreo. Para
identificar cada requerimiento se pueden usar las letras iniciales del tipo de requerimiento y un
nmero de referencia, por ejemplo si se tratara de un requerimiento funcional puede usarse la
siguiente estructura RFn, donde n es un nmero entero consecutivo para cada requerimiento y
para los requerimientos no funcionales RNFn. Ejemplos de identificacin de requerimientos
funcionales y no funcionales:
RF2.1 En este sub-sistema se podr asignar valores de unidades mtricas
RNF4 Se debe poder hacer uso del SAM-V desde toda PC que este conectada a la red
informatica de la institucion.

13

2.9.1. LISTAS DE VERFICACION (Checklist).

Esta tcnica es muy fcil de utilizar y proporciona una gran utilidad. En general, es una lista de
preguntas que el analista debe usar para evaluar cada requerimiento. Los analistas deben verificar
y marcar los puntos de esta lista mientras leen el documento de requerimientos, cuando se
descubran problemas potenciales, debern ser anotados, ya sea en los mrgenes del documento,
en una lista de verificacin. Las listas de verificacin son tiles porque brindan un recordatorio
de lo que se debe buscar y reducen la posibilidad de pasar por alto alguna verificacin
importante. No slo son tiles para verificar requerimientos, sino tambin se puede aplicar con
los casos de uso. El proceso de verificacin se puede implementar con una hoja de clculo en
donde las filas representan, por ejemplo, los distintos requerimientos, y las columnas representan
los puntos a verificar los criterios que deben cumplir, como se ilustra en la tabla 2.1. Entonces
se completan las intersecciones que correspondan con los comentarios sobre los problemas
potenciales.

Tabla 2.1 Lista de verificacin de calidad en los requerimientos.

2.9.2. MATRIZ DE DEPENDENCIA ENTRE REQUERIMIENTOS
Suponiendo que los requerimientos sean claramente identificados y enumerados, entonces
podemos utilizar una matriz de dependencia de requerimientos, donde se listen en orden todos los
requerimientos identificados, como se muestra en la tabla 2.2.

Tabla 2.2 Matriz de dependencia entre requerimientos.

14

Las celdas de la matriz son marcadas con una X si dos requerimientos tienen dependencia o se
escribe en las celdas si estn intercalados o en conflicto. Una celda vaca indica que los
requerimientos son independientes. Los requerimientos en conflicto o intercalados podrn ser
discutidos con los clientes para despus ser replanteados y de este modo resolver los conflictos o
la intercalacin entre estos. La matriz de dependencia de requerimientos es una tcnica simple
pero efectiva para encontrar conflictos e intercalaciones cuando el nmero de requerimientos es
relativamente pequeo. Sin embargo, cuando el nmero de requerimiento es mayor, la tcnica
an puede ser usada si los requerimientos se agrupan en categoras, de esta forma los
requerimientos pueden ser comparados separadamente en cada categora.
2.10. TIPOS DE REQUERIMIENTOS DE ACUERDO A SUS CARACTERISTICAS
Esta clasificacin se realiza en funcin de la naturaleza de las caractersticas del sistema que se
desarrolla, generalmente los requerimientos de sistemas de software se clasifican en funcionales,
no funcionales.
2.10.1. REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales son declaraciones de los servicios que proveer el sistema y
comprenden la interaccin entre el sistema y su ambiente, la reaccin a entradas particulares de
datos y su comportamiento en condiciones especficas. En algunos casos tambin declaran lo que
el sistema no debe hacer.
2.10.2. REQUERIMIENTOS NO FUNCIONALES.
Los requerimientos no funcionales, son especificaciones de las restricciones de los servicios o
funciones ofrecidas por el sistema, restricciones sobre el sistema que limitan nuestras elecciones
en la solucin a un problema.
Los requerimientos no funcionales no se refieren directamente a las funciones especficas que
entrega el sistema, sino a sus propiedades emergentes. Existen muchas maneras de clasificarlos,
Sommerville [2] propone la siguiente clasificacin.

15

2.11. ESTANDARES DE DOCUMENTACION

El Documento de Especificacin deber estar escrito de una manera correcta y formal de tal
modo que tenga solo una interpretacin por las personas involucradas. De esta forma, se
analizaron todas las propuestas para obtener y presentar una manera de organizar el Documento
de Especificacin de Requerimientos.

2.11.1. EL ESTANDAR IEEE/ANSI 830-1993

Existen diferentes formas de definir y especificar los requerimientos en un documento formal,
por lo que un gran nmero de diferentes organizaciones se han preocupado por definir estndares
para los documentos de requerimientos. El ms usual es el propuesto por la IEEE y la ANSI
conocido como el estndar IEEE/ANSI 830-1993, tambin brevemente llamado como, el estndar
830-1993, que sugiere la siguiente estructura para los documentos de requerimientos:
1. Introduccin
Propsito del documento de requerimientos
Alcance del producto
Definiciones, acrnimos y abreviaturas
16

 Referencias
Resumen del resto del documento
2. Descripcin general
Perspectiva del producto
Funciones del producto
Caracterstica del usuario
Restricciones generales
Suposiciones y dependencias
3. Requerimientos especficos
Requerimientos funcionales
Requerimientos no funcionales
Requerimientos de interfaz.
(Los requerimientos pueden documentar las interfaces externas, describir la
funcionalidad y el desempeo del sistema, especificar los requerimientos
lgicos de las bases de datos, las restricciones de diseo, las propiedades
emergentes del sistema y las caractersticas de calidad).
4. Apndices
5. ndices
El estndar propuesto es una gua o recomendacin para la estructuracin del documento de
requerimientos. Sin embargo, se puede transformar y adaptar para definir un estndar que se
ajuste a las necesidades de una organizacin en particular.
Para presentar el documento de requerimientos del SAM-V, se propone la siguiente estructura
que es una definicin de los puntos ms importantes de todos los enfoques estudiados y tomando
como referencia el estndar IEEE/ANSI 830-1993.
1. Introduccin
Propsito del documento de Especificacin de Requerimientos del SAM-V
Alcance del documento de Especificacin de Requerimientos del SAM-V
2. Descripcin General
Descripcin del sistema actual

17

 Propsito y alcance del SAM-V

Contexto del SAM-V
Identificacin de interesados (stakeholders)
3. Definicin de los Requerimientos
Definicin de los Requerimientos bsicos del SAM-V.
Definicin de los Requerimientos Funcionales del SAM-V usando lenguaje natural
Definicin de los Requerimientos No Funcionales del SAM-V usando lenguaje natural
4. Especificacin de los requerimientos del SAM-V
Especificacin de Requerimientos Funcionales del SAM-V usando formas en lenguaje
natural estructurado.
Modelos del sistema

Modelo de Datos

Modelos de Comportamiento

Modelos Orientados a Objetos

5. Criterios de Validacin del Documento de Especificacin de Requerimientos del SAM-V

6. Evolucin del SAM-V
7. Apndices
8. Glosarios

2.12. TECNICAS DE ESPECIFICACION DE REQUERIMIENTOS

En esta actividad se obtiene el documento de especificacin de requerimientos que es orientado a
diversos tipos de lectores, por lo que es necesario contar con mltiples niveles de descripcin. Es
necesario contar con modelos de representacin, mtodos, metodologas y herramientas que
proporcionan la manera de describir los diferentes tipos de requerimientos del sistema en el
documento de especificacin. El documento es redactado para que sea interpretado por los
usuarios y por los diseadores del sistema, recordemos que los usuarios son personas sin
conocimientos tcnicos de implementacin, por otro lado el equipo de diseo son expertos en el
rea, por lo que se requiere de ambas perspectivas del documento. Existen varias maneras de
describir los requerimientos de software en este caso utilizaremos e Lenguaje Natural.

18

2.12.1. LENGUAJE NATURAL

El lenguaje natural es utilizado en la mayora de las veces para escribir los requerimientos del
sistema con el fin de que los usuarios puedan comprenderlos sin necesidad de conocimientos
tcnicos de desarrollo y comprobar que sus necesidades estn expresadas en el documento de
requerimientos. Por otro lado, aunque el lenguaje natural sea flexible y sencillo puede contener
problemas de interpretacin. Algunos problemas que se pueden encontrar en la descripcin de los
requerimientos utilizando el lenguaje natural son:
Conjuncin de Requerimientos. Varios requerimientos diferentes se expresan de forma
conjunta como un nico requerimiento.
La comprensin del lenguaje natural radica en que los lectores y redactores de la
especificacin utilicen la misma palabra para el concepto.
La especificacin del lenguaje natural es demasiado flexible. Se puede decir lo mismo
de formas completamente diferentes.
No existe una forma fcil de modularizar los requerimientos. El lenguaje natural es
difcil exhibir todos los requerimientos relacionados.
2.12.2. LENGUAJE NATURAL ESTRUCTURADO
Este lenguaje es una forma restringida del lenguaje natural para expresar los requerimientos del
sistema asegurando que se imponga un cierto grado de uniformidad a la especificacin y
manteniendo la expresividad y comprensin del lenguaje natural. Para la notacin de este
lenguaje es fundamental el uso de plantillas o formas estndar para especificar los
requerimientos. Cada forma debe incluir la siguiente informacin:
1. Una descripcin de la funcin o entidad a especificar.
2. Una descripcin de sus entradas y de donde provienen.
3. Una descripcin de sus salidas y hacia donde van.
4. Una descripcin de que otras entidades se utilizan.
5. Si se utiliza un enfoque funcional, definir una precondicin y poscondicin.
6. Una descripcin de los efectos colaterales (si existes) de la operacin.
Con esto podemos lograr eliminar algunos problemas y obtener menos variacin en
laespecificacin, sin embargo pueden permanecer algunas ambigedades en la especificacin. La
figura 2.7 muestra un ejemplo de una plantilla para especificar los requerimientos de software.

19

Figura 2.7 Plantilla para especificar requerimientos de software en lenguaje natural estructurado.
2.13. EL MTODO VORD.
El mtodo VORD (Viewpoint-Oriented Requirements Definition, Definicin de Requerimientos
Orientado a Puntos de Vista), es sobre todo propuesto para especificar sistemas interactivos, pero
tambin puede ser usado para especificar otras clases de sistemas [11]. El mtodo VORD est
basado en puntos de vista que se enfocan en usuarios involucrados en aspectos organizacionales.
El modelo orientado a puntos de vista es orientado a servicios. El sistema da servicios a los
puntos de vista y los puntos de vista pasan informacin de control y parmetros asociados al
sistema. Los puntos de vista proyectan las clases de usuarios finales de un sistema o de otro
interconectado. Los puntos de vista que estructuran el ncleo del modelo, son conocidos como
puntos de vista directos. Por el hecho de que no todos los requerimientos son derivados de gente
o subsistemas que interactan con sistemas especificados. Los puntos de vista que respecta a
sistemas externos que tienen influencia en el dominio de la aplicacin tambin son considerados
y son llamados puntos de vista indirectos.

20

2.13.1.

PUNTOS DE VISTA DIRECTOS.

Estos corresponden directamente a clientes que reciben

servicios del sistema y envan

informacin de datos y de control al sistema. Pueden ser cualquier sistema usuario/operador u

otro subsistema que interacta con el sistema analizado.
2.13.2.

PUNTOS DE VISTA INDIRECTOS.

Los puntos de vista indirectos tienen un inters en algunos o todos los servicios del sistema, pero
no interactan directamente con l, estos pueden generar requerimientos que restringen los
servicios entregados a puntos de vista directos. Los puntos de vista indirectos tienen una
importancia en los puntos de vista de la ingeniera (estos se refieren al diseo e implementacin
del sistema), mediante los puntos de vista organizacional (se refieren a la influencia de
organizacin), a puntos de vista externos (se refieren a la influencia del sistema en el ambiente
externo).
El mtodo VORD est basado en tres principales pasos iterativos llamados:
1. Identificacin y estructuracin de los puntos de vista.
2. Documentacin de los puntos de vista.
3. Anlisis y especificacin de los requerimientos de puntos de vista.
En el primer punto se trata de identificar los puntos de vista, y son declaraciones abstractas de las
necesidades de la organizacin. El segundo paso consiste en documentar los puntos de vista
identificados en el paso uno. La documentacin consiste en:
1. Etiquetar y describir el punto de vista identificado.
2. Rastrear los tipos de puntos de vista como directos o indirectos.
3. Atributos que caracterizan a los puntos de vista en el dominio de la aplicacin.
4. Requerimientos de puntos de vista, estos incluyen un conjunto de servicios requeridos,
requerimientos de control y requerimientos funcionales.
5. Escenarios de eventos que describen la interaccin entre los puntos de vista y el sistema
propuesto.
6. Historial de puntos de vista que describen la evolucin de los requerimientos de los
puntos de vista.
El tercer paso se refiere con la identificacin de errores y conflictos y su solucin. El resultado
final es el documento de la especificacin de requerimientos.

21

En la figura 2.8 se muestra el proceso del modelo iterativo VORD. Los procesos son mostrados
en rectngulos con esquinas redondeadas y los productos en rectngulos con esquinas cuadradas.
Cada producto puede ser visto como el control para un proceso de revisin.

Puntos de vistas y
Requerimientos abstractos

Especificar

Documentar

Analizar

Especificar

puntos de vista

puntos de vista

requerimientos

requerimientos

Puntos de vistas

Puntos de vistas

Requerimientos

Especificacin de

documentados

negociados

Requerimientos

Figura 2.8 El proceso del modelo VORD.

La notacin grafica usada para representar los puntos de vista en el VORD se muestra en la figura
2.9. Los puntos de vista se representan en rectngulos, se identifican como se muestra en la
esquina superior izquierda y se etiquetan a partir de la mitad de abajo del rectngulo, el tipo de
punto de vista o rastreo se muestra en la esquina superior derecha y su especializacin son
rectngulos contiguos por el lado derecho, sealado por una flecha que parte de izquierda a
derecha. Cada punto de vista tiene uno o ms tipos especializados. Un punto de vista
especializado comparte ciertos servicios y atributos con los puntos de vista padre, pero puede
recibir servicios adicionales o imponer sus propias limitaciones sobre los servicios heredados.

22

n.1
n

Tipo
Etiqueta
n.2
M | atributo

Figura 2.9 El proceso del modelo VORD.

2.14. HERRAMIENTA DE SOFTWARE PARA LA ADMINISTRACIN DE LOS
REQUERIMIENTOS.
Cada vez es ms comn el uso de las herramientas de software en el desarrollo de sistemas, estas
herramientas pueden integrarse y constituir una herramienta CASE compleja que puede abarcar
todo el proceso de desarrollo de un sistema. En este parte se realiza una revisin de una
herramienta de software para la administracin de los requerimientos. Aunque todas las
herramientas de administracin de los requerimientos conservan un propsito comn. En general,
una herramienta de software para la administracin de los requerimientos, se concentran en
administrar y producir el documento de especificacin de los requerimientos del sistema.
2.14.1 VOORTool.
La herramienta VordTool fue desarrollada por Ian Sommerville y Katonya en el ao de 1996 [33],
y se basa en la especificacin de requerimientos orientado a puntos de vista. El modelo adoptado
por VORDTool es orientado a servicios donde los puntos de vista son anlogos a clientes en un
sistema cliente-servidor. El sistema capta los servicios como puntos de vista y los puntos de
vistas pasan informacin de control al sistema. Los puntos de vista mapean clases de usuarios
finales de un sistema o las interfaces hacia otros sistemas. Los puntos de vista que constituyen la
base del modelo son conocidos como puntos de vista directos. Los puntos de vista que respecta a
otros sistemas que tienen influencia en el dominio de la aplicacin tambin son considerados y
son llamados puntos de vista indirectos. Ambos puntos de vistas representan a los requerimientos
funcionales y no funcionales respectivamente.
23

a. Puntos de vista Directos.

Corresponden directamente a clientes que reciben servicios del sistema y envan informacin
de datos y de control al sistema, y puede ser cualquier sistema usuario/operador u otro
subsistema que interacta con el sistema analizado.
b. Puntos de vista Indirectos.
Los puntos de vista indirectos tienen un inters en algunos o en todos los servicios del
sistema, pero no interactan directamente con l. Los puntos de vista indirectos pueden
generar requerimientos que restringen los servicios entregados a puntos de vista directos.
El mtodo VORD est basado en tres pasos iterativos que son:
1. La Identificacin y estructuracin de los puntos de vista trata de identificar los puntos de
vista, y son declaraciones abstractas de las necesidades de la organizacin
2. La Documentacin de los puntos de vista consiste en documentar los puntos de vista
identificados. La documentacin consiste en:
a) Etiquetar y describir el punto de vista identificado.
b) Rastrear los tipos de puntos de vista como directos o indirectos.
c) Definir atributos que caracterizan a los puntos de vista en el dominio de la aplicacin.
d) Identificar los requerimientos de puntos de vista, estos incluyen un conjunto de servicios
requeridos, requerimientos de control y requerimientos funcionales.
e) Definir los escenarios de eventos que describen la interaccin entre los puntos de vista y
el sistema propuesto.
f) Historial de puntos de vista que describen la evolucin de los requerimientos de los
puntos de vista.
2.14.1.1.

EL ANLISIS Y ESPECIFICACIN DE LOS REQUERIMIENTOS DE

PUNTOS DE VISTA
La herramienta VORDTool se basa en la definicin de los puntos de vistas directos que
corresponden con los requerimientos funcionales y los puntos de vistas indirectos que
corresponden con los requerimientos no funcionales. Mediante este esquema, se definen los
nodos descendientes. En los puntos de vista directos se establecen dos jerarquas, los puntos de
vista directos del operador y los puntos de vista directos del sistema. En los puntos de vista del
operador, se consideran los usuarios o sistemas externos que obtienen o proporcionan un servicio
al sistema analizado, y para los puntos de vista del sistema se consideran los subsistemas internos

24

o componentes del sistema en desarrollo. La figura 2.10 ilustra la jerarqua de puntos de vista
abstracta definida en VORDTool.

Figura 2.10. Jerarqua de Puntos de Vista en VORDTool.

Para los puntos de vista indirectos se tienen cuatro jerarquas de nodos, los puntos de vista no
funcionales de la organizacin del negocio, regulacin, ambiente e ingeniera. Estos ltimos tres
se refieren a requerimientos no funcionales propios del sistema de cmputo en donde residir el
sistema, y las restricciones de tecnologa.
En VORDTool, para agregar un punto de vista a la jerarqua de clases abstractas, se elige el icono
, el cual mostrar una forma donde describir el punto de vista que desee agregar, como se
ilustra en la figura 2.11.

25

Figura 2.11. Agregando un punto de vista.

VORDTool proporciona dos maneras de mostrar el esquema de puntos de vista de sus proyectos,
una es mediante el esquema jerrquico de clases abstracta (como en la figura 2.10), y la otra
mediante un esquema descriptivo de los nodos o puntos de vistas descendientes en el editor
canvas de la aplicacin (como aparece en la figura 2.12). Se puede alternar de un esquema a otro,
mediante el icono

Para asignar atributos a un punto de vista seleccionado, se utiliza el icono

, por ejemplo en

la figura 2.12 se muestra como agregar el atributo Num_Emp al punto de vista Coordinador.
Cada punto de vista definido le corresponde un identificador numrico que se muestra en la
esquina superior izquierda, tambin los atributos tienen un identificador que depende del
identificador del punto de vista al que corresponden.

26

Figura 2.12. Agregando atributos a un punto de vista.

En este contexto, cada punto de vista le corresponde uno o ms requerimientos que lo definen, y
para agregar un requerimiento a un punto de vista, en VORDTool se utiliza el icono

Primero seleccione el punto de vista, enseguida el icono para agregar un requerimiento, esta
accin despliega una forma donde se coloca el identificador o etiqueta del requerimiento, la
descripcin del requerimiento, el origen y la razn de importancia en el sistema. Con la opcin
Racionale, puede agregar los siguientes datos: La prioridad del requerimiento y su justificacin,
el tipo de requerimiento y los requerimientos asociados. En la figura 6 se ilustra la pantalla de
VORDTool para agregar el requerimiento Elegir_Curso al punto de vista Alumno, para el
ejemplo del SIV.

27

Figura 2.13. Asignar requerimientos a un punto de vistas.

Otra de las caractersticas de VORDTool es que puede describir los conflictos encontrados entre

los requerimientos, mediante el icono

de la barra de herramienta. Para revisar los

requerimientos asignados a cada punto de vista, el procedimiento es el siguiente. Se elige un par

de requerimientos que se van a analizar, si se encuentran conflictos en la casilla conflict found se
escriben recomendaciones para resolver los conflictos de los requerimientos analizados. Estas
recomendaciones podrn ser utilizadas ms tarde para negociar con el cliente los requerimientos
en conflictos. En la figura 2.14. se muestra la ventana de la forma para identificacin de conflicto
ara los requerimientos del ejemplo SIV, en este caso son Ver_Curso, y Elegir_Curso, ambos
requerimientos no presentan conflictos.

28

Figura 2.14. Forma de identificacin de conflictos.

En VORDTool, la revisin de los requerimientos, puntos de vista y las notas puede llevarse acabo

de manera automtica, mediante el icono

. Esta accin proporciona una forma como la que

se ilustra en la figura 2.15 , donde aparecen atributos como el nmero de la revisin, la fecha y el
ttulo que define la revisin, el nombre de las personas que llevan a cabo la revisin, el tipo de
elemento que se esta revisando, en este caso puede ser un punto de vista, un requerimiento, una
nota, o un escenario de evento. De acuerdo a la seleccin del elemento a revisar, se activa una
lista de preguntas que deben ser contestadas por las personas que realiza la revisin. En caso de
que haya conflictos el revisor puede escribir sus recomendaciones en el rea para aparece para
este fin.

29

Figura 2.15. Forma para revisin de los requerimientos.

La desventaja de esta herramienta es que se encuentra ligada a un anlisis orientado a puntos de

vista para definir los requerimientos. Esto obliga a utilizar tcnicas de obtencin de
requerimientos que estn orientadas a este paradigma. No posee flexibilidad para elegir un
enfoque diferente como lo es la orientacin a objetos mediante casos de uso.
2.15. PARADIGMAS PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN.
Un paradigma o modelo del proceso de desarrollo de software, es una descripcin de las
actividades que se llevan a cabo en la elaboracin de un producto de software. Al proceso
completo de desarrollo, tambin se le conoce como ciclo de vida del software, debido a que en
l se detalla la vida de un sistema desde su concepcin, implementacin, entrega, utilizacin y
hasta su mantenimiento. En la literatura de Ingeniera de Software existe una variedad de
modelos o paradigmas de desarrollo. Los modelos ms utilizados se describen a continuacin.

30

El Paradigma Cascada, Evolutivo, Incremental o Iterativo, Espiral, Mtodos Formales, Basado en

Componentes, El RUP, etc. Siendo el Estrella y el RUP, el nuevo enfoque de Aplicacin,
mostrando una estructura Evolutiva Incremental.
2.15.1 DESARROLLO EN ESPIRAL
El modelo en espiral fue propuesto por Boehm en el ao de 1988. Este modelo representa el
proceso de software como una espiral, examina el progreso de desarrollo de software tomando en
consideracin los riesgos involucrados para minimizarlos y controlarlos, de esta forma combina
las actividades del desarrollo con la gestin del riesgo [1]. El espiral se divide en cuatro sectores
que comprenden: la definicin de objetivos, la evaluacin y reduccin de riesgos, el desarrollo y
validacin, y por ltimo la planeacin (figura 2.16).
El modelo fue desarrollado en el Pentgono como un mtodo para controlar los costos
desbocados de armas masivas y proyectos de desarrollo de sistemas de defensa. La idea fue
dividir el proyecto en fases ms cortas de anlisis, diseo, desarrollo y evaluacin. Despus de
cada fase se evala la viabilidad del trabajo terminado junto con una estimacin refinada para las
siguientes fases. Esta tcnica de presupuestacin proporciono revisiones de factibilidad cruciales
para proyectos en donde frecuentemente estaban haciendo investigaciones sobre tecnologas
completamente nuevas. Se toma una decisin en la fase de evaluacin sobre si se debe continuar
con otra iteracin de ajuste. La idea de la espiral ha cambiado ligeramente para adaptarse a las
sensibilidades peculiares de la industria de software.

31

Figura 2.16 Desarrollo en espiral.

El modelo del espiral se ajusta al avance de los proyectos, sin embargo requiere de una
administracin muy cuidadosa. El ciclo del espiral comienza con los requerimientos y un plan de
desarrollo, agregando una evaluacin de riesgos y construye prototipos alternativos antes de
escribir el documento de conceptos de operacin. El documento de conceptos de operacin
describe en un alto nivel como debe trabajar el sistema, es decir, especifica un conjunto de
requerimientos completos y consistentes. El principal producto de la primera iteracin es el
concepto de operaciones, en la segunda iteracin son los requerimientos, en la tercera iteracin el
diseo y de la cuarta son las pruebas. Para cada iteracin el anlisis de riesgos pondera diferentes
alternativas en base de los requerimientos y restricciones, el prototipado verifica el grado de
factibilidad antes de elegir alguna alternativa de desarrollo en particular, si se identifican riesgos
los lideres del equipo de desarrollo son los que deciden como eliminarlos o minimizarlos [1].
Caractersticas del modelo espiral
o Mejora los Ciclos de Vida Clsicos y Prototipos.
32

o Permite acomodar otros modelos.

o Incorpora objetivos de calidad y gestin de riesgos.

o Elimina errores y alternativas no atractivas al comienzo.

o Permite Iteraciones, vueltas atrs y finalizaciones rpidas.

o Cada Ciclo empieza identificando los objetivos de la porcin correspondiente, las

Alternativas y las Restricciones.
Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el plan para el
siguiente.
Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las
restricciones, y se analizan e identifican los riesgos. Si el anlisis de riesgo indica que hay una
incertidumbre en los requisitos, se puede usar la creacin de prototipos en el cuadrante de
ingeniera para dar asistencia tanto al encargado de desarrollo como al cliente. El cliente evala el
trabajo de ingeniera (cuadrante de evaluacin de cliente) y sugiere modificaciones. Sobre la base
de los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo.
Siendo la ultima iteracin el proceso de ajuste final. Obteniendo de esta manera un Sistema de
Informacin acorde a las exigencias del usuario.
2.16. INTERFACES GRFICAS DE USUARIO (GUI).
Los interfaces graficas de usuario (GUI) permiten el manejo directo de la representacin grafica
en la pantalla, proporcionan un panorama ms amigable y cmodo sujeto a las especificaciones
del usuario.
La clave para el GUI es la retroalimentacin constante sobre el logro de la tarea que proporciona.
La retroalimentacin continua del objeto manipulado significa que los cambios o reversiones en
las operaciones pueden hacerse rpidamente sin caer en mensajes de error.Retroalimentacin
para usuarios.7

Kendall & Kendall: ANALISIS Y DISEO DE SISTEMAS, 3ra. Ed., Mexico, Prentice Hall Hispanoamericana
S.A. 1997, p.657

33

2.17. ANALISIS Y DISEO DE SISTEMAS.

Tanto el Anlisis como el Diseo son actividades complementarias, veamos algunas definiciones:
Definicin Anlisis: El anlisis de sistemas es el estudio de una aplicacin del sistema de
informacin y de empresa actual y la definicin de las necesidades y las prioridades de usuario
para conseguir una aplicacin nueva o mejorada.8
Definicin Diseo: "Diseo es el proceso de aplicar distintas tcnicas y principios con el
propsito de definir un dispositivo, proceso, o sistema, con los suficientes detalles como para
permitir su realizacin fsica."9
Por lo tanto el Anlisis es el proceso de clasificar e interpretar los hechos, diagnostico de
problemas y empleo de la informacin para recomendar mejoras al sistema, mientras que el
Diseo es el proceso de planificar, reemplazar o complementar un sistema organizacional
existente, pero antes de llevar a cabo esta planeacin es necesario comprender, en su totalidad, el
viejo sistema, nos indica como transformar la necesidad producto del anlisis en formas que los
satisfaga, desarrollando modelos a partir de un conjunto de principios y/o heursticas que guan la
forma en la que se desarrolla el modelo, un conjunto de criterios que permiten discernir sobre
calidad y un proceso de iteracin que conduce finalmente a una representacin del diseo final.
Finalmente el Anlisis especifica QUE es lo que el sistema debe hacer. El Diseo establece
COMO alcanzar el objetivo.
Frecuentemente analista y diseador son la misma persona, sin embargo es necesario que se
realice un cambio de enfoque mental al pasar de una etapa a la otra. Al abordar la etapa de diseo,
la persona debe cambiar de un razonamiento de analista a un razonamiento de diseador.
.
.
.
..
.
..
.
..
.

8
9

Whitten y Bentley y Barlow: ANALISIS Y DISEO DE SISTEMAS, 3ra. Edicion., Espaa, Irwin, 1996, p.265
E.S. Taylor: AN INTERIM REPORT ON ENGINEERING DESIGN, Massachussets Institute of Technology, 1959

34

2.18. DISEO DE ENTRADAS.

Las decisiones de diseo para el manejo de entradas especifican la forma en que sern aceptados
los datos para su procesamiento por computadora. .Los analistas deciden que los datos sern
proporcionados directamente o quizs a travs de una estacin de trabajo. El diseo de la entrada
tambin incluye la especificacin de los medios por lo que tanto los usuarios finales como los
operadores darn instrucciones al sistema sobre las acciones que deben emprender.
Los analistas de sistemas deciden los siguientes detalles del diseo de entradas:
o Que datos ingresan al sistema
o Que medios utilizar
o La forma en que se deben disponer o codificar los datos
o El dialogo que servir de gua a los usuarios para dar entrada a los datos
o Validaciones necesarias de datos y transacciones para detectar errores
o Mtodos para llevar a cabo la validacin de las entradas y los pasos a seguir
cuando se presentan errores
La disposicin de mensajes y comentarios, as como la ubicacin de los datos, encabezados y
ttulos sobre las pantallas o documentos fuentes, tambin forman parte del diseo de entradas.
2.19. DISEO DE SALIDAS.
El trmino salida, se refiere a los resultados e informacin generados por el sistema. Para muchos
usuarios finales, la salida es la nica razn para el desarrollo del sistema y la base sobre la que
ellos evaluaran la utilidad de la aplicacin. En la realidad, muchos usuarios no operan el sistema
de informacin y tampoco ingresan datos con l, pero utilizan la salida generada por el sistema.
Cuando disea la salida, los analistas deben realizar lo siguiente:
o Determinar que informacin presentar
o Decidir si la informacin ser presentada en forma visual, verbal o impresa.
o Disponer la presentacin de la informacin en un formato aceptable.
o Decidir como distribuir la salida entre los posibles destinatarios.
35

La disposicin de la informacin sobre una pantalla o documento impreso se denomina

distribucin.
Para llevar a cabo las actividades antes mencionadas, se requieren decisiones especficas tales
como el empleo de formatos ya impresos cuando se preparan reportes, cuantas lneas planear
sobre una pgina impresa o si se deben emplear graficas y colores.
El diseo de la salida esta especificado en los formularios de distribucin, que son hojas que
describen la ubicacin, caractersticas (como longitud y tipo) y formato de los encabezados de
columnas y la paginacin.
2.20. PRUEBAS DEL SISTEMA.
Durante la prueba, el sistema se utiliza en forma experimental para asegurar el software no falle,
es decir, que correr de acuerdo con sus especificaciones y a manera en la que los usuarios
esperan que lo haga. Se examinan datos especiales de prueba en la entrada del procesamiento y
los resultados para localizar algunos problemas inesperados. Puede permitirse tambin a un grupo
limitado de usuarios que utilice el sistema, de manera que los analistas puedan captar si tratan de
utilizar, o en forma no planeadas. Para esto las pruebas se basaran en la Prueba de la Caja Negra
y La Prueba de la Caja Blanca.
2.20.1 PRUEBA DE LA CAJA NEGRA.
Las pruebas funcionales o de caja negra son un enfoque para llevar a cabo pruebas donde estas
derivan de la especificacin del programa o componente. El sistema es un caja negra cuyo
comportamiento solo se puede determinar estudiando las entradas y salidas relacionadas. Otro
nombre de estas pruebas funcionales debido a que el probador solo le interesa la funcionalidad y
no la implementacin del software.
El probador introduce

las entradas en los componentes del sistema y examina las salidas

correspondientes. Si las salidas no son las previstas, entonces la prueba ha detectado

exitosamente un problema con el software.
El problema clave para el probador de defectos es seleccionar las entradas que tienen una alta
probabilidad de ser miembros de un conjunto de entradas que provocan comportamiento
anmalo. En muchos casos, la seleccin de estos casos de prueba se basa en la experiencia previa
de los ingenieros de pruebas.10

10

Sommerville, Ian: INGENIERIA DE SOFTWARE, 6ta. Ed. Mexico, Pearson Educacin, 2002, p.443

36

Es casi imprescindible lograr una cobertura de caja negra del 100%, pues los usuarios se
quejaran con todo derecho de fallos de este calibre.
Las actividades de las pruebas seran:
o Ignora la estructura de control
o Diseo de pruebas
o Datos entrada -> Buen caso de prueba
o Atencin a la informacin
2.20.2 PRUEBA DE LA CAJA BLANCA.
Las pruebas estructurales o de caja blanca, caja de cristal o de caja transparente son un
enfoque de prueba donde estas se generan a partir del conocimiento de la estructura e
implementacin del software.
Por lo general, las pruebas estructurales se aplican a unidades del programa relativamente
pequeas como las rutinas o las operaciones asociadas con un objeto. Como su nombre indica, el
probador puede analizar el cdigo y utilizar el conocimiento de la estructura de un componente
para derivar los datos de prueba. El anlisis de cdigo se puede utilizar para descubrir cuantos
casos de prueba son necesarios para garantizar que todas las instrucciones del programa o
componente se ejecuten al menos una vez.11
Puede que habiendo logrado una cobertura de caja negra del 100%, midamos una cobertura de
sentencias (Pruebas de Caja Blanca) del 100%. Puede ser que partes del cdigo no hayan sido
ejecutadas jams (la cobertura de sentencias es inferior al 100%). En estos casos hay que pasar
ms pruebas buscando que se ejecuten todas y cada una de las sentencias del programa.
En el caso extremo de que no haya forma de ejecutar alguna parte del programa, deberamos
preguntarnos si esa parte sirve para algo, o si podemos prescindir de ella.
La cobertura de las pruebas de Caja Blanca sera:
o Ejercitar una vez todos los caminos.
o Ejercitar todas las decisiones (V/F).
o Ejercitar todos los bucles (lmites).
11

Sommerville, Ian: INGENIERIA DE SOFTWARE, 6ta. Edicin, Mxico, Pearson Educacin, 2002 p.449

37

[1] Shari Lawrence Pfleeger, Ingeniera de Software, teora y prctica, Prentice Hall, 2002.
[2] Sommerville Ian, Software Engineering, Wiley, 1998.
[11]

Kotonya

Gerald,

Sommerville

Ian,

Requirements

techniques,Wiley, 2000.

38

Engineering,

processes

and