3.2 ANÁLISIS DE REQUERIMIENTOS Y DISEÑO INICIAL

ANÁLISIS-DETERMINACIÓN DE LOS REQUERIMIENTOS

“Esta etapa consiste en una investigación descriptiva del sistema actual, mediante hechos, para conocerlo en profundidad e inferir cuáles son los requerimientos que debe satisfacer el nuevo sistema”. (Cáceres, 2014)

Hechos: Para llegar a un sistema mejor que el actual, debemos conocerlo

adecuadamente. Sintéticamente, debemos saber qué hace bien, qué hace mal, qué le

sobra y qué le falta. El nuevo sistema deberá incluir lo que hace bien, hacer bien lo

que hace mal, eliminar lo que sobra, incorporar lo que falta.

Mientras mejor se conozca el sistema actual, mejor será el nuevo sistema. La única

forma de conocer adecuadamente el sistema actual es mediante hechos. Recordemos

que un hecho es un dato verificado. La despreocupación por obtener hechos produce

muchos inconvenientes, que podemos resumir como sigue.

Conocimiento incierto del sistema actual. Si los datos no son verificados pero

se los toma como ciertos, el conocimiento del sistema actual no será cierto.

Requerimientos inciertos. El nuevo sistema resultará de requerimientos que se

deducen del sistema actual. Pero si éste no se conoce con certeza, los

requerimientos serán inciertos, lo que llevará a diseñar un nuevo sistema sobre

bases inciertas.

Desperdicio. El trabajo del analista basado en opiniones tendrá poco valor, con

lo cual se habrá malgastado tiempo y dinero.

Con respecto a la calidad de hechos a recolectar, deben estar en función del

objetivo del proyecto, es decir, deben ser pertinentes. Hay que recolectar no

cualquier hecho, sino aquéllos que contribuyan a conocer el sistema actual.

Con respecto a la cantidad de hechos a recolectar, deben ser suficientes. Esto

significa que no deben ser menos de los necesitados para conocer el sistema,

pues el conocimiento sería incompleto; pero tampoco más, pues el costo de

conseguirlos aumentaría innecesariamente, sin aportar conocimiento relevante.

Acá vale el criterio que se aplica en la investigación preliminar: detener la

investigación de un aspecto cuando la información adicional que se obtenga

redunde con la información ya obtenida. Para recolectar los hechos se puede

aplicar cualquier técnica de recolección de datos o combinaciones de ellas. El

tipo de hecho determina la técnica a usar.

Hechos a buscar No hay una forma estipulada para buscar hechos, pero

conviene comenzar por las salidas. Identificadas éstas, se pueden identificar

los procesos que las producen, las entradas que brindan los datos y los

archivos donde se almacenan éstos.

Salidas. La forma más habitual de las salidas son los tabulados, sean impresos

o en pantalla. Otras formas también usuales son gráficos y textos

personalizados. Muchas de las salidas que produce el sistema actual son

“naturales”, por lo que resulta fácil conseguirlas. En un sistema de ventas, por

ejemplo, seguramente hay facturas, listas de precios, resúmenes de ventas en

cantidades y pesos. Otras salidas, que usan confidencialmente los jefes, son

más difíciles de obtener.

Sea para ejemplificar un informe mensual que usa el gerente de ventas, donde

se resume por cada empleado cuántos días trabajó, cuánto y cuáles rubros

vendió, cuántas devoluciones y reclamos hubo. El informe es confidencial,

porque sirve para calificar a cada vendedor. La manera de conocer estas

salidas confidenciales es que el analista cuente con la colaboración efectiva y

motivada de quienes las usan, para que las hagan conocer.

Observando las salidas, se puede saber si sus aspectos formales son

adecuados y se pueden reconocer los datos utilizados para producirlas. Pero

su validez funcional debe evaluarse en relación a las necesidades de los

usuarios. Ellos son la clave para saber si las salidas actuales sirven o no, si

deben modificarse y si se necesitan otras, ahora inexistentes. Con respecto a

estas últimas, el analista y los usuarios afectados deben definir su contenido.

Esto permitirá conocer los datos y establecer los procesos que las producirán.

Procesos. Como las salidas resultan de procesos, conociendo las salidas

actuales se determinan los procesos generadores. Los procesos son una

secuencia de pasos y pueden ser manuales o automáticos. Por procesos

manuales queremos decir procedimientos de oficina, representables por

cursogramas. Los procesos automáticos están contenidos en programas de

computadora.

El analista debe entender bien los procesos actuales, porque no son evidentes

como las salidas y pueden ser complicados. Esto hará que pueda

perfeccionarlos o eliminarlos en el diseño del nuevo sistema. Las salidas

inexistentes actualmente, pero necesitadas, van a requerir nuevos procesos en

el nuevo sistema. La obtención de hechos sobre procesos debe centrarse en

aquellos que sean complejos, requieran cálculos complicados y cuándo deben

realizarse.

Entradas. Hay que determinar todos los datos que entran al sistema actual y

cuáles documentos los soportan. Las salidas ayudan a encontrar la mayoría de

esos datos, pero no todos. Muchos datos de salida son simples transcripciones

de los datos de entrada, tal como fueron capturados; por ejemplo los nombres

y domicilios de los clientes. Otros datos de salida resultan de cálculos con

datos de entrada, como el total vendido en una semana, que es la suma de los

productos entre cantidad y precio de cada factura.

Archivos. En sistemas computarizados, los datos de entrada se guardan en

archivos a través de captura. Es fácil obtener listados de los archivos del

sistema actual, sus campos de datos y los índices que emplean. Si estos

archivos usan campos que guardan códigos, es necesario conocer la ley de

formación y si se llenan manual o automáticamente. Si hay campos que

guardan datos de control llenados por procesos posteriores a la captura, hay

que averiguar en qué consisten esos controles.

En lo posible, los archivos del sistema actual deberán ser reciclados para

obtener los archivos del nuevo sistema. Esto a veces es sencillo y otras veces

necesita programas complejos para convertirlos.

Circunstancias. Adicionalmente a los hechos sobre salidas, procesos, entradas

y archivos, hay otros que también van a influir en el diseño del nuevo sistema.

Sólo podemos dar ejemplos de tales hechos, ya que dependen de las

circunstancias en que se desarrolla cada proyecto. Así, la normativa legal que

regula la actividad de la empresa; la decisión ya tomada de vender por Internet,

cobrar a los clientes mediante débitos bancarios automáticos o abrir nuevas

sucursales, etc.

DISEÑO INICIAL

Concluido el análisis del sistema actual, se tiene suficiente conocimiento de él como

para describirlo. Sin embargo, el propósito no es describir algo que va a dejar de

existir, sino concluir qué características de él deben sobrevivir en el nuevo sistema y

qué nuevas características debe tener éste. Algunas de las nuevas características

surgen por la comprobación de su inexistencia en el sistema actual, siendo que

debería poseerlas necesariamente; otras nacen de la imaginación, el conocimiento y la

experiencia del analista y de los usuarios.

Generalmente, éstos necesitan que el nuevo sistema no sea un remiendo del actual,

sino una creación original, para circunstancias internas y ambientales quizás muy

diferentes a aquéllas que dieron origen al sistema actual. Esto hace necesario la

incorporación de muchas características nuevas. “El analista deberá tener presentes los requerimientos cuando diseñe el nuevo sistema” (Bentley, 2015).

Hay requerimientos comunes a cualquier sistema, de modo que no es necesario

registrarlos. Otros, específicos al sistema a diseñar, deben ser anotados, para no

olvidarlos.

3.2.1 Dimensionamiento de volúmenes y sistemas

Requerimientos comunes: Los sistemas deben cumplir con ciertos

requerimientos comunes, de modo que son una guía para cualquier analista.

Veamos algunos.

Calidad. El nuevo sistema debe ser valioso en cuanto a calidad de información,

redundancia mínima, facilidad operativa, controles suficientes y eficiencia.

Mientras mejor cumpla estos aspectos, más calidad tendrá el nuevo sistema en

sí mismo y más calidad tendrá el servicio que preste a los usuarios directos e

indirectos. Las consideraciones realizadas al analizar los hechos del sistema

actual contribuyen a aplicar este criterio.

Flexibilidad. Los cambios internos y externos de la institución pueden ser

radicales, convirtiendo en obsoleto el sistema actual de un momento para otro.

Pero la mayoría de los cambios son menores, de modo que el nuevo sistema

debe ser lo suficientemente flexible para poder adaptarse a ellos. Veamos un

ejemplo. Sea un proceso de un sistema que liquida un impuesto.

Si las escalas de montos y tasas se introducen como instrucciones de

programación, cuando se produzca un cambio en las escalas el proceso el

programa quedará inutilizado. Esto se da porque el sistema tiene una rigidez

en tal proceso. En cambio, si las escalas se registran en una tabla que puede

ser modificada en otro proceso, los cambios de escala obligarán a modificar

esa tabla, pero no afectarán el proceso de liquidación. Este sencillo recurso ha

introducido flexibilidad, permitiendo que el sistema resista el golpe.

Adaptación tecnológica. La calidad del nuevo sistema depende de la tecnología

empleada. La disponibilidad de tecnología en hardware y software puede

cambiar radicalmente la forma de encarar el nuevo sistema. Si la tecnología

ideal tiene un precio inalcanzable, habrá que considerar la mejor tecnología

dentro de la capacidad financiera de la institución, que se adecue a los

requerimientos. La carencia de tecnología adecuada puede hacer imposible un

nuevo sistema de calidad.

Realismo. Los requerimientos deben adecuarse a la realidad de la empresa.

No es posible pensar en procesos que exijan lenguajes desconocidos por los

programadores disponibles; en el manejo de software complejo por empleados

cuyo nivel intelectual es insuficiente; en formas de trabajo que impongan

cambios culturales improbables; etc.

3.2.2 Incorporación de controles

Los controles son esenciales en los sistemas de información. Hay distintos tipos, de

los que veremos algunos. “Estudiar los controles que emplean los procesos actuales sirve para descubrir fallas que hay que subsanar y mecanismos seguros que deben ser mantenidos en el nuevo sistema” (CIAMPAGNA, 2011). Sin embargo, esto no basta. La importancia de los datos y los procesos puede

llevar a establecer nuevos controles futuros.

Controles de datos. Son los que hemos visto como validación simultánea o

posterior, mediante códigos, rangos, consistencia, dígitos verificadores,

integridad referencial, etc. Se aplican a la captura o transcripción de datos,

procurando reducir el ingreso de errores al sistema. Como esos datos

originales son la materia prima para la elaboración de datos calculados y de

información, es vital controlarlos.

Controles de procesos. Se aplican cuando se deben realizar distintos

procesos según un orden prefijado, sin omitir ninguno. En los sistemas

manuales, por ejemplo, son los vistos buenos que se incorporan a un

formulario, a medida que se va procesando en distintas unidades

funcionales. Permiten saber si falta alguna intervención. En sistemas

computarizados, los procesos se pueden controlar mediante una tabla

diseñada al efecto.

Por ejemplo, sea una empresa que fabrica a pedido productos que requieren

tres etapas sucesivas de diseño, fabricación y pintura. Al recibir un pedido,

la Gerencia Industrial da de alta un registro en una tabla de productos en

proceso, con el número de pedido, otros datos complementarios y tres

campos de fecha de terminación, uno para cada etapa. Cuando el sector

Diseño completa su trabajo, manda un parte a Gerencia Industrial, que llena

la fecha de cumplimiento de diseño en el registro correspondiente.

Cuando el sector Fabricación completa su trabajo, manda un parte a

Gerencia, que llena la fecha de fabricación. Cuando el sector Pintura

completa su trabajo, manda un parte a Gerencia, que llena la fecha de

pintura. Si Fabricación comunicara haber terminado un producto todavía no

diseñado o Pintura haber pintado un producto todavía no diseñado o no

fabricado, el programa de carga debe detectar la anormalidad y no permitir

llenar la fecha correspondiente.

El gerente puede consultar el registro de un pedido particular para ver su

estado de avance, obtener un informe de todos los productos en proceso,

etc.

Controles de seguridad. Son los que permiten acceder al sistema a quienes

tienen autorización para hacerlo, impidiendo el ingreso de extraños. En

sistemas manuales, por ejemplo, para ingresar al tesoro de un banco, se

establece que la clave para abrir la puerta sea conocida solamente por el

tesorero y el gerente general, quienes pueden tener dos llaves que en

conjunto abran la puerta. En sistemas computarizados en red se usan

claves de usuario para entrar a ellos.

El supervisor del sistema, que tiene acceso total a él, define a cada persona

autorizada en una tabla de usuarios. La definición incluye: (1) datos del

usuario; (2) una clave invariable que lo identifica, accesible al supervisor

pero inaccesible al usuario; (3) una clave personal del usuario, que por

razones de seguridad puede o debe cambiar periódicamente; (4) los

permisos otorgados al usuario: leer archivos, modificarlos, copiarlos,

destruirlos, imprimirlos, etc.

Para ingresar, cada usuario debe proporcionar su clave personal, que está

asociada a la clave invariable. Si hay correspondencia entre ambas, la

persona puede ingresar, con los permisos que tiene otorgados.

Además de la tabla de usuarios, suele llevarse otra tabla de conexiones.

Cada vez que un usuario se conecta a la red, se agrega un registro a esta

tabla, llenando su clave invariable y la hora de conexión. Cuando termina su

trabajo, en el registro que le corresponde se llena la hora de desconexión.

Esta tabla permite saber quiénes han estado conectados un día y a una

hora determinados. Como el lector puede inferir, mantener usuarios y

permisos es una tarea de administración delicada.

El supervisor de este sistema debe ser cuidadosamente elegido, porque se

le exige confidencialidad máxima.

Controles de responsabilidad. Son los que permiten conocer quién intervino

en un proceso. En sistemas manuales, por ejemplo, son el agregado de las

iniciales de quien escribió una nota o llenó un formulario, o la firma y el sello

de quien dio una autorización. En sistemas informatizados, cuando es

importante controlar quién realizó una tarea riesgosa, se desarrolla un

mecanismo de control más refinado.

Controles de autenticidad. Son los que procuran que los datos, informes,

credenciales, etc., no sean alterados o falsificados. Veamos algunos

ejemplos. Para asegurar la autenticidad de una nota, es común el uso de

membretes y la aclaración de las firmas mediante sellos.

En los documentos donde se escriben importes y otros datos importantes,

se pueden usar tramados para dejar en evidencia si el papel ha sido

borrado; asteriscos de protección en lugar de espacios izquierdos, como en

***.**7.247,29; signos flotantes adheridos al dígito izquierdo de una cifra,

como en $7.247,29 o $5.744.300,00; impresión de importes en números y

en palabras; etc.

En los mensajes y documentos enviados por correo electrónico, se usan

firmas digitales que garantizan la autenticidad del remitente y la no

adulteración del mensaje.

Controles de funcionamiento. Son los que comprueban que las distintas

actividades de un sistema funcionen correctamente. No son parte

constitutiva del sistema, sino que forman una auditoría sobre él. Se aplican

intensamente durante la etapa de pruebas, sometiendo el sistema a datos

simulados, correctos y erróneos. Debido que estas simulaciones, por

meticulosas que sean, pueden no agotar todas las combinaciones de

circunstancias, quizás queden casos sin probar.

3.3 Especificaciones detalladas/Documentación

Según los estándares de la IEEE el documento de especificación de requerimientos de

software deben tener los siguientes ítems:

Descripción de la Funcionalidad de la Aplicación.

Descripción de la relación de la Aplicación con Sistemas e Interfaces Externas.

Descripción de las métricas de Desempeño del Sistema (Velocidad,

disponibilidad, tiempos de respuesta y mantenibilidad).

Limitaciones de la implementación (Lenguaje de desarrollo, políticas de Base

de Datos, Sistemas Operativos y otros Recursos utilizados).

Además tiene que cumplir con las siguientes características:

Debe ser correcta.

No debe ser ambigua.

Debe ser completa.

Debe ser consistente.

Debe ser verificable.

Debe ser modificable.

Debe proveer trazabilidad.

Para lograr los objetivos y resultados anteriormente mencionados, el grupo de trabajo

propone el seguimiento de un proceso estructurado que culminará con la elaboración y

verificación de los artefactos de salida mencionados a continuación:

Documento de definición de Requerimientos Funcionales.

Documento de definición de Requerimientos No Funcionales.

A CRITERIOS DE INICIO O CRITERIOS DE ENTRADA: Este proceso se inicia

inmediatamente después de la aprobación del acta de inicio del proyecto para

el desarrollo del sistema para el seguimiento de la gestión de proyectos de

software. Adicionalmente se cuenta con el enunciado general de

requerimientos del proyecto, a partir del cual se desarrollará el proceso de

especificación.

B OBJETIVO DEL PROCESO: El objetivo principal del proceso de especificación

es lograr definir de forma clara y precisa cada uno de los requerimientos del

Sistema para el seguimiento de la gestión de proyectos de desarrollo de

Software.

El seguimiento adecuado del proceso además nos permitirá:

Disminuir el número de defectos encontrados en la fase de

implementación del producto de software.

Realizar la fase de implementación de forma ágil y con la seguridad de

estar desarrollando exactamente las necesidades del cliente.

Lograr un dimensionamiento adecuado del tamaño del sistema.

Como resultado final del proceso de especificación deben quedar

elaborados, validados y verificados los siguientes entregables:

Documento de definición de Requerimientos Funcionales

Documento de definición de Requerimientos No Funcionales

C RESPONSABLES DEL PROCESO: El proceso de especificación será

desarrollado conjuntamente por todo el equipo de trabajo, realizando una

distribución equitativa de cargas de trabajo. El proceso estará dirigido por el

líder del proyecto y el aseguramiento de la calidad estará a cargo del Líder de

Calidad.

D Entradas: Las siguientes son las actividades que se deben ejecutar durante el

proceso de Especificación de Requerimientos.

Enunciado del trabajo del Proyecto : El enunciado del trabajo es la entrada que

describe la oportunidad o necesidad de negocio que la organización ha

identificado y por la cual se dio origen al proyecto. Adicionalmente, indica el

alcance y los requisitos del producto los cuales servirán de apoyo para los

procesos posteriores principalmente al proceso de planeación.

Acta de constitución: El acta de constitución, contiene información de los

objetivos, alcance, restricciones y demás, que se deben tener en cuenta para la

planeación del proyecto.

Formatos establecidos para la especificación : Son las plantillas definidas para

construir los documentos involucrados en este proceso. Las plantillas son:

o “Plantilla de especificación de requerimientos funcionales: En esta

plantilla se especifica de forma detallada el formato de cada uno de los casos de uso que componen el sistema”. Para esto se propone el formato. (Formato basado en el documento de especificación de

requerimientos, siglo21)

o Documento de especificación de requerimientos no funcionales: En

este documento se especificarán los requerimientos no funcionales del

sistema Este documento contará con las siguientes secciones:

REQUERIMIENTOS NO FUNCIONALES MANIFIESTOS.

Desempeño

Disponibilidad

Usabilidad

REQUERIMIENTOS NO FUNCIONALES OPERACIONALES

Robustez

Escalabilidad

Seguridad

Interoperabilidad

REQUERIMIENTOS NO FUNCIONALES DE DESARROLLO

Base De Datos

Servidor Web De Aplicaciones

Navegador Web

Máquina Virtual De Java

E ACTIVIDADES: Las siguientes son las actividades que se deben ejecutar

durante el proceso de Especificación de Requerimientos.

Análisis del mundo del sistema

Descripción: Realizar un análisis preliminar del mundo del sistema.

Resultado: Descripción del mundo del sistema.

Responsable: Líder del Proyecto

Participantes: Líder de Soporte.

Identificación de Módulos del Sistema y/o Procesos de Negocio

Descripción: Identificar los módulos que conforman el sistema y

elaborar el documento que los describe.

Resultado: Documento de Módulos del Sistema

Responsable: Líder del Proyecto

Participantes: Líder de Soporte.

Identificación de todos los actores que componen el Sistema

Descripción: Identificar los actores que intervienen en el sistema y

elaborar el correspondiente Documento de Actores del Sistema

Resultado: Documento de Actores del Sistema.

Responsable: Líder del Proyecto

Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto.

Especificación detallada de Requerimientos Funcionales

Descripción: Elaboración de los documentos de especificación

detallada de Casos de Uso.

Resultado: Documento de Especificación detallada de Casos de Uso.

Responsable: Líder del Proyecto.

Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto

Especificación de Requerimientos No Funcionales

Descripción: Elaboración del Documento de Especificación de

Requerimientos No Funcionales del Sistema.

Resultado: Documento de Especificación de Documentos No

Funcionales del Sistema

Responsable: Líder de Desarrollo

Acta de Aprobación

Descripción: En este documento se aprueba por parte del Cliente

(Profesor y Monitor) y por parte del Equipo de Trabajo el proceso de

especificación de requerimientos del Sistema.

Resultado: Acta de Aprobación de la Especificación del Sistema,

firmada por el Cliente y por el equipo de trabajo.

Responsable: Líder del Proyecto.

Participantes: Líder del Proyecto, Profesor, Monitor

F SALIDAS: Las siguientes son las salidas del proceso de Especificación de

Requerimientos.

Documento de Especificación de Módulos del Sistema:

En este documento se identifican los módulos que componen el

Sistema de Información y se da una descripción de cada uno de ellos,

indicando sus características y principales responsabilidades.

Documento de Especificación de Requerimientos Funcionales:

En este documento se especifica de forma detallada cada uno de los

casos de uso que componen el sistema.

Documento de Requerimientos No Funcionales del Sistema:

En este documento se especificarán los requerimientos no funcionales

del sistema.

G CRITERIOS DE TERMINACIÓN DEL PROCESO: El proceso finaliza una vez

se hayan ejecutado todas las actividades definidas y como resultado de la

revisión del mismo, se firmará la correspondiente Acta de Aprobación de la

Especificación del Sistema.

3.3.1 Diseño de pantallas e informes

La sola recolección de hechos, no los hace directamente analizables. Para

apreciarlos con claridad, detectar fallas e idear soluciones, normalmente hay que

describirlos mediante textos o gráficos, ordenarlos, contarlos, resumirlos, tabularlos,

etc. Estas son soluciones de sentido común, que inventa el analista en cada

ocasión. Por otro lado y complementariamente, existen herramientas con propósitos

específicos, que han sido desarrolladas por académicos y especialistas.

Son ejemplo de ellas los cursogramas, adecuados para exponer gráficamente

procedimientos manuales, y las tablas de decisión, que sintetizan procesos para

realizar distintas acciones, dependiendo del estado de varias condiciones. Las

herramientas tienen la ventaja de ser precisas y sintéticas. Son también versátiles,

porque pueden aplicarse en varios momentos del proyecto, como se explica a

continuación.

EXPOSICIÓN DE HECHOS. Permiten expresar con claridad un hecho o un

conjunto relacionado de ellos, constituyendo una forma de documentarlos.

ANÁLISIS DE HECHOS. Facilitan el análisis de los hechos del sistema

actual, posibilitando el hallazgo de errores, complicaciones y carencias.

DISEÑO DEL NUEVO SISTEMA. Sirven para diseñar el nuevo sistema, ya

sea en forma general o en aspectos particulares.

PROGRAMACIÓN. Permiten expresar con exactitud muchas de las

instrucciones que el analista debe escribir para los programadores.

En lo que sigue, veremos algunas de las herramientas. Advierta que hay muchas

más que las tratadas aquí. Tenga también en cuenta que, por ser herramientas,

sirven de ayuda al analista, pero no reemplazan por sí solas el esfuerzo, la agudeza

ni la inventiva requerida de este especialista.

Lenguaje estructurado: Esta herramienta consiste en usar estructuras lógicas y

sintácticas para controlar la ejecución de un conjunto de acciones. Las estructuras

lógicas se refieren a modos eficientes de controlar la ejecución de acciones. Las

estructuras sintácticas son la traducción de las estructuras lógicas a fórmulas

lingüísticas precisas, en la lengua nativa del país. Las estructuras sirven para

controlar rigurosamente la ejecución de las acciones.

La herramienta fue inicialmente desarrollada para lenguajes de programación, pero

dada su potencia ha sido ampliada a otros ámbitos. El lenguaje estructurado sirve

para documentar y analizar procedimientos de cualquier grado de complejidad.

También es útil como herramienta de diseño, para dar instrucciones a los

programadores.

Estructuras lógicas: Tras años de programar computadoras, se concluyó que

todos los programas pueden ejecutar sus comandos siguiendo tres modalidades.

Estas fueron llamadas estructuras lógicas de secuencia, selección e iteración. Gran

parte de las complicaciones y fallas de programación se debían a no haberlas

respetado adecuadamente. A partir de allí, cambió no sólo la forma de escribir los

programas, sino que fueron modificados los mismos lenguajes de programación

para incluir comandos explícitos que materializaran estas estructuras.

Un programa que observa las estructuras lógicas es más fácil de escribir y menos

propenso a fallar, porque ellas controlan mejor el funcionamiento y facilitan hallar

errores debidos a la mala ubicación de un comando. Como los comandos de

programación no son sino condiciones y acciones, las estructuras lógicas pueden

aplicarse también a cualquier conjunto de condiciones y acciones para realizar un

procedimiento.

3.3.2 Diagramación de flujo de requerimientos de hardware y software

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”. (SENN, Enero 1990 )

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.

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.

CÁLCULO DE LAS CARGAS DE TRABAJOEl próximo paso en la determinación de las necesidades de hardware es

calcular las cargas de trabajo. Así, los analistas de sistemas establecen

cifras que representan las cargas de trabajo actuales y proyectadas para el

sistema con el fin de que cualquier hardware que se adquiera cuente con la

capacidad para manejar las cargas de trabajo actuales y futuras.

Si las estimaciones se realizan adecuadamente, la empresa no debe

reemplazar el hardware tan sólo por el crecimiento inesperado en el uso del

sistema. (Sin embargo, otros eventos, como innovaciones tecnológicas

superiores, pueden dictar el reemplazo del hardware si la empresa quiere

mantener su ventaja competitiva.)

Aparte de la necesidad, las cargas de trabajo se muestrean en lugar de

completarlas realmente en varios sistemas de cómputo. Los lineamientos

sobre el muestreo proporcionados en el capítulo 5 pueden ser útiles aquí, ya

que en el muestreo de las cargas de trabajo el analista de sistemas toma

una muestra de las tareas necesarias y los recursos de cómputo requeridos

para completarlas.

La siguiente figura es una comparación de los tiempos requeridos por un

sistema de información actual y uno propuesto que se supone manejan una

carga de trabajo dada.

Observe que la compañía está usando actualmente un sistema manual para

preparar un resumen mensual de los envíos a sus almacenes de

distribución, y se está sugiriendo un sistema de cómputo. La comparación

de las cargas de trabajo toma en cuenta el costo por hora de cada sistema,

cuándo y cómo se realiza cada proceso, cuánto tiempo humano se requiere

y cuánto tiempo de la computadora se necesita.

DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWAREFue “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".

(crea tu web Alojado en Galeon.com Hispavista) 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.

3.3.3 Definición de requerimientos técnicos

Comprende los recursos técnicos y tecnológicos que debes estar disponibles para

desarrollar la aplicación, perfil del personal técnico para dar mantenimiento a la

aplicación, sistema operativo, herramienta para programación, base de datos, etc.

Adquisición de software para la administración de LOGs y monitoreo de seguridad,

que incluya la configuración, pruebas, instalación, administración, soporte y

mantenimiento. La solución a contratar debe permitir identificar de manera

anticipada eventos de acceso, disponibilidad e integridad del hardware, software e

información y teniendo como premisa principal que estos sistemas (software) deben

garantizar una correcta integración con el sistema COBIS con el fin de no poner en

riesgo la operación y rendimiento del sistema.

3.4 Evaluación y adquisición de hardware

EVALUACIÓN DEL HARDWARE DE CÓMPUTOLa evaluación del hardware de cómputo es una responsabilidad compartida de

los directivos, usuarios y analistas de sistemas. Aunque los fabricantes

proporcionarán detalles acerca de los productos que ofrezcan, los analistas

necesitan supervisar personalmente el proceso de evaluación porque ellos se

preocuparán por los mejores intereses del negocio.

Además, tal vez los analistas de sistemas tengan que enseñar a los usuarios y

a los directivos las ventajas y desventajas generales del hardware para que

puedan evaluarlo de manera eficaz.

Con base en el inventario actual del equipo de cómputo y en las estimaciones

adecuadas de las cargas de trabajo actuales y futuras, el siguiente paso en el

proceso es considerar los tipos de equipo disponibles que parezcan satisfacer

las necesidades proyectadas. La información que los fabricantes ofrezcan

acerca de los posibles sistemas y las configuraciones de éstos será más

apropiada en esta fase y debe revisarse de manera conjunta con los directivos

y los usuarios.

Además, las cargas de trabajo se pueden simular y ejecutar en diferentes

sistemas, incluyendo los que ya se usan en la organización. Este proceso se

llama benchmarking (evaluación comparativa). Entre los criterios que los

analistas de sistemas y los usuarios deben usar para evaluar el desempeño de

los diferentes sistemas de hardware están los siguientes:

1. El tiempo requerido para las transacciones promedio (incluyendo cuánto

tiempo toma la entrada de datos y cuánto obtener la salida).

2. La capacidad de volumen total del sistema (cuánto se puede procesar al

mismo tiempo antes de que ocurra un problema).

3. El tiempo que la unidad central de procesamiento se mantiene inactiva.

4. El tamaño de la memoria proporcionada.

Algunos criterios se presentarán en demostraciones formales; algunos no se

pueden simular y es necesario obtenerlos de las especificaciones de los

fabricantes. Durante las demostraciones es importante estar seguro de cuáles

son las funciones requeridas y cuáles las deseadas antes de analizar

detalladamente las afirmaciones de los fabricantes. Una vez que se conocen

los requerimientos funcionales y que se comprenden los productos actuales

disponibles y se comparan con los que ya existen en la organización, los

analistas de sistemas deciden en conjunto con los usuarios y los directivos si

es necesario obtener nuevo hardware.

Se puede considerar que las opciones van desde utilizar únicamente equipo

disponible en el negocio hasta adquirir equipo totalmente nuevo. Entre estos

dos puntos hay opciones intermedias como la de hacer modificaciones

menores, o mayores, al sistema de cómputo actual.

Tamaño y uso de la computadora: El rápido avance de la tecnología obliga a

los analistas de sistemas a investigar qué tipos de computadoras están

disponibles en el momento específico en que se escribe la propuesta de

sistemas. El tamaño de las computadoras va desde las pequeñas

computadoras Palm que caben en una mano hasta las supercomputadoras que

podrían ocupar toda una sala. Cada una tiene atributos diferentes que se

deben considerar al decidir cómo implementar un sistema de cómputo.

ADQUISICIÓN DEL EQUIPO DE CÓMPUTO Las tres opciones principales para la adquisición de hardware de cómputo son

la compra, el arrendamiento financiero o el alquiler. Como se muestra en la

siguiente figura, hay ventajas y desventajas que se deben analizar para cada

una de las decisiones.

Algunos de los factores que se deben tomar en cuenta al momento de

determinar cuál opción es mejor para una instalación en particular incluyen los

costos iniciales versus los costos a largo plazo, si la empresa se puede dar el

lujo de invertir capital en el equipo de cómputo y si desea tener el control total y

la responsabilidad sobre el equipo de cómputo.

La compra implica que la empresa poseerá el equipo. Uno de los principales

factores que determinan la compra es la vida proyectada del sistema. Si el

sistema se usará por más de cuatro a cinco años (con todos los demás

factores constantes), normalmente se toma la decisión de comprar. Observe

que en el ejemplo de la siguiente figura el costo de compra después de tres

años es más bajo que el del arrendamiento financiero o el alquiler.

Conforme los sistemas se hacen más pequeños y aumenta la popularidad de

los sistemas distribuidos, la mayoría de las empresas se decide por comprar

equipo. Otra posibilidad distinta a la compra es el arrendamiento financiero del

hardware. Arrendar el equipo al fabricante o a una compañía de arrendamiento

de terceros es más práctico cuando la vida proyectada del sistema es menor a

cuatro años. Además, si es inminente un cambio significativo en la tecnología,

el arrendamiento financiero constituye una mejor opción. Este esquema

también permite a la empresa poner su dinero en otra parte, donde puede ser

más rentable para la compañía en lugar de invertirlo en bienes de capital.

Sin embargo, el arrendamiento a largo plazo no es una forma económica de

adquirir equipo de cómputo. La tercera opción para la adquisición de

computadoras es el alquiler del hardware de cómputo. Una de las ventajas

principales del alquiler es que no se invierte el capital de la compañía y por lo

tanto no se requiere ningún financiamiento. También, alquilar el hardware de

cómputo facilita cambiar el hardware del sistema. Por último, el mantenimiento

y el seguro se incluyen por lo general en el contrato de alquiler. Sin embargo,

debido a los altos costos que implica y al hecho de que la compañía no será

dueña del equipo alquilado, el alquiler sólo se debe considerar como un

movimiento a corto plazo para satisfacer necesidades no recurrentes o

limitadas de cómputo o los tiempos volátiles de la tecnología

3.4.1 Selección e implementación de computadores y componentes relacionados

Siempre se deben considerar en conjunto los costos y beneficios del sistema de

cómputo propuesto, debido a que con frecuencia están vinculados y dependen uno

del otro. Aunque el analista de sistemas está intentando proponer un sistema que

cumple los diversos requerimientos de información, las decisiones de continuar con

el sistema propuesto se basarán en el análisis de costo-beneficio, no en los

requerimientos de información. En gran medida, los beneficios se miden por los

costos.

CÓMO PRONOSTICAR LOS COSTOS Y BENEFICIOSSe necesita que los analistas de sistemas pronostiquen ciertas variables

importantes antes de enviar la propuesta al cliente. Hasta cierto punto, un

analista de sistemas se apoyará en un análisis de “qué pasa si”, tal como,

“¿Qué pasa si los costos de mano de obra suben sólo 5 por ciento por año

durante los próximos tres años, en lugar de 10 por ciento?” Sin embargo, el

analista de sistemas debe entender que él o ella no se pueden apoyar

únicamente en un análisis del tipo “qué pasa si” si quieren que la propuesta sea

creíble, significativa y valiosa. El analista de sistemas tiene disponibles muchos

modelos de predicción. La condición principal para escoger un modelo es la

disponibilidad de los antecedentes. Si no están disponibles, el analista debe

volver a uno de los métodos de discernimiento: las estimaciones de la fuerza

de ventas, estudios para estimar la demanda del cliente, estudios Delphi (un

pronóstico del acuerdo general desarrollado independientemente por un grupo

de expertos a través de una serie de iteraciones),

Crear guiones o dibujar las analogías históricas. Si los antecedentes están

disponibles, la siguiente diferencia entre las clases de técnicas involucra si el

pronóstico es condicional o incondicional. El condicional implica que hay una

asociación entre las variables en el modelo o que dicha relación causal existe.

Los métodos comunes en este grupo incluyen correlación, regresión,

indicadores principales, econometría y modelos de entrada/salida. El

pronóstico incondicional significa que no se necesita del analista para encontrar

o identificar cualquier relación causal. Por consiguiente, los analistas de

sistemas encuentran que estos métodos son alternativas económicas y de fácil

implementación. En este grupo se incluyen el juicio gráfico, medias móviles y

análisis de datos de serie de tiempo. Debido a que estos métodos son simples,

fiables y rentables, el resto de la sección se enfoca en ellos.

IDENTIFICACIÓN DE BENEFICIOS Y COSTOS Los beneficios y costos se pueden representar como tangibles o intangibles.

Cuando se consideran los sistemas se deben tener en cuenta los beneficios y

costos tangibles e intangibles.

Beneficios tangibles: Los beneficios tangibles son ventajas que se pueden medir en

dólares que se acreditan a la organización mediante el uso del sistema de información.

Los ejemplos de beneficios tangibles son un aumento en la velocidad del

procesamiento, acceso de otra forma a la información inaccesible, acceso a la

información en una forma más oportuna, ventaja por el poder de cálculo de la

computadora y las disminuciones en el tiempo del empleado necesario para cumplir

tareas específicas.

Beneficios intangibles: Algunos beneficios que se acreditan a la organización

mediante el uso del sistema de información son difíciles de medir pero aun así son

importantes. Éstos se conocen como beneficios intangibles. Los beneficios intangibles

incluyen mejorar el proceso de toma de decisiones, incrementar la exactitud, ser más

competitivo en el servicio al cliente, mantener una buena imagen del negocio e

incrementar la satisfacción del trabajo para los empleados eliminando las tareas

tediosas.

Aunque los beneficios intangibles de un sistema de información son factores

importantes que se deben considerar al decidir proceder con un sistema, un sistema

construido únicamente por sus beneficios intangibles no tendrá éxito. Debe discutir los

beneficios tangibles e intangibles en su propuesta, debido a que presentar ambos

permitirá a tomadores de decisiones del negocio tomar una decisión bien

documentada acerca del sistema propuesto.

COMPARACIÓN DE LOS COSTOS Y BENEFICIOS

Se conocen muchas técnicas para comparar los costos y beneficios del

sistema propuesto. Dichas técnicas incluyen análisis del punto de equilibrio,

análisis del tiempo de recuperación de la inversión, análisis de flujo de efectivo

y análisis de valor presente. Todas estas técnicas proporcionan formas directas

de producir información para los tomadores de decisiones sobre el valor del

sistema propuesto.

CÓMO EXAMINAR LAS ALTERNATIVAS DE SISTEMAS Con el uso del análisis del punto de equilibrio, análisis del tiempo de

recuperación de la inversión, análisis de flujo de efectivo y el análisis de valor

presente, es posible comparar las alternativas para el sistema de información.

Como se mostró anteriormente, es importante usar análisis múltiples para

cubrir adecuadamente las limitaciones de cada enfoque.

Aunque considerará varias alternativas, la propuesta en sí recomendará sólo

una. De tal manera, que habrá hecho un análisis comparativo sobre qué

sistema hace el mejor sentido económico antes de que se escriba la propuesta.

Dichos análisis se pueden incluir para proporcionar apoyo para el sistema que

está recomendando. No piense que sólo hay una solución “correcta” del

sistema para ayudar a un negocio a resolver sus problemas y alcanzar su

meta.

INTRODUCCION

El desafío es tomar las teorías y aplicarlas considerando las características específicas

del contexto de trabajo de cada organización. Estudios realizados muestran que más

del 53% de los proyectos de software fracasan por no realizar una adecuada gestión

de requerimientos. Algunos de los motivos más habituales para llegar a esta situación

suelen ser la falta de participación del usuario, la presencia de requerimientos

incompletos o que se modifican en forma permanente sin poder estabilizarse. El costo

de solucionar un error en la etapa de mantenimiento es aproximadamente 200 veces

mayor que solucionarlo en la etapa de requerimientos.

CONCLUSIONES

El análisis de los requerimientos es una herramienta imprescindible para que el

profesional contable, hoy en día gestor de proyectos medianos y grandes en donde

desarrollan muchos procesos y funciones, y así poder tomar decisiones sobre las

necesidades de sistemas de información o detectar alguna falla de las existentes en

base al análisis de los hechos de todos los equipos de las organizaciones.

Tomar la decisión de seleccionar equipos de cómputo y otros es una tarea un poco

difícil, ya que para ello el gestor de negocios realiza un estudio aplicando diferentes

métodos como el flujo de caja y algunas proyecciones para evaluar la rentabilidad que

generarían la incursión en la compra de un tipo de hardware para su utilización en la

empresa.

BIBLIOGRAFÍABentley, J. L. (2015). Análisis de sistemas. Diseño y métodos . 7ma edición.

Cáceres, E. A. (2014). Análisis y Diseño de Sistemas de Información.

CIAMPAGNA, J. M. (2011). ADMINISTRACION SIG . CURSO ADMINISTRACION SIG , (págs. 7-15).

crea tu web Alojado en Galeon.com Hispavista. (s.f.). Obtenido de crea tu web Alojado en Galeon.com Hispavista: http://requerimientos.galeon.com/

Formato basado en el documento de especificación de requerimientos. (siglo21). Informática, FO-DS-0011.

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