1

INSTITUTO SUPERIOR TECNOLÓGICO

NORBERT WIENER

Manual del Alumno

ASIGNATURA:

Desarrollo de Sistemas

PROGRAMA: S3C

Lima-Perú

2

Análisis y desarrollo de Sistemas

Indice

1. Justificación

2. Planeación De Sistemas

3. Análisis De Sistemas

4. Desarrollo De Sistemas

5. Implantación

6. Conclusiones

7. Bibliografía

1. Justificación

Los métodos para la creación de sistemas de procesamiento de datos están cambiando rápidamente. En la actualidad existen dos tendencias metodológicas; la primera orientada al estudio de los procesos soportada por la ingeniería de software y la segunda orientada al estudio de los datos y procesos, soportada por la Ingeniería de Información.

El término Ingeniería es usado en la descripción de metodologías modernas para explicar que se usan disciplinas formadas con técnicas precisas y bien pensadas, antes que inventadas sobre la marcha.

El concepto de Ingeniería de Software se refiere al conjunto de disciplinas usadas para la especificación, diseño e implantación de Software para computadoras, siendo su enfoque primario la lógica utilizada en los procesos computarizados. La metodología de Ingeniería de Software se llega a formalizar a finales de los 70´s e

3

involucra técnicas para desarrollo de Software tales como la programación estructurada, análisis y diseño estructurado y herramientas para soportarlas.

La Ingeniería de Información se refiere al conjunto de disciplinas interrelacionadas necesarias para construir una empresa computarizada basada en sistemas de datos. El enfoque primario de Ingeniería de Información son los datos que se almacenan y se mantienen en una computadora y la información que se produce de esos datos.

La primera premisa de la Ingeniería de Información es que los datos se encuentran en los centros de procesamiento de datos y, una segunda premisa es que los tipos de datos de una empresa no cambian con mucha frecuencia. Los tipos de entidades no cambian, excepto para la adición de nuevas entidades. Los tipos de atributos que se almacenan acerca de esas entidades cambian con poca frecuencia pero, los valores de los datos cambian constantemente.

2. Planeación De SistemasReseña De Análisis De SistemasLos métodos de desarrollo de sistemas orientados a la estructura de los datos tienen un enfoque y una notación distintos, todos tienen algunas características comunes :

1. Todos ayudan a los analistas en la identificación de los objetos de información clave (también llamados entidades o elementos) y de las operaciones (llamadas acciones o procesos)

2. Todos asumen que la estructura de la información es jerárquica.

4

3. Todos requieren que se represente la estructura de los datos usando las construcciones secuencia, selección y repetición.

4. Todos proporcionan un conjunto de pasos para transformar una estructura jerárquica de los datos en una estructura de programa.

El desarrollo de sistemas estructurados en datos (DSED, ó DSSD, por sus siglas en inglés), también denominado metodología de Warnier-Orr, ha evolucionado del innovador trabajo sobre el análisis del campo de información realizado por J. D. Warnier.

Warnier desarrolló una notación para representar la jerarquía de la información usando 3 construcciones de secuencia, selección y repetición, y demostró que la estructura del Software puede derivarse directamente de la estructura de los datos.

Ken Oir amplío el trabajo de Warnier para abarcar una visión algo más amplia del campo de información, evolucionando el desarrollo de sistemas estructurado de datos. El DSED considera el flujo de la información y las características funcionales, así como la jerarquía de los datos.

Método de Warnier

El diagrama de Warnier permite al analista representar la jerarquía de información de una manera compacta. Se analiza el campo de la información y se representa la naturaleza jerárquica de la salida. Para ilustrar esto, consideremos un sistema de composición automática semestral en un plantel para representar los horarios del personal docente. La organización general de los horarios del personal docente tiene la siguiente forma :

HORARIO DE GRUPOS

Maestros y materias (por grupo)

5

Distribución de Horas

HORARIO DE MAESTROS

Carga Docente (horas frente a grupo y horas comisionadas)

Grupos

Aulas

HORARIO DE AULAS

Grupos (turno vespertino y matutino)

Docentes Asignados

Este perfil de los horarios es una jerarquía de información. Se puede usar el diagrama de Warnier para representar la jerarquía a cualquier nivel de detalle se representa la jerarquía de información del periódico usando la notación de Warnier. Se usa la llave ({) para diferenciar niveles de la jerarquía de información. Todos los nombre contenidos dentro de una llave representan una secuencia de elementos de información (cada elemento puede estar compuesto de otros elementos o de un único elemento). La notación que acompaña a algunos nombres representa la repetición, es decir, el número de veces que aparece cada elemento particular en la jerarquía.

El método DSED

En lugar de comenzar el análisis examinando la jerarquía de la información, el método DSED examina primero el contexto de la aplicación, es decir, cómo se mueven los datos entre productores y consumidores de la información, desde la perspectiva de uno de los productores o de uno de los consumidores de la información. A

6

continuación, se establecen las funciones de aplicación con representación similar a la de Warnier que describe los elementos de la información y el procesamiento que debe realizarse sobre ellos (esto es similar al concepto de diagramas de flujos de datos). Finalmente, se modelizan los resultados de la aplicación usando el diagrama de Warnier. Usando este método, DSED engloba todos los atributos del ámbito de la información : Flujo, contenido y estructura.

Contexto de la aplicación

Para determinar el contexto de la aplicación en DSED, debe caracterizarse el problema de la forma que nos permita responder a 3 preguntas :

1. ¿Cuáles son los elementos de información que han de procesarse?

2. ¿Quién/qué son los productores y los consumidores de la información?

3. ¿Cómo ve la información cada productor/consumidor en el contexto de los demás grupos?

En el método DSED propone un diagrama de entidades como mecanismo para responder a las preguntas. El diagrama de entidades utiliza una notación que es, lamentablemente muy parecida al diagrama de flujo de datos. Sin embargo símbolos similares tiene propósitos diferentes. El círculo en un diagrama de entidades corresponde a un productor o a un consumidor de información (una persona, una máquina, otro sistema).

Desarrollo de sistemas Jackson

7

El Desarrollo de Sistemas Jackson (DSJ) evolucionó a partir del trabajo de M.A. Jackson sobre análisis del campo de la información y sus relaciones con el diseño de programas y de sistemas. Similar, de alguna forma al enfoque de Warnier y el DSED, el DSJ se centra en modelos del ámbito de información del “mundo real”. En palabras de Jackson “El desarrollador del software comienza creando un modelo de la realidad concerniente al sistema, la realidad que comprende su materia base ...”

Para llevar a cabo un DSJ, el analista sigue los siguientes pasos:

Paso de Entidad Acción. Usando un enfoque muy similar a la técnica de análisis orientada a los objetos, se identifican las entidades (personas, objetos u organizaciones que necesita el sistema para producir o usar información) y las acciones (los sucesos que ocurren en el mundo real que afectan las entidades).

Paso de estructura de Entidad . Se ordenan en el mismo tiempo las acciones que afectan a cada entidad y se representan mediante diagramas de jackson (una notación en forma de árbol).

Paso del Modelo Inicial. Se crea un modelo de procesamiento que representa las entidades y las acciones; se definen las conexiones entre el modelo y el mundo real.

Paso de las funciones. Se especifican las funciones que corresponden a las acciones definidas.

Paso de temporalización del sistema. Se establecen y especifican los aspectos de planificación del proceso.

Paso de implementación. Se especifica el Hardware y el software como un diseño.

Los últimos tres pasos del DSJ están muy relacionados con el diseño de sistemas o de software.

8

SADT

SADT (Structured Analysis and Design Techinique) es una técnica de análisis y diseño de sistemas que ha sido ampliamente utilizada para la definición de sistemas, el análisis de requisitos de software y el diseño de sistemas/software consiste en un conjunto de procedimientos que permiten al analista descomponer las funciones del software (o del sistema); una notación gráfica, los actigramas y datagramas, que comunican las relaciones de la información (datos y control) y de las funciones con el software; directrices para aplicar la metodología al control del proyecto. Usando SADT, el analista desarrolla un modelo compuesto por muchos actigramas y datagramas definidos de forma jerárquica.

La metodología SADT engloba un conjunto de herramientas automáticas de soporte para los procedimientos de análisis y un método organizativo bien definido mediante el que se aplican las herramientas. Quedan especificadas revisiones y puntos de referencia que permiten una validación de la comunicación entre el cliente y el desarrollador.

Etapas De La Planeación Estratégica De SistemasPara llevar a cabo una planeación de sistemas se requiere de 3 pasos:

1. establecer las metas de los sistemas,

2. determinar y asignar prioridades a las solicitudes de proyectos de sistemas y

3. Evaluar los recursos y la capacidad de los sistemas.

9

Establecer las metas de los sistemas. Este paso implica la revisión de la dimensión de las operaciones de la organización, las políticas de sistemas y el plan de la empresa. El objetivo principal es establecer las metas de la organización y enlazarlas con las metas de los sistemas. A partir de esto empiezan a surgir ideas de proyectos en sistemas para dar soporte a estas metas. Para dar forma a las ideas de proyectos, se recopila información de entrada de los miembros del equipo , incluyendo información de otras personas que puedan contribuir al proceso de planeación como consultores y auditores internos. El proceso de planeación deberá alinear sus actividades con la estrategia de la empresa, enfocando los proyectos hacia las metas estratégicas de la compañía e identificando las áreas en las que probablemente se encontraran oportunidades con altos beneficios. A partir de este proceso de investigación se plantean metas generales de sistemas de información. Estas metas pueden proponerse como :

diseño e implementación de sistemas que apoyen a las metas organizacionales,

aprovechar las oportunidades de negocios proporcionadas por las nuevas tecnologías informáticas y

seguir una metodología de desarrollo de sistemas que interactúe con los usuarios y proporcione el estado de los sistemas.

Determinar y asignar prioridades a las solicitudes de proyectos de sistemas. Durante el paso anterior se tiene una gran comunicación entre los usuarios y el personal de sistemas. A partir de esta interacción empiezan a formalizarse los proyectos, formado por algunas ideas de los usuarios como ideas provenientes por el personal de sistemas. Siendo en cualquier caso, se producen solicitudes de proyectos de sistemas y se realiza en un intercambio libre de ideas. Para ello ninguna compañía, ni su sistema de

10

información cuentan con los recursos necesarios para atender a las solicitudes de proyectos de sistemas, ni todas las solicitudes son buenas. Este método implica el llenado de una forma de solicitud de proyectos de sistemas que se ilustra en la figura 1-1., así como la preparación de una hoja de trabajo de prioridades de las solicitudes de proyectos de sistemas que se muestran en la figura 1-1.

Fig 1-1 Hoja de Solicitud de proyectos

SOLICITUD PARA UN TRABAJO DE SISTEMAS

PARTE I. Llenada por el solicitante

FECHA DE SOLICITUD : _____________PRESENTADA POR : ____________________________DEPARTAMENTO :_____________________________________________________________________________NATURALEZA DE LA SOLICITUD : __________________________________________________________________________________________RAZONES DE LA SOLICITUD : _____________________________________________________________________________________________ANEXO DE DOCUMENTOS DE APOYO : _____________________________________________________________________________________

SOLICITUD DE: Modificación del Sistema

Rediseño del Sistema

PARTE I. Llenada por el personal de informática

LAS MODIFICACIONES PARECEN SER : Menores Mayores Extensas

LA IMPLEMENTACION PUEDE REQUERIR CANTIDAD ADICIONAL DE :

HARDWARE SOFTWARE PERSONAL

LOS RECURSOS REQUERIDOS SERIAN :

MENORES MAYORES EXTENSAS

CALIFICACIONES DE LOS FACTORES DE FACTIBILIDAD :TECNICO ____ LEGAL _____ ECONOMICO ______ SOCIAL _____ OPERACIONAL _____

INVESTIGACIÓN PRELIMINAR DESARROLLADA POR : ____________________________________________________________________________________________________NOMBRE DEL PROYECTO : ___________________________________________________________________________________________________________________________FECHA : __________

PARTE I. Llenada por el personal de informática

CALIFICACION DE LOS FACTORES ESTRATEGICOS :PRODUCTIVIDAD : ___ DIFERENCIACION : _____ ADMINISTRACION : _____ CALIFICACION ____

Aprobación del inicio del trabajo de sistemas

Inicio : ___________

11

Hoja de trabajo de prioridades de las solicitudes de proyectos

La puntuación tiene una escala de 1 a 10, tanto para factores estratégicos como de factibilidad. Los miembros del equipo de planeación proporcionan puntaje acerca de que tan bien una solicitud de proyecto se enlaza con las necesidades estratégicas y organizacionales de la empresa, tanto en la productividad, mejorar la diferenciación de productos y servicios, así como la toma de decisiones a nivel gerencial. Haciendo lo mismo para los factores de factibilidad: económicos, técnicos, operacionales, legales y de calendario.

Determinación de los recursos y la capacidad de los sistemas. Los aspectos clave en un sistema y su capacidad de operación están representados por su personal y su tecnología. La finalidad de este paso es la determinación de la aceptación que tendrán los proyectos de sistemas planeados sobre estos recursos, así como afirmar de que se cuenta con capacidad suficiente durante la etapa de planeación, no solo para solucionar la necesidad actual, sino para respaldarlo por condiciones de funcionamiento permanente hasta que un nuevo proyecto lo reemplace de acuerdo a nuevas necesidades estratégicas por parte de la empresa. Los cambios en la capacidad del sistema generalmente mantienen una función escalonada, en tanto que el crecimiento en las necesidades de la capacidad es en cierta forma continua. Esta relación se ilustra con la figura 1-3 en donde se demuestra la forma en que las mejoras tecnológicas, mainframes, software, almacenamiento auxiliar, los periféricos, las redes de telecomunicación y el personal de sistemas, deberán alinearse al crecimiento y satisfacer los requerimientos de capacidad con el paso del tiempo. Fijando a la capacidad máxima en el punto donde la línea punteada está a punto de interceptar la línea de carga. Se considera que las mejoras son necesarias antes del punto de línea de carga para evitar la degradación del sistema en el servicio a los usuarios.

12

Fig. 1-3 Nombre de la gráfica

Análisis Preliminar De SistemasLa principal finalidad de realizar un Análisis Preliminar consiste en evaluar las necesidades del proyecto. Lo cual no abarca un estudio de diseño, ni la recopilación de datos para hacer una descripción completa del sistema; en cambio sirve a los analistas que recopilan la información que permite al comité evaluar las ventajas del proyecto y cimentar bases bajo un juicio sobre la factibilidad del proyecto propuesto.

Las funciones de los analistas que trabajan en el Análisis Preliminar son :

Aclarar y entender la solicitud del proyecto. ¿Qué se está haciendo?, ¿Qué es lo que se necesita?, ¿Por qué?

13

Determinar la dimensión del proyecto

Señalar los costos y beneficios de las alternativas apropiadas

Determinar la factibilidad técnica y operativa de otras alternativas

Informar los hallazgos a la gerencia con recomendaciones y subrayando la aceptación o rechazo de la propuesta.

Preparación del reporte de la propuesta para realizar un análisis de sistemas.Una vez aceptado el proyecto el analista de sistemas debe definir el alcance y desarrollar un enfoque profundo de los requerimientos y necesidades de los usuarios. El documentos que resulta de este análisis preliminar es el reporte de la propuesta para realizar un análisis de sistemas en donde este documento representa un acuerdo entre el analista de sistemas y los usuarios.

Razones para iniciar el análisis de sistemasLos analistas de sistemas deben entender en primer lugar porque se va a realizar un trabajo de sistemas. Las razones básicas para iniciar un análisis de sistemas son las siguientes :

Necesidad de resolver un problema .- Puede suceder que el actual sistema no este funcionando como se esperaba entonces se acude al analista de sistemas para que corrija esta anomalía.

Nuevas necesidades .- Esto ocurre cuando surgen nuevas disposiciones en la organización. Puede tratarse de una nueva ley, práctica contable, ó una nueva práctica administrativa. Independientemente de la causa que de origen a la nueva necesidad el analista de sistemas identificará las modificaciones o adiciones que deben hacerse al sistema, con el fin que la empresa pueda satisfacer dicha necesidad.

Implantación de una nueva tecnología .- Puede ser el caso de implantar un técnica diferente por ejemplo: Si se ha empezado a utilizar equipo de reconocimiento de caracteres ópticos

14

para dar entrada a los pedidos de los clientes, es más probable que haya necesidad de diseñar un nuevo subsistema.

Mejoramiento general de los sistemas .- Por último el analista deben encontrar el modo de hacer mejor lo que ya se tiene.

Solicitud de un análisis de sistemasLos analistas de sistemas independientemente de las razones para efectuar un análisis de sistemas, todos los proyectos deberán empezar con una forma de solicitud de servicios de sistemas de información similar a la siguiente (Fig. 1-4):

SOLICITUD DE SERVICIOS DE SISTEMAS DE INFORMACION

NOMBRE DEL SISTEMA :

BENEFICIOS ANTICIPADOS:

NUEVO

REVISADO

FECHA DE SOLICITUD:________FECHA REQUERIDA : _________

SALIDA ENTRADA

SOLICITADO POR : ____________________ DEPARTAMENTO: _____________________ PUESTO:___________APROBADO POR : _____________________ DEPARTAMENTO: _____________________ PUESTO:___________

APROBADO

APROBADO BAJO CONDICION RAZON:________________________________________________

RECHAZADO RAZON:________________________________________________FIRMA ________________________________

DEPARTAMENTO :__________________________________

PUESTO :__________________________________________

FECHA :____________________________________________

___________________________________________________________________________________________

COMENTARIOS : ___________________________________________________________________________

15

Esta forma no solo sirve para proporcionar información acerca del proyecto de sistemas y sus objetivos, sino también de beneficios anticipados, así como una especie de contrato o acuerdo entre el usuario y el analista de sistemas.

La mayoría de las veces esta solicitud es llenada entre los usuarios y los analistas trabajando conjuntamente, el usuario generalmente tiene la información completa de las necesidades de entrada y de salida y posiblemente una noción general de los controles necesarios.

Los analistas de sistemas interactuan con el usuario para refinar, sintetizar y agregar sobre estas ideas. Esta forma determina un punto claro de inicio, eliminando de esta forma la posibilidad de varias salidas no requeridas e innecesarias que seria el objetivo principal que se debe evitar en esta etapa.

Inicialmente el proyecto debe tener un alias o un nombre corto llamativo, esto personaliza el proyecto y facilita su referencia. Además se ha determinado que si los usuarios que solicitan el sistema asignan el nombre al proyecto de sistemas, entonces éste se convierte en su sistema.

Conclusiones del análisis preliminar de sistemasUna vez que el analista de sistemas completa las entrevistas iniciales y determina que deberá realizarse el análisis de sistemas, se deberá comunicar formalmente con los usuarios solicitantes y la gerencia del analista de sistemas el entendimiento de lo que debe realizar y el enfoque general hacia esta meta.

Esta comunicación se le denomina reporte de la propuesta para realizar el análisis de sistemas. Proporcionando un punto de verificación en el que el solicitante puede evaluar si el analista entiende lo que se requiere dando también a la gerencia de sistemas la oportunidad de evaluar el enfoque y la cantidad de recursos que se van a emplear durante el análisis.

16

El reporte deberá incluir lo siguiente :

1. Una definición clara y concisa de las razones para realizar el análisis.

2. Un planteamiento específico referente a los requerimientos del desempeño del sistema propuesto.

3. Una definición del alcance del análisis

4. Una identificación de los hechos que probablemente necesiten recopilarse durante el análisis.

5. Una identificación de las fuentes potenciales donde pueden obtenerse los hechos.

6. Un programa que indique los eventos principales del análisis.

Fuentes de los hechos de estudio para el análisis de sistemas.Existen diferentes fuentes de hechos de estudio, dentro y fuera de la organización, información que se encuentra a disposición del analista durante el análisis de sistemas. Las categorías de hechos son :

El sistema actual

Fuentes internas

Fuentes externas

Sistema actualEn la mayoría de las organizaciones existe el caso de que se cuenta con un sistema o subsistema, con frecuencia se dedica una gran cantidad de dinero y tiempo investigando, analizando y documentando el sistema anterior, con resultados que en la mayoría de los casos aporta muy pocos resultados.

17

Algunos aspectos a tomar en cuenta para analizar el sistema anterior son :

Eficacia del sistema actual. El estudio del sistema anterior es una oportunidad para conocer si dicho sistema es satisfactorio, si requiere alguna reparación menor, si requiere mantenimiento o si hay que reemplazarlo.

Ideas de diseño. El análisis del sistema anterior puede apoyar al analista en ideas de diseño, así como apreciar notablemente la forma en cómo se está haciendo y de que forma, así como la observación de las necesidades y capacidades que el sistema anterior ahora requiere.

Reconocimiento de recursos. El reconocimiento de recursos permite al analista identificar con que recursos cuenta, como personal de oficina, instalaciones de infraestructura, equipo de cómputo que posee actualmente y está en operación.

Conocimiento de conversión. En el caso de que se implemente el nuevo sistema, el analista coordinará funciones que se dejaran de hacer del sistema anterior, así adecuar algunas funciones anteriores al nuevo sistema, para ello es necesario que el analista revise el sistema anterior para observar cómo se hacia.

Los gastos de tiempo generalmente convertidos en dinero son una desventaja en el análisis de un sistema anterior.

Fuentes internasLa fuente más importante para un analista es la gente. Esto incluye la parte gerencial, personal de oficinas o usuarios directos, ya que son las personas más cercanas que se encargan de procesar la información, siendo una fuente parlante que nos puede proporcionar una lista de necesidades y requerimientos, influyendo la participación del analista de lo que se puede hacer para proporcionar y orientar a los usuarios hacia un mejor planteamiento de requerimientos.

Otra fuente interna es el papeleo o la documentación existente dentro de una organización, clasificándolo en documentos que describen la organización de la empresa, documentos que describen lo que la empresa planea así como documentos que describen lo

18

que hace la empresa. En la tabla 1-1 se muestra una lista de la posible documentación interna.

Documentos que describen cómo está organizada la empresa.

Documentos que describen lo que planea hacer la empresa.

Documentos que describen lo que hace la empresa.

Declaraciones políticas

Manuales de métodos y procedimientos

Organigramas

Descripción de puestos

Delegación de desempeño

Delegación de autoridad

Catálogo de cuentas

Declaración de metas y objetivos

Presupuestos

Programas

Pronósticos

Planes (a largo y corto plazo)

Minutas corporativas

Estados financieros

Reportes de desempeño

Estudios por personal asesor

Reportes históricos

Archivos de Transacciones

(incluyendo: órdenes de compras, pedidos de los clientes, facturas, hojas de tiempo, registros de gastos, correspondencia con los clientes.)

Documentos legales

(incluyendo: derechos, patentes, franquicias, marcas registradas, juicios)

Archivos de referencia maestros (incluyendo:clientes, empleados, productos,

19

proveedores)

Tabla 1-1 Diversos tipos de documentos a disposición del analista en una organización a partir de las cuales se puede obtener información referente al análisis de sistemas.

Fuentes externas

El trabajo del analista de sistemas lo puede llevar a cabo fuera de los límites de una organización para la cual se está efectuando el análisis. Es decir, el analista de sistemas puede tomar ideas, conceptos, técnicas, procesos y formas de operación de los sistemas de otras organizaciones, tomando en cuenta que algunas organizaciones son muy celosas de su información, pero cabe resaltar que se puede tomar en cuenta la información de experiencias, así como observaciones vistas en otros sistemas que pueden ser de utilidad para el desarrollo del nuevo sistema.

Los libros de texto y revistas proporcionan información teórica o práctica, así como algunas propuestas que pueden beneficiar al analista donde ideas o tomando bases para el desarrollo de sistemas. El asistir a cursos, seminarios, talleres, conferencias los analistas se pueden beneficiar, obteniendo información actualizada e innovadora.

Las fuentes de hechos de estudio disponibles para un analista durante el análisis de sistemas son variadas y abundantes. La cantidad de fuentes puede diferir del análisis a análisis, tomando en cuenta restricciones en tiempo y costo. El tamaño y complejidad del sistema a estudiar también ayuda a determinar la fuente necesaria a utilizar.

20

Técnicas de la recopilación de hechos de estudioExisten una variedad de métodos para los analistas a fin de recopilar datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros y observación. En donde en cada uno de ellos tiene ventajas y desventajas. Generalmente se utilizan una o dos técnicas para complementar el trabajo.

Entrevista

La entrevista se utiliza para recopilar información en forma verbal, a través de preguntas que propone el analista. Las personas que responden pueden ser gerentes o empleados, quienes son usuarios actuales del sistema existente, usuarios principales del sistema propuesto o aquellos que serán afectados por el sistema propuesto. La entrevista puede ser en forma individual o en grupo, se debe tomar en cuenta que las entrevistas no son siempre la mejor fuente de información.

Recabar Datos Mediante La Entrevista

“¡La entrevista es una forma de conversación, no de interrogación! al analizar las características de los sistemas con el personal seleccionado cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no están disponibles en ninguna otra forma” 1

En la investigación de sistemas, los aspectos cuantitativos y cualitativos de información son importantes. Los aspectos cuantitativos tratan con números, cantidades ó frecuencias, mientras que los aspectos cualitativos se relaciona con opiniones, políticas, descripción narrativa de actividades o problemas. En general las entrevistas tienden ser mejores fuentes de información cualitativas, mientras que las otras técnicas son mejores fuentes de aspectos cuantitativos.

21

Se debe tomar en cuenta los beneficios que se obtiene al elaborar una entrevista, ya que mucha gente es incapaz de expresarse por escrito, pero puede expresar sus ideas en forma verbal. Como resultado de estos las entrevistas pueden detectar malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo. Siendo valioso los comentarios, ideas o sugerencias en relación a cómo se podría hacer el trabajo. La entrevista, a veces es la mejor forma para conocer las actividades de una empresa.

Determinación Del Tipo De Entrevista

La estructura de la entrevista de acuerdo a los objetivos, es decir, si los objetivos de la entrevista radican en adquirir información en general, es conveniente llevar a cabo una serie de preguntas sin estructura, con sesión de preguntas y respuestas libres, esto proporciona una mayor oportunidad para conocer actitudes, creencias e ideas de quién responde, sin embargo cuando se desean conocer respuestas más directas sobre el sistema o asegurar una alta confiabilidad sobre las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores.

La entrevista estructurada estandariza las preguntas. El formato de las preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta, permiten a los entrevistados dar cualquier respuesta que parezca apropiada contestando con sus propias palabras. Con las preguntas para respuestas cerradas se proporciona a los entrevistados un conjunto de respuestas que pueda seleccionar. Todos los entrevistados se basan en un conjunto de respuestas posibles. Las entrevistas no estructuradas requieren menos tiempo de preparación, Sin embargo analizar las respuestas lleva más tiempo que con las entrevistas estructuradas, De cualquier forma , el mayor costo radica en la preparación, administración, análisis de las entrevistas estructuradas para preguntas cerradas.

22

Selección De Entrevistados

Dado que el número de entrevistados el limitado los analistas deben tomar en cuenta todas aquellas personas tiene información que no se podrá conseguir de otra forma, Durante la investigación detallada en donde el propósito es descubrir hechos específicos, opiniones y conocer cómo se desempeñan actualmente las actividades, las entrevistas se aplican a todos los niveles gerenciales y de empleados y se depende de quien pueda proporcionar la mayor parte de la información útil para el estudio.

Realizacion De La Entrevista

La habilidad del entrevistador es importante en la búsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen de la capacidad del analista tanto en la preparación del objetivo de una entrevista específica como de las preguntas por realizar a una persona determinada. El tacto, la imparcialidad e incluso la forma apropiada de vestirse ayudan a segurar una entrevista exitosa. La falta de alguno de estos factores puede determinar el éxito de una entrevista. A través de la entrevista, los analistas deben preguntarse así mismos las siguientes preguntas :

1. ¿Qué es lo que me está diciendo la persona?

2. ¿Por qué me lo está diciendo a mí?

3. ¿Qué se está olvidando?

4. ¿Qué espera esta persona que haga yo?

Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán más conocimiento no solamente de la información adquirida sino también la importancia que implica.

23

Cuestionario

Los cuestionarios son un medio que proporcionan una alternativa muy útil para las entrevistas; sin embargo existen ciertos aspectos que pueden ser apropiados en algunas situaciones e inapropiados en otras. Al igual que las entrevistas, deben elaborarse cuidadosamente.

Recabacion De Datos Mediante Cuestionarios

Para los analistas de sistemas los cuestionarios pueden ser el medio de comunicación con un gran número de personas para la obtención de conocimiento de varios aspectos del sistema, En los cuestionarios no es posible ver las expresiones, gestos o reacciones de quienes responden los cuestionarios.

Para obtener mejores resultados se recomienda reunir al mayor número posible de gentes para la resolución de un cuestionario, las tasas de respuesta pueden mejorar, aunque rara vez se tendrá una respuesta total

Selección De Formas Para Cuestionarios

La elaboración, desarrollo y distribución de los cuestionarios es costoso, debido a esto se debe utilizar de forma inteligente el tiempo invertido en los cuestionarios. Existen dos formas de cuestionario para recopilar datos : cuestionario abierto y cuestionario cerrado

Cuestionario Abierto. Este tipo de cuestionario se aplica cuando se quiere conocer los sentimientos, opiniones así como experiencias generales. El cuestionario abierto es el medio que proporciona una amplia oportunidad para las personas que respondan expresen las

24

razones de sus ideas, En algunos casos las personas prefieren un conjunto de respuestas preparadas que pensar por sí mismas.

Cuestionario Cerrado. Limita respuestas posibles del interrogado. Esto es por medio de preguntas que en su elaboración se prestan para este tipo de recopilación de datos, cuidando el marco de referencia de lo que desea el analista. Este medio es el mejor método para obtener información sobre los hechos. La forma del cuestionario cerrado forza a los interrogados tomen una posición y formar su opinión sobre los aspectos importantes.

Etapas En El Desarrollo De Un Cuestionario

Los cuestionarios bien elaborados no se desarrollan rápidamente, llevan tiempo y mucho trabajo. El primer aspecto en tomar en cuenta es determinar el objetivo del cuestionario, en donde el analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura más útil para el estudio y la forma más sencilla por parte de los interrogados.

Para la elaboración de un buen cuestionario requiere de mucho tiempo en la formulación de las preguntas, que deben ser probadas y modificadas antes de aplicarlo, si es necesario antes de que se imprima la forma final y se distribuya. A continuación se presentan los lineamientos generales para la recaudación efectiva de los hechos de sistemas por medio de cuestionarios.

COMO DESARROLLAR UN CUESTIONARIO

Los buenos cuestionarios no nada más se escriben, se diseñan. Un pensamiento cuidadoso, acompañado de una prueba previa tanto del formato como de las

25

preguntas, son la base de una recaudación de datos significativa a través de cuestionarios.

Aquí hay algunas pautas para ayudarle en la formulación de un cuestionario:

Determínese qué datos necesitan recabarse y qué personas son las más calificadas para proporcionarlos. Si otros grupos pueden proporcionar datos variantes y mayor visión identifíquese también.

Selecciónese el tipo de cuestionario para utilizarlo (Abierto o Cerrado). Reconózcase que algunos cuestionarios pueden ser más útiles, si contienen una sección con preguntas de respuesta cerrada y otras con preguntas de respuestas abierta.

Desarróllese un grupo de preguntas para incluirlas en el cuestionario. Las preguntas extras que son intencionalmente redundantes, pueden ser útiles al asegurar respuestas consistentes por parte de quien responda.

Examínese el cuestionario para encontrarle fallas y defectos; como :

a. Interrogantes innecesarias, lo mismo se ha preguntado y no hay necesidad para una verificación extra.

b. Las preguntas pueden ser mal interpretadas debido a su enfoque o forma de escritura.

c. Preguntas que el sujeto posiblemente no pueda responder, dado que desconoce la respuesta.

d. Preguntas que están escritas de forma que se escogerá la respuesta preferida.

26

e. Preguntas que se interpretarán en forma diferente, dependiendo del marco de referencia de cada entrevistado.

f. Preguntas que no proporcionan opciones adecuadas de respuesta.

g. Un ordenamiento no adecuado de las preguntas o respuestas.

Pruébese previamente el cuestionario en un grupo pequeño de personas, para detectar otros problemas posibles. Hacer esto no solamente descubre los problemas en cuanto a su escritura, espaciado, ortografía y métodos de registro de respuesta, sino también proporciona una indicación del tipo de respuesta que se recopilarán en un grupo mayor. Si existen muchas respuestas inesperadas, se captarán durante la prueba previa más que durante la recaudación de datos reales.

Analícense las respuestas del grupo de prueba para asegurar que el análisis de los datos que se busca puede llevarse a cabo con el tipo de datos recopilados. Si los datos de la prueba no revelan algo que los analistas no conocen y no necesitan verificar, el cuestionario puede no ser necesario en su forma actual.

Realícense cambios finales de edición, correcciones de mecanografía y ajustes a la forma; entonces imprimase el cuestionario en una forma limpia legible. Distribúyase el cuestionario. Cuando sea posible, anótese el nombre de cada persona. Se comienza en forma incorrecta con nombres y direcciones como “a quien corresponda”, “empleado por hora de producción”, o “departamento 34 A”

27

Selección De Quienes Recibirán El Cuestionario

Aquellas personas que reciban el cuestionario debe seleccionarse de acuerdo con la información que pueda proporcionar. Lo pueden contestar personas no calificadas y si el cuestionario no es anónimo, ya no será posible retirar las respuestas de la muestra, lo cual es caro y ocasiona desgaste.

Antes de la distribución de los cuestionarios es necesario asegurar que quienes lo reciban tengan los datos necesarios para responder los cuestionarios, además de verificar sus antecedentes y experiencias que fueron la base para responder el cuestionario.

Revisión de Registros

El término “Registro, se refiere a los manuales sobre las políticas, regulaciones y procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para gerentes y empleados”. Debido a ello con frecuencia en muchas organizaciones la información se encuentra a disposición para que los analistas tengan conocimiento de las actividades u operaciones con las cuales no se encuentra familiarizado.

Los manuales con que cuentan estas organizaciones documentan o describen las operaciones para los procesos de datos ya existentes, o los sistemas de información que entran dentro del área de investigación también proporcionan una visión sobre la forma en que la organización debe conducirse. Generalmente muestran los requerimientos y restricciones del sistema y características de diseño. Estos registros en algunos casos no muestran donde se ubica el verdadero poder para la toma de decisiones, como se realizan las tareas en la actualidad, ó las posibles alternativas de como solucionar un problema. Es aquí donde entran las entrevistas y cuestionarios, herramientas que son eficaces para proporcionar al analista este tipo de información.

28

Selección De Los Registros Para Revisión

En la mayoría de las empresas los manuales y estándares de procedimientos de operación con los que cuentan generalmente son obsoletos, ya que no por lo regular no señalan los procedimientos existentes.

Algunos analistas seleccionan los documentos a fin de determinar cuáles se utilizan y cuándo, y cuáles no se utilizan después de llenarlos. Este esfuerzo extra puede ser difícil y llevar mucho tiempo si son demasiados documentos; pero establecer un diagrama de procedimientos y flujos puede resultar de gran utilidad para lograr una visión integral de todas las tareas.

El analista debe buscar formas y documentos que desconoce la mayoría, aquellas que las personas elaboran para su propio uso, pero que no pertenecen a los procedimientos preestablecidos. No deben pasarse por alto los informes de estudios previos, los resúmenes de consultores y los informes de los gerentes. Estos pueden proporcionar una historia que explique el mecanismo de los procedimientos que los analistas observan durante el estudio, y pueden proporcionar algún dato sobre puntos ya detectados y aún sin solución.

Observación

Observar las operaciones le proporciona al analista hechos que no podría obtener de otra forma.

Recopilación De Datos Mediante La Observación

Leer en relación con una actividad de un negocio le proporciona al analista un visión de las actividades del sistema. Aplicar Entrevistas o cuestionarios a grupos de personas, también le ayuda o le dice algo más. Ninguno de los dos métodos da una información completa. Leer sobre autos de carrera no reproduce la experiencia de viajar a 300kph. de velocidad. La observación proporciona información de primera en relación con la forma en la que se llevan a cabo las actividades.

29

Cuando Observar

La observación es muy útil cuando el analista necesita ver cómo se manejan los documentos, cómo se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y cómo interpretar su significado, también requiere de experiencia. Algunos observadores con experiencia captan quién utiliza los documentos y si encuentran dificultades; también están alertas para detectar documentos o registros que no se utilizan. Siempre se deben identificar las tareas problemáticas, que llevan a los empleados a cometer errores con frecuencia al completarlas, así como aquellas que tienden a retardar el procedimiento.

La Observación Le Enseña Al Analista

Lo que debe suceder....

Procedimientos normales de operación

Controles y verificaciones de exactitud y grado de terminación

Documentos llenados en forma apropiada

Terminación del trabajo en forma eficiente y a tiempo

Lo que realmente ocurre....

Retraso al hacer el trabajo

Información que se recuerda de memoria (Incorrectamente)

Etapas omitidas

Fotocopia extra necesaria

Necesidad de nuevos controles

30

Información que no se encuentra en el archivo

Documentos mal llenados

Los empleados no están conscientes de los procedimientos prescritos

3. Análisis De SistemasDefinición De Análisis De SistemasDentro de las organizaciones, el Análisis de Sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de mejorarla con métodos y procedimientos más adecuados, por consiguiente, es el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y empleo de la información para recomendar mejoras al sistema.

Un Sistema “Es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común”. La figura 2.1 muestra una aplicación de los conceptos de sistemas a una situación familiar en una organización, Observe la interrelaciones entre los elementos. Esta característica es importante para lograr la exitosa operación de los sistemas.

31

Figura 2.1 Elementos básicos de control de un modelo de sistemas

Análisis Del Modelo FuncionalEn el modelo funcional, el objetivo de los analistas es el de identificar y analizar las áreas funcionales, funciones y actividades que se realizan para llevar a cabo los objetivos de la empresa. Este tipo de información constituye el punto de partida para la agrupación adecuada de la información que se empleará para construcción de los modelos de datos.

Las tareas principales para llevar a cabo el análisis del modelo funcional son :Identificar y analizar las áreas funcionalesIdentificar y analizar las funciones de cada área funcionalIdentificar y analizar las actividades de cada funciónRevisar y analizar el modelo funcional con los ejecutivos de alto nivel

Frontera del Sistema

Componentes del Sistema

Retroalimentación de los resultados de la comparación

Entrada Salida

Medios de Comparación

DesempeñoActual

Actual Estándar

32

El modelo funcional es representado por un documento analítico que muestra el conjunto de áreas funcionales de la organización con sus funciones y actividades el cual se puede representar de formas. La primera forma consta de una tabla que contiene el nombre del área funcional con sus funciones y su respectiva actividad por función

La segunda forma de representar a un Modelo Funcional puede llevar a cabo mediante un organigrama como se muestra en la figura 2.3.

ACTIVIDAD ACTIVIDAD

F U N C IO N

ACTIVIDAD ACTIVIDAD

F U N C IO N

AREA FUNCIONAL

33

Figura 2.3. Otras representaciones del Modelo Funcional

Existen unas formas para registrar e identificar las áreas funcionales “FORMA 0” (figura 2-4), Identificación y registro de Funciones/Actividades “FORMA 1” (figura 2-5), Identificación y registro de Documentos “FORMA 2” (figura 2-6), Registro de Campos “FORMA 3” (figura 2-7).

34

Figura 2-4. Forma para identificación y registro de Áreas Funcionales

35

Figura 2-5. Forma para identificación y registro de Funciones/Actividades

36

Figura 2-6. Forma para identificación de Documentos

37

Figura 2-7. Forma para Registro de Campos

El Modelo Funcional sirve como base para el análisis del Modelo de Datos, porque del Modelo Funcional se extraen datos de acuerdo a las actividades y funciones analizadas con el objetivo de obtener información de :

Las formas y los reportes que se emplean

El origen y destino del reporte y documento

Las características de su uso

Los catálogos que se emplean en la elaboración del reporte

La descripción y el formato de cada dato

Análisis Del Modelo De DatosEste modelo de datos es la base para sistemas con propósito de toma de decisiones de la parte directiva y los mismos datos se aplican en usos múltiples. Para este método se deben tomar en cuenta conceptos asociados con las bases de datos y los sistemas para su manipulación. Los diagramas de entidad-relación y los diagramas de estructuras de datos son herramientas de utilidad para el diseño y poder llevar a cabo la aplicación de este modelo.

FORMA 3Nombre de la Actividad :Documento:

No. Consecutivo Nombredel Campo

Tipo Longitud Formato Descripción

38

Esta filosofía de diseño marca que los datos son el centro de procesamiento de datos, en donde los datos son almacenados y mantenidos con el apoyo de distintas transacciones, este almacenamiento y mantenimiento es efectuado por un sistema manejador de base de datos (DBMS: Data Base Manager System) auxiliándose de transacciones para la producción de información, es decir, existe una generación de datos así como su actualización, este modelo con los datos, el DBMS y las transacciones da como resultado generación de documentos, generación de gráficas, así como apoyo en la toma de decisiones, auditorias y búsqueda de información. Figura 2.8

CREACIONDE DATOS

ACTUALIZACIONDE DATOS

GENERACIONDE

DOCUMENTOS

GENERACIONDE GRAFICAS

TOMA DEDESICIONES

BUSQUEDADE

INFORMACION

AUDITORIAS

DATOS

TRANSACCIONES

TRANSACCIONES

DBMS

DBMS

39

Figura 2.8 Modelo de datos

Diagrama de Estructura de DatosEsta técnica considera a los datos independiente del procesamiento que transforma los datos, esto no indica que se omitan. Esta modelización de datos como su nombre lo indica modeliza datos sin preocuparse por el procesamiento que se deba aplicar para transformar los datos, siendo por tanto una técnica complementaria en donde se puede combinar con otro enfoque de modelo que se haga cargo de la modelización que manipule aspectos de procesamiento para un análisis completo.

La modelización de datos es ampliamente en aplicaciones de bases de datos. Esto proporciona un gran panorama para analistas y diseñadores de la base de datos una amplia visión de los datos y sus relaciones. Los datos pueden ser entidades externas, cosas, concurrencias, sucesos, papeles, estructuras o lugares. Por ejemplo: En un plantel se cuenta con docentes y alumnos, los cuales pueden ser tomados como datos puesto que estos contienen un conjunto de atributos (Figura 2.9).

DATOS/ENTIDAD ATRIBUTOS RELACIONES

Nombre del plantel

Director

Teléfono

Número de Aulas

Nombre

RFC

40

Plaza

Horas frente a grupo

Horas comisionadas

Número de Control

Nombre del Alumno

Edad

Calificaciones

Grupo

Semestre

Figura 2.9 Entidades, Atributos y Relaciones

Los atributos de las entidades u objetos de datos se caracterizan por 3 aspectos :

Dar nombre a una creación de entidad

Describir la entidad

Hacer referencia a otra creación de otra tabla de atributos u/o otra entidad

Además de que se pueden utilizar uno o más atributos para relacionarse con otra entidad o entidades. Esto se puede llevar a cabo utilizando un modelo relacional de los datos siendo la aplicación sobre tablas (Figura 2.10) en donde se muestran los

41

atributos y su relación tomando en cuenta la optimización de relaciones redundantes. Estas reglas de normalización son las siguientes :

Una entidad tiene un valor y sólo un valor para cada atributo.

Los atributos representan la unidad mínima, es decir, no contienen estructuras.

Cuando se utiliza más de un atributo para identificar una entidad, hay que asegurarse que estos atributos representen una características completa de la entidad.

Todos los atributos que no sean identificadores deben representar características de la entidad nombrada.

AM01MT02FR03EG04

AVENDAÑO MORALES RAMIREZ VALTIERRA M.GONZALES ELIAGONZALES FELIPE

AVEM540723X2GRAVM640315BN5GOEL650923JJ1GOFE740513BN2

E4861E4521E4527E4729

40384036

G04G02G04G01

ABCD

1111

G04G02G04G01

CLAVE DOCENTE RFC PLAZA HRS GRUPO

GRUPO SEMESTRE CLAVE

IDENTIFICADOR ATRIBUTOS DE DENOMINACION ATRIBUTOS DESCRIPTIVOSATRIBUTOS

REFERENCIALES

Relaciona una entidadcon otra

42

Figura 2.10 Las entidades representadas en tablas.

Carta de Entidades.Para la modelización de datos se utiliza una notación denominada “Diagrama de Entidad-Relación”, siendo su propósito principal representar a cada entidad y su relación mostrando la clase de información necesaria para satisfacer un requerimiento de información. Su notación es sencilla, las entidades se representan con rectángulos etiquetados, las conexiones entre entidades se representan mediante varias líneas de conexión con un formato especial. (Figura 2-11)

43

Figura 2-11 Notación de diagramas Entidad-Relación

La modelización de datos y el diagrama de Entidad-Relación se convierten para el analista una notación que produce resultados concisos para ser examinados en el procesamiento de datos.

44

Carta de Burbujas.Debido a que los datos se mueven a través del sistema sufre constantes modificaciones, los diagramas son técnicas para representar el flujo de la información desde la entrada, proceso, hasta su salida.

El diagrama de Burbuja o diagrama de flujo de datos puede representar un sistema a cualquier nivel de abstracción representando así un mayor flujo de información y un mejor detalle funcional, el primer nivel o nivel 0 también denominado modelo fundamental del sistema del cual se puede elaborar en subniveles más diagramas partiendo del nivel 0.

En los diagramas de burbuja la notación que se usa para su creación consiste en un rectángulo el cual representa una entidad externa (hardware, persona, otro programa, etc..) u otro sistema que genere información a ser transformada por el software o sistema. El círculo representa un proceso o transformación aplicado a los datos, las flechas utilizadas en el diagrama de burbuja indican el flujo y estas deben estar acompañadas por una etiqueta. La doble línea representa almacenamiento de información que es utilizada por el sistema. (Figura 2-13)

45

Figura 2-13. Notación de un diagrama de burbuja básico.

Cabe mencionar que el diagrama de burbuja no representa ninguna información explícita de la secuencia de procesamiento, estando

implícitamente en el diagrama.

Esquema general del sistema.Este tipo de diagrama muestra la operación propuesta para el nuevo sistema, en el cual se representan las transacciones manuales y las transacciones automatizables, las cuales interactuan con la base de

datos.

Su notación es simple utilizando rectángulos sencillos para indicar las transacciones manuales y rectángulos dobles para indicar las transacciones automatizables utilizando las flechas que indican la

dirección de la transacción. (Figura 2.14)

UnidadExterna

PROCESO

Elementosde datos

Almacén de Datos

Un productor o consumidor de información que residefuera de los límites del sistema a ser modelado.

Un transformador de información que reside dentro de loslímites del sistema a ser modelado

Un elemento de datos o una colección de elementos dedatos; la cabeza de la flecha indica la dirección del flujode datos.

Un depósito de datos que se guardan para ser usados poruno o más procesos.

46

Figura 2-14. Notación para representar el Esquema General de un Sistema

47

Mapa de Acceso Lógico Este tipo de diagrama sirve para representar la secuencia del acceso lógico de una transacción a un modelo de datos, siendo su notación básica similar a un Diagrama de Entidad-Relación con la diferencia de que en el Diagrama de Mapa de Acceso Lógico muestra unas líneas que indican la dirección etiquetadas por el tipo de operación que se efectúa, estas operaciones afectan a los datos como : lectura, modificación, borrado o agregar datos. Las entidades representadas por un rectángulo van acompañadas en su parte exterior por los atributos de cada entidad (Figura 2-15).

Figura 2-15. Ejemplo de un submodelo de datos extraído para el diseño de la transacción de admisión de pedidos.

CLIENTE

PEDIDO

DETALLEDE

PEDIDO

ORDEN

PRODUCTOS

C1

C2

2. Adición A

1. Lee

3. Modifica

4. Lee

5. Adición A

C1. Si razón de crédito es buenaC2. Si hay producto disponible

No_Cliente,Nombre,Rfc,Tel,Dir

No_Pedido,FechaEntrega,NoClienteTotalPed,Descuento,FechaPedido

No_Pedido,NoProd, Cant_PediCant_Entre,PrecTotal,Detalle

NoProd,NombrePed,Precio,Punto_ReorCantidadExis,PrecioCata

No_Prod,No_Pedido,FechaPedCanti_Ord

48

Cabe mencionar que dentro de la nomenclatura básica de un Mapa de Acceso Lógico existe la aplicación de condiciones representadas por un punto etiquetado el cual establece una conexión, en el Mapa de Acceso Lógico se agregará la etiqueta de condición acompañada de la descripción de la condición.

Diagrama de Acción Es una representación gráfica de la utilización de los datos en las transacciones, en donde se ubican las acciones que se efectúan seguidas por un rectángulo que contiene la entidad y las estructuras de control (condiciones y estructuras de control repetitivas) Figura 2-16.

CLIENTE

PEDIDO

PRODUCTO

DETALLE DE PEDIDO

ORDENA

PEDIDO

ADMISION DE PEDIDOS

LEE

SI RAZON DE CREDITO ES BUENA

PARA TODOS LOS PRODUCTOS PEDIDOS

ADICION A

LEE

SI HAY PRODUCTO DISPONIBLE

DE LO CONTRARIO

ADICION A

ADICION A

MODIFICA A

49

Figura 2-16 Ejemplo de un diagrama de acción para la transacción de admisión de pedidos.

El Diagrama de Acción tiene la función de indicar de una forma más clara la especificación de las estructuras de control repetitivas y de condición, las cuales son especificadas en el Mapa de Acceso Lógico. Su nomenclatura es simple. En la Figura 2-17 se ilustra los posibles usos de las condiciones.

Figura 2-17. Notación para indicar condiciones

ENTIDAD 1

ENTIDAD N

CONDICION

OPERACION 1

OPERACION N

::: :::

ENTIDAD 1

ENTIDAD N

CONDICION

OPERACION 1

OPERACION N

::: :::

ENTIDAD 1

ENTIDAD X

OPERACION A

OPERACION X

::: :::

DE LO CONTRARIO

50

En la Figura 2-18 se ilustra la notación básica para representar una estructura de control repetitiva.

Figura 2-18. Notación para indicar una estructura de control repetitiva

Miniespecificación La miniespecificación es un listado de proposiciones en un lenguaje parecido a cualquier lenguaje natural como el Español o el Inglés. Cada una de estas proposiciones especifican un paso de transacción o Actividad en un Modelo Funcional o un proceso en un Diagrama de Flujo de Datos.

Debido a que es una narrativa desarrollada con nuestras propias palabras no existe una nomenclatura estricta a seguir. Por lo cual se pueden aplicar palabras o frases comunes de nuestro lenguaje cotidiano. Por ejemplo:

INICIO

FIN

RESTA

SUMA

51

SI/ENTONCES/FIN DEL SI

SI/DE LO CONTRARIO

ESCRIBE

LEE

MODIFICA

REPITE HASTA / FIN DEL REPITE

ENVÍA MENSAJE

CALCULA

+,*,-,/

MULTIPLICA

DIVIDE

ELIMINA

BORRA

ACTUALIZA

SALIR

COMENTARIO

La miniespecificación únicamente lista actividades o transacciones de una parte del sistema en donde se omite la especificación de la presentación de la información visual en pantalla o impresora (color, tipo de letra, posición, cuadros, etc...) ya que se presenta a detalle la transacción, más no aspectos secundarios, los cuales se describen en formatos especiales como son : Formatos de Pantallas y Reportes

Formato de Pantalla y Reportes La mayoría de los sistemas en un análisis requieren de una planeación de la forma en que se obtendrán los datos, así como la forma en que el sistema presentará los resultados, es decir se requiere de una planeación de la distribución de los atributos de las entidades presentadas en pantalla y en papel.

Los formatos de pantalla van acompañados de una hoja de especificación de colores, su función es la de establecer una estandarización en los colores que se aplicaran en las pantallas, en donde además cada color debe estar acompañado por una descripción que representa una acción en el sistema. Por ejemplo:

52

HOJA DE ESPECIFICACION DE COLORES

???

???

???

???

????

Se utiliza para pantallas de captura, modificaciones, consultas y bajas

Indica un mensaje de error enviado por el sistema

Pantallas de ayuda (Cualquier tipo de ayuda)

Para aquellas pantallas donde existan preguntas y menús de barra iluminada

Para indicar la barra iluminada de cada menú

Los formatos de pantalla deben contener una escala para columnas y filas que representen la cantidad máxima de filas y columnas (Por ejemplo: si se está presentando el sistema en el modo texto, la escala en los formatos debe ser de 80 columnas y 24 filas). El formato de pantalla también debe contener una descripción de los campos que se aplican en la pantalla con su nombre, tipo y longitud representando en la pantalla el espacio físico que ocuparía realmente. Cabe mencionar que los campos de tipo carácter o alfanuméricos se representan por medio de una equis (“x”) y los campos de tipo numérico se representan por un nueve (“9”).

53

Los formatos de reporte sirven para indicar como se representará la información producida por el sistema en hoja. Estos deben contener una escala que representa la cantidad máxima de columnas de acuerdo a la capacidad de la impresora que se utilizará o al tipo de letra (Por ejemplo: podemos contar con una impresora de 10” de matriz de puntos y en letra normal el espacio máximo ocupado será de 80 columnas, pero si utilizamos letra comprimida en la misma impresora puede ocupar un máximo de 130 columnas). Los formatos de reporte también van acompañados de una descripción de campos que indique su nombre, tipo y longitud. La información contenida en cada campo al igual que los formatos de pantalla también se deben representar físicamente en el formato de reporte indicando con equis (“x”) la longitud de los campos alfanuméricos o de tipo carácter, con nueves (“9”) la longitud de los campos de tipo numérico (Figura 2-20).

54

REPORTE : 1

OBJETIVO: Reporte de horario de Aulas

1 10 20 30 40 50 60 70 80 90 100 110 120

Descripción de Campos (Nombre, Tipo y Longitud)

55

1 10 20 30 40 50 60 70 80 90 100 110 120

Figura 2-20. Ejemplo de un formato de reporte

Los formatos de pantalla y los formatos de reporte deben ser tantos como sea necesario ya que estos simplifican el trabajo en tiempo de desarrollo. Es necesario agregar en ambos formatos un número y una descripción de su objetivo, por ejemplo : la pantalla número 1 su objetivo es “menú principal del sistema”.

56

Otras técnicasExisten otras técnicas de relevante importancia para documentar el modelo de datos que tienen cierta similitud a técnicas anteriores, variando únicamente los propósitos de dicha técnica:Mapa de transacciones. Es relevante a una transacción, a través de una tabla de referencias donde muestra las rutas utilizadas en particular por dicha transacción, en donde su objetivo principal es hacer referencia al número de veces que los datos sufren una transacción o pasan por un proceso.Mapa de uso combinado. Este documento se encarga de mostrar las transacciones concurrentes contra el modelo de datos, y la carga con la cual contribuye cada transacción, a través de cada ruta utilizada (asociación entre dos entidades), durante un período de procesamiento seleccionado.Mapa de carga compuesto. Muestra las transacciones concurrentes contra el Modelo de Datos, y la carga con la cual contribuyen todas las transacciones a través de cada ruta utilizada (asociación entre dos entidades), durante un período de procesamiento seleccionado.Matriz de Carga. Este documento de diseño es importante para ser utilizado durante el diseño físico de la base de datos; este sumariza la carga total del sistema sobre la base de datos para aquellas transacciones que se procesan concurrentemente durante su período definido; totaliza el número de referencias lógicas contra la base de datos para una transacción sencilla y el número total para aquellas transacciones procesadas durante un período.Modelo Relacional. Diagrama que muestra el Modelo de Datos Lógico convertido en Modelo Físico, siendo su dependencia del tipo de manejador de base de datos utilizado.

Análisis De TransaccionesEn muchos sistemas un elemento de datos es el motivo para determinar uno o más flujos de información, que afectan a la función de acuerdo con el que determine dicho elemento de datos, a este elemento se le denomina transacción que desencadena otro flujo de datos a través de uno o varios caminos. En el caso de que suceda esto en un Diagrama de Flujo de Datos se muestra como en la figura 2-21 denominado flujo de transacción.

57

58

Figura 2-21. Flujo de Transacción

Los pasos a seguir para manipular el flujo de transacción tiene el objetivo de transformar un diagrama de flujo de datos en la estructura de un programa.

Revisión del modelo fundamental del sistema, que consiste en una revisión del diagrama de flujo de datos iniciando del nivel 0 y el nivel 1 que describen la especificación del sistema y la especificación de requisitos del sistema.

Refinar y revisar los diagramas de flujo de datos para el sistema, siendo una revisión a detalle de los niveles 1 y 2 para detectar con

TCaminosde AcciónCentro

deTransacción

...

...

.........

59

mayor posibilidad de éxito un diagrama de flujo de transacción. Determinar si el diagrama de flujo de datos tiene características de transformación o de transacción, en donde el diseñador se encarga de determinar si la característica natural del diagrama de flujo de datos pertenece a un flujo de transacción de acuerdo a la figura 2-21.

Identificar el centro de transacción y las características de cada camino de acción, para detectar un flujo de transacción cuando es el origen de varios flujos de información que surgen de él, tratando de aislar las burbujas. (Figura 2-22).

Figura 2.22. Establecimiento de divisiones de flujo

60

Transformar el diagrama de flujo de datos en una estructura adecuada al procesamiento de transacciones, llevándose a cabo creando subgrupos de burbujas a lo largo de un camino, así el flujo de cada camino de acción del diagrama de flujo de datos se convierte en una estructura con las características específicas de flujo. Las correspondencias en la transacción se ilustra en la figura 2-23.

Control de

Transacción

Camino de

Recepción

A

B

D

P

Q

R

S

Flujo 1

61

Figura 2-23. Correspondencias en la transacción

Factorizar o Refinar la estructura de transacciones y la estructura de cada camino aplicando reglas de diseño para mejorar la calidad. Para factorizar se busca la mejor correspondencia entre los caminos, tratando de no omitir ninguno de ellos puesto que ocasionaría perdida de una transacción en el sistema conllevando a que este no cumpla sus objetivos en su totalidad.

En el análisis de transacciones la estructura del programa, en sus módulos pueden expandirse o reducirse con el objetivo de mejorar su independencia, tomando en cuenta que la expansión de un módulo se divide en 2 o más módulos en la estructura de un programa final. Un módulo reducido es el resultado de la combinación del procesamiento involucrado en 2 o más módulos. Es necesario lograr una estructura en donde los módulos contengan varios niveles para una mejor entrada/salida ya que esto indica varias capas de control y gran aprovechamiento de recursos en los módulos de niveles inferiores. Se recomienda que la estructura sea como se muestra en la parte derecha de la figura 2-24.

62

Figura 2-24. Niveles de Entrada/Salida

Se debe tomar en cuenta que cuando hablamos de módulos, no solo nos referimos a los niveles iniciales 0, 1 ó 2 sino que también hablamos de aquellos que conforman al sistema los cuales nos muestran las transacciones en forma superficial, es decir, sin llegar al código ó al tipo de estructura de datos, uso de archivos, etc... Es por ello que se recomienda evaluar las interfaces de los módulos para reducir la complejidad y la redundancia y así mejorar la consistencia de los módulos.

Evitese este tipo de estructura

Consigase este tipode estructura

63

Una aplicación correcta del análisis de transacciones se complementa documentando al análisis realizando los siguientes pasos :

Desarrollar para cada módulo, un texto explicativo del procesamiento

Dar para cada módulo una descripción de la interfaz

Definir las estructuras de datos globales y locales

Anotar todas las restriccciones/limitaciones de diseño

Llevar a cabo una revisión del diseño preliminar registrando las actualizaciones.

Algunos aspectos típicos en las restricciones/limitaciones son el tipo de formato de datos, limitaciones de memoria, valores o cantidades límites para las estructuras de datos así como características especiales de un módulo individual. Todo esto con el fin de reducir el número de errores antes de llegar al diseño o con ello justificar que no es viable su desarrollo. Las actividades de revisión se centran en el seguimiento de los requisitos del sistema, la estructura del programa, en las descripciones de las interfaces, descripción de las estructuras de datos, la descripción de restricciones/limitaciones, en la facilidad de implementación y desarrollo de pruebas, y en la facilidad de mantenimiento.

Análisis Del Uso De Los Datos

A medida que la información se mueve a través del software, está es modificada por una serie de transformaciones. El diagrama de flujo de datos (DFD) es una técnica gráfica que representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida, en la figura 2-25 se muestra la forma básica de un diagrama de flujo de datos. El DFD

64

también se le conoce como grafo de flujo de datos o como diagrama de burbujas.

Figura 2-25 Modelo de flujo de información

Se puede utilizar un DFD para representar cualquier software a cualquier nivel de abstracción. En la figura 2-26 muestra la notación básica que se usa para crear un diagrama de flujo de datos. El rectángulo se utiliza para representar una unidad externa, es decir, un elemento del sistema (Ejemplo: Hardware, personas, conjunto de datos u otro programa) u otro sistema que produzca información a ser transformada por el software o que reciba información producida por el software. Un círculo representa un proceso o transformación que se aplica a los datos y los cambia de alguna manera. Todas las flechas que aparezcan en un diagrama de flujo de datos deben ser etiquetadas. La línea doble representa un almacén de información, Información almacenada que se utiliza por el software. La sencillez

Sistema basado en

computadora

Entidad Externa

Entidad Externa

Entidad Externa

Entidad Externa

Entidad Externa

Información de Entrada

Información deEntrada

InformacióndeSalida

Informaciónde Salida

Información de Salida

65

de la notación de un DFD es una de las razones por las que las técnicas de análisis estructurado son ampliamente utilizadas.

Figura 2-26 Notación DFD básica.

El Diagrama de Flujo de Datos es una herramienta gráfica que puede ser valiosa durante el análisis de requisitos del sistema. Cabe mencionar que el diagrama no proporciona ninguna sencuencia explícita de los procesos.

UnidadExterna

Proceso

Elementosde Datos

Almacén de Datos

Un productor o consumidor de información que reside fuerade los límites del sistema a ser modelado

Un transformador de información que reside dentro de loslímites del sistema a ser modelado

Un elemento de datos o una colección de elementos de datos;la cabeza de la flecha indica la dirección del flujo de datos

Un depósito de datos que se guardan para ser usados poruno o más procesos

66

4. Desarrollo De SistemasEstrategias De Pruebas Del SoftwareLa prueba es un proceso individualista y el número de tipos diferentes de pruebas varía tanto como los diferentes enfoques de desarrollo, una prueba es un conjunto de actividades que se puede planificar por adelantado y llevar a cabo sistemáticamente. Una estrategia de prueba de software integra las técnicas de diseño de casos de prueba en un conjunto de pasos bien planeados que dan como resultado la correcta construcción del software. Una estrategia de prueba de software proporciona una guía o plano para los desarrolladores del software (sistema), para la organización de control de calidad y para el cliente -un plano que describe los pasos a llevar a cabo como parte de la prueba, cuando se deben planificar y llevar a cabo su realización, y cuánto tiempo, esfuerzo y recursos se van a utilizar-. Por tanto una estrategia de software debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de pruebas y la agrupación y evaluación de los datos resultantes.

Prueba de unidadLa prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software. Aquí se prueban los caminos de control importantes, con el fin de descubrir errores dentro del ámbito de un módulo.

La complejidad relativa de las pruebas y errores descubiertos se encuentra limitada por los lineamientos establecidos por la prueba de software. La pruebas unificadas dentro de la prueba de unidad están representadas en la figura 3-1

67

Figura 3-1 Prueba de Unidad

MóduloInterfazEstructura de datos localesCondiciones límiteCaminos independientesCaminos de manejo de Errores

Casos de Prueba

68

Se prueba la Interfaz del módulo para asegurar que la información fluye en forma adecuada hacia y desde la unidad del programa que está siendo probada. Se analizan las estructuras de datos para asegurar que los datos mantienen su integridad temporal durante todos los pasos de ejecución del algoritmo, Se prueba las condiciones límite para asegurar que el módulo funciona correctamente dentro de los límites establecidos por el procesamiento. Se activan los caminos básicos de la estructura de control con el fin de asegurar de que las sentencias del módulo se ejecutan por lo menos una sola vez, y finalmente, se prueban todos los caminos de manejo de errores.

Antes de iniciar cualquier otra prueba es preciso probar el flujo de los datos del módulo, ya que si los datos no entran correctamente, todas las demás pruebas no tienen sentido. Myers, propone una lista de comprobaciones para la prueba de interfaces 1:

1. ¿Es igual el número de parámetros de entrada al número de argumentos?

2. ¿Coinciden las características (atributos) de los parámetros con los argumentos?

3. ¿Coinciden el sistema de unidades de los parámetros con el de los argumentos?

4. ¿Son correctos el número, atributos y el orden de los argumentos de las funciones incorporadas?

5. ¿Existen referencias o parámetros que no estén asociados con el punto de entrada actual?

6. ¿Entran sólo argumentos alterados?

7. ¿Son consistentes las definiciones de variables globales entre módulos?

8. ¿Se pasan las restricciones como argumentos?

69

Cuando un módulo tenga operaciones básicas de Entrada/Salida externa, se deben llevar a cabo pruebas adicionales :

1. ¿Son correctos los atributos de los archivos?

2. ¿Son correctas las sentencias de apertura?

3. ¿Coinciden las especificaciones de formato con las sentencias de Entrada/Salida?

4. ¿Coincide el tamaño del buffer con el tamaño del registro?

5. ¿Se abren los archivos antes de usarlos?

6. ¿Se tienen en cuenta las condiciones de fin de archivo?

7. ¿Se manejan errores de Entrada/Salida?

8. ¿Hay algún error textual en la información de salida?

Las estructuras de datos locales de cada módulo son una gran fuente de errores. Se deben diseñar casos de prueba para descubrir errores :

1. Tipificación impropia o inconsistente

2. Inicialización o valores implícitos erróneos

3. Nombres de variables incorrectos (mal escritos o truncados)

4. Tipos de datos inconsistentes

5. Desbordamiento o errores en el direccionamiento de memoria

Se deben diseñar casos de prueba para detectar errores causados por cálculos incorrectos o flujos de control inapropiados. Las pruebas

70

de camino básico o de ciclos son técnicas más efectivas para descubrir una gran cantidad de errores en los caminos. Entre los errores más comunes en los cálculos están :

Procedencia aritmética incorrecta mal aplicada

Operaciones de modo mixto

Inicializaciones incorrectas

Falta de precisión

Representación incorrecta de una expresión

Las comparaciones y el flujo de control están muy relacionadas, es decir, el flujo de control cambia tras una comparación

Los casos de prueba deben descubrir errores como :

Comparaciones entre tipos de datos distintos

Operadores lógicos o de procedencia incorrecta

Terminación de ciclos inapropiada o inexistente

Falta de salida cuando se encuentra una iteración mal aplicada (Ciclos infinitos)

Variables internas a un ciclo modificadas en forma inadecuada.

Entre los errores que se deben comprobar se evalúa en la manipulación de errores lo siguiente :

La condición de error hace que intervenga el sistema antes que el mecanismo de errores

71

Descripción ilegible del error

El error señalado no corresponde con el error encontrado

La descripción del error no proporciona suficiente información para ayudar en la localización de la causa del error.

La prueba de los límites es la última etapa de la prueba de unidad y quizá la más importante. El software falla en sus condiciones límite, o sea, que frecuentemente aparece un error cuando se procesa el elemento n-ésimo de un arreglo n-dimensional, cuando se hace la i-ésima repetición de un ciclo de x pasos o cuando se llega a los valores máximo ó mínimo permitidos. Los casos de prueba que ejerciten las estructuras de datos por debajo o encima de los mínimos y máximos permitidos son apropiados para descubrir estos errores.

Normalmente, se considera a la prueba de unidad como algo adyacente a al paso de la codificación. En donde los casos de prueba de unidad comienzan una vez que se ha desarrollado, revisado y verificado en su sintaxis el código a nivel fuente.

Prueba de integraciónUna vez que los módulos funcionen por separado y hayan pasado la prueba de unidad es necesario cuestionar lo siguiente : “El módulo funciona bien sólo”, ¿Por qué dudar de que funcionen juntos?. Aquí pueden surgir los problemas en la unión de los módulos. Los datos se pueden perder en una interfaz, un módulo puede tener un efecto adverso sobre otro módulo; las subfunciones, cuando se combinan, pueden no producir el objetivo principal deseado, las estructuras de datos globales pueden presentar problemas.

La prueba de Integración es una técnica sistemática para construir la estructura del programa mientras que al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con lo que dicta el diseño.

72

Existen 2 tipos de integración, la primera es no incremental en donde se intenta elaborar software en módulos grandes, en otros casos un sólo módulo, pero en ellos es más difícil aislar los errores y cuando alguno de ellos es corregido produce otros errores. El segundo tipo de integración es incremental en donde se desarrollan módulos pequeños y funcionales que hacen que los errores sean más fácil de aislar y corregir, es más probable que se puedan probar completamente las interfaces y aplicar un enfoque de prueba sistemático.

Integración descendente, es una estrategia de integración incremental a la construcción de la estructura de programas, en cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía de control comenzando con el módulo principal (Programa principal). Los módulos subordinados al módulo de control principal se incorpora en la estructura, bien, de forma primero-en-profundidad, bien de forma primero-en-anchura representado en la figura 3-2

73

M1

M2 M3 M4

M7M6M5

M8

Figura 3-2 Integración Descendente

De acuerdo a la figura 3-2 primero-en-profundida integra todos los módulos de una camino de control principal a la estructura, por ejemplo: si se elige el camino a la izquierda se integrarán primero los módulos M1, M2, M5 y M8, enseguida se construyen los caminos de control central y derecho. La integración primero-en-anchura integra todos los módulos directamente subordinados a cada nivel desplazándose en la estructura en forma horizontal de acuerdo a la figura 3-2 , en donde los primeros módulos que se integran son M2, M3 y M4, para el siguiente nivel M5, M6 y M7.

El proceso de integración se lleva a cabo en 5 pasos :

74

1. Se usa el módulo de control principal como conductor de prueba, disponiendo de resguardos para todos los módulos directamente subordinados al módulo de control principal.

2. Dependiendo del enfoque de integración elegido (primero-en profundidad o primero-en-anchura) se van sustituyendo los resguardos subordinados cada uno por los módulos reales.

3. Las pruebas se llevan a cabo cada vez que se integra un módulo.

4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real.

5. Se hace una prueba de regresión, es decir, todas las pruebas anteriores para asegurar que no se han introducido errores.

La estrategia descendente puede ocasionar algunos problemas. Uno de ellos puede ser cuando se requiere un procesamiento de los niveles más bajos de la jerarquía para probar los niveles superiores. El encargado de la prueba tiene 3 opciones :

1. Retrasar muchas de las pruebas hasta que los resguardos sean reemplazados por módulos reales.

2. Desarrollar resguardos que realicen funciones limitadas que simulen los módulos reales.

3. Integrar el software desde el fondo de la jerarquía hacia arriba.

Integración Ascendente, es en donde la construcción del diseño empieza de los módulos más bajos hacia arriba (Módulo principal), el procesamiento requerido de los módulos subordinados siempre está disponible y elimina la necesidad de resguardos. Una estrategia de integración ascendente puede ser implementada mediante los siguientes pasos :

75

1. Se combinan los módulos de bajo nivel en grupos que realicen una subfunción en el software.

2. Se escribe un programa de control de prueba para coordinar la Entrada y Salida de los casos de prueba

3. Se prueba el grupo

4. Se eliminan los programas de control y se combinan los grupos moviéndose hacia arriba por la estructura del programa

La integración sigue el esquema mostrado en la figura 3-3 en donde se combinan los grupos 1, 2 y 3, cada uno de ellos se somete a prueba mediante un programa de control (ilustrado como bloque punteado). Los módulos de los grupos 1 y 2 son subordinados de Ma y se eliminan los programas de control D1 y D2 y se conectan directamente los grupos a Ma de manera similar se elimina el programa de control D3 del grupo 3 quedando con el módulo Mb finalmente el módulo Ma como el módulo Mb se integran al módulo Mc y así sucesivamente.

76

Figura 3-3 Integración Ascendente

La selección de una estrategia de integración depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.

Prueba de validación y verificaciónAl conjunto de actividades que aseguran que el software implementa correctamente una función específica se denomina Verificación. La Validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos y necesidades del cliente. Boehm lo establece de otra forma :

Verificación : “¿estamos construyendo el software correctamente?”

Mc

Ma Mb

D1 D2 D3

Grupo 2

Grupo

3

Grupo

1

77

Validación : “¿estamos construyendo el software correcto?”

La definición de Verificación y Validación envuelve lo que se conoce como calidad del software, en donde se puede ver representada como un conjunto de bloques en la figura 3-4 Los métodos de análisis, de diseño y de implementación (codificación) actúan para mejorar la calidad al proporcionar técnicas continuas y resultados predecibles. Las revisiones técnicas formales ayudan (inspección) ayudan a asegurar la calidad la calidad de los productos, a lo largo del proceso la medición y el control se aplican sobre cada elemento de una configuración del software. La prueba constituye un elemento importante desde el que se puede evaluar la calidad y, de forma más práctica, descubrir los errores. Cabe mencionar que la prueba no se debe contemplar como una red de seguridad. La aplicación adecuada de los métodos y de las herramientas, las revisiones técnicas formales efectivas y una sólida gestión y medida, conducen a la calidad, que se confirma durante la prueba.

78

Figura 3-4 Obtención de calidad del software

Miller relaciona la prueba del software con la garantía de calidad al establecerse que “la motivación subyacente de la prueba de programas es confirmar la calidad del software con métodos que se puedan aplicar de forma económica y efectiva, tanto en grandes como pequeños sistemas”.1

Es importante mencionar que la validación y verificación abarcan un amplio rango de la calidad del software que incluyen revisiones técnicas formales, auditorías de configuración y calidad, supervisión de rendimiento, simulación, estudio de viabilidad, revisión de la documentación, revisión de la base de datos, análisis de algoritmos, pruebas de desarrollo, prueba de calificación y prueba de instalación.

CALIDAD

RevisionesTécnicas Formales

Medida

Prueba

Garantia de Calidad del

Software

Métodos de Ingeniería del

Software

Estándares y

Procedimientos

79

Una vez que se culminó la etapa de integración se puede decir que el software está completamente ensamblado, se han encontrado y corregido errores de la interfaz y se puede comenzar una serie final de pruebas del software. La prueba de validación se logra cuando las expectativas razonables del cliente su cumplen en donde incluyen la especificación de requisitos, documentos en donde se describen los atributos del software que son visibles para el usuario, esta información forma la base del enfoque a la prueba de validación.

El procedimiento de prueba estará diseñado para asegurar que se satisfacen los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentación es correcta y que se alcanzan otros requisitos tales como portabilidad, compatibilidad, recuperación de errores, facilidad de mantenimiento, etc...

Una vez que se procede con la prueba de validación, puede darse una de las dos condiciones :

Las características de funcionamiento o rendimiento están de acuerdo con las especificaciones y son aceptables ó

Se encuentra una desviación de las especificaciones y se crea una lista de deficiencias.

Cuando se construye el software para llevar a cabo la prueba de validación es casi imposible que el desarrollador pueda prever como un cliente usará realmente el programa es por ello que se hace una serie de pruebas de aceptación que puede permitir que un cliente valide todos los requisitos, se puede dar el caso de las pruebas alfa y beta. La prueba alfa consiste en una prueba del software ejecutado por el cliente estando presente el desarrollador para hacer las anotaciones necesarias cuando los errores o las observaciones del

80

cliente sucedan. Las pruebas beta son versiones del software que los desarrolladores lanzan antes de la versión final, esto es que se realicen las pruebas si la presencia del desarrollador ni el equipo de desarrollo para efectos de compatibilidad, portabilidad, mantenimiento, etc.., Así la prueba beta es una aplicación en vivo del software en un entorno diferente.

Prueba del sistemaEn las técnicas anteriores se mencionan algunas técnicas de prueba que se efectúan durante el diseño del software, cabe mecionar que en cada una de esas técnicas serán el éxito o fracaso para la integración del software en el sistema total. Un clásico problema de la prueba del sistema es la delegación de culpabilidad. Esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros, para evitar esto se debe prever y tomar medidas correctivas tomando en cuenta lo siguiente :

1. Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.

2. Llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de otros posibles errores en la interfaz del software.

3. Registrar los resultados de las pruebas como “evidencia” en el caso de señalamientos informales.

4. Participar en la planificación y diseño de las pruebas del sistema para asegurarse de que el software es probado en forma adecuada.

La prueba del sistema se basa en otras técnicas de prueba que hacen ejercitar profundamente el sistema basado en computadora, aunque la finalidad de cada prueba es distinta, sirven para verificar que se hayan integrado correctamente cada uno de los elementos del sistema :

81

Prueba de Recuperación. Muchos sistemas basados en computadora deben recuperarse de los fallos y resumir el procesamiento en tiempos previamente especificados. La prueba de recuperación es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación.

Prueba de Seguridad. Cualquier sistema basado en la computadora que manipule información sensible o efectúe acciones que pueden perjudicar o beneficiar a los individuos es objeto de penetraciones impropias o ilegales. La penetración incluye una serie de actividades como :

penetrar sistemas por joby

personas disgustadas que intentan penetran por venganza

personas deshonestas que intentan penetrar para obtener ganancias personales ilícitas

usuarios que intentan penetrar para solucionar problemas, desconociendo las consecuencias que esto pueda traer a la integridad del sistema.

La prueba de seguridad intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema. Durante la prueba el encargado de la prueba desempeña el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema, negando así el servicio a otras personas además de producir errores a propósito en el sistema; o debe curiosear los datos públicos intentando encontrar una clave de acceso al sistema.

82

Prueba de Resistencia. La prueba de resistencia está diseñada para enfrentar a los programas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar tirar el sistema. Para lograr esto se puede tomar en consideración lo siguiente :

Diseñar pruebas especiales que generen 10 o más interrupciones por segundo.

Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar como responden las funciones de entrada.

Ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco.

Diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en disco.

83

DepuraciónLa depuración aparece como resultado de una prueba efectiva, es decir, cuando en un caso de prueba se encuentra un error, la depuración es el proceso que resulta en la eliminación de un error. Se debe tomar en cuenta que la depuración no es una técnica de prueba, aunque siempre se da como consecuencia de la prueba. De acuerdo con la figura 3-5 el proceso de depuración comienza en los casos de prueba, se evalúan los resultados y resulta una falta de correspondencia entre los esperados y los reales, el proceso de depuración intenta hacer corresponder el sistema con una causa, llevando así a la corrección del error.

Fig. 3-5 Depuración

Casosde

Prueba

Depuración

CausasAdicionales

CausasSospechadasPruebas de

Regresión

CorreccionesCausasIdentificadas

asdfadasdasdasdasdasdasdsafasdafasdasdasdasdasdasdasdasdasdasdasdasdasdasdasdasdasasaassdfsd

Resultados

Ejecución de casos

84

El proceso de depuración siempre tiene uno de los dos resultados :

1. Se encuentra el error, se corrige y elimina

2. no se encuentra la causa del error

En el último caso es cuando la persona encargada de la depuración debe sospechar la causa, en donde debe diseñar casos de prueba que ayuden a confirmar sus sospechas y el trabajo se regresa a la corrección del error de una forma interactiva.

La depuración tiene como objetivo principal encontrar y corregir la causa de un error en el software, existen 3 enfoques que se pueden proponer en la depuración1

1. Eliminación de causas

2. Fuerza Bruta

3. Vuelta atrás

La categoría de depuración “eliminación de causas” se manifiesta mediante inducción o deducción. Los datos relacionados con la ocurrencia del error se organizan para llegar a las posibles causas; se desarrolla una lista de las causas y se llevan a cabo las pruebas para eliminar cada una.

La categoría de depuración por “fuerza bruta” es la categoría probablemente la más común y la menos eficiente en el momento de aislar la causa del error del software en donde se confía que en algún lugar de la gran cantidad de información producida nos puede llevar finalmente al éxito, lo más frecuente es que se desperdicie tiempo y esfuerzo.

85

La vuelta atrás es el enfoque más normal para la depuración, que se puede usar con gran éxito en programas pequeños. Partiendo de donde se detecta el error hacia atrás en el código fuente hasta llegar a la posición del error.

Cada uno de los enfoques anteriores puede complementarse con herramientas de depuración, ayudas dinámicas de depuración, generadores automáticos de casos de prueba, etc.. En general a partir de una indicación de un problema, la actividad de depuración debe rastrear la causa del error.

Mantenimiento Del SoftwareEl mantenimiento de software, es mucho más que una corrección de errores; el mantenimiento se puede describir en tres actividades.

Mantenimiento correctivo

Mantenimiento adaptativo

Mantenimiento perfectivo

Mantenimiento correctivo, esta actividad del mantenimiento es debido a que no es razonable que en la prueba de software se haya descubierto los errores de un gran sistema de software. Durante el uso de cualquier programa se encuentran errores y estos son informados al personal de desarrollo. Este proceso incluye el diagnóstico y corrección de uno o más errores.

La evolución rápida tanto de hardware como de software genera cambios en periféricos, sistemas operativos o nuevas versiones de los anteriores en otros casos nuevas disposiciones nacionales (por ejemplo en nuestro país el cambio de moneda) hacen que algunos sistemas no se adopten a la nueva tecnología o las nuevas

86

disposiciones, por lo tanto una actividad que modifica al software para que interaccione adecuadamente con su entorno cambiante, es la del mantenimiento adaptativo.

La tercera actividad del mantenimiento se da cuando existe software que tiene un gran éxito. A medida que se utiliza el software algunos usuarios hacen observaciones sobre recomendaciones para nuevas posibilidades ó sobre modificaciones a las funciones ya existentes ó sobre mejoras en general. Para satisfacer estas peticiones se lleva a cabo el mantenimiento perfectivo siendo una actividad que genera un mayor esfuerzo empleado en el mantenimiento de software.

Características del mantenimientoLas actividades requeridas para cubrir la fase de mantenimiento abarca dos aspectos importantes : mantenimiento estructurado y mantenimiento no estructurado

El mantenimiento no estructurado, es cuando sólo se dispone del código fuente como un elemento de configuración empezándolo a evaluar a menudo complicada por la pobre documentación interna. Las delicadas características, tales como las estructuras de datos, variables globales, las interfaces del sistema, el rendimiento y/o limitaciones del diseño, son difíciles de descubrir y frecuentemente mal interpretados.

Si existe una completa configuración del software, la tarea del mantenimiento comienza con la evaluación de la documentación del diseño, se determinan las importantes características estructurales, de rendimiento y de interfaz del software.

Se estudian las consecuencias de las correcciones o modificaciones requeridas y se traza un plan de acciones, se modifica el diseño y revisa. Se desarrolla el nuevo código fuente sometiéndolo a las pruebas del software haciendo las respectivas correcciones y se

87

vuelve a lanzar el software, a este suceso de actividades corresponde al mantenimiento estructurado.

Con respecto al costo del mantenimiento del software algunas veces genera insatisfacción al cliente cuando una petición o modificación aparentemente legitima no se puede atender en un tiempo razonable, Disminución de la calidad global del software debido a los errores permanentes que se generan cuando se introducen cambios al software en mantenimiento, utilización de muchos recursos humanos del área de mantenimiento para efectuar el mantenimiento.

La falta de control y disciplina en las actividades de desarrollo, casi siempre se traduce en problemas para el mantenimiento del software como los siguientes :

Frecuentemente es difícil seguir la evolución del software a través de varias versiones ya que los cambios no están adecuadamente documentados.

Frecuentemente es imposible o difícil seguir el proceso por el que se construyó el software.

Generalmente es completamente difícil comprender un programa “ajeno”.

Ese personaje “ajeno”, por lo regular, no se encuentra cerca para que pueda explicar lo que hizo.

No existe una documentación apropiada o está mal preparada.

La mayoría del software no ha sido diseñado previendo el cambio.

Estos problemas que se acaban de mencionar, en parte, se pueden atribuir al gran número de programas actualmente existentes que

88

han sido desarrollados sin tener en cuenta una metodología de desarrollo.

Efectos secundarios del mantenimientoLa modificación al software en los códigos fuente es peligrosa. Algunas veces hemos escuchado..”pero si todo lo que realicé fue cambiarle una sentencia”, lamentablemente cada vez que se introduce un cambio en un proceso lógico muy complejo, la posibilidad del error aumenta.

FREEDMAN y WEINBERG 2 definen tres grandes categorías de efectos secundarios del mantenimiento

Efectos secundarios sobre el código. Con el hecho de realizar un sencillo cambio sobre una sola sentencia puede a veces tener resultados desastrosos. El cambio inadvertido de algún símbolo “.” ó “;” muchas veces pueden acarrear problemas trágicos. En una computadora nos comunicamos mediante el código fuente en algún lenguaje de programación. Las posibilidades de efectos secundarios abundan, aunque cada modificación que se realice en el código puede regularmente inducir al error. Los siguientes cambios tienen mayor probabilidad de inducir a error que otros :

Un subprograma eliminado o cambiado

Eliminación ó modificación de una sentencia o etiqueta

Eliminación o modificación de un identificador

Cambios para mejorar el rendimiento en ejecución

Modificación de apertura o cierre de archivos

Modificación de operadores lógicos

Cambios sobre las pruebas límite

89

Efectos secundarios sobre las bases de datos. Durante el mantenimiento frecuentemente se hacen cambios sobre determinados elementos de una estructura de datos o sobre la propia estructura de datos. Los efectos secundarios sobre las bases de datos regularmente suceden por las modificaciones sobre la estructura de la información del software. Los siguientes cambios en los datos producen efectos secundarios como :

Redefinición de constantes locales o globales

Redefinición de registros o archivos

Aumento o disminución del tamaño de los arreglos o de las estructuras de datos de mayor orden

Modificación de datos globales

Reiniciación de indicadores de control o de punteros

Reorganización de argumentos de Entrada/Salida o de subprogramas

Los efectos secundarios se pueden limitar mediante una profunda documentación de diseño que describa las estructuras de datos y dé una referencia que asocie los elementos de datos, los registros, los archivos y otras estructuras a los módulos del software.

Efectos secundarios sobre la documentación. El mantenimiento que se efectúa en el software se debe centrar en la completa configuración del software, no solo las modificaciones que se efectúan en el código fuente. Los efectos secundarios en la documentación es debido a que no se reflejan las modificaciones hechas en el código fuente sobre la documentación respectiva, no

90

llevando a cabo un registro u/o actualización de los códigos fuente modificados.

Siempre que se realice una modificación sobre el flujo de datos, sobre la arquitectura de diseño sobre los procedimientos (módulos) o sobre cualquier otra característica asociada, se debe actualizar la información técnica soporte, la documentación actual no se reflejará en su totalidad en el software pero puede ser peor la ausencia total de este tipo de documentación.

5. ImplantaciónConversiónLa conversión consiste en el cambio del sistema anterior con el sistema nuevo, así como los métodos para llevarla a cabo y verificación de que la conversión se haya efectuado correctamente.

Existen cuatro métodos para efectuar una conversión en un sistema, en donde cada método tiene ventajas y desventajas entre los mismos. Es conveniente mencionar que algunos métodos de conversión se ajustan perfectamente a problemas planteados, en donde nos es conveniente aplicar otro método debido a que los posibles resultados sean ampliar los periodos de conversión, situación que puede crear problemas con los usuarios y los analistas.

91

Sistemas paralelosEste método es un modelo seguro, ya que el sistema nuevo funciona al mismo tiempo que el sistema anterior; debido a que si encuentran fallas en el sistema nuevo, el anterior permanece en constante funcionamiento sin perdidas de tiempo, ni de información. Una desventaja muy notable es que este método de conversión es muy costoso ya que se duplican los recursos humanos como materiales para trabajar en forma paralela ambos sistemas duplicando así los costos de operación.

Conversión directaEl sistema anterior será reemplazado por el nuevo sistema, ya que la organización confía plenamente en el nuevo sistema. Obligando así a los usuarios a que hagan funcionar al nuevo sistema encontrando en él nuevos métodos y controles. En caso de encontrar errores no existe un sistema que lleve un respaldo de seguridad en las operaciones, este método ocasiona una planeación más cuidadosa.

Enfoque pilotoEn este método se implanta el nuevo sistema en una parte de la organización. Con base a retroalimentación se hacen cambios y el sistema se instala en el resto de la organización mediante algunos otros métodos, esto en gran medida proporciona experiencia y prueba directa antes de la implantación. Ocasionando la desventaja de que el nuevo sistema puede dar la impresión de que el nuevo sistema no es confiable, ni está libre de errores.

Conversión por etapasSe implanta el nuevo sistema de manera gradual, reemplazando partes del sistema anterior, permitiendo a los primeros usuarios aprovechar las ventajas del nuevo sistema, así como la capacitación de los mismos, llevando a cabo la instalación de una nueva etapa una vez que fue aceptada sin hacer uso necesario de recursos extras.

Plan De ConversiónEl plan de conversión incluye una lista de actividades para llevar a acabo la implantación del nuevo sistema y ponerlo en operación. En él se identifica a las personas responsables de cada actividad, así como un programa de actividades para dar seguimiento a cada una de estas etapas.

92

El plan de conversión debe prevenir los posibles problemas y la forma de enfrentarlos implementando planes de emergencia adecuados. Algunos problemas que se presentan comúnmente son :

Documentos perdidos

Variación entre datos de los formatos nuevos y anteriores

Errores en la conversión de datos

Extravío de datos o pérdida de archivos

Omisión en algunos pasos de la conversión

Durante la conversión se deben considerar diversos aspectos, desde la instalación del equipo hasta el orden de las formas y los suministros. Algunas actividades de conversión comienzan realmente desde que un sistema se está desarrollando, así como contactar proveedores.

93

Acondicionamiento De Las InstalacionesFrecuentemente los analistas trabajan con el personal de los proveedores para definir el acondicionamiento de las instalaciones. El cliente o el ingeniero de sistemas presentará una lista de especificaciones para el cableado eléctrico y los contactos, necesidades de aire acondicionado, controles de humedad y exigencias de espacio, lo más recomendable es tener el local antes de la llegada del equipo.

Capacitación De Operadores Y Usuarios Para Operar El SistemaEn algunos casos los sistemas de las compañías de más prestigio pueden tener éxito o fracasar debido a la forma en que se operan y se usan. Como consecuencia la calidad de capacitación recibida por el personal manipulará el sistema ayuda u obstruye, y puede llegar a impedir, la implantación exitosa de un sistema de información. Aquellas personas que se encuentren asociadas o afectadas por el sistema deben conocer cuál es su papel, cómo pueden usar el sistema y qué hará o no hará el sistema. Tanto operadores como los usuarios del sistema requieren de capacitación.

Capacitación de operadoresLa mayoría de los sistemas dependen del personal de Centro de Cómputo, el cual es el encargado de mantener los equipos de cómputo funcionando, así como de proporcionar el apoyo necesario. La capacitación que el personal reciba debe de asegurar que puedan manejar todas las operaciones posibles, tanto rutinarias como extraordinarias. La capacitación que reciba el operador también debe contemplar al personal de captura de datos.

Si el sistema requiere de la instalación de equipo nuevo, el personal debe ser capacitado en lo necesario para encender y apagar el equipo, así como conocimiento de lo que es su operación y su uso normal. Como parte de la capacitación se le debe dar al personal una lista de formas de resolver los problemas y que identifique los posibles problemas y solución, así como datos personales de las personas a quién buscar cuando surjan problemas inesperados.

94

Capacitación de usuariosLa capacitación de usuarios incluye la identificación de problemas, determinando si el problema que surge es ocasionado por hardware o por software, o por algo realizado por los mismos usuarios que ocasione la falla del sistema.

No hay nada más desesperante que trabajar con un sistema y que suceda un problema y no ser capaz de determinar si es falla del propio sistema, del equipo o de los usuarios. El lugar para prevenir estos casos es durante la capacitación. La mayor parte de la capacitación de los usuarios tiene que ver con la operación del sistema en sí. La capacitación en la codificación de los datos marca la pauta en el proceso de captura a partir de las transacciones, o en la preparación de datos necesarios para las actividades de apoyo a las decisiones.

Las actividades de manipulación de los datos que recibe la mayor atención en la capacitación de usuarios son la captura de datos (Cómo modificar datos previamente almacenados), la formulación de consultas (Cómo localizar información específica u obtener respuestas a preguntas) y el borrados de los registros de datos. La parte fundamental de la capacitación cae sobre esta actividad dedicándose la mayor parte del tiempo a esta área.

En algunos casos los usuarios tienen que tener conocimiento de la operación básica de algunos periféricos tales como una impresora, en donde deben tener el conocimiento de como colocar el papel ó cambiar la cinta de la impresora, así como otros procesos rutinarios como mantener limpio el equipo, y además del conocimiento para la manipulación de los discos como es formatear y probar discos.

En la capacitación de usuarios se debe tomar en cuenta dos aspectos importantes mencionados anteriormente los cuales consisten en la familiarización con el sistema de procesamiento en sí (es decir, el equipo usado para la captura y procesamiento de datos)

95

y la capacitación en el uso de la aplicación (es decir, el software que acepta los datos, los procesa y produce los resultados). La debilidad de cualquier aspecto de la capacitación puede ser una posibilidad para la generación de errores. Una buena documentación, aunque es importante, no reemplaza la capacitación.

Métodos de capacitaciónLa capacitación a operadores y usuarios se puede manifestar de diferentes formas. Las actividades de capacitación se pueden llevar a cabo en las instalaciones de los proveedores, locales rentados como podría ser el caso de hoteles y Universidades, “en casa”, o en las instalaciones de la empresa. Los métodos y contenido de la capacitación varia de acuerdo a la fuente y del lugar de la capacitación

Instalación Y Pruebas Del Usuario Para Aceptación Del SistemaEn la instalación y prueba del usuario, son algunas actividades que realiza el usuario con el fin de verificar el sistema si funciona con el hardware diferente al hardware de desarrollo, así como su instalación y funcionamiento en general, en esta etapa se abarcan cuatro aspectos importantes :

La prueba de entrada que implica ver si las formas electrónicas y las de papel así como la estructura de codificación cumplen con las guías y especificaciones de diseño, también se hacen una autoprueba los usuarios finales del sistema para saber si están llenando correctamente las formas. Al efectuar estas pruebas se supone que el usuario ya recibió capacitación y en ella se les enseño como llenar los formatos. Las pruebas en esta etapa consisten en determinar si fueron capacitados correctamente.

Muchas organizaciones contratan personas cuya única función es capturar datos siendo de gran importancia una capacitación adecuada para la captura de datos.

96

La prueba de salida, en la mayoría de estas pruebas son un subproducto de la prueba de otros componentes estructurales. Por ejemplo, mientras se prueban la entrada y las bases de datos, se revisa la utilidad y exactitud de la salida resultante.

Una prueba de salida no es otra cosa que la generación de un reporte, su entrega al usuario y determinar si satisface las necesidades de información. Una buena forma de llevar a cabo la prueba de salida consiste en entregar un reporte a una persona no familiarizada con el sistema, si esta persona puede explicar el reporte, entonces probablemente el formato puede ser entendido por los usuarios.

Prueba de la base de datos. Las pruebas importantes para determinar si las bases de datos satisfacen las necesidades de los usuarios, en gran medida, es la prueba de salida. Sin embargo se pueden llevar a cabo pruebas adicionales para asegurarse que las bases de datos contengan la información que satisfaga todas las demandas que se le plantean. Incluyendo pruebas tales como la creación de un nuevo registro antes del primer registro en el archivo maestro, la creación de un nuevo registro después del último, la creación de un registro de un departamento que no existe, intentar leer o escribir en un archivo con el disco fuera de la unidad (en el caso de sistemas en unidades flexibles).

Prueba de los controles. El propósito primordial de la prueba de controles es asegurar que estos se encuentren en su lugar y trabajen según se planeó. Las transacciones de prueba ayudan a asegurar que los controles de procesamiento, como las verificaciones de límite y racionalidad, la prueba aritmética y la identificación están en su lugar funcionando correctamente. Algunas pruebas de control que normalmente se realizan son :

Tratar de leer o escribir en un archivo incorrecto

97

Introducir varios campos con datos incompletos o faltantes

Tratar de procesar una transacción delicada sin la autorización apropiada y ver si el sistema lo rechaza

Hacer verificaciones de caracteres numéricos, alfabéticos y especiales, por ejemplo en la captura de una clave se deberán introducir únicamente valores numéricos, en donde se deben introducir valores alfabéticos. Una verificación que funcione correctamente detectará el error antes de realizar el procesamiento.

Hacer verificaciones de límite y racionalidad, por ejemplo : Un docente no puede tener más de 40 horas en una jornada al día, se probará introduciendo valores que excedan la jornada de un día

Realizar verificaciones de validez de campos clave, por ejemplo : introducir una clave inválida y ver como responde el sistema

Introducir en un campo numérico valores negativos y ver si lo acepta como tal, o los efectos que ocasiona

Las pruebas de los controles incluyen también una revisión de la documentación que aparece en los reportes del desarrollo de sistemas. Después de que el usuario considera que el software paso las pruebas, deberá llevarse a cabo una reunión de aceptación, a la que asista el gerente de operaciones de sistemas, el analista de sistemas y el personal usuario. En este momento se le da terminación oficial del proyecto de desarrollo obteniendo así la “clausura” final de sistemas, es entonces cuando el equipo de desarrollo queda libre para otra tarea o para diseñar o implementar algunas de las solicitudes y sugerencias de mejora del sistema que fueron suspendidas anteriormente.

98

6. ConclusionesEn el análisis y desarrollo del sistema de horarios, he comprobado los conocimientos adquiridos en mi Licenciatura con respecto a las materias Administración de Archivos, Ingeniería del Software y Bases de Datos. Así como ejercer y aplicar profesionalmente estos conocimientos en el medio real.

He tenido la oportunidad de ejercer en el sector público, ofreciendo mis conocimientos, así como tomando experiencias del medio real, esto se vive cuando uno egresa de la Licenciatura, por ello considero que durante mi carrera aprendí, apliqué y comprobé académica y laboralmente mis estudios.

Además, con esta aplicación conocí la diferencia del desarrollo de proyectos escolares y proyectos laborales, que son totalmente distintos, ya que en los buenos proyectos escolares obtenemos una evaluación numérica y en el ámbito real laboral, la evaluación de estos se da como la base del buen funcionamiento de toda una infraestructura organizacional, en donde madure profesionalmente.

99

7. Bibliografía

Aylmer V. Nichols., "SISTEMA MODERNO DE PROCESAMIENTO DE DATOS"., Editorial Limusa., Primera Edición.

Corro Arango Miguel A.., "II SIMPOSIUM METODOLOGIA DE DESARROLLO DE SISTEMAS"

Churchman C. West., "EL ENFOQUE DE SISTEMAS"., Editorial Diana., Primera Edición.

Burch Jhon G. ., "DISEÑO DE SISTEMAS DE INFORMACION"., Editorial Limusa.

Singelmann Jay., "MANUAL DEL PROGRAMADOR TOMO I"., Editorial Prentice-Hall., Primera Edición.

Pressman Roger S. ., "INGENIERIA DEL SOFTWARE"., Editorial McGrawHill., Tercera Edición.

Senn James A., "ANALISIS Y DISEÑO DE SISTEMAS DE INFORMACION"., Editorial McGrawHill.

100