Tareas de ingeniería de software

Table of Contents

1. Introduction 4

2. Functionality 8

Reporte de usuario en cada programa Requirement 14

3. Usability 14

4. Performance 15

6. Purchased Components 17

7. Interfaces 18

4.1 User Interfaces 18

4.2 Hardware Interfaces 18

4.3 Software Interfaces 19

4.4 Communications Interfaces 19

8. Licensing Requirements 19

9. Legal, Copyright and Other Notices 20

10. Aplicable Standards 20

Supplementary Specification

1. Introduction

El Análisis y Especificación de Requerimientos es la tarea de la ingeniería del Software que establece un puente entre la asignación del software a nivel de sistema y el diseño del software. El análisis de requisitos facilita la especificación de las funciones y sobre todo del rendimiento del software, la descripción de la interfaz con otros elementos del sistema y el establecimiento de las restricciones de diseño que debe considerar el software. El SRS contiene una descripción completa del comportamiento externo del sistema.

El SRS sirve como base para las actividades de prueba y verificación del sistema, con el fin de mostrar que el sistema que se ha construido satisface los requerimientos. Si el SRS es ambiguo o inconsistente o si algún requisito no se ha establecido correctamente, entonces tales pruebas no son posibles.

El propósito del SRS se encarga de brindar un medio de comunicación a todas las partes, garantizando con claridad el funcionamiento del sistema para que el cliente no se desilusione con el producto final. Si SRS no es ambiguo, va a definir el comportamiento externo del sistema a construir, y no pueden haber mal interpretaciones. Si existe un desacuerdo entre el cliente y los desarrolladores concernientes al comportamiento externo, debe detectarse durante la etapa de requerimientos y no durante el proceso de entrega del software, cuando es mucho más costoso de corregir. Desafortunadamente varios desarrolladores prefieren mantener el SRS lo más ambiguo para proveerse ellos mismos de mayor flexibilidad durante el diseño. Sin embargo, esta flexibilidad incrementa significativamente el riesgo del cliente.

El SRS se debe caracterizar por ser específico sobre todo, como el sistema se observará externamente por el entorno del sistema o por el usuario. Esto tiene un efecto de segundo orden al limitar los posibles diseños, pero no es parte de la etapa de diseño; de hecho algunos diseñadores indican que una especificación es demasiado restrictiva.

1.1 Purpose

El Análisis expuesto a continuación pretende establecer los lineamientos y necesidades de la Escuela de Postgrado. validando información de procedimientos de Programas de Postgrado y la administración de la Escuela identificando así el ambiente de aplicación de nuestro sistema, formulando alternativas de cambio y de posibles requerimientos en el campo competitivo, para ello se realiza un previo estudio del campo de aplicación y de las deficiencias del sistema actual.

Los requerimientos a cubrir deben satisfacer las necesidades de la Escuela de Postgrado en un 100% tanto a nivel Académico-Administrativo como de usuario especificando cada uno de los procesos que se efectúan y la respuesta opcional fundamentada en los conocimientos de investigación.

1.2 Scope

El Alcance del Análisis de Requerimientos varía de acuerdo a las necesidades de Escuela de Postgrado para ello en forma general se presenta dos tipos de estudio a aplicar:

a.- Los requerimientos de comportamiento define que hace el sistema. Ellos describen todas las entradas y salidas desde y hacia el sistema así como la información concerniente a como las entradas y salidas se interrelacionan. En otras palabras debemos definir completamente la función de transformación del sistema que esta siendo especificado. Esta descripción de cómo las entradas se relacionan con sus salidas son típicamente llamadas descripciones del comportamiento o especificaciones operacionales y pueden no ser triviales.

b.- Los requerimientos no de comportamiento definen los atributos del sistema como él desarrolla su trabajo. Ellos incluyen una descripción completa de los niveles requeridos de eficiencia, confiabilidad, seguridad, mantenibilidad, portabilidad, visibilidad, capacidad y cumplimiento de estándares, para mencionar unos pocos.

1.3 Definitions, Acronyms and Abbreviations

Definiciones:

Director EPEC.- Persona que se encarga de la parte administrativa de la Escuela de Postgrado y

Educación Continua.

Asistente Técnico.- Persona encargada de realizar el mantenimiento de los equipos de cómputo y

de la red de computadores.

Secretaria.- Persona que se encarga de la parte académica de la Escuela de Postgrado y

Educación Continua.

Conserje.- Su función es la limpieza del local.

Usuario.- Persona (ente) a la cual se le brinda un servicio.

Casos de Uso.- Representación del flujo de información mediante los actores y los casos

de uso correspondientes.

Acces -Ram Usa: Empresa proveedora de Internet.

Módem: Es un dispositivo que adapta los datos digitales de forma que estos puedan trasmitirse a través de un canal analógico.

Switch: Dispositivo de propósito especial diseñado para resolver problemas de rendimiento en la red, debido a anchos de banda pequeños y embotellamientos.

Intranet: Es una red de computadoras internas dentro de una institución u organización.

SISAEPEC : Nombre del sistema(Sistema Académico – Administrativo de la EPEC)

Flash Work: Nombre de la empresa encargada de desarrollar el sistema ASSEP.

Siglas:

En el transcurso del desarrollo de este proyecto de software hemos utilizado algunas siglas entre las cuales tenemos:

ESPOCH: Escuela Superior Politécnica de Chimborazo.

EPEC : Escuela de Postgrado y Educación continua

DBMS: Sistema manejador de base de datos.

SQL: (Structured Query Language) Lenguaje de consulta estructurado.

PC: (Personal Computer) Computadora Personal.

PF: Puntos

...