• No se han encontrado resultados

CAPITULO III y IV

N/A
N/A
Protected

Academic year: 2020

Share "CAPITULO III y IV"

Copied!
12
0
0

Texto completo

(1)

CAPITULO III (Continuación…)

Documento de definición de requisitos (Requerimientos Funcionales y no

Funcionales)

Requerimientos funcionales

Expresan la naturaleza del funcionamiento del sistema (cómo interacciona el sistema con su entorno y cuáles van a ser su estado y funcionamiento). Los requisitos funcionales definen qué debe hacer un sistema.

Realizar la siguiente tabla en donde cada requisito contiene un identificador donde las dos primeras letras indican que es un requisito funcional y un número que corresponde a la secuencia de los requisitos. Las columnas nombre y descripción definen el requisito, la columna usuario y proceso indican quien debe realizar el requisito y de que proceso fue derivado dicho requisito. Finalmente, la columna medio indica el medio en que se mostrará el requisito.

EJEMPLO:

ID. Requisito Nombre del Requisito

Descripción del Requisito Usuario Medio

RF-001 Registrar datos

de alumnos

El sistema debe permitir el registro de la información de un nuevo alumno, dentro del cual se llenaran los datos referentes a nombre, cedula, entre otros.

Usuario y administrador

Pantalla

Requerimientos no funcionales

Son requisitos que imponen restricciones en el diseño o la implementación como restricciones en el diseño o Estándares de Calidad. Son propiedades o cualidades que el producto debe tener. Los requisitos no funcionales definen cómo debe ser el sistema.

Existen diferentes categorías de los Requisitos No Funcionales entre ellas:

• Requisitos de Apariencia.

• De Usabilidad.

• De Rendimiento.

• De Mantenibilidad y Portabilidad.

• De Seguridad.

• Culturales y Políticos

• Legales.

Además existen otros menos usados pero igual de importantes:

• De Interfaz.

• De Desempeño.

(2)

• Funcionalidad.

• Eficiencia y Simplicidad.

Crear una tabla con la lista de la definición de requisitos no funcionales de este sistema. Dichos requerimientos no funcionales están identificados en una celda con el número de requisito y una pequeña descripción del mismo.

EJEMPLO:

ID. Requisito Descripción del requisito no funcional

RNF-001 Cada usuario que desee ingresar al sistema, deberá introducir en la

página principal un código de usuario y una contraseña, la cual será validada por el sistema, dándole acceso al sistema o enviándole un mensaje para que introduzca nuevamente sus datos.

Evaluación

Dentro de este aspecto colocaremos:

Pruebas del Sistema

Mediante diversas actividades los desarrolladores van evaluando el progreso del proyecto y la calidad del mismo. Es necesario describir brevemente esas actividades en este punto del informe.

Pruebas de Caja Blanca

Se basan en el conocimiento de la lógica interna del código del sistema. Se encarga de verificar que

líneas específicas de código funcionan tal como está definido. Intentan garantizar que: • Se utilizan las decisiones en su parte verdadera y en su parte falsa

• Se ejecuten todos los bucles en sus límites

•Se utilizan todas las estructuras de datos internas.

En esta parte hay que describir las líneas de código utilizadas, también los bucles usados poniendo

una captura de pantalla de los mismos.

Pruebas de Caja Negra

Las pruebas se aplican sobre el sistema empleando un determinado conjunto de datos de entrada y

observando las salidas que se producen para determinar si la función se está desempeñando

correctamente por el sistema bajo prueba. Las herramientas básicas son observar la funcionalidad y

contrastar con la especificación.

Las pruebas de caja negra se limitan a que el tester pruebe con “datos” de entrada y estudie como

salen, sin preocuparse de lo que ocurre en el interior.

Se puede elaborar una tabla como la que se muestra a continuación:

Caja negra

Fallas

Correcciones

En este espacio hay que especificar el archivo con el que estamos trabajando

En este espacio se coloca el error que hemos conseguido

(3)

Pruebas Alfa

Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el

desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas

alfa se llevan a cabo en un entorno controlado.

Se le proporciona al cliente los datos necesarios para probar el sistema y se verifica el funcionamiento

del sistema tomando en cuenta las condiciones antes de realizar la acción, el resultado y las

condiciones después de realizar la acción.

Pruebas Beta

Se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A

diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una

aplicación en vivo del software en un entorno que no puede ser controlado por el desarrollador. El

cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos

regulares al desarrollador. Las pruebas beta es la última fase de las fases de prueba y se hace

utilizando técnicas de caja negra. La prueba involucra a los usuarios y que compruebe la funcionalidad

requerida.

Se trata de las críticas constructivas que tenga el cliente acerca del sistema. Hay que describir las

(4)

CAPITULO IV

Descripción del Sistema (Breve descripción del Sistema con su respectiva

diagramación)

En este capítulo se da a conocer la descripción general del sistema y su funcionamiento en general, así como las partes que lo conforman y su trabajo dentro del mismo. También se da a conocer la arquitectura del sistema y los diferentes actores que forman parte del mismo, así como el análisis de los requerimientos necesarios y el análisis del diseño del sistema, incluyendo los respectivos diagramas UML.

Lo primero es describir los tipos de usuario del sistema y el rol que cumple cada uno en el mismo. Lo siguiente es describir cada una de las funciones del sistema enfocada a cada tipo de usuario. Cada elemento usado hay que describirlo.

Diagrama General del Sistema

o

(VTOC – Tabla Visual de Contenidos), HIPO.

Es el diagrama de jerarquía. Proporciona un mapa que permite al lector localizar un módulo del programa existente dentro del sistema. Los números de cada proceso o módulo siguen un patrón definido de tal forma que es fácil reconocer las relaciones existentes entre los módulos. El diagrama jerárquico de VTOC parece ser similar a un típico diagrama de estructura de una organización tomando la forma de una pirámide y en la parte de debajo de la hoja en que se dibuja el diagrama se deja un espacio para una descripción más detallada de los cuadros.

EJEMPLO:

Elementos de interfaz (Botones)

Consiste en describir cada uno de los botones, colocando la imagen del mismo y su uso.

Se puede hacer una tabla como la que se muestra a continuación:

Botones Descripción

(5)

Políticas de seguridad del Sistema (Autenticación, Autorización y

Accounting)

Se describe la importancia de la seguridad en el sistema y se detallan cada una de las medidas de

seguridad utilizadas en el sistema así como el objetivo de las mismas.

Diagramas de Flujos de Datos (D.F.D) diagrama de Contexto y el siguiente

Nivel

El diagrama de flujo de datos es un modelo que describe los flujos de datos o tuberías, los procesos

que cambian o transforman los datos en un sistema, las entidades externas que son fuente o destino

de los datos (y en consecuencia los límites del sistema) y los almacenamientos o depósitos de datos

a los cuales tiene acceso el sistema, permitiendo así describir el movimiento de los datos a través del

sistema.

En síntesis, el Diagrama de Flujo de Datos describe:

• ð los lugares de origen y destino de los datos (los límites del sistema),

• ð las transformaciones a las que son sometidos los datos (los procesos internos),

• ð los lugares en los que se almacenan los datos dentro del sistema, y

• ð los canales por donde circulan los datos.

Simbología utilizada

Diagrama de Contexto: Nivel 0

En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su

entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o

(6)

escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten

los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no

admitiéndose otros procesos ni almacenamientos en el dibujo, ya que estos son procesos

estructurados y ordenados, además posee una cardinalidad que varia según la función que

desempeñe cada diagrama. Resulta de gran utilidad para los niveles posteriores de análisis como

herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos DFD de Nivel "0".

EJEMPLO:

El diagrama de flujo de datos de contexto muestra cómo se relacionan las entidades: “Alumno”, “secretaria”, “alumno” con la biblioteca.

El alumno Solicita un libro, las secretarias consultan en el sistema o registran el préstamo en el sistema

y como resultado el alumno obtiene el libro.

Diagrama de Nivel Superior: Nivel 1

En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal.

En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir

algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al

(7)

probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté

especificado por un Requisito funcional, siendo en realidad un requisito no-funcional.

EJEMPLO:

UML

o

Modelo de Casos de Usos del Negocio (Descripción de cada caso de

uso)

Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores

en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos

de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su

interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación

entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos

del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos

de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos

que se producen en su ámbito o en él mismo.

(8)

EJEMPLO CASO DE USO GENERAL:

Diagrama de actividades

Los diagramas de actividades sirven para representar el comportamiento dinámico de un sistema

haciendo hincapié en la secuencia de actividades que se llevan a cabo y las condiciones que guardan

(9)
(10)

Bases de Datos.

o

Diccionario de Datos (D.D)

Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas y

puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre,

descripción, alias, contenido y organización.

Es un catálogo, un depósito, de los elementos en un sistema. Como su nombre lo sugiere, estos

elementos se centran alrededor de los datos y la forma en que están estructurados para satisfacer los

requerimientos de los usuarios y las necesidades de la organización. En un diccionario de datos se

encuentra la lista de todos los elementos que forman parte del flujo de datos en todo el sistema. Los

elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario guarda

los detalles y descripciones de todos estos elementos.

EJEMPLO:

Columna Tipo Comentarios

cod_cargo int(11) es el código que representa el cargo del funcionario

nombre_cargo varchar(30) nombre del cargo que ocupa

ced_grup varchar(11) cedula del miembro del grupo familiar

Modelo Entidad Relación

El modelo entidad-relación ER es un modelo de datos que permite representar cualquier abstracción,

percepción y conocimiento en un sistema de información formado por un conjunto de objetos

denominados entidades y relaciones, incorporando una representación visual conocida como

(11)

Modelo Relacional

El modelo relacional constituye una alternativa para la organización y representación de la información que se pretende almacenar en una base de datos. Se trata de un modelo teórico matemático que, además de proporcionarnos los elementos básicos de modelado (las relaciones), incluye un conjunto de operadores (definidos en forma de un álgebra relacional) para su manipulación, sin ambigüedad posible.

EJEMPLO:

Especificaciones técnicas del Proyecto

En esta parte hay que describir cada una de las interfaces del sistema. Detallando de cada una los siguientes aspectos:

(12)

➢ Propósito

➢ Usuario y nivel de acceso

➢ Diseño de Pantalla: donde se coloca la imagen de la interfaz.

➢ Función de la pantalla: donde se describe la interfaz y los procedimientos que se realizan en la misma, así como las conexiones que tiene con la base de datos.

Procedimiento de instalación del Sistema.

En este punto se debe explicar de manera ordenada los pasos sencillos para la instalación correcta y satisfactoria del Sistema de Información incluyendo los pasos previos a la instalación como lo es el uso de otros programas necesarios para su funcionamiento.

Requerimientos mínimos de hardware y software

Se presentan los requerimientos mínimos tanto físicas (disco duro, memoria ram, entre otros) como lógicas (programas necesarios), que debe cumplir el computador para el buen funcionamiento del Sistema de Información.

Mensajes generales del Sistema.

Se describen los mensajes que arroja el sistema en cada caso que se presente.

Se coloca la imagen del mensaje y se describe el uso del mismo asi como en qué caso es usado.

Limitaciones en la ejecución del PST II.

Referencias

Documento similar

Volviendo a la jurisprudencia del Tribunal de Justicia, conviene recor- dar que, con el tiempo, este órgano se vio en la necesidad de determinar si los actos de los Estados

Luis Miguel Utrera Navarrete ha presentado la relación de Bienes y Actividades siguientes para la legislatura de 2015-2019, según constan inscritos en el

En cuarto lugar, se establecen unos medios para la actuación de re- fuerzo de la Cohesión (conducción y coordinación de las políticas eco- nómicas nacionales, políticas y acciones

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de

Després d’un inventari pericial i de consensuar-ho amb els mateixos redactors de l’estudi, s’apunta a que la problemàtica és deguda a que en els casos on l’afectació

Polígon industrial Torrent d'en Puig. Polígonindustrial de Can

● Cursos y recursos útiles para trabajar con ODSs.. ● Guías para incorporar ODSs en la

Se llega así a una doctrina de la autonomía en el ejercicio de los derechos que es, en mi opinión, cuanto menos paradójica: el paternalismo sería siempre una discriminación cuando