Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading…
Transcript

JAVIER DIAZ FAJARDO

Analisis y desarrollo de software

ETAPAS

>

Ingeniería de Requisitos

MODELOS

CLASIFICACION DE REQUISITOS

INGENIERIA DE REQUISITOS

La ingeniería de requisitos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema.

- (Boehm, 1979).

OBJETIVOS

Entender lo que el cliente quiere.

1

2

Analizar las necesidades.

OBJETIVOS

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

ELICITACION

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.

ELICITACION

ANALISIS

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).

ESPECIFICACION

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).

VALIDACION

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.

CICLO DE VIDA DEL SOFTWARE

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.

FASES

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).

FASES

FASE PLANIFICACION

PLANIFICACION

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.

FASE ANALISIS

ANALISIS

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.

FASE DISEÑO

DISEÑO

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.

FASE PRUEBAS

PRUEBAS

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.

FASE MANTENIMIENTO

MANTENIMIENTO

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.

PARADIGMAS

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.

PARADIGMAS

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)

PARADIGAMA TRADICIONAL

PARADIGMA TRADICIONAL

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.

PARADIGAMA ORIENTODO A OBJETOS

PARADIGMA ORIENTADO A OBJETOS

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.

PARADIGAMA DE DESARROLLO AGIL

PARADIGMA DE DESARROLLO AGIL

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 .

MODELO DE CASCADA

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.

CASCADA

MODELO DE ESPIRAL

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.

ESPIRAL

MODELO DE INTERACTIVO O POR PROTOTIPO

Este modelo crea un prototipo o maqueta el cual sera evaluado y analizado para luego ser implementado con la aprobación del cliente.

INTTERACTIVO

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.

MODELO SCRUM

Este modelo se basa en el incremento secuencial del proyecto, entre más se avanza más complejo.

SCRUM

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 KANBAN

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.

KANBAN

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.

MODELO DE PROGRAMACION EXTREMA XP

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.

ESTREMS XP

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.

REQUISITOS

Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado (IEEE, 1990).

REQUISITOS

NECESARIO

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).

NECESARIO

COMPLETO

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).

CONSISTENTE

Un requerimiento es consistente si no es contradictorio con otro requerimiento. Pfleeger (2002).

CORRECTO

Acuerdo entre dos partes. Contiene una sola idea. Pfleeger (2002).

CORRECTO

FACTIBLE

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).

MODIFICABLE

Los cambios en los requisitos deben hacerse de manera sistemática, y debe tenerse en cuenta su impacto en otros requisitos. Pfleeger (2002).

MODIFICABLE

PRIORIZADO

Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo: esencial/crítico, deseado, opcional verificable. Pfleeger (2002).

VERIFICABLE

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).

RASTREABLE

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).

CLARO

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).

REQUERIMIENTOS DE USUARIO

REQUERIMIENTOS DE USUARO

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.

REQUERIMIENTOS DEL SISTEMA

Aquí se plasman exactamente los servicios, las funciones, las restricciones y los alcances del sistema.

REQUERIMIENTOS FUNCIONALES

Estas son declaraciones de como se comportara el sistema, el modo de procesar las entradas y la gestión de las salidas.

REQUERIMIENTOS NO FUNCIONALES

Basicamente son las restricciones que tiene el sistema en cuanto a tiempos de respuesta, métodos de desarrollo, capacidades de almacenamiento, etc.

Learn more about creating dynamic, engaging presentations with Prezi