unidad i plan y mod

8/6/2019 Unidad I Plan y Mod

1/59


2/59

Datos de la asignaturaDatos de la asignaturaNombre de la asignatura:Nombre de la asignatura:

Planificacin y ModeladoPlanificacin y Modelado

Carrera:Carrera:

Ingeniera en Sistemas ComputacionalesIngeniera en Sistemas Computacionales

Clave de la asignatura:Clave de la asignatura:

SCMSCM--04240424

Horas teoraHoras teora-- horas prcticahoras prctica crcrditos :ditos :

33--22--88


3/59

Relacin con otras asignaturas delRelacin con otras asignaturas del

plan de estudioplan de estudioAnterioresAnteriores

Fundamentos de desarrollo de softwareFundamentos de desarrollo de software

PosterioresPosteriores

Desarrollo de proyectos de softwareDesarrollo de proyectos de software


4/59

Objetivo General del Curso:Objetivo General del Curso: El estudiante planificara, analizara y El estudiante planificara, analizara y

disediseara un proyecto de software oara un proyecto de software osistema de informacion conforme a lossistema de informacion conforme a losrequerimientos establecidos al inicio delrequerimientos establecidos al inicio delmismo y aplicando tecnicas modernas ymismo y aplicando tecnicas modernas y

de acorde a las caractersticasde acorde a las caractersticasintrinsecas del mismointrinsecas del mismo


5/59

TemarioTemario

Unidad I. Procesos de la ingeniera deUnidad I. Procesos de la ingeniera derequerimientos.requerimientos.

1.1. Requerimientos de proceso1.1. Requerimientos de proceso1.2. Requerimientos de los usuarios (actores involucrados)1.2. Requerimientos de los usuarios (actores involucrados)

1.3. Requerimientos para el anlisis y negociacin.1.3. Requerimientos para el anlisis y negociacin.1.4. Requerimientos para la gestin.1.4. Requerimientos para la gestin.

Unidad II. Planificacin del sistema.Unidad II. Planificacin del sistema.

2.1. Planificacin del tiempo2.1. Planificacin del tiempo

2.2. Evaluacin del costo beneficio2.2. Evaluacin del costo beneficio2.3. Estudio de viabilidad2.3. Estudio de viabilidad2.4. Planificacin de la documentacin2.4. Planificacin de la documentacin2.5. Gestin de la configuracin del software2.5. Gestin de la configuracin del software


6/59

TemarioTemario

Unidad III. Anlisis del proyectoUnidad III. Anlisis del proyecto

3.1. Anlisis de riesgos3.1. Anlisis de riesgos3.2. Control de calidad3.2. Control de calidad

Unidad IV. Anlisis de los requerimientosUnidad IV. Anlisis de los requerimientos4.1. Requerimientos funcionales y no funcionales4.1. Requerimientos funcionales y no funcionales4.2. Casos de Uso4.2. Casos de Uso4.3. Diseo de interfaz de usuario4.3. Diseo de interfaz de usuario

4.3.1. Reglas en el diseo de interfaz de usuario4.3.1. Reglas en el diseo de interfaz de usuario4.3.2. Integracin de la interfaz al caso de uso4.3.2. Integracin de la interfaz al caso de uso


7/59

EvaluacinEvaluacin

Exmenes rpidos (2 por unidad)Exmenes rpidos (2 por unidad) 25 %25 % Examen GeneralExamen General 20 %20 % Participacin en ClaseParticipacin en Clase 15 %15 % Proyectos Parciales y FinalProyectos Parciales y Final 40 %40 %

100 %

Puntos Extra: Asistencia


8/59

BibliografaBibliografaTitulo del LibroTitulo del Libro AutorAutor

Ingeniera de SoftwareIngeniera de Software Ian SommervilleIan Sommerville

UML y PatronesUML y Patrones Craig LarmanCraig Larman

Software EngineeringSoftware Engineering Roger S. PreesmanRoger S. Preesman


9/59

Anlisis Orientado aAnlisis Orientado a

ObjetosObjetosIntroduccinIntroduccin


10/59

IntroduccinIntroduccin

Una habilidad crtica en el desarrollo OOUna habilidad crtica en el desarrollo OOes laes la asignacin inteligente deasignacin inteligente de

responsabilidadesresponsabilidades a los objetos softwarea los objetos software


11/59

Anlisis Orientado a ObjetosAnlisis Orientado a Objetos

Investiga el problema (es mas importanteInvestiga el problema (es mas importanteque buscar una solucin)que buscar una solucin)

Es importante hacer nfasis en buscar yEs importante hacer nfasis en buscar ydescribir los objetos en el dominio deldescribir los objetos en el dominio delproblema:problema:

Por ejemplo, en un sistema para controlarPor ejemplo, en un sistema para controlar

inventario de artculos: Articulo, Bodegainventario de artculos: Articulo, Bodega El nfasis es en laEl nfasis es en la investigacin delinvestigacin del

problemaproblema y de susy de sus requisitosrequisitos (ms que(ms que

una solucin)una solucin)


12/59

Anlisis Orientado a ObjetosAnlisis Orientado a Objetos

Se enfoca en dar una solucin conceptualSe enfoca en dar una solucin conceptualque cumpla los requerimientosque cumpla los requerimientos

Es necesario definir objetos de software yEs necesario definir objetos de software yla forma en que estos colaboran parala forma en que estos colaboran paracumplir los requerimientos. Ejemplocumplir los requerimientos. Ejemplorelacin entre artculos y bodegasrelacin entre artculos y bodegas

Los diseos son implementados en algnLos diseos son implementados en algnlenguaje de programacin.lenguaje de programacin.


13/59

Del diseo a la implementacinDel diseo a la implementacin

Articulo

Clave

getCantidad()

public class Articulo {

public int getCantidad();

private String clave;

}

Articulo

(concept)

Analysis

investigation

of the problem

Design

logical solution

Construction

code

Concepto

del dominio

Representation in

analysis of concepts

Representation in an

object-oriented

programming language.


14/59

Anlisis y diseo orientado aAnlisis y diseo orientado a

objetosobjetos

Plane

tailNumber

public classPlane

{

private String tailNumber;

public List getFlightHistory() {...}

}

domain concept

visualization of

domain concept

representation in an

object-orientedprogramming language


15/59

El Lenguaje de Modelado UnificadoEl Lenguaje de Modelado Unificado(UML)(UML)

El UML es un lenguaje visual para especificar,El UML es un lenguaje visual para especificar,construir y documentar los artifacts de sistemasconstruir y documentar los artifacts de sistemas(OMG 2003).(OMG 2003).

Un lenguaje de propsito general para elUn lenguaje de propsito general para elmodelado orientado a objetosmodelado orientado a objetos

UML combina notaciones provenientes desde:UML combina notaciones provenientes desde:

ModeladoO

rientado aO

bjetosModeladoO

rientado aO

bjetos Modelado de DatosModelado de Datos Modelado de ComponentesModelado de Componentes Modelado de Flujos de Trabajo (Workflows)Modelado de Flujos de Trabajo (Workflows)


16/59

Historia de UMLHistoria de UML

Comenz como el Mtodo Unificado, conComenz como el Mtodo Unificado, conla participacin de Grady Booch y Jimla participacin de Grady Booch y JimRumbaugh.Se present en el OOPSLA95.Rumbaugh.Se present en el OOPSLA95.

El mismo ao se uni Ivar Jacobson. LosEl mismo ao se uni Ivar Jacobson. LosTres Amigos son socios en la compaaTres Amigos son socios en la compaaRational Software. Herramienta CASERational Software. Herramienta CASERational RoseRational Rose


17/59

Historia de UMLHistoria de UML


18/59

UML conjunta varias disciplinasUML conjunta varias disciplinas


19/59

Perspectivas de UMLPerspectivas de UML UML ser el lenguaje de modelado orientado aUML ser el lenguaje de modelado orientado a

objetos estndar predominante los prximosobjetos estndar predominante los prximosaosaos

Razones:Razones:

Participacin de metodlogos influyentesParticipacin de metodlogos influyentes Participacin de importantes empresasParticipacin de importantes empresas Aceptacin del OMG como notacin estndarAceptacin del OMG como notacin estndar

Evidencias:Evidencias:

Herramientas que proveen la notacin UMLHerramientas que proveen la notacin UML Edicin de librosEdicin de libros Congresos, cursos, etc.Congresos, cursos, etc.

Tarea: Investigar las herramientas que se puedenutilizar para modelar con UML


20/59

UML y el pensamiento de la balaUML y el pensamiento de la bala

de platade plata Error fundamental:Error fundamental: creer que hay unacreer que hay una

herramienta o tcnica de software queherramienta o tcnica de software quehace una diferencia dramtica enhace una diferencia dramtica enproductividad, ceroproductividad, cero--defectos, confiabilidaddefectos, confiabilidado simplicidad.o simplicidad.

Herramientas no compensan laHerramientas no compensan la

ignorancia en diseoignorancia en diseo


21/59

Tarea:Tarea:

Leer sobre los siguientes artculos:Leer sobre los siguientes artculos: No Silver BulletNo Silver Bullet

Death by UML FeverDeath by UML Fever What UML Is and IsntWhat UML Is and Isnt..


22/59

3 Perspectivas para aplicar UML3 Perspectivas para aplicar UML

La misma notacin de UML se puede utilizarLa misma notacin de UML se puede utilizardesdedesde al menosal menos-- 33 perspectivasperspectivas:: Conceptual:Conceptual: los diagramas se interpretanlos diagramas se interpretan

describiendo cosas en el mundo real (el espacio deldescribiendo cosas en el mundo real (el espacio delproblema).problema).

Especificacin (software):Especificacin (software): los diagramaslos diagramasdescriben abstracciones software o componentes condescriben abstracciones software o componentes con

especificaciones e interfaces; pero no seespecificaciones e interfaces; pero no secomprometen a una implementacin particular (Javacomprometen a una implementacin particular (Javao C# por ejemplo).o C# por ejemplo).

Implementacin (software):Implementacin (software): los diagramaslos diagramasdescriben implementaciones software en unadescriben implementaciones software en una

tecnologa particular (Java o C# por ejemplo).tecnologa particular (Java o C# por ejemplo).


23/59

Las Clases desde las 3Las Clases desde las 3

perspectivasperspectivas Clases conceptuales:Clases conceptuales: conceptos delconceptos del

mundo real o cosas.mundo real o cosas.

Clases software:Clases software: una claseuna claserepresentando una perspectiva derepresentando una perspectiva deespecificacin o implementacin de unespecificacin o implementacin de un

componente software.componente software. Clases implementacin:Clases implementacin: una claseuna clase

implementada en una lenguaje OOimplementada en una lenguaje OOespecfico como Java o C#.especfico como Java o C#.


24/59

Modelado en UMLModelado en UML

Un proceso de desarrolloUn proceso de desarrollode software debe ofrecerde software debe ofrecerun conjunto de modelosun conjunto de modelosque permitan expresar elque permitan expresar elproducto desde cada unaproducto desde cada unade las perspectivas dede las perspectivas deintersinters

El cdigo fuente delEl cdigo fuente del

sistema es el modelo mssistema es el modelo msdetallado del sistema (ydetallado del sistema (yadems es ejecutable).adems es ejecutable).Sin embargo, seSin embargo, serequieren otros modelosrequieren otros modelos......


25/59

Modelado en UMLModelado en UML

Cada modelo es completo desde su punto deCada modelo es completo desde su punto devista del sistema, sin embargo, existenvista del sistema, sin embargo, existenrelaciones de trazabilidad entre los diferentesrelaciones de trazabilidad entre los diferentes

modelosmodelos


26/59

Diferentes diagramas de UMLDiferentes diagramas de UML

Diagrama de Casos de UsoDiagrama de Casos de Uso Diagrama de ClasesDiagrama de Clases Diagrama de ObjetosDiagrama de Objetos Diagramas de ComportamientoDiagramas de Comportamiento

Diagrama de EstadosDiagrama de Estados Diagrama de ActividadDiagrama de Actividad

Diagramas de InteraccinDiagramas de Interaccin Diagrama de SecuenciaDiagrama de Secuencia Diagrama de ColaboracinDiagrama de Colaboracin

Diagramas de implementacinDiagramas de implementacin Diagrama de ComponentesDiagrama de Componentes

Diagrama de DespliegueDiagrama de Despliegue


27/59

Diagramas de UMLDiagramas de UML


28/59

El Proceso UnificadoEl Proceso Unificado

UnUn proceso de desarrollo de softwareproceso de desarrollo de softwaredescribe un enfoque para la construccin,describe un enfoque para la construccin,desarrollo y posiblemente eldesarrollo y posiblemente el

mantenimiento del software.mantenimiento del software. ElEl Proceso Unificado (UP)Proceso Unificado (UP) se hase ha

convertido en un proceso de desarrollo deconvertido en un proceso de desarrollo desoftware de gran xito para lasoftware de gran xito para laconstruccin de sistemas orientados aconstruccin de sistemas orientados aobjetos.objetos.

ElEl UPUP combina las practicas comnmentecombina las practicas comnmente

aceptadas como buenas practicas.aceptadas como buenas practicas.


29/59

Desarrollo iterativoDesarrollo iterativo

El UP fomenta el uso del desarrollo a travs deEl UP fomenta el uso del desarrollo a travs deiteraciones.iteraciones.

El desarrollo de un proyecto de software seEl desarrollo de un proyecto de software se

organiza en una serie de mini proyectos cortos,organiza en una serie de mini proyectos cortos,de duracin fija llamadosde duracin fija llamados iteracionesiteraciones.. Cada iteracin incluye sus propias actividades deCada iteracin incluye sus propias actividades de

anlisis de requisitos, diseo, implementacin yanlisis de requisitos, diseo, implementacin y

pruebas.pruebas. El sistema crece incrementalmente a lo largo delEl sistema crece incrementalmente a lo largo del

tiempo, iteracin tras iteracin, es por esto quetiempo, iteracin tras iteracin, es por esto quea este enfoque se le conoce como desarrolloa este enfoque se le conoce como desarrollo

iterativo e incremental.iterativo e incremental.


30/59

Desarrollo iterativoDesarrollo iterativo[iteration N]

Requirements Analysis - Design- Implementation - Testing

[iteration N+1]

Requirements Analysis - Design- Implementation - Testing

La retroalimentacin desde laiteracin N permite el refinamiento

y la adaptacin de los requerimientos

y diseo en la iteracin N+1.

El sistema crece de

Forma incremental.


31/59

Beneficios del desarrolloBeneficios del desarrollo

iterativoiterativo Mitigacin tan pronto como sea posible deMitigacin tan pronto como sea posible deriesgos altos.riesgos altos.

Progreso visible en las primeras etapas.Progreso visible en las primeras etapas. Una temprana retroalimentacin,Una temprana retroalimentacin,

compromiso de los usuarios y adaptacin.compromiso de los usuarios y adaptacin.

Gestin de la complejidad.Gestin de la complejidad. El conocimiento adquirido en una iteracinEl conocimiento adquirido en una iteracin

se puede utilizar metdicamente parase puede utilizar metdicamente paramejorar el propio proceso de desarrollo.mejorar el propio proceso de desarrollo.


32/59

Fases del UPFases del UP1.1. InicioInicio: visin aproximada, anlisis del negocio,: visin aproximada, anlisis del negocio,alcance.alcance.2.2. ElaboracinElaboracin: visin refinada, identificacin de: visin refinada, identificacin de

mas requisitos y alcance, estimaciones masmas requisitos y alcance, estimaciones mas

realistas.realistas.3.3. ConstruccinConstruccin: implementacin iterativa del: implementacin iterativa del

resto de los requisitos de menor riesgo yresto de los requisitos de menor riesgo yelementos mas fciles, preparacin para elelementos mas fciles, preparacin para el

despliegue.despliegue.4.4. TransicinTransicin: pruebas beta, despliegue.: pruebas beta, despliegue.

Inception Elaboration Construction Transition

time


33/59

Iteraciones entre las fasesIteraciones entre las fases

PreliminaryPreliminary

IterationIteration

Iter. #1Iter. #1 Iter. #2Iter. #2

InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition

Hito Liberacin Liberacin del

Producto finalPunto de terminacinde la iteracincuando se tomaalguna decisin oevaluacinimportante

Un subconjuntoestable yejecutable del

producto final. Elfinal en cadaiteracin es unapequea versin

En este puntoel sistema se

lanza para supuesta enproduccin


34/59

Disciplinas del UPDisciplinas del UP

Gestion del Proyecto

Entorno

Modelado del Negocio

Implementacin

Prueba

Diseo

PreliminaryIteration(s)

Iter.#1

Phases

Process Disciplines

Iteraciones

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Despliegue

Gestion de Configuraciones y cambio

Requisitos

Elaboration TransitionInception Construction

Supporting Disciplines


35/59

Desarrollo en cascada oDesarrollo en cascada o

secuencialsecuencial Es una alternativa para el desarrollo de proyectos deEs una alternativa para el desarrollo de proyectos desoftware.software. Pasos:Pasos:

Determinar, registrar y acordar un conjunto de requisitosDeterminar, registrar y acordar un conjunto de requisitoscompleto y fijo.completo y fijo.

Disear un sistema basado en estos requisitos.Disear un sistema basado en estos requisitos. Implementar en base al diseo.Implementar en base al diseo.

Existen estudios sobre los proyectos de softwareExisten estudios sobre los proyectos de softwareexitosos, en los cuales se identificaron factores comunesexitosos, en los cuales se identificaron factores comunespara el xito:para el xito: El desarrollo iterativo.El desarrollo iterativo. Al menos una incorporacin diaria de nuevo cdigo y rpidaAl menos una incorporacin diaria de nuevo cdigo y rpida

retroalimentacin de los cambios del diseo.retroalimentacin de los cambios del diseo. Equipo con experiencia.Equipo con experiencia. Centrarse en la construccin y prueba de una arquitecturaCentrarse en la construccin y prueba de una arquitectura

consistente.consistente.


36/59

Requisitos evolutivos VSRequisitos evolutivos VS

cascadacascada De acuerdo a investigaciones, en promedio, unDe acuerdo a investigaciones, en promedio, un25% de los requisitos cambian en los proyectos25% de los requisitos cambian en los proyectosde software.de software.

Cualquier mtodo que intente congelar o definirCualquier mtodo que intente congelar o definircompletamente los requisitos al inicio estcompletamente los requisitos al inicio estcondenado al fracaso, puesto que secondenado al fracaso, puesto que sefundamente en una suposicin falsa y pelea ofundamente en una suposicin falsa y pelea oniega el cambio inevitable.niega el cambio inevitable.

De acuerdo a un estudio de Thomas 2001 sobreDe acuerdo a un estudio de Thomas 2001 sobre1027 proyectos de software se encontr que el1027 proyectos de software se encontr que elfactor que contribua de forma mayor al fracaso,factor que contribua de forma mayor al fracaso,en el 82% de los casos es el supuesto de queen el 82% de los casos es el supuesto de quelos requisitos no cambiarn.los requisitos no cambiarn.


37/59

Comprensin de los requisitosComprensin de los requisitos

Los requisitos son capacidades y condicionesLos requisitos son capacidades y condicionescon las cuales debe ser conforme el sistema, encon las cuales debe ser conforme el sistema, ensi el proyecto.si el proyecto.

El primer reto del trabajo de los requisitos esEl primer reto del trabajo de los requisitos esencontrar, comunicar y recordar (registrar) loencontrar, comunicar y recordar (registrar) loque se necesita realmente, de manera queque se necesita realmente, de manera quetenga un significado para el cliente y lostenga un significado para el cliente y losmiembros del equipo de desarrollo.miembros del equipo de desarrollo.

El UP acepta el cambio de los requisitos comoEl UP acepta el cambio de los requisitos comoun motor fundamental del proyecto.un motor fundamental del proyecto. Otro termino importante esOtro termino importante es encontrarencontrar es decires decir

es buscar cuidadosamente mediante tcnicases buscar cuidadosamente mediante tcnicastales como la escritura de lostales como la escritura de los Casos de UsoCasos de Uso yy

talleres de requisitos.talleres de requisitos.


38/59

Unidad IUnidad IProcesos de la ingeniera deProcesos de la ingeniera de

requerimientosrequerimientos


39/59

Qu son los Requerimientos?Qu son los Requerimientos?

El estndar 729 de la IEEE define requerimientoEl estndar 729 de la IEEE define requerimientocomo:como:

Una condicin o capacidad requerida por unUna condicin o capacidad requerida por un

usuario para resolver un problema o parausuario para resolver un problema o paraalcanzar un objetivo.alcanzar un objetivo. La fase de requerimientos se inicia cuando uno oLa fase de requerimientos se inicia cuando uno o

ambos de los siguientes hechos ocurren:ambos de los siguientes hechos ocurren:

Un problema existe y quizs requiera una solucinUn problema existe y quizs requiera una solucinbasada en un software.basada en un software. Hay alcance para crear un software basado en unaHay alcance para crear un software basado en una

idea.idea.


40/59

Punto clavePunto clave

La ingeniera de requisitos establece unaLa ingeniera de requisitos establece unabase solida para el disebase solida para el diseo y lao y laconstruccin. Sin ella, el softwareconstruccin. Sin ella, el softwareresultante tiene una alta posibilidad de noresultante tiene una alta posibilidad de nosatisfacer las necesidades del cliente.satisfacer las necesidades del cliente.


41/59

Naturaleza de losproblemasreconocidos

Orientado aNegocio

Orientado aAplicacin

UtilidadesGenricas y de

Propsito Mltiples

Orientado a la

mejoradel producto


42/59

SRSSRS

SRS es una especificacin deSRS es una especificacin derequerimientos de software, en donde serequerimientos de software, en donde seregistra la descripcin completa de todosregistra la descripcin completa de todoslos requerimientos.los requerimientos.

Describe lo que el software har, pero sonDescribe lo que el software har, pero sondescribir como.describir como.


43/59

Anlisis y Descripcin Anlisis y Descripcin

Durante el anlisis del problema, los analistasDurante el anlisis del problema, los analistasdedican una cantidad considerable de tiempodedican una cantidad considerable de tiempohaciendo lo siguiente:haciendo lo siguiente:

Tormenta de ideasTormenta de ideas Dirigir entrevistas con los involucrados con el sistemaDirigir entrevistas con los involucrados con el sistema Obtener informacin de las personas masObtener informacin de las personas mas

familiarizadas con ese dominio.familiarizadas con ese dominio.

El anlisis del problema debe de llevarse a caboEl anlisis del problema debe de llevarse a cabohasta que se alcance una comprensin completahasta que se alcance una comprensin completadel problema.del problema.


44/59

Importancia de la fase deImportancia de la fase derequerimientosrequerimientos

Pueden existir errores que si se detectan en estaPueden existir errores que si se detectan en estafase puede ser que no se propaguen a fasesfase puede ser que no se propaguen a fasesposteriores.posteriores.

Esta fase involucra mucha comunicacin entreEsta fase involucra mucha comunicacin entrelos involucrados (actores, stakeholders) con ellos involucrados (actores, stakeholders) con elsistema y los desarrolladores.sistema y los desarrolladores.

Se debe de tener precaucin para asegurar queSe debe de tener precaucin para asegurar que

las especificaciones estn libres de hechoslas especificaciones estn libres de hechos(aseveraciones) incorrectos, omisin de detalles,(aseveraciones) incorrectos, omisin de detalles,inconsistencias y ambigedades.inconsistencias y ambigedades.


45/59

Aspectos de laIngeniera deRequerimientos

Negociacin de la

Solucin con elEl cliente

Anlisis de las

Necesidades delcliente

Comprender las

Necesidades delcliente

Especificacin deSolucin noAmbigua

Validacin de laEspecificacin

Manejo derequerimientosA travs delciclo de vida


46/59

Pasos involucrados en la IngenieraPasos involucrados en la Ingenierade requerimientosde requerimientos

LevantamientoLevantamientoAnlisisAnlisis RefinamientoRefinamiento NegociacinNegociacin EspecificacinEspecificacin ModeladoModeladoValidacinValidacinAdministracinAdministracin


47/59

Levantamiento deLevantamiento deR

equerimientosR

equerimientos Es el proceso de recibir un conjunto deEs el proceso de recibir un conjunto derequerimientos del cliente, el usuario y larequerimientos del cliente, el usuario y lagerencia. Estos participantes hacen lasgerencia. Estos participantes hacen las

preguntas siguientespreguntas siguientes:: Cules son los objetivos del sistema oCules son los objetivos del sistema o

producto?producto? Qu debe lograr el producto o sistema?Qu debe lograr el producto o sistema?

Cmo ayuda el sistema o producto en lasCmo ayuda el sistema o producto en lasnecesidades del negocio?necesidades del negocio?

Cmo usara usted el sistema o producto?Cmo usara usted el sistema o producto?


48/59

Problemas en el levantamiento deProblemas en el levantamiento deRequerimientosRequerimientos

Problema de AlcanceProblema de Alcance Limites indefinidosLimites indefinidos Detalles InnecesariosDetalles Innecesarios

Problema ComprensinProblema Comprensin Clientes Inseguros de sus necesidadesClientes Inseguros de sus necesidades Pobre dominio del conocimientoPobre dominio del conocimiento

Problema de VolatilidadProblema de Volatilidad Cambia en el tiempo de numero deCambia en el tiempo de numero derequerimientosrequerimientos

Requerimientos voltiles en si mismosRequerimientos voltiles en si mismosHacer figura


49/59

Despus del proceso de levantamiento deDespus del proceso de levantamiento derequerimientos, se obtiene la siguienterequerimientos, se obtiene la siguiente

informacin:informacin:

Un documento especificando la necesidad yUn documento especificando la necesidad yfactibilidad del sistema a construirse.factibilidad del sistema a construirse.

Alcance del sistema o producto a desarrollarse.Alcance del sistema o producto a desarrollarse. Lista de todos los involucrados que participaronLista de todos los involucrados que participaron

en el levantamiento de requerimientos.en el levantamiento de requerimientos. Un documento describiendo el entornoUn documento describiendo el entorno

tecnolgico.tecnolgico. Lista de todos los requerimientos organizadosLista de todos los requerimientos organizados

por funcin.por funcin. Especificacin de los casos de uso o escenariosEspecificacin de los casos de uso o escenarios

de uso.de uso.


50/59

Anlisis de RequerimientosAnlisis de Requerimientos

Preguntas que contribuyen al anlisis dePreguntas que contribuyen al anlisis derequerimientos:requerimientos: Es cada requerimiento consistente con los objetivosEs cada requerimiento consistente con los objetivos

globales para los cuales el software estaglobales para los cuales el software estadesarrollndose?desarrollndose? Proporcionan cada uno de los requerimientosProporcionan cada uno de los requerimientos

suficientes detalles, para que se pueda pasar a lasuficientes detalles, para que se pueda pasar a laprxima fase?prxima fase?

Cules de los requerimientos especificados sonCules de los requerimientos especificados sonabsolutamente necesarios y cuales son estticos?absolutamente necesarios y cuales son estticos?

Es posible identificar la fuente (la persona en laEs posible identificar la fuente (la persona en laorganizacin) de cada requerimiento?organizacin) de cada requerimiento?


51/59

Validacin de RequerimientosValidacin de Requerimientos

Aspectos que aseguranla validacin

de Requerimientos

ConsistenciaNo Ambigedad

Completitud

Correspondenciaa ciertos

estndares


52/59

Conducir el estudio de requerimientosConducir el estudio de requerimientos

Las siguientes son algunas actividades principales queLas siguientes son algunas actividades principales quedeben ser parte del estudio de requerimientos:deben ser parte del estudio de requerimientos: Arreglar la primera reunin con los clientes.Arreglar la primera reunin con los clientes. Procurar entender la misin de la organizacin.Procurar entender la misin de la organizacin. Familiarizarse con la estructura de la organizacin e identificar aFamiliarizarse con la estructura de la organizacin e identificar a

los diversos involucrados con el sistema.los diversos involucrados con el sistema. Utilizar la reunin para establecer credibilidad con los clientes yUtilizar la reunin para establecer credibilidad con los clientes y

para ganar su confianza.para ganar su confianza. Conducir las entrevistas con profundidad con los diferentesConducir las entrevistas con profundidad con los diferentes

involucrados para los aspectos especficos.involucrados para los aspectos especficos. Desarrollar una clara comprensin del flujo de datos y lgicaDesarrollar una clara comprensin del flujo de datos y lgica

operacional del sistema.operacional del sistema. Conocer y resguardar documentos que se utilicen para laConocer y resguardar documentos que se utilicen para la

entrada de datos, as como para salidas del sistema.entrada de datos, as como para salidas del sistema.


53/59

Tipos de requisitosTipos de requisitos

En UP (Proceso Unificado), los requisitosEn UP (Proceso Unificado), los requisitosse clasifican de acuerdo con el modelose clasifican de acuerdo con el modeloFURPSFURPS++, para nuestro estudio nos, para nuestro estudio nosbasaremos en dos tipos de requisitos:basaremos en dos tipos de requisitos: FuncionalesFuncionales No FuncionalesNo Funcionales


54/59

Requisitos FuncionalesRequisitos Funcionales

Son declaraciones de los servicios que proveer elSon declaraciones de los servicios que proveer elsistema, de la manera en que ste reaccionara asistema, de la manera en que ste reaccionara aentradas particulares y de cmo se comportar enentradas particulares y de cmo se comportar ensituaciones particulares. En algunos casos, lossituaciones particulares. En algunos casos, los

requerimientos funcionales de los sistemas tambinrequerimientos funcionales de los sistemas tambindeclaran explcitamente lo que el sistema no debedeclaran explcitamente lo que el sistema no debehacer.hacer.

Los requisitos funcionales para un sistema se expresanLos requisitos funcionales para un sistema se expresan

de diferentes formas.de diferentes formas.


55/59

Ejemplo de requisitos funcionalesEjemplo de requisitos funcionales

A continuacin se describe parte los requisitos que unA continuacin se describe parte los requisitos que un

sistema para administrar condominios requiere.sistema para administrar condominios requiere.

El sistema debe poder registrar los pagos de mantenimiento que se

reciben por parte de los condminos. Las cuotas de mantenimiento se establecen de acuerdo al tamao del

terreno que ocupe la propiedad, por lo tanto debe de haber forma decalcular dichas cuotas por medio del sistema.

Los condminos deben de poder realizar los pagos personalmente o de

forma electrnica. Se deben de enviar recordatorios mensuales a los condminos que no

realicen los pagos de forma puntual.


56/59

Requisitos no funcionalesRequisitos no funcionales

Son aquellos requisitos que no se refieren directamenteSon aquellos requisitos que no se refieren directamentea las funciones especificas que entrega el sistema, si noa las funciones especificas que entrega el sistema, si noa las propiedades emergentes de ste como la fiabilidad,a las propiedades emergentes de ste como la fiabilidad,la respuesta en el tiempo y la capacidad dela respuesta en el tiempo y la capacidad de

almacenamiento.almacenamiento. De forma alternativa definen restricciones del sistemaDe forma alternativa definen restricciones del sistema

como la capacidad de los dispositivos de entrada/salida ycomo la capacidad de los dispositivos de entrada/salida yla presentacin de los datos que se utiliza en lasla presentacin de los datos que se utiliza en lasinterfases del sistema.interfases del sistema.

Algunos ejemplos de requisitos no funcionales son:Algunos ejemplos de requisitos no funcionales son:rapidez, facilidad de uso, fiabilidad, robustez.rapidez, facilidad de uso, fiabilidad, robustez.


57/59

El documento de requisitosEl documento de requisitos

Es la declaracin oficial de que requieren losEs la declaracin oficial de que requieren losdesarrolladores del sistema. Este documentodesarrolladores del sistema. Este documentotiene un conjunto diverso de usuarios que vatiene un conjunto diverso de usuarios que va

desde los administradores principales de ladesde los administradores principales de laorganizacin, quienes pagan por el sistema,organizacin, quienes pagan por el sistema,hasta los ingenieros responsables del software.hasta los ingenieros responsables del software.

Existen varias especificaciones para crear esteExisten varias especificaciones para crear este

documento, a continuacin se presenta la quedocumento, a continuacin se presenta la quesugiere la IEEE.sugiere la IEEE.


58/59

Documento de requisitosDocumento de requisitos(contenido)(contenido)

1.1. IntroduccinIntroduccin2.2. Descripcin generalDescripcin general

3.3. Requerimientos especficosRequerimientos especficos4.4. ApndicesApndices5.5. ndicendice

Tarea: Buscar cuales otrasespecificaciones existen paracrear este documento


59/59

Resumen de RequerimientosResumen de Requerimientos Los requerimientos para un sistema de softwareLos requerimientos para un sistema de software

determinan lo que har el sistema y definen lasdeterminan lo que har el sistema y definen lasrestricciones de su operacin e implementacin.restricciones de su operacin e implementacin.

Los requerimientos funcionales son declaraciones de losLos requerimientos funcionales son declaraciones de losservicios que el sistema debe proveer.servicios que el sistema debe proveer.

Los requerimientos no funcionales son requerimientosLos requerimientos no funcionales son requerimientosdel producto que restringen el sistema a serdel producto que restringen el sistema a serdesarrollado, a menudo estn relacionados con lasdesarrollado, a menudo estn relacionados con laspropiedades emergentes del sistema, por lo tantopropiedades emergentes del sistema, por lo tantoaplican para el sistema completo.aplican para el sistema completo.

Los documentos de requerimientos de software son laLos documentos de requerimientos de software son ladeclaracin acordada de los requerimientos del sistema.declaracin acordada de los requerimientos del sistema.Se estructura de tal forma que puedan ser utilizadosSe estructura de tal forma que puedan ser utilizadostanto por los clientes del sistema como por lostanto por los clientes del sistema como por losdesarrolladores de software.desarrolladores de software.

unidad i plan y mod

Documents