Introducing
Your new presentation assistant.
Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.
Trending searches
ETAPAS
>
MODELOS
CLASIFICACION DE REQUISITOS
Entender lo que el cliente quiere.
1
2
Analizar las necesidades.
Evaluar la factivilidad.
3
4
Negociar una solucion razonable.
5
Especificar la solución sin ambigüedad.
6
Validadr las especificaciones.
7
Administrar los requisitos conforme éstos se transforman en un sistema operacional
En esta primera fase, se interactua con el cliente y los analistas quienes descubriran los problemas o requerimientos que el sistema debe resolver así como las restricciones.
OBJETIVOS
> Reconocer claramente los requerimientos del cliente para transmitirlo al equipo de trabajo.
> Hacer evidentes las necesidades del usuario, enfocandoce en aquellas que se asumen inplísitamente.
> Acordar los requisitos reales tanto del modelo de negocio, de los clientes y de los usuarios finales.
Fase en la que se analiza lo recopilado en la fase anterior para descubrir problemas.
OBJETIVOS
> Detectar los posibles conflictos entre las fuentes, ambigüedades o contradicciones.
> Profundizar en el conocimiento del dominio del problema puede facilitar el proceso de construir un producto útil para clientes y usuarios (Durán, 2000).
En éste punto se realiza la documentación en límpio del análisis de casos y de los requerimientos, aplicando los estándares de la documentación como la notación UML (Lenguaje de Modelado Unificado).
Aquí se reafirman todos los requisitos y se despejan todos los posibles conflictos, además se garantiza que el proyecto llene las necidades del cliente y el usuario, eliminando procesos innesesarios y/o adjuntando los que no estaban a simple vista.
El SDLC o Systems Development Life Cycle, es un orden de procesos mediante los cuales se garantiza el ordenamiento, el desarrollo, el seguimiento, el mantenimiento y las evaluaciones en un proyecto de desarrollo de servicios informáticos.
Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).
En esta fase se recopila la primera información, se plantean el problema, los objetivos y los alcances.
El objetivo principal es el de reconocer la viabilidad y platificar un cronograma de trabajo inicial.
Aquí buscamos entender y definir más claramente los requisitos del proyecto.
El objetivo es reconocer los requisitos, obtener acuerdos con el cliente y ratificar los alcances.
En esta etapa se realizan los bosquejos del software y se trabaja la arquitectura del mismo.
El objetivo es asignar los recursos, tecnología, métodos de validación y un modelo de desarrollo.
En esta fase se ejecutan las aplicaciones en busqueda de errores, ajustes y rediseños.
El objetivo es ajustar el producto para que su funcionalidad sea acorde a los requisitos.
Esta fase se encarga de los mantenimientos correctivos, adaptativos y de perfeccionamiento.
El objetivo es garantizar que el producto se mantenga funcional a lo largo de tiempo.
Definen una metodología comun entre las partes del proyecto, aquí se determina que tanta interacción tendra el cliente con el proceso de desarrollo, el paradigma o modelo define las etapas de trabajo y la documentación correspondiente para avanzar actividad tras actividad, fija tiempos de entregas y responsabilidades en el equipo de desarrollo.
Según la norma 1074 IEEE se define al ciclo de vida del software como:
"Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software"
La ISO/IEC 12207 Information Technology / Software Life Cycle Processes señala que es:
Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso (2008)
Este modelo se desarrollo contempla la culminacion de cada proceso antes de continuar con el siguiente, de esta manera se pueden generar reprocesos ya que si se encuentra un fayo en procesos anteriores, se debe retomar y corregir todos los procesos afectados.
Con este paradigma se pretende ahorrar tiempo y recursos ya que reutiliza código fuente basado en la creación de clases, tiene fuerte análisis de requisitos y diseños confiables.
Este modelo es el que más involucra al cliente con el diseño y desarrollo del proyecto, tambien se simplifican los procesos y se optimiza en tiempo y recursos .
Es uno de los primeros modelos en implementarse en 1970 por W. Royce.
El modelo es simple, cada actividad o proceso genera salidas que son tomadas como entradas del siguiente proceso y así hasta completar el proyecto.
Su desventaja es que requiere reprocesos largos en caso de encontrarce fallos en actividades muy tempranas del proyecto.
Basada en ciclos repetitivos de repaso y afinamiento de los procesos, tiene por objeto ir mejorando el producto las veces necesarias hasta que satisfaga al cliente.
Este modelo fue diseñado en 1988 por Boehm y define cuatro etapas: planificación, análisis de riesgo, implementación y evaluación, estos siclos se repiten hasta finalizar el proyecto.
Este modelo crea un prototipo o maqueta el cual sera evaluado y analizado para luego ser implementado con la aprobación del cliente.
Las etapas del modelo son:
1 Colecta y refinamiento de los requerimientos y proyecto rápido.
> Análisis.
> Especificación del prototipo.
2 Diseño rápido.
3 Construcción del prototipo.
4 Evaluación del prototipo por el cliente.
5 Refinamiento del prototipo.
> Diseño técnico.
> Programación y test.
> Operación y mantenimiento.
6 Producto de ingeniería.
Este modelo se basa en el incremento secuencial del proyecto, entre más se avanza más complejo.
Los procesos que utiliza son:
1 Product Backlog.
2 Sprint Backlog.
3 Sprint Planning Meeting.
4 Daily Scrum.
5 Sprint Review.
6 Sprint Retrospective
Modelo que organiza las tareas del proyecto en tableros donde se divide el proyecto sus faces, se crean etiquetas con tareas puntuales, objetivos y tiempos.
Mediante la metodología japonesa Kanban se:
1 Define el flujo de trabajo.
2 Establecen las fases del ciclo de producción.
3 Stop Starting, start finishing.
4 Tiene un control.
Este modelo se adapta a las necesidades puntuales de la fase de desarrollo en que se trabaja, interviene activamente el cliente para generar rapidez en los resultados.
Características principales de la programación extrema:
1 Tipo de desarrollo iterativo e incremental.
2 Pruebas unitarias.
3 Trabajo en Equipo.
4 Trabajo junto al cliente.
5 Corrección de errores.
6 Reestructuración del código.
7 El código es de todos.
8 El código simple es la clave.
Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado (IEEE, 1990).
Si se tiene alguna duda acerca de la necesidad del requerimiento, se puede preguntar “¿Qué sería lo peor de no incluirlo?”. Si no se encuentra una respuesta o cualquier consecuencia, entonces es probable que no sea un requerimiento necesario. Pfleeger (2002).
Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión. Pfleeger (2002).
Un requerimiento es consistente si no es contradictorio con otro requerimiento. Pfleeger (2002).
Acuerdo entre dos partes. Contiene una sola idea. Pfleeger (2002).
El requerimiento deberá de ser totalmente factible y dentro de presupuesto, calendario y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar, generar pruebas de concepto para saber su complejidad y factibilidad, si aun así el requerimiento es no factible, hay que revisar la visión del sistema y replantear el requerimiento. Pfleeger (2002).
Los cambios en los requisitos deben hacerse de manera sistemática, y debe tenerse en cuenta su impacto en otros requisitos. Pfleeger (2002).
Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo: esencial/crítico, deseado, opcional verificable. Pfleeger (2002).
Si un requerimiento no se puede comprobar, entonces, ¿cómo se sabe si se cumplió con él o no? Debe ser posible verificarlo ya sea por inspección, análisis de prueba o demostración. Cuando se escriba un requerimiento, se deberán determinar los criterios de aceptación. Pfleeger (2002).
La especificación se debe organizar de tal forma que cada función del sistema se pueda rastrear hasta su conjunto de requerimientos correspondiente. Facilita las pruebas y la validación del diseño. Pfleeger (2002).
Un requerimiento es conciso si es fácil de leer y entender, su redacción debe ser simple y clara para quienes lo consulten en un futuro. Pfleeger (2002).
Son los requerimientos hechos por el usuario y se caracterizan por usar un lenguaje comun, aquí se expresan la espectativas y problemas que el proyecto debe solucionar.
Aquí se plasman exactamente los servicios, las funciones, las restricciones y los alcances del sistema.
Estas son declaraciones de como se comportara el sistema, el modo de procesar las entradas y la gestión de las salidas.
Basicamente son las restricciones que tiene el sistema en cuanto a tiempos de respuesta, métodos de desarrollo, capacidades de almacenamiento, etc.