FEATURES (CARACTERISTICAS DEL PRODUCTO) EL DESARROLLO DEL DOCUMENTO DE VISIÓN: El documento Visión debe contener la información esencial sobre el sistema.

Slides:



Advertisements
Presentaciones similares
EL PROCESO DE DESARROLLO DEL SOFTWARE
Advertisements

IDENTIFICAR NECESIDADES, PROBLEMAS U OPORTUNIDADES
Gestión de Recursos Informáticos Unidad Nº 3: Gestión de calidad y eficiencia.
Aclaraciones de la Realización del Producto
ANÁLISIS DE REQUERIMIENTOS
CONTRATOS Y PROPUESTAS EN PROYECTOS DE CONSTRUCCIÓN
Conceptos de administración de proyectos
Razonamiento algorítmico
DISEÑO ORIENTADO AL OBJETO
PORTAL WEB Manual de Usuario Perfil Autorizador
Solución para Control de Presencia Empleados
4. Mantenimiento de los espacios de trabajo. Manual de formación 2 4. Modificación de los espacios de trabajo 4.1 Introducción……………………………….……..……..…pág.
Tablero (Panel) de Control… Ventas… Inventarios…
PRODUCTO NO CONFORME.
Aprendizaje de Microsoft® Access® 2010
Access Bases de datos.
Resolución de Problemas Algoritmos y Programación
Request for infomation – Solicitud de información
La actividad de validación tiene como entrada el documento de requisitos, los estándares relacionados y el conocimiento de la organización, y como.
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
DESCRIPCION DEL PROBLEMA
Una vez que haya dominado el material de este capítulo, podrá:  Entender los cuatro modelos principales de elaboración de prototipos.  Usar la elaboración.
Bases de una Licitación
Desarrollo Orientado a Objetos con UML
DE LAS CUENTAS DE USUARIO Y OPCIONES DE CARPETA
MANUAL DE USO DEL SISTEMA UNIDADES DE TRANSPARENCIA
y programa de Microsoft Access
ANÁLISIS Y DISEÑO DESDE UNA PERSPECTIVA ORIENTADA A OBJETOS Alan Vargas.
Registro de Software REALIZADO POR: ANDRÈS BARRETO.
UNIDAD 2:Crear, abrir y cerrar una base de datos Hacer clic sobre la opción Nuevo de la pestaña Archivo. Se mostrarán las distintas opciones para nuevos.
Ing. Héctor Abraham Hernández Erazo
 El primer navegador Web incluía un lenguaje de estilo interno que utilizaba dicho navegador para mostrar las páginas HTML.  Sin embargo estos primeros.
Viviana Poblete López Módulo: Modelo de Datos
Geo procesos.
PASO 1: Inscríbase en la jornada Para hacerlo, debe estar logado con su usuario y contraseña. Una vez logado, pulse el botón “Inscríbase en la Jornada”.
Gestión de Proyectos Informáticos Sesión N° 5 Ciclo de Vida de un Proyecto Roberto Jijena I.
El lenguaje UML comenzó a gestarse en octubre de1994 (Booch, Rumbaugh y Jacobson), cuando Rumbaugh se unió a la compañía Rational, fundada por Booch (dos.
Unidad VI Documentación
Organización y Estructuración de Datos Profesor Titular: Mg Carlos G. Neil 2009.
GUTIÉRREZ GRANADOS HÉCTOR DANIEL
¿Puede usted decir cuál es su estrategia?
COMPUTO III Ing. Jimmy Ojeda Arnica.
Elaborado por: Izmir Sánchez Juárez Uso del Sistema “SARCAI” (Sistema Administrador de Reservaciones del CAI)
Web Semántica La Web Semántica es la nueva generación de la Web, que intenta realizar un filtrado automático preciso de la información. Para ello, es necesario.
TEMA 9: DIAGRAMA DE CLASE EN UML
Unidad 3: Adquisición de Paquetes de Software Msc. Lic. Susana I. Herrera - Lic. Paola Budán UNSE 2012.
Taller de Desarrollo de Proyectos II (75.47) Grupo 2 Taller de Desarrollo de Proyectos II (75.47) Presentación Final ERNESTO GIMENO PABLO BESADA.
Contactos Todos los días, se contactan clientes, proveedores y asociados. En SugarCRM, cada una de estas personas es un contacto. También puede conectar.
Alexander Aristizabal Ángelo flores herrera
Ciclo de vida de un sistema
Tema 6 – Servicio de Correo Electrónico
Introducción al proceso de verificación y validación.
CICLO DE VIDA CLÁSICO DE UN SISTEMA
EDIMex Electronic Data Information México S.A. de C.V. (Ver 1.0.1) 1 Capacitación Clientes.
Proceso de Diseño de Interfaces
Control Estadístico de Procesos
Colegio de Bachilleres Plantel 13 Xochimilco - Tepepan
ANGIE PAOLA SOLANO CASTIBLANCO DAR SOPORTE A LOS PROCESOS NORMAS ISO DOC. JOHANA LÓPEZ CHAVEZ SENA 2010.
¿QUÉ ES EL MODELO ENTIDAD-RELACIÓN?  Como ya he comentado este modelo es solo y exclusivamente un método del que disponemos para diseñar estos esquemas.
DIAGRAMAS ADMINISTRATIVOS
Análisis de Requerimientos
Introducción a la Administración de Proyectos
DESARROLLO DE SOFTWARE Cuando se va desarrollar un software intervienen muchas personas como lo es el cliente quien es el que tiene el problema en su.
6.6 Administración de defectos
Fundamentos de Computación
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Utilizando la Metodología RUP:: Desarrollo de un Sistema de Gestión:: MSc. Manuel Sánchez Chero IntroducciónGestión.
Entregables del Proyecto
13/11/14. UNIDADES DEL SEMESTRE Este trabajo esta diseñado para saber los propósitos de los sistemas de información, así como el buen desempeño que le.
INGENIERÍA WEB FORMULACIÓN Y PLANEACIÓN PARA INGENIERÍA WEB.
Transcripción de la presentación:

FEATURES (CARACTERISTICAS DEL PRODUCTO) EL DESARROLLO DEL DOCUMENTO DE VISIÓN: El documento Visión debe contener la información esencial sobre el sistema en desarrollo. Además de las lista de todas las características, debe contener una descripción del producto, una descripción del usuario, un resumen de las capacidades del sistema, y otra información que pueda ser necesaria para comprender el sistema y objetivo, de igual manera los documentos deben de ser comprobables, sin redundancia y claridad.

LAS CARACTERÍSTICAS SE DERIVAN DE LAS NECESIDADES

Algunas partes de la Visión se crean al principio, incluso antes de empezar a suscitar requisitos de los interesados. Ejemplos: Una descripción del problema a resolver Identificación de los usuarios / clientes / actores LAS CARACTERÍSTICAS SE DERIVAN DE LAS NECESIDADES

DESARROLLO DE UNA VISIÓN DOCUMENTO: El documento de Visión es uno de los tres documentos más importantes, creados en RequisitePro., los otros dos son los casos de uso y los documentos complementarios. EL DOCUMENTO DE VISIÓN CONTIENE LO SIGUIENTE: Una descripción del problema a resolver por el nuevo sistema Una descripción de alto nivel de la solución Una lista de las principales características del sistema El documento de visión puede servir como un contrato entre un cliente y los desarrolladores.

FEATURES (CARACTERISTICAS DEL PRODUCTO) EL PROPÓSITO DEL DOCUMENTO VISIÓN ES: Definir los límites del sistema Identificar las limitaciones impuestas en el sistema Ganancia de acuerdo con el cliente sobre el alcance del proyecto Crear una base para definir los casos de uso y especificaciones suplementarias documentos

STRQ1: El usuario deberá ser capaz de comparar precios de vuelos desde otros aeropuertos cercanos. Este requisito es redundante con STRQ11. Se pueden combinar en un solo requisito: FEAT1 El usuario deberá ser capaz de comparar precios de vuelos desde otros aeropuertos, en las proximidades (por vuelo de ida y vuelta). FEATURES (CARACTERISTICAS DEL PRODUCTO)

STRQ2 se muestra en las fechas el dd / mm / aaaa. Este requisito es incompatible con STRQ 16, que pide al dd / mm / aaaa. Requisito STRQ2 vino por parte del usuario en Francia, y STRQ16 fue suministrada por el usuario en el EE.UU. Los requisitos STRQ2 y STRQ16 se sustituye por el texto siguiente: FEAT2 las fechas se muestran de acuerdo con el formato almacenado en el navegador web FEATURES (CARACTERISTICAS DEL PRODUCTO)

STRQ3 En las pantallas de entrada de datos, el sistema indicará que los campos son obligatorios. En algún momento la decisión será tomada en cuanto a cómo los campos obligatorios se indican como los campos obligatorios. Esta decisión se puede tomar cuando se crea un requisito función, o un poco más tarde, cuando los requisitos adicionales que se derivan de las características. Supongamos que queremos hacer esta ahora, por lo que aplicamos una explicación para crear una hazaña: FEAT3 En la entrada de datos pantallas el sistema indicará que los campos son obligatorios por colocando una estrella al lado del campo. FEATURES (CARACTERISTICAS DEL PRODUCTO)

STRQ4 La capacidad de cancelar una compra del billete debe estar disponible. Por coherencia, es mejor utilizar las construcciones estándar de las necesidades, tales como "deberá" en lugar de "debería". Usando diferentes palabras como "será", "hará ", "debería", y "podría" puede ser erróneamente interpretados como los diferentes niveles de necesidad. (Por ejemplo, "se" puede sonar más fuerte que "deberá", y "se" puede sonar más fuerte que "debería". Es necesaria una aclaración en cuanto a quién será capaz de cancelar la compra de boletos (usuario, cliente representante o administrador) y en qué etapa del proceso así lo exijan: FEAT4 El usuario será capaz de cancelar una compra del billete en cualquier momento antes de la confirmación final de la compra. FEATURES (CARACTERISTICAS DEL PRODUCTO)

STRQ5 El usuario será capaz de cancelar una reserva del coche o un hotel. Es hasta el analista de sistemas para decidir si un requisito específico es atómico. En este caso, decidió que la cancelación de un coche o reservar habitación de hotel puede ser considerado el mismo requisito, lo que no hay necesidad de dividir: FEAT5 El usuario será capaz de cancelar una reserva del coche o un hotel. FEATURES (CARACTERISTICAS DEL PRODUCTO)

STRQ6 La vuelos de salida y regreso serán ordenados por el menor número de paradas. Esta terminología es incompatible con STRQ11. El mismo concepto se denomina "vuelo de regreso" en STRQ6 y "vuelo de vuelta" en STRQ11. Supongamos que después de consultar con las autoridades, hemos decidido utilizar el término "vuelo de regreso". Sin embargo, ya han sido instalados STRQ11 con STRQ1 en FEAT1. Tenemos que volver a FEAT1 y cambiarlo por la coherencia: El usuario deberá ser capaz de comparar precios de vuelos desde otros aeropuertos cercanos (para salida idas y vueltas) y. FEAT1 Debido a que han cambiado FEAT1 para ser coherente con STRQ6, podemos volver a escribir STRQ6 en FEAT6: FEAT6 Los vuelos de salida y regreso serán ordenados por el menor número de paradas precios. de los Sin embargo, esto contradice STRQ18, que solicita que los vuelos serán ordenados por. Podemos acomodar las necesidades de una característica: el usuario podrá elegir si los vuelos serán seleccionados por el menor número de paradas o por precio. FEAT6 como puede ver, se derivan las características es un proceso iterativo, y algunos requisitos de necesidad de cambiar un par de veces hasta que sean coherentes y no redundante. FEATURES (CARACTERISTICAS DEL PRODUCTO)

Los atributos describen las propiedades de los requisitos. Ellos ayudan a organizar y analizar los requisitos en el proyecto. Podemos crear reglas para decidir, basándose en los atributos, que los requisitos para aplicar en la siguiente iteración, fase, o la liberación. Por ejemplo, usted puede decidir que en la elaboración que desea implementar todos los requisitos que tienen alto riesgo e importancia media o alta y todos los requisitos que tienen gran importancia y dificultad alta o media. Los atributos pueden ser de tipo lista (identificados por los conjuntos de valores predefinidos descriptivo como Alta, Media y Baja) o la entrada de tipo (texto, hora, fecha, número entero numérico, numérico real). LOS ATRIBUTOS DE LAS CARACTERÍSTICAS:

EL VALOR PREDETERMINADO DE LOS ATRIBUTOS DE LAS CARACTERÍSTICAS SON LAS SIGUIENTES: Prioridad (generalmente se usa para determinar el orden de aplicación) Estado (seguimiento del progreso del desarrollo-requisito propuesto, aprobado y validados) Dificultad (lo difícil es la aplicación de este requisito, los valores por defecto son de alta, Media y Baja) Estabilidad (la probabilidad de que la función no va a cambiar durante el proyecto) El riesgo (la probabilidad de que las cuestiones relacionadas con este requisito, con problemas de aplicación, incumplimiento de los plazos, y así sucesivamente) Planificación de iteración (por ejemplo, E1-la primera iteración en la fase de elaboración) Actual iteración Origen (fuente de la obligación) Nombre de contacto (por lo general la persona responsable de este requisito) Solicitud de mejora Defecto Autor Localización (documento en el que reside)