Download - Unidad I Plan y Mod
-
8/6/2019 Unidad I Plan y Mod
1/59
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
9/59
Anlisis Orientado aAnlisis Orientado a
ObjetosObjetosIntroduccinIntroduccin
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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)
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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)
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
17/59
Historia de UMLHistoria de UML
-
8/6/2019 Unidad I Plan y Mod
18/59
UML conjunta varias disciplinasUML conjunta varias disciplinas
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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..
-
8/6/2019 Unidad I Plan y Mod
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).
-
8/6/2019 Unidad I Plan y Mod
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#.
-
8/6/2019 Unidad I Plan y Mod
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......
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
27/59
Diagramas de UMLDiagramas de UML
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
38/59
Unidad IUnidad IProcesos de la ingeniera deProcesos de la ingeniera de
requerimientosrequerimientos
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
41/59
Naturaleza de losproblemasreconocidos
Orientado aNegocio
Orientado aAplicacin
UtilidadesGenricas y de
Propsito Mltiples
Orientado a la
mejoradel producto
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
46/59
Pasos involucrados en la IngenieraPasos involucrados en la Ingenierade requerimientosde requerimientos
LevantamientoLevantamientoAnlisisAnlisis RefinamientoRefinamiento NegociacinNegociacin EspecificacinEspecificacin ModeladoModeladoValidacinValidacinAdministracinAdministracin
-
8/6/2019 Unidad I Plan y Mod
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?
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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?
-
8/6/2019 Unidad I Plan y Mod
51/59
Validacin de RequerimientosValidacin de Requerimientos
Aspectos que aseguranla validacin
de Requerimientos
ConsistenciaNo Ambigedad
Completitud
Correspondenciaa ciertos
estndares
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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.
-
8/6/2019 Unidad I Plan y Mod
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
-
8/6/2019 Unidad I Plan y Mod
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.