Download - SQA en fase de analisis de requisitos y fase de diseño

5/13/2018 SQA en fase de analisis de requisitos y fase de dise o - slidepdf.com

http://slidepdf.com/reader/full/sqa-en-fase-de-analisis-de-requisitos-y-fase-de-diseno

Instituto TecnológicoSuperior de Lerdo

“La excelencia académica al servicio de la sociedad”

Lic. Informática

B. Ivveth García Puentes 09231360

Investigación de SQA en fase de análisis y diseño.

M.E. E.D. I.S.C. Ricardo de Jesús Bustamante González

28 de Febrero del 2012



2

Calidad de software ITSL

Primero para entender esto que es el aseguramiento en la fase de análisis seva a definir que es aseguramiento.

El aseguramiento de calidad del software es el conjunto de actividadesplanificadas y sistemáticas necesarias para aportar la confianza adecuada enque el producto (software) satisfacer los requisitos dados de calidad. ElAseguramiento pretende dar confianza en que el producto tiene calidad.

FASE DE REQUERIMIENTOS: Las tareas de SQA para los requerimientosson los siguientes:

♣ 1) Verificar que todos los participantes correctos estén involucrados en el análisis delos requisitos para identificar todas las necesidades del usuario.

♣ 2) Revisar todos los requerimientos para determinar si su implementación esfactible.

♣ 3) Verificar que los contratos fueron documentados, comunicados y revisados.

♣ 4) Verificar que los requisitos que puedan tener algún tipo de error sean analizadospor el equipo de requerimientos.

♣ 5) Verificar que los requisitos estén documentados

♣ 6) Darle seguimientos a los cambios que puedan tener los requerimientos

♣ 7) Verificar que las personas involucradas en el equipo de requisitos esténentrenadas para el trabajo

♣ 8) Verificar que los procesos establecidos para definir y documentar requisitos sonseguidos y documentados.

FASE DE DISEÑO: Las tareas de SQA en el proceso de diseño son:

♣ 1)Verificar que los procesos de diseño de software sigan los estándaresdeterminados

♣ .2) Verificar que todos los elementos que no cumplen con la calidad requerida seanprocesados de acuerdo a los estándares y procedimientos establecidos.

♣ 3) Verificar que la matriz de rastreo de los requerimientos al diseño este lista. Los

requisitos deben ser trazables, es decir, ³rastreables .́ Se podría decir que unrequisito es trazable si se pueden identificar todas las partes del producto existente



2


relacionadas con ese requisito. Todos los requisitos deberían ser trazables paramantener consistencia entre los distintos documentos de un proyecto. Es importanteconocer aspectos de los requisitos tales como: Su origen(Quién los propuso)Necesidad (Por qué existe) Relación con otros requisitos(Dependencias) Relación

con otros elementos (Dependencias)

♣ 4) Verificar que todos los requerimientos estén presentas en el diseño.

El análisis de requerimientos puede dividirse en cuatro áreas:1.- Reconocimiento del problema2.- Evaluación y síntesis3.- Especificación4.- Revisión.

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

El analista debe establecer contacto con el equipo técnico y de gestión delusuario / cliente y con la empresa que vaya a desarrollar el software. El gestor

del programa puede servir como coordinador para facilitar el establecimiento delos caminos de comunicación. El objetivo del analista es reconocer loselementos básicos del programa tal como lo percibe el usuario / cliente.

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

pueda sintetizarse un enfoque o solución global.

Las tareas asociadas con el análisis y especificación existen para dar unarepresentación del programa que pueda ser revisada y aprobada por el cliente.En un mundo ideal el cliente desarrolla una especificación de requerimientosdel software completamente por sí mismo. Esto se presenta raramente en elmundo real. En el mejor de los casos, la especificación se desarrollaconjuntamente entre el cliente y el técnico.Una vez que se hayan descrito las funcionalidades básicas, comportamiento,interfase e información, se especifican los criterios de validación para

demostrar una comprensión de una correcta implementación de los programas.Estos criterios sirven como base para hacer una prueba durante el desarrollo



2


de los programas. Para definir las características y atributos del software seescribe una especificación de requerimientos formal. Además, para los casosen los que se desarrolle un prototipo se realiza un manual de usuariopreliminar.

Puede parecer innecesario realizar un manual de usuario en una etapa tantemprana del proceso de desarrollo, Pero de hecho, este borrador del manualde usuario fuerza al analista a tomar el punto de vista del usuario del software.El manual permite al usuario / cliente revisar el software desde una perspectivade ingeniería humana y frecuentemente produce el comentario: "La idea escorrecta pero esta no es la forma en que pensé que se podría hacer esto". Esmejor descubrir tales comentarios lo más tempranamente posible en elproceso.Los documentos del análisis de requerimiento (especificación y manual deusuario) sirven como base para una revisión conducida por el cliente y el

técnico. La revisión de los requerimientos casi siempre produce modificacionesen la función, comportamiento, representación de la información, ligaduras ocriterios de validación. Además, se realiza una nueva apreciación del plan delproyecto de software para determinar si las primeras estimaciones siguensiendo validas después del conocimiento adicional obtenido durante el análisis.

* Obteniendo de la información *

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

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

Las necesidades y / o requerimientos del cliente evolucionan con el tiempo ycada cambio involucra un costo. Por eso es necesario tener archivada unacopia de la documentación original del cliente, así como cada revisión o cambioque se haga a esta documentación. Como cada necesidad del cliente estratada de diferente forma, es necesario clasificar estas necesidades parasaber cuales de ellas serán satisfechas por el software y cuales por algún otroproducto del sistema.

* Especificación de Requisitos de Software



2


*(SRS)

La especificación de requisitos de software es la actividad en la cual se generael documento, con el mismo nombre, que contiene una descripción completa de

las necesidades y funcionalidades del sistema que será desarrollado; describeel alcance del sistema y la forma en como hará sus funciones, definiendo losrequerimientos 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 desoporte y guía para fases posteriores.Es importante destacar que la especificación de requisitos es el resultado finalde las actividades de análisis y evaluación de requerimientos; este documentoresultante será utilizado como fuente básica de comunicación entre los clientes,

usuarios finales, analistas de sistema, personal de pruebas, y todo aquelinvolucrado 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 yprogramadores la utilizan para determinar el producto que debe desarrollarse.El personal de pruebas elaborará las pruebas funcionales y de sistemas enbase a este documento. Para el administrador del proyecto sirve comoreferencia 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 unode los requerimientos debe cumplirlas; por ejemplo, para que una SRS seconsidere verificable, cada requerimiento definido en ella debe ser verificable;para que una SRS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente. Las características de la SRS son verificadasen la actividad de Validación, descrita en el punto.La estandarización de la SRS es fundamental pues ayudará, entre otras cosas,a facilitar la lectura y escritura de la misma. Será un documento familiar paratodos 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 potestadde crear su propia plantilla.Clasificación de los requerimientosEl clasificar requerimientos es una forma de organizarlos, hay requerimientosque por sus características no pueden ser tratados iguales.La siguiente es una recomendación de como pueden ser clasificados losrequerimientos aunque cada proyecto de software pueda usar sus propiasclasificaciones.

• Requerimientos del "entorno" El entorno es todo lo que rodea al sistema.Aunque no podemos cambiar el entorno, existen cierto tipo de requerimientos



2


que se clasifican en esta categoría por que:El sistema usa el entorno y lo necesita como una fuente de los serviciosnecesarios para que funcione. Ejemplos del entorno podemos mencionar:sistemas operativos, sistema de archivos, bases de datos.

El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en elentorno, tales como congestión en los dispositivos y errores de entrada dedatos, por lo tanto el entorno se debe de considerar dentro de losrequerimientos.• Requerimientos "ergonómicos"Él mas conocido de los requerimientos ergonómicos es la interfase con elusuario o GUI (Graphic User Interface). En otras palabras, los requerimientosergonómicos son la forma en que el ser humano interactúa con el ser sistema.• Requerimientos de InterfaseLa interfase es como interactúa el sistema con el ser humano o con otros

sistemas (el enfoque es prácticamente el opuesto a los requerimientosergonómicos), La interfase es la especificación formal de los datos que elsistema recibe o manda al exterior. Usualmente se especifica el protocolo, eltipo de información, el medio para comunicarse y el formato de los datos que sevan a comunicar.

* Actividades de la Ingeniería de

Requerimientos *

En el proceso de IR son esenciales diversas actividades. En este documentoserán presentadas, sin embargo, en un proceso de ingeniería derequerimientos efectivo, estas actividades son aplicadas de manera continua yen orden variado.Dependiendo del tamaño del proyecto y del modelo de proceso de softwareutilizado para el ciclo de desarrollo, las actividades de la IR varían tanto ennúmero como en nombres. La tabla #1 muestra algunos ejemplos de lasactividades identificadas para cada proceso.A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre

el conjunto de actividades mostradas en la tabla anterior, podemos identificar yextraer cinco actividades principales que son:• Análisis del Problema• Evaluación y Negociación• Especificación• Validación• Evolución

* Principios de Especificación *

La especificación, independientemente del modo en que se realice, puede ser



2


vista como un proceso de representación. Los requerimientos se representande forma que conduzcan finalmente a una correcta implementación delsoftware.Baltzer y Goldman proponen ocho principios para una buena especificación:

PRINCIPIO #1. Separar funcionalidad de implementación.Primero, por definición, una especificación es una descripción de lo que sedesea, en vez de cómo se realiza (implementa). Las especificaciones puedenadoptar dos formas muy diferentes. La primera forma es la de funcionesmatemáticas: dado algún conjunto de entrada, producir un conjunto particular de salida. La forma general de tales especificaciones es encontrar [un/el/todos]resultado tal que P (entrada), donde P representa un predicado arbitrario. Entales especificaciones, el resultado a ser obtenido ha sido expresadoenteramente en una forma sobre el que (en vez de cómo). En parte, esto es

debido a que el resultado es una función matemática de la entrada (laoperación tiene puntos de comienzo y parada bien definidos) y no esta afectadopor el entorno que le rodea.PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemasorientado al proceso.Considerar una situación en la que el entorno sea dinámico y sus cambiosafecten al comportamiento de alguna entidad que interactúe con dicho entorno.Su comportamiento no puede ser expresado como una función matemática desu entrada. En vez de ello, debe emplearse una descripción orientada al

proceso, en la cual la especificación del que se consigue mediante laespecificación de un modelo del comportamiento deseado en términos derespuestas funcionales, a distintos estímulos del entorno.PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el softwarees una componente.Un sistema esta compuesto de componentes que interactúan. Solo dentro delcontexto del sistema completo y de la interacción entre sus partes puede ser definido el comportamiento de una componente especifica. En general, unsistema puede ser modelado como una colección de objetos pasivos y activos.

Estos objetos están interrelacionados y dichas relaciones entre los objetoscambian con el tiempo. Estas relaciones dinámicas suministran los estímulos alos cuales los objetos activos, llamados agentes, responden. Las respuestaspueden causar posteriormente cambios y, por tanto, estímulos adicionales a loscuales los agentes deben responder.PRINCIPIO #4. Una especificación debe abarcar el entorno en el que elsistema opera.Similarmente, el entorno en el que opera el sistema y con el que interactúadebe ser especificado.Afortunadamente, esto tan solo necesita reconocer que el propio entorno es un

sistema compuesto de objetos que interactúan, pasivos y activos, de los cualesel sistema especificado es una agente, Los otros agentes, los cuales son por



2


definición inalterables debido a que son parte del entorno, limitan el ámbito deldiseño subsecuente y de la implementación. De hecho, la única diferencia entreel sistema y su entorno es que el esfuerzo de diseño e implementaciónsubsecuente opera exclusivamente sobre la especificación del sistema. La

especificación del entorno facilita que se especifique la interfaz del sistema dela misma forma que el propio sistema, en vez de introducir otro formalismo.PRINCIPIO #5. Una especificación de sistema debe ser un modelo cognitivo.La especificación de un sistema debe ser un modelo cognitivo, en vez de unmodelo de diseño o implementación. Debe describir un sistema tal como espercibido por su comunidad de usuario. Los objetivos que manipula debencorresponderse con objetos reales de dicho dominio; los agentes debenmodelar los individuos, organizaciones y equipo de ese dominio; y las accionesque ejecutan deben modelar lo que realmente ocurre en el dominio. Además,debe ser posible incorporar en la especificación las reglas o leyes que

gobiernan los objetos del dominio. Algunas de estas leyes proscriben ciertosestados del sistema (tal como "dos objetos no pueden estar en el mismo lugar al mismo tiempo"), y por tanto limitan el comportamiento de los agentes oindican la necesidad de una posterior elaboración para prevenir que surjanestos estados.PRINCIPIO #6. Una especificación debe ser operacional.La especificación debe ser completa y lo bastante formal para que puedausarse para determinar si una implementación propuesta satisface laespecificación de pruebas elegidas arbitrariamente. Esto es, dado el resultado

de una implementación sobre algún conjunto arbitrario de datos elegibles, debeser posible usar la especificación para validar estos resultados. Esto implicaque la especificación, aunque no sea una especificación completa del como,pueda actuar como un generador de posibles comportamientos, entre los quedebe estar la implementación propuesta. Por tanto, en un sentido extenso, laespecificación debe ser operacional.PRINCIPIO #7. La especificación del sistema debe ser tolerante con laincompletitud y aumentable.Ninguna especificación puede ser siempre totalmente completa. El entorno en

el que existe es demasiado complejo para ello. Una especificación es siempreun modelo, una abstracción, de alguna situación real (o imaginada). Por tanto,será incompleta. Además, al ser formulad existirán muchos niveles de detalle.La operacionalidad requerida anteriormente no necesita ser completa. Lasherramientas de análisis empleadas para ayudar a los especificadores y paraprobar las especificaciones, deben ser capaces de tratar con la incompletitud.Naturalmente esto debilita el análisis, el cual puede ser ejecutado ampliando elrango de comportamiento aceptables, los cuales satisfacen la especificación,pero tal degradación debe reflejar los restantes niveles de incertidumbre.PRINCIPIO #8. Una especificación debe ser localizada y débilmente acoplada.

Los principios anteriores tratan con la especificación como una entidad estática.Esta surge de la dinámica de la especificación. Debe ser reconocido que



2


aunque el principal propósito de una especificación sea servir como base parael diseño e implementación de algún sistema, no es un objeto estáticoprecompuesto, sino un objeto dinámico que sufre considerables modificaciones.Tales modificaciones se presentan en tres actividades principales: formulación,

cuando se está creando una especificación inicial; desarrollo, cuando laespecificación se esta elaborando durante el proceso iterativo de diseño eimplementación; y mantenimiento, cuando la especificación se cambia parareflejar un entorno modificado y / o requerimientos funcionales adicionales.• Requerimientos funcionalesEstos son los que describen lo que el sistema debe de hacer. Es importanteque se describa él ¿Qué? Y no él ¿Cómo?. Estos requerimientos al tiempo queavanza el proyecto de software se convierten en los algoritmos, la lógica y granparte del código del sistema.• Requerimientos de desempeño

Estos requerimientos nos informan las características de desempeño quedeben de tener el sistema. ¿Que tan rápido?, ¿Que tan seguido?, ¿Cuantosrecursos?, ¿Cuantas transacciones?Este tipo de requerimientos es de especial importancia en los sistemas detiempo real en donde el desempeño de un sistema es tan crítico como sufuncionamiento.• Disponibilidad (en un determinado periodo de tiempo)Este tipo de requerimientos se refiere a la durabilidad, degradación, potabilidad,flexibilidad, contabilidad y capacidad de actualización. Este tipo de

requerimientos es también muy importante en sistemas de tiempo real puestoque estos sistemas manejan aplicaciones críticas que no deben de estar fuerade servicio por periodos prolongados de tiempo.• EntrenamientoEste tipo de requerimientos se enfoca a las personas que van usar el sistema.¿Que tipo de usuarios son?, ¿Que tipo de operadores?, ¿Que manuales seentregarán y en que idioma?Este tipo de requerimientos, aunque muchas veces no termina en un pedazo decódigo dentro del sistema, son muy importantes en el proceso de diseño ya que

facilitan la introducción y aceptación del sistema en donde será implementado.• Restricciones de diseñoMuchas veces las soluciones de un sistema de software son normadas por leyes o estándares, este tipo de normas caen como "restricciones de diseño".• MaterialesAquí se especifica en que medio se entregara el sistema y como estaempaquetado. Es importante para definir los costos de industrialización delsistema.

* Manejo de requerimientos *



2


De acuerdo con el "Capability Maturity Model" (CMM), el manejo derequerimientos involucra:"Establecer y mantener un acuerdo con el cliente sobre los requerimientos delproyecto de software. Este acuerdo son los requerimientos del sistema alojados

al software." … ". Este acuerdo cubre requerimientos técnicos y no técnicos(como fechas de entrega). El acuerdo forma las bases para estimar, planear,ejecutar y monitorear el proyecto de desarrollo de software a través de todo suciclo de vida." … "Bajo las restricciones del proyecto, el grupo de manejo derequerimientos toma las medidas necesarias para que los requerimientos queestán bajo su responsabilidad estén documentados y controlados"¿De que manera podemos controlar los requerimientos de software si estossiempre evolucionan con el tiempo?. El CMM nos proporciona las guías paralograrlo."Para lograr el control de los requerimientos, el grupo de requerimientos revisa

los requerimientos antes de que estos sean incorporados al proyecto desoftware y cada vez que los requerimientos cambian los planes, productos, yactividades son ajustadas para quedar en línea con los nuevos requerimientosde software".En otras palabras, para obtener el nivel que requiere el CMM en manejo derequerimientos débenos de tomar en cuenta dos cosas.• Que los requerimientos deben de ser revisados (y aprobados) por el grupo derequerimientos, y no son impuestos por en su totalidad por presiones externasajenas al proyecto.

El requerimiento técnico podrá ser impuesto por el mercado o presiones de lacompetencia, pero entonces los requerimientos no técnicos (Calidad, Costo yTiempo de entrega) deberán estar especificados de común acuerdo con elgrupo de requerimientos del proyecto de software.• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, sicambia uno forzosamente deberán cambiar los demás. Esto es: más contenidotécnico implica o más costo, o menos calidad o más tiempo estimado deentrega. De modo que los cambios técnicos deberán ser aprobados por elgrupo de requerimientos y este grupo estimará los impactos en tiempo, costo,

calidad. El resultado de la estimación es la entrada a los líderes del proyectopara decidir si el cambio se acepta o no.

* ORGANIZACIÓN Y CAPTURA DEREQUERIMIENTOS DE USUARIO *

Para prosperar en el mercado, cualquier producto debe satisfacer lasnecesidades de los usuarios, lo cual no resulta posible si no integra y pone alalcance del consumidor de forma comprensible los fundamentos de todos los

aspectos del desarrollo. Para captar las necesidades específicas de losusuarios es indispensable que los documentos que recogen los requerimientos



2


se redacten utilizando métodos pragmáticos.Se debe utilizar una metodología detallada de definición de los requerimientosde usuario. Organizar entrevistas destinadas a obtener la máxima informaciónposible acerca de los requerimientos de los usuarios. Traducir las

oportunidades / necesidades en requerimientos del proyecto. Comprender elperfil y entorno del usuario. Evaluar el flujo de trabajo. Crear un documento derequerimientos generales. Conseguir la participación y confirmación delusuario.Los gerentes y usuarios del sistema también poseen un papel importante en lediseño del sistema; no es solamente el proyecto del analista. Durante el diseño,a algunos se les pide que revisen los borradores de los informes, que examinenlos formatos de entrada y que ayuden en la escritura de los procedimientospara decirles a otras personas como utilizar el sistema en forma apropiada.La participación del usuario proporciona al analista una retroalimentación

importante conforme avanza en el diseño; además asegura a los usuariostengan un conocimiento no técnico de lo realizara o no el nuevo sistema.Esta visión general del diseño de sistemas subraya los aspectos de diseño quese verán mas adelante en el diseño de la salida de sistema.

* REQUERIMIENTOS DEL SISTEMA *

Los Sistemas de Información por computadora normalmente están integradospor muchos componentes. En la mayor parte de los casos, es difícil para los

analistas entender todos estos componentes aún mismo tiempo; por lo tanto losinvestigadores tienen que comenzar con preguntas de tipo general con relaciónal propósito del sistema sus entradas y salidas de los procesos incluidos.En los grandes proyectos de sistema varios analistas llevan a cabo unainvestigación en forma seccionada que la distribuye entre ellos mismos, demanera que cada uno pueda trabajar en forma independiente.Existen dos estrategias ampliamente utilizadas para determinar losrequerimientos de información. Se clasifican en dos tipos:1.- Flujo de Datos.

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

* Estrategia del Flujo de Datos *

Cuando se siguen un flujo a través de los procesos de negocio, que es elpropósito del análisis del flujo de datos, le indica a los analistas una grancantidad de datos sobre como sé esta llevando a cabo los objetivos de lacompañía. Al manejar las transacciones y completar las tareas, los datos de

entrada se procesan, almacenan, consultan, utiliza, modifica y se emiten.El análisis de flujo de datos que muestra el estudio y el uso de cada actividad,



2


documenta los hallazgos en los diagramas de flujo de datos.

* Estrategia del Análisis de Decisiones *

La estrategia del análisis de decisiones es un complemento del análisis del flujode datos. Esta estrategia realza el estudio de los objetivos de una operación yde las decisiones que deben realizarse para cumplir con los objetivos.Las decisiones se presentan tanto en los niveles operativos como en los de altonivel gerencial, la estrategia de análisis de decisión con frecuencia utiliza por parte de alta gerencia para desarrollar la toma de decisiones.La alternativa que selecciona los gerentes responsables en la toma dedecisiones, en cuanto a una estrategia de precios entre un conjunto dealternativas, se maneja de forma diferente a la opción que toma un supervisor

de departamento para aceptar o rechazar pedidos.La decisión de rechazar pedidos generalmente ocurre con más frecuencia, demanera que las condiciones y acciones normalmente se conocen como unaspecto importante.

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

1. - Estudiar las operaciones y procesos en marcha.2. - Identificar cómo se procesan los datos al manejar transacciones y terminar las tareas.3. - Seguir el flujo de datos:* Proceso* Almacenamiento* Recuperación* Salida4. - Añadir gradualmente detalles a los niveles inferiores.Etapas en la Estrategia del Análisis de Decisión

1. -Estudiar los objetivos y decisiones necesarias.2. - Desarrollar un modelo del proceso de decisión.3. - Probar el modelo con datos de prueba.4. - Identificar los requerimientos del proceso para los datos.

* Requerimientos De Entrada *

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

cuenta estos son:• Objetivos del Diseño de Entrada.



2


• Captura de Datos para la Entrada.

Objetivo del Diseño de EntradaConsiste en el desarrollo de especificaciones y procedimientos para la

preparación de datos, la realización de los procesos necesarios para poner losdatos de transacción en una forma utilizable para su procesamiento así como laentrada de los datos se logra al instruir a la computadora para que lea ya seadocumentos escritos, impresos ó por personas que los escriben directamente alsistema.Existen cinco objetivos que controlan la cantidad de entrada requerida, a enviar los retrasos, controlar los errores y mantener la sencillez de los pasosnecesarios, estos son:• Control de la Calidad de Entrada• Evitar los Retrasos

• Evitar los errores en los datos• Evitar los pasos adicionales• Mantener la Sencillez del ProcesoControl de la Calidad de Entrada:Existen varias razones por las cuales un buen diseñador debe controlar lacantidad de datos en la entrada:- Las Operaciones de preparación y entrada dependen de las personas dadoque los costos de mano de obra son altos y la preparación de ingreso de losdatos también lo son.

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

Evitar los Retrasos:También conocido con el nombre de cuello de botella son siempre uno de losobjetivos que el analista evita al diseñar la entrada, una forma de evitarle esutilizar los documentos de retorno.

Evitar los errores en los datos:La tasa de errores depende de la cantidad de datos, ya que entre más pequeñasea esta menores serán las oportunidades para cometer errores. Es comúnencontrar en las operaciones de ventas por lo menos un 3% de errores en lasoperaciones de entrada de datos.Evitar los Pasos Adicionales:Algunas veces el volumen de transacciones y la cantidad de datos enpreparación es algo que no se puede controlar por ello el analistaexperimentado, evitara diseños para la entrada que traigan una mayor cantidadde pasos a seguir. Ya sea añadir o quitar pasos cuando se alimenta un proceso

muchas veces al transcurso de un día.



2


Mantener la sencillez del Proceso:El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismotiempo proporcionarán métodos para el control de los errores, la simplicidadfunciona y es aceptada por cualquier usuario. Cuesta trabajo que los usuarios

acepten sistemas complejos o confusos y que no exista ninguna garantía parael éxito al instalar un sistema complejo y que domine.Captura de Datos para la Entrada:En una transacción existen datos importantes y otros que no, el analista debesaber cuales utilizará y cuales en realidad deben formar la entrada. Existen dostipos de datos: datos variables datos de identificaciónDatos Variables: Son aquellos que cambian para cada transacción o toman dedecisión.Datos de Identificación:Estos son los que identifican en forma única el artículo que esta siendo

procesado.

* Requerimientos De Salida *

Niveles de diseñoEl diseño de sistema se representa a través de dos fases: el diseño lógico y eldiseño físico.Cuando los analistas formulan un diseño lógico; escriben las especificacionesdetalladas del nuevo sistema; esto es, describen sus características: lassalidas, entradas, archivos y bases de datos y procedimientos; todos demanera que cubran los requerimientos del proyecto.El diseño lógico de un sistema de información es como el plano de un ingenieropara armar un automóvil: muestra las características principales(motor,transmisión y área para los pasajeros)y como se relacionan unas conotras(donde se conectan entre sí los componentes del sistema, o por ejemplo,cuan separadas están las puertas.Los informes y la producción del analista son los componentes de todo elmecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y

entonces se produce un sistema que trabaje.El diseño lógico también especifica las formas de entrada y las descripcionesde las pantallas de todas las transacciones y archivos a fin de mantener losdatos de inventario, los detalles de las transacciones y los datos del proveedor.Las especificaciones de los procedimientos describen métodos para introducir los datos, corridas de informes copiados de archivos y detección de problemas.

El diseño físico, actividad que sigue el diseño lógico, produce programas desoftware, archivos y un sistema en marcha, las especificaciones del diseño

indican a los programadores que debe hacer el sistema. Los programadores asu vez escriben los programas que aceptan entradas por parte de los usuarios,



2


procesan los datos, producen los informes y almacenan estos datos en losarchivos.Utilización de los Datos de Requerimientos:El alcance del diseño de sistemas se guía por el marco de referencia para el

nuevo sistema desarrollado durante el análisis. Los datos de losrequerimientos, recopilados durante la investigación, conforman las actividadesy componentes del sistema. Los analistas formulan un diseño lógico que apoyalos procesos y decisiones, los contenidos del sistema pueden cambiar comoresultado de un nuevo diseño.El diseño lógico va de arriba hacia abajo, como lo hizo la determinación derequerimientos.En primer lugar se identifican las características generales, como informes yentradas; en el diseño de la salida por ejemplo, los analistas deben conocer lalongitud de campo de un dato específico para establecer cuanto espacio dejar

en la información, en la pantalla de despliegue visual o archivo.A lo largo de los años hemos visto una evolución de ideas y técnicas en elcampo del análisis de sistemas. La cual cabe en tres períodos amplios segúnYourdon:1. El análisis de sistema convencional, anterior a los años 70´s, caracterizadopor especificaciones tipo novela victoriana que eran difíciles de leer y entender,y casi imposibles de mantener.2. El análisis estructurado clásico, de mediados de los años 70´s, a mediadosde los años 80´s. Esto se caracterizó por primeras versiones de modelos

gráficos, y énfasis en el modelado de las implementaciones actuales de unsistema antes de modelar el nuevo.

3. El análisis estructurado moderno, en el cual se introducen mejoras sobretodo para modelar sistemas de tiempo real y relaciones de situacionescomplejas. Aumentando por ende la comunicación entre el analista y elsistema.



2


Ciclo de vida del desarrollo del software.