20131ADS1-01---Analisis y Diseño de Sistemas Overview.pdf

7/28/2019 20131ADS1-01---Analisis y Diseo de Sistemas Overview.pdf

1/85

UniversidadPeruanaUnin

Anlisis y Diseo de Sistemas: Overview

Docente: Ing. Angel Sullon

asullom

Curso: Anlisis y Diseo IUnidad 1 - Entrenamiento en Gestin de Requisitos y Diseo de Sistemas


2/85


Objetivos

Reconocer la importancia del Anlisis y Diseode Sistemas en el marco de trabajo de laingeniera de software


3/85


Agenda

Introduccin Ingeniera de requerimientos

Modelos de procesos de software

Conclusiones


4/85


INTRODUCCIN


5/85


Intro>Alert!

Las ideas dadas durante el desarrollo del cursono necesariamente puede aplicarse a todoslos escenarios de la factora de software, estodepender del contexto donde se aplique

como el proyecto a desarrollar, los procesos,los mtodos, las herramientas, experiencia,etc.

i.e. desarrollar pensamiento crtico


6/85


Intro>Qu es el software?


7/85


Intro>Problema

Imagnese que tiene un cliente enfrente, y queeste cliente necesita un software

En su imaginacin describa todo lo que ocurredesde que usted conoce al cliente hasta quetermina el trabajo y le entrega su software.


8/85


Intro>Qu necesito saber para definir un sistema?

Los objetivos de negocio que se desean satisfacer con el

sistema (esto viene del modelo de negocio del cliente o deldominio del problema) La visin general del sistema. De qu se trata (Lista de

caractersticas del sistema) El propsito del sistema. Para qu lo necesito

Los objetivos del proyecto (hasta qu etapa debo llegar) ycmo mido si se cumplieron o no Factibilidad Requisitos Los involucrados

Restricciones impuestas (por el cliente o el entorno) Riesgos Otro hechos relevantes


9/85


Intro>Involucrados en el Desarrollo de Software

Consumidores

Usuarios Clientes de la

empresa Instituciones

Gubernamentales Comunidad Empresa

contratante

Gerentes Clientes Analistas Arquitectos Diseadores Programadores Lderes de

proyecto

Proveedores Consultores Etc.


10/85


Intro>Solucin

La Ingeniera de Software es un enfoquesistemtico del desarrollo, operacin ymantenimiento, y retiro del software (IEEE).

Desarrollo Produccin Retiro

El curso Anlisis y

diseo de sistemas I, esel punto de partida parael desarrollo de software


11/85


Intro>Pero por donde comienzo?

Por los Procesos de ingeniera de requisitos

Luego, vamos a ver los Modelo de Proceso deSoftware ms importantes.

Un modelo tambin es llamado Mtodo o

metodologa. La estructura de un modelo no necesariamente

se representa mediante una grfica.

Al proceso de software tambin se le conocecomo Ciclo de Vida del Software Ciclo de Vidade Desarrollo de Software


12/85


PROCESOS DE INGENIERA DEREQUISITOS


13/85


Requisitos> IntroduccinMala comprensin de lo que quiere el cliente.El cliente o usuario no tiene claro lo que quiereEl analista cree que sabe que es lo que necesita el cliente y por lo tanto no leconsulta. Nunca diga yo creo

Requisitos>Introduccin

Ante la duda, siempreconsulte al clienteinvolucrado

Nunca d nada porsentado


14/85


Requisitos> Introduccin

Requisitos>Introduccin

Para poder desarrollar software se necesitanusuarios comprometidos, disponibles einvolucrados en el desarrollo.


15/85


Requisitos>Definicin

Un requisito es lo que el cliente quiere quehaga el software.

Los requisitos definen el qu debe hacer, masno el cmo debe hacerlo.

e.g.RF06:El sistema debe permitir manejardiferentes listas de precios de los productos.

RN02: La actualizacin de precios de productossolo debe ser realizado por el gerente


16/85


Requisitos>Ms problemas

Los requisitos cambian constantemente

Aislamiento de los equipos del proyecto.

El cliente (lenguaje asociado al dominio delcliente) y el analista (lenguaje tcnico) no se

entienden Requisitos que no reflejan las necesidades

reales del cliente, son inconsistentes,incompletos, no factibles, etc.

Requisitos que el usuario no necesitarealmente


17/85


Requisitos>Ms problemas

Y cmo obtengo los requisitos?

Cmo se pone orden en los requerimientos? Qu usuario defini qu requerimiento? Qu requerimiento satisfacen qu objetivos de

negocio? (por qu lo necesita el cliente?)

Qu requerimiento afecta a qu otro requerimiento? Dnde estn diseados e implementados losrequerimientos?

Qu sucede si un usuario quiere cambiar unrequerimiento?

Cmo se manejar los cambios, cul es el proceso paramanejar los cambios? Etc.


18/85


Requisitos>La ingeniera de requisitos como solucin

La IR, es el proceso de establecimiento de losservicios que debe proporcionar un sistema,as como de las restricciones sobre las cualesdebe operar.

Es considerada una etapa clave en eldesarrollo de software

Recuerde que la satisfaccin del cliente es la

mejor mtrica de calidad de un sistema.


19/85


Procesos de ingeniera de requisitos

Procesos de Ingeniera de Requerimientos

Cap

tura

An

li

sis

Esp

ec

ificac

in

Va

lid

ac

in

Gestin de los Requerimientos


20/85


Requisitos>Captura

Es la actividad por medio de la cual seobtienen los requerimientos

Tcnicas:

Entrevistas

Observacin directa

Modelando el negocio

Lectura/anlisis de documentos

Prototipos Otros.


21/85


Requisitos>Captura: Entrevistas

Quin est detrs de las solicitudes? Clientes

Quin usar la solucin? Usuarios

Cul ser el beneficio econmico de unasolucin exitosa?

Cmo s que una solucin es buena?

Cules problemas debera atacar la solucin?

Podra usted mostrar o describir el ambiente

de negocios en el que se utilizar la solucin?


22/85



Cuando el cliente ya est hablando. debesactuar como un nio.

Por qu?

Y por qu?

Qu es esto? Y esto otro?

Cmo se hace esto?

Y esto otro? Quin hace esto?


23/85



Es usted la persona adecuada para contestar esta

pregunta?. Sus repuestas con oficiales? Mis preguntas son relevantes para su problema?

Estoy haciendo demasiadas preguntas?

Alguien ms puede proporcionar informacinadicional?

Debera preguntarle alguna otra cosa?

Cmo se soluciona el problema actualmente?

Entre qu rango de costos se debera mover unasolucin para ser rentable?

Etc.


24/85


Requisitos>Tipos segn RUP

SoftwareRequirements DesignConstraints

Functional

Requirements

Nonfunctional

Requirements

Types ofRequirements

StakeholderRequests

Features

TIPOS DE REQUISITOS (FURPS+): Functionality (Funcionalidad) No Funcionales:

Usability (Capacidad de Uso)Reliability (Confiabilidad)Performance (Desempeo)

Supportability (Capacidad de Soporte) +

Requerimientos de diseo / implementacin,Requerimientos de interface, yRequerimientos fsicos.

SystemConstraints


25/85


Requisitos>Anlisis

Es la actividad por medio de la cual seextiende el modelo de requisitos, se buscan ylocalizan errores, inconsistencias, limitaciones,carencias, etc.

Inspecciones de documentos Discusiones, entrevistas, talleres

Desarrollo de prototipo

Tcnicas de captura


26/85


Requisitos>Especificacin

Es la actividad por medio de la cual sedescriben en b/n los requerimientos

Documento de Definicin de Requerimientos

Documento de SRS

!si los requerimientos no estn por escrito, nosirven porque no existen!


27/85


Requisitos>Validacin

Es la actividad crtica por medio de la cual sevalidan los requerimientos con el cliente

Inspecciones de documentos

Discusiones, entrevistas, talleres

Tcnicas de captura

!si los requerimientos no se han validado, no

sirven!


28/85


Recuerde:

Desarrolle el software no solo correctamentesino el software correcto.

Una vez que comprenda algo, reptalo alcliente con sus propias palabras, y si ste loentiende, entonces usted estar seguro de

que lo ha entendido correctamente


29/85


MODELOS DE PROCESOS DE SW


30/85


Qu es un Modelo?

Un modelo es una simplificacin de la realidad


31/85


Proceso de Desarrollo de Software

Conjunto de etapas con la intencin deen tiempo y

presupuesto definido.


32/85


Qu es un Modelo de Procesos de Software?

Es una estrategia mtodo de desarrollo quelos ingenieros de software deben emplearpara resolver problemas de la industria desoftware

Requerimientosde

UsuariosSoftware

Modelo de proceso

Plan del proyecto


33/85


Fases y Actividades Genricas

Ingeniera del SW La Fase de Definicin Qu?

Anlisis de requisitos Planificacin del Proyecto

La Fase de Desarrollo Cmo? Diseo Codificacin

Pruebas Instalacin

Reingeniera del SW La Fase de Mantenimiento Cambio

Preventivo Correctivo Adaptativo Perfectivo


34/85


Clasificacin de los Modelos de Proceso de SW

Formales Cascada

Prototipeo

Modelo en V

Evolutivos: Espiral

RUP

OpenUP

AgileUP NTP ISO 12207 SWEBOK

PMBOK Modelos dirigidos por

procesos de negocio Etc.

giles XP

TDD

ATDD

Scrum

Muro Kanban (Toyota)

Etc.

Sin embargo, stos procesos, pararealizar adecuadamente eltrabajo, necesita de algunos delos artefactos de los procesosformales


35/85


Cul es el modelo apropiado que debo aplicaral equipo de proyecto?

Cules son los modelos apropiados que debocombinar y aplicar al equipo de proyecto?

Estos modelos son suficientes para desarrollarmi sistema?. No

Se necesita todo un marco de trabajo queincluya: modelos guas, plantillas,

herramientas, estndares, mtodo de trabajo,libreras, tcnicas de codificacin de altorendimiento, etc.


36/85


Para comenzar a desarrollar lo que el clientequiere se debe partir de un administrador delbackend de la aplicacin y no partir de cero.

Este backend debe estar codificado bajo elestndar de desarrollo y bajo el estilo decodificacin que guiar el resto decomponentes.

Vamos conociendo algunos de los modelos deprocesos de software antes de conocer lasherramientas y tecnologas a emplear.


37/85


Cascada

Ciclo de vida clsico, + antiguo, + usado

Enfoque sistemtico secuencial

Dirigido por documentos

Anlisis

DiseoCodif.

PruebaMant.

Ing. Sist.

Cundo usar?Usar cuando todos los requerimientoshan sido establecidos claramente deentrada


38/85


Prototipeo

No estn claros los reqs. de entrada

Iterativo. Hasta cuando se itera?

Working prototype, desechar y

empezar con desarrollo de sistema.

Establecer

objetivos

prototipo

Evaluar

prototipo

Desarrollar

prototipo

Definir

funcionalidad

prototipo

Plan

prototipo

Reporte

eveluacin

Prototipo

ejecutable

Definicin

prototipo

Proceso Genrico del Prototipeo

Cundo usar?Para sistemas pequeos o de vidacorta. Cuando es difcil conocer bienlos requerimientos.


39/85


40/85


Evolutivos

Se adaptan ms fcilmente a los cambios introducidos a lo

largo del desarrollo. Iterativos En cada iteracin se obtienen versiones ms completas del

SW. Modelos Evolutivos:

Modelo Incremental (*) Modelo en Espiral (*) Modelo de Desarrollo Basado en Componentes (*) Modelo WINWIN Modelo de Desarrollo Concurrente


41/85


Incremental

Anlisi

s

Diseo PruebaCodif.Entrega 1er

IncrementoInc1

Anlisi

s

Diseo PruebaCodif. Entrega2do

Incremento

Inc2

Anlisi

s

Diseo PruebaCodif.Entrega 3er

IncrementoInc3

Tiempo


42/85


Espiral


43/85


Basado en Componentes

Basado en modelo en Espiral (evolutivo e

iterativo) + Tecnologas de Objetos. Enfatiza la Reusabilidad.

Planificacin Anlisis de Riesgos

Ingeniera,

Construccin y

Entrega

Evaluacin

del Cliente

Comunicacin

con el Cliente

Ident. Comps. candidatos

Buscar Comps. en biblioteca

Construir Extraer

Colocar en

biblioteca

Construir iteracin

VF


44/85


RUP

EstructuraCaractersticas

Artefactos

Roles y Actividades


45/85


RUP>Estructura


46/85


RUP>Estructura

Disciplinas de soporte


47/85


RUP> Caractersticas


48/85


49/85


50/85


Arquitectura Fsica


51/85


52/85


53/85


Tecnologas emergente para el desarrollo webmoderna


54/85


55/85

i id d


56/85


Qu es UML?

Es un estndar notacional empleado paramodelar y representar sistemas de software ysus partes desde distintas perspectivas,generando diagramas o artefactos.

Etapas donde se utiliza UML Requerimientos

Anlisis

Diseo

Implementacin

U i id d


57/85


DIAGRAMAS UML 2.0

U i id d


58/85


RUP>Artefactos principales

U i id d


59/85


RUP>Artefactos al culminar cada fase

tiempo

Objetivos(Vision)

Arquitectura CapacidadOperacional

Inicial

Releasedel Producto

Inicio Elaboracin Construccin Transicin


60/85

Universidad


61/85


RUP> Roles y Actividades: Anlisis y Diseo

Universidad


62/85


RUP> Roles y Actividades: Implementacin

Universidad


63/85


RUP> Roles y Actividades: Pruebas

Universidad


64/85


RUP> Roles y Actividades: Despliegue


65/85

Universidad


66/85


Open UP

Universidad


67/85


NTP ISO 12207

UniversidadDe los Procesos del Negocio a los Casos de Uso


68/85


De los Procesos del Negocio a los Casos de Uso(del Sistema)

Es decir, elproceso es laaplicacin, y

la aplicacines el proceso.

Ver

BizagiBPMS,IntalioBPMS

Universidad


69/85

PeruanaUnin

agend

Universidad


70/85

PeruanaUnin

Factibilidad

Universidad


71/85

PeruanaUnin

Requisitos-anlisis

Universidad


72/85

PeruanaUnin

Diseo


73/85

Universidad


74/85

PeruanaUnin

MTODOS GILES

Universidad


75/85

PeruanaUnin

eXtreme Programming (XP)

Se basa sobre la suposicin de que es posible desarrollarsoftware de gran calidad a pesar, o incluso comoconsecuencia del cambio continuo. Su principal asuncin esque con un poco de planificacin, un poco de codificaciny unas pocas pruebas se puede decidir si se est siguiendoun camino acertado o equivocado, evitando as tener queechar marcha atrs demasiado tarde.

Valores:

FEEDBACK CORAJE COMUNICACINSIMPLICIDAD

RESPETO


76/85

Universidad

l


77/85

PeruanaUnin

TDD>Algoritmo

Escribir la especificacin del requisito (el

ejemplo, el test).

Implementar el cdigo segn dicho ejemplo.

Refactorizar para eliminar duplicidad y hacer

mejoras.


78/85


79/85


80/85

UniversidadPS E t t


81/85

PeruanaUnin

Scrum> Estructura

Roles El Product Owner El Scrum Master El Team

Artefactos El Product Backlog (Requerimientos funcionales y no funcionales) Sprint Backlog

Burndown del Sprint Burndown del Release o Producto Backlog de impedimentos

Reuniones Eventos Sprint Planning Meeting (Parte 1 y 2) Daily Scrum Meeting

Sprint Review Meeting (Demo) Sprint Retrospective meeting


82/85


83/85

UniversidadPeruanaConclusiones


84/85

PeruanaUnin

Conclusiones

Los modelos formales como RUP requieren

grandes esfuerzos en la construccin demodelos.

En lo mtodos giles, la comunicacin resultavital para identificar qu se debe y qu no se

debe hacer. Nada asegura el xito de un proyecto, pero el

aplicar un proceso disminuye la probabilidadde fracaso.

La experiencia es lo ms importante queconocer mtodo y herramientas.

UniversidadPeruanaReferencias


85/85

PeruanaUnin

Referencias

Diseo de una Metodologa gil de Desarrollo

de Software. Schenone Marcelo Hernn. Un mejor Scrum http://www.scrumsense.com/wp-

content/uploads/2012/03/Un-mejor-Scrum-2.pdf

PROCESO DE DESARROLLO DE SOFTWARE MIXTOCOMBINANDO RUP Y SCRUM

http://revista.info.unlp.edu.ar/tesinas/tesis88.pdf

Diseo gil con TDD. Carlos Bl Jurado ycolaboradores.
http://www.scrumsense.com/wp-http://revista.info.unlp.edu.ar/tesinas/tesis88.pdhttp://revista.info.unlp.edu.ar/tesinas/tesis88.pdhttp://www.scrumsense.com/wp-

20131ADS1-01---Analisis y Diseño de Sistemas Overview.pdf

Documents

Transcript of 20131ADS1-01---Analisis y Diseño de Sistemas Overview.pdf