par EDINSON ARIEL CHAVARRO QUINTERO Il y a 1 année
151
Plus de détails
Paradigma de Desarrollo Agil
Simplificación de procesos agiliazndo fases
Cliente involucrado directamente
Paradigma Orientado a Objetos
Se basa por la creación de
Análisis de requisitos
Clases
Desventaja
Por perdida de tiempo
si ha errores se debe retornar todas las fases
Paradigma tradicional
Son lineales y van de principio a fin
Modelos PT
Modelo XP o Programación Externa
Modelo Kanban
Modelo Scrum
Modelo Iterativo o por Prototipos
Modelo Espiral
Modelo Cascada
Correctivo, adaptativo y perfectivo para el proyecto
Implementación y pruebas
Establece ajustes para corrección de errores
Diseño
Establece metodos de validación
Asignación de recursos
Identifica soluciones
Actividades principales de la fase
Calendarización del proyecto
Estudio de procesos de negocio
Toma de requerimientos
Identificación del negocio
Definición del alcance
Definición de requisitos o Requerimientos
Clasificación
Basada en los requerimientos de sistema
Requerimientos no funcionales
son
Todos los requerimientos basados en
Capacidad de almacenamiento
Tiempo de respuesta
Fiabilidad
Restricciones de los servicios
Requerimientos Funcionales
Lo que el sistema no debe hacer
Declaraciones de los servicios que debe proporcionar el sistema
Enfocado en las entradas particulares
Basada en el nivel de descripción
Requerimientos de sistema
Presentan en detalle
Restricciones operativas del sistema
Servicios
Funciones
Requerimientos de usuario
Declaraciones
Diagrama
Lenguaje natural
Caracteristicas segun Pfleeger
Claro
Priorizado
Modificable
Factible
Correcto
Consistente
Completo
Necesario
Importancia
Exito o fracaso del proyecto
Necesidades del negocio
Viabilidad del negocio
Es
Comunicación de Expectativas
Esperada o inesperada
Conocida o desconocida
Obvias o ocultas
Necesidad usuario
alcance del proyecto
Conocimiento de requisitos
Planificación
Enfoque en la viabilidad
Aplicación de casos de uso y obtencion de requisitos
Aplicación de diagramas UML (lenguaje de modelado unifiado)
El analista debe Proporcionar un sistema de retroalimentación
Profundizar en el conocimiento del dominio del problema
Presentar Contradicciones o ambiguedades debido a su naturaleza informal
Detectar conflicto en los requisitos que suelen provenir de distintas fuentes
Objetivos
Consensuar los requisitos entre los propios clientes y usuarios
Descubrir necesidades reales entre clientes y ususarios
Conocer el dominio del problema
Administración de Requisitos o Requerimientos antes explicados
Enfoca en actividades
Validación
Especificación
Análisis
Obtención