Plataformas Empresariales

[pic 1][pic 2]

TECNOLOGICO NACIONAL DE MEXICO

INSTITUTO TECNOLÓGICO DE IZTAPALAPA 2

Materia: Plataformas Empresariales

publico

Profesor

Alumno:

Contenido

4.2 ANALISIS        3

4.1 REVISION DE ESPECIFICACION DE REQUISITOS        4

4.1.1.1 NORMA IEEE830        5

4.1.1.2 TRAZABILIDAD DE REQUISITOS        5

4.1.2. DECRIPCION DE PROCESOS ACTUALES        6

4.1.3 DIAGRAMA UML        7

4.1.4 ESTUDIOS DE FACTIBILIDAD        7

4.1.5 ANALISIS DE COSTOS-BENEFICIOS        8

4.2 DISEÑO        8

4.1 DSEÑO DE PROCESOS PROPUESTOS        8

4.1.1 HERRAMIENTAS CASE PARA DISEÑO        9

4.2 DISEÑO ARQUITECTONICO        9

4.3 DISEÑO DE DATOS        9

4.4 DISEÑO DE INTERFAZ DE USUARIO        10

4.3 DESARROLLO        10

4.3.1 CONSTRUCCION DEL SISTEMA        10

4.4 PRUEBAS DE IMPLEMENTACION        10

4.4.1 DISEÑOS DE CASO PRUEBA        10

4.4.2 PRUEBAS DE COMPONENTE        11

4.4.3 PRUEBAS DEL SISTEMA        11

4.4.4 DOCUMENTACION DE RESULTADOS  DE LAS PRUEBAS        11

4.4.5  ENTREGA  DEL SISTEMA Y CAPACITACION  A USUARIOS        11

4.4.6 ENTREGA DE DOCUMENTACION TECNICA Y DE USUARIOS DEL SISTEMA        11

4.2 ANALISIS

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software. La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification).

4.1 REVISION DE ESPECIFICACION DE REQUISITOS

La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales(complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseños.

4.1.1.1 NORMA IEEE830

El estándar IEEE 830-1998 para el SRS (en inglés) o ERS (Especificación de requerimientos de software) es un conjunto de recomendaciones para la especificación de los requerimiento o requisitos de software

esta norma es ayudarnos a elaborar un documento muy útil: el ERS (Especificación de Requerimientos de Software) y este a su vez tiene como finalidad la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas

4.1.1.2 TRAZABILIDAD DE REQUISITOS

La trazabilidad es establecer una línea imaginaria que relacione hacia atrás los requisitos con objetivos del proyecto, y hacia delante con test cases o releases. Permite, por lo tanto, relacionar y establecer dependencias entre requisitos, y también con otros elementos importantes en el proyecto (diseño técnico, componentes de código, test cases, releases, incidencias…). Se realiza trazabilidad para asegurar que los requisitos son aprobados y gestionados de manera correcta a lo largo del ciclo de vida del proyecto. Normalmente utilizamos una matriz de trazabilidad, que puede estar implementada en una hoja de cálculo sencilla

4.1.2. DECRIPCION DE PROCESOS ACTUALES

...