Scribd
Cargar
6 vistas8 páginas

Estructura de Proyecto Socio - Tecnológico Año IV

Cargado por

jose caraballo

Copyright:

© All Rights Reserved
Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
Descargar como docx, pdf o txt

Estructura de Proyecto Socio - Tecnológico Año IV

Cargado por

jose caraballo
6 vistas8 páginas

Derechos de autor

© © All Rights Reserved

Formatos disponibles

DOCX, PDF, TXT o lea en línea desde Scribd

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

© All Rights Reserved
Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
Descargar como docx, pdf o txt
6 vistas8 páginas

Estructura de Proyecto Socio - Tecnológico Año IV

Cargado por

jose caraballo

Copyright:

© All Rights Reserved
Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
Descargar como docx, pdf o txt
Está en la página 1/ 8

Orientaciones para la elaboración

del proyecto Socio – Tecnológico


IV (PNFI – UPTAAPC)

Elaborado por: Dpto PNFI

Restructuración: Enero 2017

Mantecal, Enero 2017


Capítulo V
Análisis de la investigación

1.1 Definición de requerimientos funcionales y no funcionales

Los requerimientos son declaraciones que identifican atributos,


capacidades, características y/o cualidades que necesita cumplir un sistema (o un
sistema de software) para que tenga valor y utilidad para el usuario. En otras
palabras, los requerimientos muestran qué elementos y funciones son necesarias
para un proyecto.

En el modelo clásico de desarrollo de sistemas o desarrollo software, la etapa de


los requerimientos viene antecedida de la etapa de factibilidad del
sistema/software y precedida por la etapa de diseño del sistema/software.

Etapas de la fase de requerimientos

* Obtención de requerimientos: búsqueda y obtención de los requerimientos desde


los grupos de interés.

* Análisis: comprobación de la consistencia y completitud de los requerimientos.

* Verificación: constatación de que los requerimientos especificados son correctos.

Clasificación de los requerimientos

* Requerimientos funcionales: qué debe hacer el sistema o software.

Los requerimientos funcionales son declaraciones de los servicios que


proveerá el sistema, de la manera en que éste reaccionará a entradas
particulares. En algunos casos, los requerimientos funcionales de los sistemas
también declaran explícitamente lo que el sistema no debe hacer.
En principio, la especificación de requerimientos funcionales de un sistema debe
estar completa y ser consistente. La compleción significa que todos los servicios
solicitados por el usuario están definidos. La consistencia significa que los
requerimientos no tienen definiciones contradictorias.

En la práctica, para sistemas grandes y complejos, es imposible cumplir los


requerimientos de consistencia y compleción. La razón de esto se debe
parcialmente a la complejidad inherente del sistema y parcialmente a que los
diferentes puntos de vista tienen necesidades inconsistentes. Estas
inconsistencias son obvias cuando los requerimientos se especifican por primera
vez. Los problemas emergen después de un análisis profundo. Una vez que éstos
se hayan descubierto en las diferentes revisiones o en las fases posteriores del
ciclo de vida, se deben corregir en el documento de requerimientos.

* Requerimientos no funcionales: cómo debe funcionar el sistema o software (no


su implementación), por ej. Calidad, rendimiento, facilidad de uso, etc.

Son aquellos requerimientos que no se refieren directamente a las


funciones específicas que entrega el sistema, sino a las propiedades emergentes
de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de
almacenamiento. De forma alternativa, definen las restricciones del sistema como
la capacidad de los dispositivos de entrada/salida y la representación de datos que
se utiliza en la interface del sistema.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a


las restricciones en el presupuesto, a las políticas de la organización, a la
necesidad de interoperabilidad con otros sistemas de software o hardware o a
factores externos como los reglamentos de seguridad, las políticas de privacidad,
entre otros.
1.2 Diagramas UML

5.1.1 Casos de uso


5.1.2 Estado
5.1.3 Entidad relación
5.1.4 Actividades
5.1.5 Clases
5.1.6 Secuencias

1.3 Diccionario de Datos.


El diccionario de datos es una lista organizada de todos los datos
pertinentes al sistema, con un conjunto de definiciones precisas y rigurosas para
que tanto el analista como el usuario se entiendan.

En el Diccionario de Datos se :

- Describe el significado de los flujos y almacenes que muestran los DFD’s

- Describe la composición de los paquetes de datos que se mueven a través de


los flujos de datos

- Describe la composición de los paquetes de datos en los almacenes

- Especifica los valores y unidades relevantes de piezas elementales de


información entre los flujos de datos y los almacenes de datos

- Describe los detalles de las relaciones entre las entidades que aparecen en un
diagrama Entidad- Interrelación.

Notación en el Diccionario de Datos

= está compuesto de
+y
() Opcionalidad

{} iteración

[] selección
| Separador de alternativas en caso de selección

** Comentarios

@ identificador en caso de almacenes

1.4 Especificaciones Técnicas

 Pantalla.
 Funcionalidad.
o Inclusión
o Consulta
o Modificación
o Eliminación
o Reporte
o Seguridad
 Niveles de Usuarios. (Administrador y Usuario)
 Manual de Usuarios
 Manual del sistema.

1.5 Pruebas del Sistema

Se conoce con el nombre de pruebas de sistema a aquellas pruebas que


toman el Sistema de Información al completo y lo prueban tanto en su conjunto
como en sus relaciones con otros sistemas con los que se comunique.

Las pruebas de sistema permiten verificar que tanto las especificaciones


funcionales como las técnicas se cumplen para el entregable. Además, si el
entorno en el que se realizan estas pruebas es equivalente al de producción,
permiten obtener una visión sobre su comportamiento que podrá extrapolarse a
dicho entorno.
El conjunto de pruebas de sistema está formado por un amplio abanico de
pruebas, entre las que destacan:

Pruebas Funcionales

Permiten determinar si el Sistema de Información hace lo que se requiere de él.

Pruebas de Comunicación

Buscan detectar posibles problemas de comunicación de la aplicación con otros


Sistemas de Información.

Pruebas de Carga

Permiten conocer el comportamiento del Sistema de Información cuando trabaja


con grandes volúmenes tanto de usuarios como de datos.

Pruebas de Recuperación

Permiten determinar si la aplicación es capaz de recuperarse de un fallo sin


comprometer la integridad de los datos.

Pruebas de Accesibilidad

Comprueban si es posible acceder al Sistema de Información desde los entornos


para los que ha sido diseñado.

Pruebas de Usabilidad

Ayudan a determinar el grado de facilidad y comodidad de los Interfaces de Usuario


de la aplicación para sus usuarios objetivo.

Pruebas de Seguridad

Comprueban si los mecanismos de control de acceso al Sistema de Información


evitan alteraciones indebidas en los datos.
Pruebas de Operación

Prueban la posibilidad de realizar las diferentes operaciones de mantenimiento


(arranques, paradas, copias de seguridad, ...) sin comprometer el nivel de servicio
esperado para la aplicación. Será responsabilidad del equipo establecer el
conjunto de pruebas que debe pasar el Sistema de Información antes de su
entrega al cliente.

1.6 Plan de implantación


La implantación de una aplicación en ambiente orientado a objetos se
realiza en forma diferente a la tradicional. El prototipo se va desarrollando
gradualmente en forma incremental iterativamente de tal manera que el diseño,
programación, pruebas, implementación y documentación se llevan a cabo
simultáneamente. Esta forma especial del desarrollo orientado a objetos nos
permite tener control sobre una versión o producto terminado en cada iteración.
En la fase de implementación presentamos una propuesta que incluye los
siguientes aspectos:
•Lineamientos para la Instalación e Implantación.

También podría gustarte