análisis y requerimientos de software · químico, electrónico, magnético, electro-óptico, por...

1

DISCAPACIDAD E INTEGRIDADManual Autoformativo Interactivo

Sandra Wong Durand

Anlisis y requerimientos de software

Administracin Financiera . Manual Autoformativo InteractivoSandra Wong Durand

Primera edicin digital

Huancayo, octubre de 2017

De esta edicin Universidad Continental Av. San Carlos 1980, Huancayo-Per Telfono: (51 64) 481-430 anexo 7361 Correo electrnico: [email protected] http://www.continental.edu.pe/

Versin e-bookDisponible en http://repositorio.continental.edu.pe/ISBN electrnico N. 978-612-4196-

Direccin: Emma Barrios IpenzaEdicin: Miguel ngel Crdova Sols

Miriam Ponce GonzlesAsistente de edicin: Pal Juan Gmez HerreraAsesor didctico: Susana Beatriz Diaz DelgadoCorreccin de textos: Juan Guillermo Gensollen SoradosDiseo y diagramacin: Alexander Frank Vivanco Matos

Todos los derechos reservados. Cada autor es responsable del contenido de su propio texto.

Este manual autoformativo no puede ser reproducido, total ni parcialmente, ni registrado en o transmitido por un sistema de recuperacin de informacin, en ninguna forma ni por ningn medio sea mecnico, foto-qumico, electrnico, magntico, electro-ptico, por fotocopia, o cualquier otro medio, sin el permiso previo de la Universidad Continental.

WONG DURAND, SandraAnlisis y requerimientos de software: manual autoformativo interactivo / Mg. Sandra Wong Durand. -- Huancayo: Universidad Continental, 2017

Datos de catalogacin del Cendoc

Datos de catalogacin bibliogrfica

NDICE

Introduccin 9

Organizacin de la asignatura 11

Resultado de aprendizaje de la asignatura 11

Unidades didcticas 11

Tiempo mnimo de estudio 11

U - I MODELAMIENTO Y ANLISIS DE SOFTWARE 13

Diagrama de organizacin de la unidad I 13

Organizacin de los aprendizajes 13

Tema n. 1: Fundamentos de modelamiento 14

1. Modelo de sistemas 142. Ciclo de vida del producto 14 2.1. Predictivo 14 2.2. Iterativo e incremental 15 2.3. Adaptativo 15

Tema n. 2: Tipos de modelos 18

1. Modelo de contexto 182. Modelado para el desarrollo estructurado 19 2.1.Diagramadeflujodedatos 20 2.2. Modelos de datos 21 2.2.1. Modelo entidad-relacin 21 2.2.2. Modelo relacional 24 2.3. Diagrama de transicin de estados 25 2.4. Diccionario de datos 273. Modelado para el desarrollo orientado a objetos 28 3.1.RationalUnifiedProcess(RUP) 29 3.2.LenguajeUnificadodeModelado(UML) 31 3.2.1. Diagrama de clases 31 3.2.2. Diagrama de casos de uso 32 3.2.3. Diagramas de secuencia 33

Lectura seleccionada n. 1 35

Actividad n. 1 35

Tema n. 3: Fundamentos del anlisis 36

1. Modelado basado en escenarios 362.Modeladoorientadoalflujo 363. Modelado basado en clases 37


Actividad n. 2 37

Tarea acadmica n. 1 38

GlosariodelaUnidadI 40

Bibliografa de la Unidad I 41

Autoevaluacin n. 1 42

U - II ELICITACIN DE REQUERIMIENTOS 45

Diagrama de organizacin de la unidad II 45


Tema n. 1: Fundamento de los requerimientos 46

1. Anlisis de negocio 462. Ingeniera de requisitos 47 2.1. Inicio 48 2.2. Obtencin 49 2.2.1. Problemas de mbito 49 2.2.2. Problemas de comprensin 49 2.2.3.Problemasdevolatilidad 50 2.3.Elaboracin 50 2.4.Negociacin 50 2.5.Especificacin 50 2.6.Validacin 50 2.7.Gestinderequisitos 50

Tema n. 2: Origen de los requerimientos 51

1.Definicinderequisito 512. Esquemadeclasificacinderequisitos 51 2.1. Requisitos de negocio 51 2.2. Requisitos de las partes interesadas 52 2.3. Requisitos de la solucin 52 2.3.1. Requisitos funcionales 52 2.3.2. Requisitos no funcionales 52 2.4. Requisitos de transicin 53


Actividad n. 3 53

Tema n. 3: Tcnicas de elicitacin de requerimientos 54

1. Lluviadeideas(Brainstorming) 542. Anlisis de documentos 553. Focus group 554. Anlisis de interfaces 555. Entrevistas 576. Observacin 587. Prototipos 598. Talleresderequisitos 609. Encuestas / Cuestionarios 6110.Tcnicasgrupalesdetomadedecisiones 6211. Estudios comparativos 62


Actividad n. 4 63


Glosario de la Unidad II 65

Bibliografa de la Unidad II 66


U - III ESPECIFICACIN DE REQUERIMIENTOS DE SOFTWARE 69

Diagrama de organizacin de la unidad III 69


Tema n. 1: Documentacin de los requerimientos 70

1.Documentacindelciclodevida 701.1 Documento Modelo de proceso de negocio 71

1.1.1 Modelamiento de la situacin actual 71 1.1.2 Modelamiento de la situacin propuesta 71 1.1.3 Requerimientos del proyecto 72 1.2 Documento de anlisis 72 1.2.1 Modelamiento de requerimientos 72 1.2.2 Anlisis de casos de uso 76 1.2.3 Anlisis de clases 77 1.2.4 Anlisis de paquetes 77 1.2.5 Elaboracin del modelo de datos 77 1.2.6Especificacindenecesidadesdemigracin 78 1.3 Documento de diseo 78 1.3.1Definicindelaarquitectura 78 1.3.2Diseodecasosdeuso 80 1.3.3Diseodeclases 80 1.3.3.1Identificacindeatributosdelasclases 81 1.3.3.2Identificacindelasoperacionesdelasclases 81 1.3.4 Diseo de mdulos del sistema 82 1.3.5 Diseo fsico 83 1.3.6Generacindeespecificacionesdeconstruccin 84 1.3.6.1 Entorno de construccin 84 1.3.6.2 Definicindecomponentesysubsistemasdeconstruccin84 1.3.7 Migracin de datos 85 1.4 Manuales de usuario 85 1.5 Evidencias de pruebas unitarias 85 1.6 Evidencias de pruebas integrales 85 1.7 Documento de pase a produccin 86 1.8 Plan de pruebas 87 1.9 Casos de pruebas 88 1.10Evidenciasdepruebas 88 1.11 Informe de Calidad 88


Actividad n. 5 88

Tema n. 2: Tcnicas de especificacin de requerimientos 89

1. EspecificacinderequerimientosdesoftwareIEEE830 89 1.1Naturalezadelaespecificacinderequerimientosdesoftware 89 1.2 Medioambientedelaespecificacinderequerimientosdesoftware 89 1.3Caractersticasdelaespecificacinderequerimientosdesoftware89 1.4Preparacinconjuntadelaespecificacinderequerimientosde software 89

1.5Evolucindelaespecificacinderequerimientosdesoftware 90 1.6Prototipado 90 1.7Diseodeinclusinenlaespecificacinderequerimientosdesoftware 90 1.8Incorporacindelosrequisitosdelproyectodeespecificacinderequerimientosdesoftware 90

Lecturaseleccionadan.6 90

Actividad n. 6 91


Glosario de la Unidad III 92

Bibliografa de la Unidad III 93


U - IV VALIDACIN DE REQUERIMIENTOS 97

Diagrama de organizacin de la unidad IV 97


Tema n. 1: Revisiones e inspecciones 99

1. Revisiones 992. Inspecciones 99

Tema n. 2: Prototipo para validar requerimientos 100

1.Validacindeprototipos 100 1.1Ventajasdelprototipo 100 1.2Desventajasdelprototipo 101

Tema n. 3: Prueba de aceptacin de diseo 102

1.Validacindeladefinicindelaarquitectura 102 1.1Validacindelaarquitecturadedatos 102 1.2Validacindelasespecificacionesdeconstruccin 102


Actividadn.7 103

Tema n. 4: Validacin de los atributos de calidad del producto 104

1. Pruebasunitarias 1042. Pruebasintegrales 1043. Pruebasdesistemas 104 3.1Pruebasdecajablanca 104 3.2Pruebasdecajanegra 105 3.3Pruebasderegresin 105 3.4Pruebasnofuncionales 1064. Pruebasdeaceptacin 1075. Pruebasautomatizadas 108 5.1Selenium 108 5.2JMeter 110 5.3 Testlink 111 5.4 PMD 112 5.5 Check Style 113 5.6 Sonarqube 113 5.7 Bugzilla 114 5.8 Appium 114 5.9 Mantis 114 5.10Jenkins 1156. Ciclo de vida de desarrollo con el uso de herramientas 116

Tema n. 5: Anlisis de la interaccin de requerimientos 117

1.Definicinderequerimiento 1172. Anlisis de factibilidad de un requerimiento 1173. Interaccin de requerimientos 118

Tema n. 6: Anlisis formal requerimientos 119

1.Caractersticasdelaespecificacinderequisitosdesoftware 1192. Anlisis formal 119


Actividadn.8 120


Glosario de la Unidad IV 122

Bibliografa de la Unidad IV 123


Anexos 126

Esta asignatura pertenece a la especialidad de la carrera de Ingeniera de Sistemas e Informtica de la modalidad a distancia, es de carcter terico-prctico y est dirigida a los estudiantes de pregrado. Tiene como propsito desarrollar en el estudiante la capacidad de interpretar los diferentes tipos de modelos de diagramas de software, las perspectivas de modeladoy los requerimientos del sistema para disear las especificaciones a alto nivel.

En general, los contenidos propuestos en el manual autoformativo se dividen en cuatro unidades: En la Unidad I se har una introduccin a los Fundamentos del Modelado, tipos de modelos y fundamentos de anlisis; luego, en la Unidad II, se explicarn los fundamentos y el origen de los requerimientos, adems de las tcnicas de elicitacin de estos; en la Unidad II I , abordaremos los conceptos sobre la documentacin de los requerimientos y tcnicas de especificacin de requerimientos; en la Unidad IV se desarrollarn los conceptos

de revisiones e inspecciones, prototipos para validacin de requerimientos, pruebas de aceptacin, validacin de atributos, y anlisis de requerimientos.

Es recomendable que haga una permanente lectura de estudio de los contenidos desarrollados y de los textos seleccionados que amplan o profundizan el tratamiento de la informacin, junto con la elaboracin de resmenes y una minuciosa investigacin va internet. El desarrollo del manual se complementa con autoevaluaciones, que son una preparacin para la prueba final de la asignatura.

Organice su tiempo para que obtenga buenos resultados. La clave est en encontrar el equil ibrio entre sus actividades personales y las actividades que asuma como estudiante. El estudio a distancia requiere constancia; por ello, es necesario encontrar la motivacin que lo impulse a hacerlo mejor cada da.

INTRODUCCIN

El autor

11

MANUAL AUTOFORMATIVO INTERACTIVO


ORGANIZACIN DE LA ASIGNATURA

Resultado de aprendizaje de la asignaturaAltrminodelaasignatura,elestudiantesercapazdevalidarlaespecificacinderequerimientosdesoftwareparaunproyectodesoftware.

Unidades didcticasUNIDAD I UNIDAD II UNIDAD III UNIDAD IV

Modelamiento y anlisis de software

Elicitacin de requerimientos Especificacinderequerimientosdesoftware

Validacin de requerimientos

Resultado de aprendizaje Resultado de aprendizaje Resultado de aprendizaje Resultado de aprendizaje

Alfinalizarlaunidad,elestudiante ser capaz de

construir el modelamiento de softwareorientadoaobjetos

de su proyecto.


elicitar los requerimientos de softwareparasuproyecto.


organizarlaespecificacinderequerimientosdesoftwarede

su proyecto.

Alfinalizarlaunidad,elestudiante ser capaz de validarlaespecificacinde

requerimientosdesoftwaredesu proyecto.

Tiempo mnimo de estudioUNIDAD I UNIDAD II UNIDAD III UNIDAD IV

Semana 1 y 2

16 horas

Semana 3 y 4

16 horas

Semana 5 y 6

16 horas

Semana 7 y 8

16 horas

13



UNIDAD I MODELAMIENTO Y ANLISIS DE SOFTWARE

DIAGRAMA DE PRESENTACIN DE LA UNIDAD I

CONTENIDOS EJEMPLOS ACTIVIDADES

AUTO EVALUACIN BIBLIOGRAFA

ORGANIZACIN DE LOS APRENDIZAJESRESULTADO DE APRENDIZAJE: Alfinalizar launidad,elestudiantesercapazdeconstruirelmodela-mientodesoftwareorientadoaobjetosasuproyecto.

CONOCIMIENTOS HABILIDADES ACTITUDESTema n. 1: Fundamentos de modelamiento1. Modelo de sistemas2. Ciclo de vida del producto

2.1 Predictivo2.2 Iterativo e incremental2.3 Adaptativo

Tema n. 2: Tipos de modelos de sistemas1. Modelo de contexto2. Modelado para el desarrollo estructurado

2.1Diagramadeflujodedatos2.2 Modelos de datos

2.2.1. Modelo entidad-relacin2.2.2. Modelo relacional

2.3 Diagrama de transicin de estados2.4 Diccionario de datos

3. Modelado para el desarrollo orientado a objetos3.1RationalUnifiedProcess(RUP)3.2Lenguaje Unificado de Modelado

(UML)3.2.1 Diagrama de clases3.2.2 Diagrama de casos de uso3.2.3 Diagramas de secuencia

Lectura seleccionada n. 1SWEBOK Guide(2004,pp.158-165)

Tema n. 3: Fundamentos del anlisis1. Modelado basado en escenarios. 2. Modeladoorientadoalflujo3. Modelado basado en clases

Lectura seleccionada n. 2Software Requirements (Wiegers & Beatty,2013)

Autoevaluacin de la Unidad I

1. Construyemodelosdesoftwareapar-tir de una situacin real analizada.

Actividad n. 1Los estudiantes participan en el foro de dis-cusin sobre modelos de sistemas y mode-los de anlisis.

Tarea acadmica n. 1

1. Cooperar en la consolida-cin de los modelos de an-lisisdesoftware.

14

Fundamentos de modelamientoTema n. 1

En el siguiente captulo usted comprender los diferentes conceptos de modelamiento y anlisis de softwareasociadoalaIngenieradeSoftware;adems,sercapazdedescribirlosdiferentesmode-lamientosaplicadosaldesarrollodelsoftwareenlafaseinicialdelciclodevida.

1. Modelo de sistemas

EdwardYourdon(1989)ensulibroAnlisis Estructurado Moderno precisa:

Podemos construir modelos de manera tal que enfatizamos ciertas propiedades crticas del sistema, mientras que simultneamente desacentuamos otros de sus aspectos. Esto nos per-mite comunicarnos con el usuario de una manera enfocada, sin distraernos con asuntos y caractersticas ajenas al sistema. Y si nos damos cuenta de que nuestra comprensin de los re-querimientosdelusuarionofuelacorrecta(odequeelusuariocambidepareceracercadesusrequerimientos),podemoshacercambiosenelmodeloodesecharloyhacerunonuevo,de ser necesario. La alternativa es tener algunas reuniones preliminares con el usuario y luego construirtodoelsistema;desdeluego,existeelriesgodequeelproductofinalseaaceptable,y pudiera ser excepcionalmente costoso hacer un cambio a esas alturas.

Por esta razn, el analista hace uso de herramientas de modelado para:

Concentrarse en las propiedades importantes del sistema y al mismo tiempo restar aten-cin a otras menos importantes.

Discutir cambios y correcciones de los requerimientos del usuario, a bajo costo y con el riesgo mnimo.

Verificarqueelanalistacomprendacorrectamenteelambientedelusuarioyquelohayarespaldado con informacin documental para que los diseadores de sistemas y los pro-gramadorespuedanconstruirelsistema(p.73).

Elmodeladodesistemasesuncomponenteesencialdeldesarrollodesoftwareyconstituyelabasedel ciclo de vida. El modelamiento de sistemas empieza con una visin global y luego del anlisis ini-cialsedescomponedetalladamentecreandounprocesoomedianteunflujoconentradasysalidas,componentes, supuestos, restricciones, entre otros.

2. Ciclo de vida del producto

Elciclodevidadelproductodesoftwarepuedeser:

2.1. Predictivo

Este modelo hace referencia a la ejecucin de actividades secuenciales del ciclo de vida del desarrollodesoftware.Enestemodeloseoptaporlasvalidacionesy/oaprobacionespreviasdelos entregables; por tanto, la fase siguiente no inicia si la anterior no ha sido validada y/o aproba-da, pues cada fase requiere informacin de la etapa previa para iniciar. La desventaja de este modeloessuinflexibilidad,pueslasfasesdelciclodevidanopuedenejecutarseenparalelo.Asi-mismo,cuandoenlasetapasintermediasseidentificancambios,esnecesariovolveralaetapainicial para documentarlos, paralizando las atenciones hasta que se completen las fases previas; como consecuencia, esto puede implicar sobrecostos y desviaciones de plazos. A continuacin semuestraelmodelogrficamente:

15



Despliegue en ProduccinPruebasConstruccinAnlisis Diseo

Figura 1.Modelopredictivo.Fuente:Wong,2017.

2.2. Iterativo e incremental

Estemodelohacereferenciaalaejecucindeactividadesdeldesarrollodesoftwaredeformamodular;estoquieredecirquesevaadesarrollarelsoftwarepormdulos,cadaunoconsuciclocompleto. La ventaja de este modelo son las siguientes:

Elusuariofinalobtieneresultadosparcialesdesuproducto.

Los riesgos de integracin del producto se mitigan en etapas tempranas porque la integracin se va dando de forma progresiva conforme se va culminando cada mdulo.

Elproductodesoftwaresepuedeirafinandoymejorandoencadaiteracin.

Se puede optar por la reutilizacin de componentes en cada iteracin y mejorarlos.

Las desventajas de este modelo son las siguientes:

Al no priorizarse los requisitos de manera integral desde el inicio, pueden surgir problemas pos-teriores en la arquitectura.

El usuario piensa que el producto ya se encuentra terminado en las primeras entregas.

Anlisis Anlisis Anlisis

Diseo Diseo Diseo

Construccin Construccin Construccin

Pruebas Pruebas Pruebas

Despliegue Despliegue Despliegue

Iteracin 1 Iteracin 2 Iteracin N

......

Figura 2.Modeloiterativoeincremental.Fuente:Wong,2017.

2.3. Adaptativo

Estemodelorefierealaimplementacindedesarrollodesoftwareconelusodemtodosgiles;similar a otros modelos, su proceso es cclico y asume que cada iteracin tendr oportunidades demejora.Lasactividadesdeldesarrollodelsoftwaregeneranfuncionalidadesdelnegocioyuna

16

funcionalidad puede tener varios casos de uso en su desarrollo, aqu desaparece el concepto de mdulo y existe una retroalimentacin continua del desarrollo. Entre los modelos ms conocidos deesteciclodevidatenemosaSCRUMyExtremeprogramming(XP).Lasventajasdeestemodeloson las siguientes:

Es un desarrollo iterativo. Eldesarrollosecentraenloscomponentesdelsoftware. Es tolerante a los cambios. En cada iteracin se revisan las oportunidades de mejora y se aplican los cambios. Enfocado en la organizacin y colaboracin de equipo.

Este Modelo DAS se basa en tres fases que son las siguientes:

Colaboracin

Aprendizaje Especulacin

Figura 3:FasesdeDAS.Fuente:Wong,2017.

Especulacin:enestafaseseefectalaplanificacinpreliminardelasentregasqueseirndandocomopartedeldesarrollodelsoftware.Aestafaseseleprecisaconeltrminoespecu-lacin porque se quiere precisar lo impredecible del desarrollo de los sistemas. Si bien es cierto seefectaunaplanificacin,lamismaencadaiteracinsersusceptibleacambios;laideaesfijarunrumboquedebenseguirelequipodeldesarrollo,sedebeconsignarqueelaprendi-zaje de cada iteracin generar mayores ventajas para solucionar futuros inconvenientes con mayor rapidez.

Colaboracin:estafasesecentraeneldesarrollodelcomponente,elmismoquerefiereaunao muchas funcionalidades por ser desarrolladas como parte de cada iteracin. El enfoque del equipo de desarrollo ser concluir el componente comprometido para la iteracin; el modelo no precisa una metodologa o estndar a seguir para el desarrollo, deja libre la posibilidad de la experiencia del equipo de desarrollo para aplicar sus mejores prcticas, colaborar entre s, apoyarse mutuamente y sacar el producto.

Aprendizaje: esta fase se centra en lo siguiente:

o La calidad del producto desde la perspectiva del cliente. Mediante tcnicas de grupos focalizados el equipo de desarrollo podr conocer el punto de vista del cliente en relacin con el producto desarrollado; aqu se anotarn mejoras que se pueden aplicar al produc-to.

17



o La calidad del producto desde la perspectiva tcnica. Aqu se efectuar una revisin de diseo, cdigo, base de datos, arquitectura, uso de servicios, entre otros. La revisin se centra en buscar defectos para mejorar y aprender de ellos, no se buscan culpables, la visin del equipo se centra en resolver los problemas, aprender de lo acontecido y propo-ner mejoras para ser aplicadas en la siguiente iteracin; con ello el equipo enriquece sus mejores prcticas.

o El funcionamiento del equipo de desarrollo y las prcticas utilizadas. Uno de los puntos ms crticos es el recurso humano; por ello, en este modelo se asigna un tiempo para la revisin del funcionamiento de equipo. Aqu se vislumbra el grado de cohesin, integracin y co-laboracin, el objetivo de equipo debe ser nico, no deben primar intereses personales, cada uno debe de cumplir su rol y aportar. El equipo debe discutir de aquello que funcio-n bien y de aquello que no, y proponer mejoras para la interaccin del equipo.

o Estatusdelproyecto,severificademaneraintegralcmovaelproyecto,qusepuedemejoraryajustarparaefectosdelaplanificacin.

El modelo adaptativo es similar al modelo incremental pero aplica prcticas adicionales de ges-tin en manejo de equipos, as como gestin de usuarios; asimismo se enfoca en el desarrollo de componentes.

Anlisis Anlisis Anlisis

Diseo Diseo Diseo

Construccin Construccin Construccin

Pruebas Pruebas Pruebas

Despliegue Despliegue Despliegue

Iteracin 1

Componente 1

Iteracin 2

Componente 2

Iteracin N

Componente N

......

......

Figura 4:Modeloadaptativo.Fuente:Wong,2017.

18

Tipos de modelos

Tema n. 2

Los modelos de sistemas son representaciones del modelo de negocio de la concepcin del reque-rimientodesoftware.Estosmodelosrepresentarndeformagrficaelprocesodenegocio,locualservirdebaseparalaespecificacintcnicay,posteriormente,paraeldesarrollodelsoftware.Losmodelos que detallaremos a continuacin son representaciones del modelo funcional y de datos de los sistemas; dependiendo del ciclo de vida o metodologa por elegir para el desarrollo, se deber definirelmodelomsapropiadoparautilizar.

1. Modelo de contexto

Sommerville(2005)ensulibroSoftware Engineering menciona los siguientes tipos de modelos:

Enunadelalasprimerasetapasdelaobtencinderequerimientossedebendefinirloslmitesdel sistema. Esto comprende trabajar conjuntamente con los stakeholders del sistema para distinguirloqueeselsistemayloqueelentornodelsistema(p.155).

Los modelos de contexto son utilizados para las etapas tempranas del relevamiento de informacin, en los modelos de proceso de negocio; esto, para conocer la funcionalidad y la descripcin del re-querimiento de usuario a alto nivel.

Este primer diagrama permite validar el primer requisito funcional con el usuario y tener una visin global del sistema. Los requisitos funcionales se irn incrementando conforme se va explotando o detallando el diagrama de contexto; para ello se puede hacer uso de otros diagramas del modelo estructurado o del modelo orientado a objetos.

Porejemplo,tenemoseldesarrollodeunsistemadenotificacioneswebcuyafinalidadesoptimizarlascomunicacionesformaleseinformalesconelusuariofinal;loqueelusuariorequiereesoptimizarlostiempos de generacin de la comunicacin que se viene trabajando de manera manual y mediante mensajerafsica.Asimismo,tenerconocimientodequeelmensajehasidoledoporelusuariofinal.

Lasolucinpropuestaimplicaeldesarrollodeunaplicativowebymvil,paralocualsedeberim-plementar lo siguiente:

DesarrollarelmantenimientodelprocesodeNotificacin,queactualmenteesmanual;aquseregistrarelcdigodelprocesodeNotificacin,porcadatipodedocumentoqueserequiereenviar(carta,oficio,memorndum),sedebevincularelcanaldecomunicacin(Correo,SMS,buznelectrnico)yplantillaqueserequiera.

Desarrollarelmantenimientodelasplantillasporcanal(Correo,SMS,buznelectrnico).Esteregistro permite crear la plantilla y vincularla al canal y al tipo de documento requerido. Ser unmantenimientoquepodrsergeneradoporelusuariofinalenelmomentoqueserequiera.

Desarrollar el mantenimiento de responsables. Aqu se anotar a los colaboradores que regis-trarnelmantenimientodelosdocumentosdeNotificacin.

19



Usuario Usuario

Administracin del Proceso de

Notificacin

Registro de plantilla del canal de Notificacin

Cerrar el proceso de Notificacin

Responsables registrados

Ficha del proceso de la Notificacin

Registro de responsables de la NotificacinPlantilla del canal

de Notificacin

Figura 5:Sistemadenotificaciones.Fuente:Wong,2017.

Eldiagramadelafigura5especificaaaltonivelelrequerimientodeusuariodescritopreviamente.Paraefectosdeldesarrollodesoftware,estediagramaser labase inicial,ysegnestesepodrnefectuar otros diagramas a mayor detalle.

2. Modelado para el desarrollo estructurado

Seenfocaenladescomposicinfuncionaldelsistema,suobjetivoesobtenerunadefinicincompletadelsoftwarepordesarrollaratravsdelaelicitacinderequisitos.Paraefectosdeldesarrollo,estadefinicinsedescomponeenfuncionesqueparaestemodeloeslaunidadbsicadelaconstruccin.Asimismo,sedefinenlosdatosdeentradaysalida.Losdiagramasutilizadosenestemodeloson:

Diagramadeflujodedatos Diagramaentidadrelacin Diagrama de transicin de estados

Cada uno de los diagramas establece una funcin dentro del modelado del sistema: el diagrama de flujosecentraenlafuncionalidaddelsistema,eldiagramaentidad-relacinseenfocaenlosdatosyel diagrama de transicin de estados muestra el comportamiento con base en el tiempo. El dicciona-rio de datos es un diagrama complementario que permite conocer el detalle de los datos.

Depsito central de informacin

Diccionariode datos

Generadorde cdigo

Herramientas de creacin de

formularios

Facilidades de generacin de

informes

Facilidades de lenguajes de

consulta

Herramientas de diagramas estructurados

Recursos de importacin/exportacin

Herramientas de diseo, anlisis y

verificacin

Figura 6: Componentes de una herramienta CASE para el soporte de mtodos estructurados. Fuente:Sommerville,2005.

20

2.1. Diagrama de flujo de datos

Eldiagramadeflujodedatosmuestraunaperspectivafuncionaldeunproceso,estilenelanli-sisdelosrequerimientosporquemuestranelprocesodenegociodeinicioafin.Sielprocesoglobalcontienesubprocesos,elmodelodeflujodeprocesos sedescomponeensubprocesos,conelobjetivo de otorgar al usuario una visin ms detallada del negocio.

Ficherode pedidos

Fichero de presupuestos

Enviar al proveedor

Validar el pedido

Ajustar el presupuesto disponible

Registrar el pedido

Completar el formulario del

pedido

Detalles del

pedido + formulario en blanco del pedido

Pedidos verificado y firmados +

notificaciones del pedido

Formulario delpedido completo

Formulario delpedido firmado

Formulario delpedido firmado

Detallesdel pedido

Formulariodel pedido

firmadoCoste de pedido +

detalles de la cuenta

Figura 7:Flujodedatosdelprocesamientodeunpedido.Fuente:Sommerville,2005

Elmodelodeflujodedatospuede serdiagramadoenvisiooutilizarotrasherramientascomoSmartDrawoLucidChart,queposeenplantillaspredefinidasqueayudanenlaelaboracindelosdiagramas. La simbologa que se utiliza para la elaboracin de estos diagramas es la siguiente:

Tabla 1 Simbologa de un Diagrama de Flujo

Representacin grfica Descripcin

Inicio / Fin Inicioofindelprograma

Proceso Descripcin del proceso

Entrada Operaciones de entrada y salida

Decisin Decisin S/NO

Conector

Nota:TomadodeWong,2017.

21



2.2. Modelos de datos

Losdesarrollosdesoftwareincluyencomopartedesuimplementacinlabasededatosquecon-tendr la informacin relevante del usuario en un repositorio centralizado digital. Muchas veces los sistemas se integran con otros y los datos se pueden grabar en bases de datos ya existentes o tambin el nuevo sistema puede consumir datos de la base de datos de otro sistema.

Los diagramas de datos ms usados son el diagrama relacional y el diagrama entidad-relacin; ambosrepresentandemaneragrficaladescripcindelosdatosdelaaplicacin.Cabemen-cionar que el diagrama entidad-relacin es el utilizado en el modelado estructurado.

2.2.1. Modelo entidad-relacin

Describe las necesidades de informacin del proceso de negocio del usuario mediante un conjun-to de entidades y relaciones entre ellas. Asimismo, detalla las descripciones de los datos y restric-ciones que los datos deben cumplir. Adicionalmente, el modelo contempla los atributos que son las caractersticas de la entidad y que para efectos de un modelo fsico representarn los datos de una tabla de base de datos. Tambin se describe la cardinalidad, que indica la cantidad de veces que se ejecuta una relacin entre las entidades, las cuales pueden ser de uno a uno, de uno a muchos y de muchos a muchos.

A continuacin, se muestra la simbologa del diagrama:

Tabla 2 Simbologa Modelo entidad-relacin


Nombre_Entidad Entidad

Nombre_Atributo Atributo

11 1

N

NN

Cardinalidad

Nombre_Relacin Decisin S/NO


Las entidades son representaciones del negocio, pueden ser una persona, objeto o animal del cualsedescribeunacaractersticaoaccindentrodelsoftware.Porejemploacontinuacinsecitan algunas entidades:

22

PRODUCTO

CLIENTE

LIBRO AUTOR

Figura 8:Ejemplodeentidades.Fuente:Wong,2017.

En lafigura8 se tienencuatroejemplosdeentidades: laentidadproducto, la entidad libro, la entidad autor y la entidad cliente; cada una de ellas puede representar en la base de datos una tabla, ya que poseen atributos diferentes; dependiendo del contexto del negocio y la necesidad del usuario se debern asignar los atributos a cada entidad. Es importante validar con el usuario previamente la necesidad de informacin que requerir almacenar en la base de datos del siste-ma,afindenoconsignarentidadesoatributosnorequeridosquefinalmentenuncacontendrndatos.

A continuacin, se muestra un ejemplo de entidad con sus atributos:

PRODUCTO

Modelo de Negocio: Mini Market Entidad Atributos

Cdigo de Barras Nombre del producto Ingredientes Fecha de fabricacin Fecha de vencimiento Nombre del fabricante Nmero de lote

Figura 9:Ejemplodeatributos.Fuente:Wong,2017.

Lafigura9muestraelmodelodenegociodeunminimarket,elmismoquerequieredeunaenti-dad producto como parte de su sistema. A continuacin se describen las caractersticas que necesita el producto, tales como cdigo de barras, nombre del producto, ingredientes, fecha de fabricacin, fecha de vencimiento, nombre del fabricante y nmero de lote. Las caractersticas de la entidad son consideradas atributos. Entonces, siempre se deber partir del negocio para primero seleccionar entidades y luego describir sus atributos.Porejemplo,acontinuacinsemuestralanotacingrficadelmodeloentidadrelacinparalaentidad persona:

23



NOMBRE APELLIDO IDENTIFICACIN

PERSONA

Figura 10:Ejemplodeentidadyatributos.Fuente:Wong,2017.

Las relaciones son el enlace entre las entidades y describen la accin que se da entre ellas. La siguientefiguramuestralarelacinentrelapersonayelproductomediantelaaccincomprar;entonces, se tiene que la persona compra un producto y un producto puede ser comprado por una persona.

PERSONA PRODUCTOCOMPRA

Figura 11:Ejemploderelacinentreentidades.Fuente:Wong,2017.

Las cardinalidades indican la cantidad de veces mxima y mnima en que puede ocurrir una re-lacin entre las entidades. As, se tiene lo siguiente:

Uno a uno: a cada ocurrencia en A le corresponder una ocurrencia en B, a cada ocu-rrencia en B le corresponder una ocurrencia en A. Para el siguiente ejemplo, la lectura serlasiguiente:Cadaoficinaesdirigidaporunjefe,unjefedirigeunaoficina.

OFICINA JEFEDIRIGE

1 1

Figura 12:Ejemploderelacindeunoauno.Fuente:Wong,2017.

Uno a muchos: a cada ocurrencia en A le corresponde una o ms ocurrencias en B, a cada ocurrencia en B le corresponde una ocurrencia en A. Para el siguiente ejemplo, la lecturaserlasiguiente:Encadaoficinatrabajanvarioscolaboradores,varioscolabora-dorestrabajanenunaoficina.

OFICINA COLABORADORESTRABAJA

1 N

Figura 13:Ejemploderelacindeunoamuchos.Fuente:Wong,2017.

24

Muchos a muchos: a cada ocurrencia en A le corresponden muchas ocurrencias en B y viceversa.Elsiguientegrficomuestralarelacindemuchosamuchosyseleedelasi-guiente manera: Muchos alumnos estudian en muchos cursos, en muchos cursos pueden estudiar muchos alumnos.

ALUMNOS CURSOSESTUDIAN

N N

Figura 14:Ejemploderelacindemuchosamuchos.Fuente:Wong,2017.

2.2.2. Modelo relacional

Este modelo, al igual que el modelo entidad-relacin, recoge la informacin de datos que el usuario requiere que se almacene en una base de datos. A diferencia del modelo entidad-rela-cin, el modelo relacional utiliza tablas, campos y relaciones, un modelo similar al modelo fsico de base de datos. En este modelo, las tablas son los elementos de almacenamiento principales y secomponendefilas(registros)ycolumnas(campos).Cadatablatieneunaclaveprimaria,queeselidentificadordelatabla.Elestablecimientoderelacinentrelastablassedamediantelainclusin en forma de columna de la clave primaria de la tabla A en la tabla B; a esta columna se le denomina clave fornea.

Hotel

Atributos

Nombres

Direccin

Telefono

Distrito

Provincia

IdCategoria

IdHotel

Figura 15:Representacindeunatabladelmodelorelacional.Fuente:Gmez,2015.

Enlafigura15,setomacomomodelodenegociounsistemaadministrativodeunacadenadehoteles, y la primera referencia inicial es la tabla Hotel. Para ello, el usuario requiere que se graben en una base de datos la informacin relacionada con los datos de sus sedes. Entonces, se proce-deaidentificarlaclaveprimariadelatabladenominndolaidHotel;acontinuacinseidentificanlos atributos adicionales, tales como nombres, direccin, telfono, distrito, provincia e IdCategora.Enlafigura16sepuedeidentificarlaclaveprimariaylaclaveforneadelatablaIdHotel.Cabemencionar que la clave fornea se genera como producto de la relacin entre dos tablas:

25



Hotel

Clave primaria

Clave fornea

Nombres

Direccin

Telefono

Distrito

Provincia

IdCategoria (FK)

IdHotel

Figura 16:Elementosdeunatabla.Fuente:Gmez,2015.

En lafigura17 semuestra la relacinentredos tablas;paraefectosdelejemplo se relacionanla tabla Hotel y la tabla Habitacin. La relacin entre ellas es de una a muchos; su lectura es la siguiente: en un hotel puede haber muchas habitaciones, muchas habitaciones corresponden a un hotel.

HotelHabitacion

Nombres

Direccin

Telefono

Distrito

Provincia

IdCategoria (FK)

NroEdificio

TipoHabitacion

Piso

Costo

IdHotel (FK)

IdHotelIdHabitacion

Figura 17:Relacinentredostablas.Fuente:Gmez,2015.

2.3. Diagrama de transicin de estados

Tambin conocido como DTE, muestra los estados que puede tomar el componente de una apli-cacin, as como los eventos que implican el cambio de un estado a otro. Los elementos principa-les de este tipo de diagrama son el estado y la transicin.

Estado: hace referencia al comportamiento del sistema en un determinado perodo de tiempo y los atributos que lo caracterizan.

Transicin: es el cambio de estado generado por algn evento, muestra el camino del estadoinicialalestadofinal.

26

De un estado pueden generarse diversas transiciones sobre la base de un evento que desenca-denaelcambio.Entonces,eldiagramainiciarconunestadoinicialcomopartedelflujo;poste-riormente,productodeloseventossegenerarntransicionesdeotrosestados.Elestadofinalseraquel que deje de tener alguna actividad. Cabe mencionar que el diagrama puede tener varios estadosfinalescomopartedelflujo,losmismosquesedanatravsdelastransiciones.

Adems de los estados y las transiciones, los diagramas de transicin de estados contienen otros componentes, tales como la accin y la actividad. Una accin es una operacin que se genera dentro de un estado y se asocia a un evento, la accin se ejecuta al entrar o salir del estado.

Aligualquelosdiagramasdeflujo,losdiagramasdeestadospuedendescomponerseenmsdeuno para tener una mejor visibilidad de las transiciones; por lo tanto, se pueden tener diagramas de alto nivel y diagramas de bajo nivel. En el caso de que tengamos diagramas de bajo de nivel, los mismos deben ser referenciados en el diagrama principal.

Los elementos del diagrama de estados son los siguientes:

Tabla 3 Notacin del diagrama de estados


Nombre de estado Estado

Estado inicial

Estadofinal

Transicin


A continuacin, se mostrar un ejemplo de un diagrama de estados de la revisin de documentos:

aprobar

rechazar

FinalizadoPendiente

Rechazado

Aprobadocompleto

completo

Figura 18:Ejemplodediagramadetransicindeestados.Fuente:Wong,2017.

27



2.4. Diccionario de datos

Esunalistadetodoslosdatosquepertenecenalaaplicacin.Incluyedefinicionesdelosdatos,de modo que todos tengan la misma comprensin de la informacin; registra la documentacin deprocesos,almacenesdedatos,flujosdedatosydatoselementales.

El diccionario de datos debe ir actualizndose continuamente por el equipo de desarrollo, con-forme se van dando los mantenimientos al sistema. Esta informacin es sumamente importante en las etapas de anlisis, diseo y construccin del sistema.

El diccionario de datos contiene lo siguiente:

Estructura de dato: hace referencia al nombre de la entidad. Elementodedato:refierealosatributosdelaentidad. Flujos y almacenes de datos: son estructuras de datos.

La notacin de los elementos del dato se describir segn lo siguiente:

Nombredelosdatos:seasignarunadescripcinalaentidadenrelacinconelsignifica-do que este tiene en el contexto del sistema por desarrollar.

Descripcindelosdatos:seexplicabrevementeelsignificadodeldatoysuusoenelsiste-ma; la descripcin debe ser funcional, de modo que el usuario pueda comprenderla.

Alias:refierealautilizacindeldatoendiferentescontextosdentrodelmismosistema.Afindeidentificarlomejor,elprogramadorpodrasignarlevariosnombresdeacuerdoconsu utilizacin.

Longitud: es la cantidad de caracteres que se deben considerar para el registro del dato. Rangodevaloresdelelementodeldato:refierealacantidadinfinitadevaloresquepue-

de contener un dato. Puede estar en los siguientes rangos: o Rango continuo: dentro de un rango vlido, el elemento del dato puede tomar cual-

quier valor.o Rangodiscreto:refierealosvaloreslimitadosquepuedetomarelelementodeldato;

se restringen los valores. Codificacino tipo: seespecifica lacaractersticade valordel elementodeldato,de

modo que puede ser numrico, alfanumrico, alfabtico.

Tabla 4Ejemplo de Diccionario de datos

Artculo Detalle del artculo publicado que puede pedirse por las personas que usen LIBSYS

Entidad 30.12.2002

Autores Los nombres de los autores del artculo que pueden compartir los honorarios

Atributo 30.12.2002

Comprador La persona u organizacin que emite una orden de copia del artculo

Entidad 30.12.2002

Honorarios a pagar a

Una relacin 1:1 entre Artculo y la Agencia de derechos de autor a quien se debera abonar el honorario de derechos de autor

Relacin 29.12.202

Direccin (Comprador)

La direccin del comprador. sta se utiliza para cualquier informacin que se requiera sobre la factura en papel

Atributo 31.12.2002

Nota:TomadodeSommerville,2005.

28

3. Modelado para el desarrollo orientado a objetos

En este modelo, la unidad bsica de construccin es la clase y el objeto; el modelo muestra los datos del sistema as como su procesamiento. A continuacin, se describen los elementos principales del modelado orientado a objetos:

Objetos: son instancias de la clase que poseen atributos y servicios. La comunicacin entre los objetos se da mediante los mensajes.

Clases:refierealosobjetosquerespondenaunmismomensaje;laclaseimplementa(encap-sula)elmtododelcomportamientodelasinstancias.

El modelado orientado a objetos implica la ejecucin de las siguientes actividades:

Identificacindeclases,objetosysusatributos,serviciosyoperacionesquesernconsideradoscomo parte del modelo de desarrollo.

Descripcin del comportamiento de objetos, considerando su estado, transicin, evento y ac-cin; asimismo, la colaboracin entre ellos.

Organizacindeclasesporjerarquaapartirdelaherencia,afindeoptimizarlaspropiedadescomunes.

Jerarquizacin de clases por niveles de abstraccin.

Existen varias metodologas orientadas a objeto; entre las ms utilizadas se tienen a las siguientes:

Tabla 5 Diferentes mtodos de desarrollo de software orientado a objetos

SIGLAS MTODO

RDD Responsibility-Driven Design

CRC Tarjetas Clase-Responsabilidad-Colaboracin

OOAD Object-Oriented Anlisis and Design

OOD Object-Oriented Design

OMT Object Modeling Tecbnique

OOSE Object Oriented Software Engineerine

OOK/MOSES Object-Oriented Knowledge

OOSA Object-Oriented System Analysis

OBA Object Behavior Analysis

DORA Object-Oriented Requirements Analysis

Synthesis Synthesis Method

OOSD Object Oriented System Development

OOAD/ROSE Object-Oriented Analysis & Design

FUSION Object-Oriented Development

UP Unified Software development Process

Nota:TomadodeWeitzenfeld,2004.

29



Elprocesounificadodedesarrollodesoftware(UnifiedSoftwareDevelopmentProcess)deIBM,hoyendadenominadoRUP(RationalUnifiedProcess),juntoconelLenguajeUnificadodeModelado(UML),son la metodologa estndar ms utilizada para el desarrollo de anlisis, diseo e implementacin de software.ElRUPesunprocesoquepresentaunconjuntodeactividadesconunasecuenciapredefi-nida, mientras que UML es un lenguaje de modelado.

3.1. Rational Unified Process (RUP)

Aplica lasmejoresprcticasde losdiferentesmodelosdeprocesosdesoftware,yseadaptaaproyectos de diversas envergaduras. IBM comercializa el producto, el mismo que ofrece una am-plia base de conocimientos como guas y plantillas basadas en el UML; esto permite estandarizar losdiagramasdeldesarrollodesoftwarey,dependiendodelproyecto,aplicarlosnecesarios.IBMdefineelRUPas:

IBMRationalUnifiedProcess,oRUP,es unaplataformadeprocesodedesarrollodesoftwareconfigurablequeentregamejoresprcticascomprobadas yunaarquitecturaconfigurable.

Le permite seleccionar y desplegar solamente los componentes de proceso que usted necesita para cada etapa de su proyecto.

LaplataformaRUPincluye(IBM,s/f):

HerramientasparaconfigurarRUPparalasnecesidadesespecficasdesuproyecto.

Herramientas para transformar sus propios conocimientos internos en componentes del proceso.

Herramientaspotentesypersonalizablesdedesplieguebasadasenweb.

Una comunidad online para intercambio de mejores prcticas con pares y lderes del mercado.

Las fases del RUP se describen en dos dimensiones segn lo siguiente:

30

Organization along time

Organizacinalong content

Core ProcessWorkflows

Core SupportingWorkflows

Business Modeling

Inception

PreliminaryIterations

iter#1 iter#2 iter#n iter#n+1 iter#n+2 iter#m iter#m+1

TransitionElaboration Construction

Configuration &Change Management

Project Management

Environment

Requirements

Analysis & Design

Implementation

Test

Deployment

PHASES

ITERATIONS

Figura 19:Grficodelmodeloiterativo.Fuente:RationalSoftware,1998.

Lafigura19muestradosperspectivasdelmodelo:

Perspectiva dinmica: se muestra en el eje horizontal, representa el tiempo y se expresa en trminos de ciclos, fases, iteraciones e hitos.

Perspectiva esttica: se muestra en el eje vertical, se expresa en trminos de actividades, artefactos,trabajadoresyflujosdetrabajo.

Asimismo,sepuedeobservarquecadaunadelasfasesconcluyeenunhito,porloquelaplanifi-cacindeproyectosestpresentedesdelasetapastempranasdeldesarrollodelsoftware.RUP muestra el ciclo de vida del producto en cuatro fases:

Inicio:enestafaseseestableceelcasodenegocio,seidentificanentidadesexternas(ac-tores)conlasqueinteractuarelsistema;asimismo,eltipodeinteraccinencadacaso.

Elaboracin: en esta fase se analizan los requisitos funcionales y no funcionales estable-cindoseelalcancedelsistema,ysedefinelaarquitecturadelsistema;asimismo,elplande proyecto y lista de riesgos del proyecto. En esta fase, de ser necesario, se elaboran pruebas de concepto que muestren la viabilidad del proyecto.

Construccin:enestafasesecomplementaeldiseo,sedesarrollaeintegraelsoftware,se elaboran los manuales de usuario y el documento de pase a produccin; asimismo, setrabajanlaspruebasinternas.Lafinalidaddeestafaseestenerunproductooperativoparaelusuariofinal.

Transicin:enestafasesedespliegaelsoftwareenunaambientesimilaraldeproduccinyseefectanlaspruebasnecesariasparaobtenerunaversinfinaldelsoftware.Aqu,sepuedenidentificar incidenciasquedebensercorregidasygenerarnuevasversionesdelproducto.

31



Major Milestones

Inception Elaboration Construction Transition

Time

Figura 20:Fasesehitosprincipalesdelproceso.Fuente:RationalSoftware,1998.

3.2. Lenguaje Unificado de Modelado (UML)

ELUMLestrespaldadoporelOMG(ObjectManagementGroup),encargadodelmantenimientodeestndaresynuevasversionesdel lenguajeunificado.UMLproporcionadiagramasquees-quematizanlosrequisitosfuncionalesentrminostcnicosquefacilitaneldesarrollodelsoftware.Dichosdiagramasseclasificanjerrquicamentesegnlosiguiente:

Diagramas de estructura: hacen referencia a los elementos del sistema.

o Diagrama de clases

o Diagrama de componentes

o Diagrama de objetos

o Diagramadeestructuracompuesta(UML)

o Diagrama de despliegue

o Diagrama de paquetes

Diagramas de comportamiento e interaccin: hacen referencia a las interacciones del sistema.

o Diagrama de actividades

o Diagrama de casos de uso

o Diagrama de estados

o Diagrama de secuencia

o Diagrama de colaboracin

o Diagramadetiempos(UML)

o Diagramadevistadeinteraccin(UML)

Acontinuacin,sedetallanlosdiagramasmsusadoseneldesarrollodelsoftware.

3.2.1. Diagrama de clases

En este diagrama se muestran las clases de un sistema y la interrelacin entre ellas. Se les denomi-na estticos porque las clases se denotan junto con sus mtodos y atributos.

32

AutosModelo de auto

Modelo de motor

Velocidad

MarcaAcelerar()

Girar()

Desacelerar()

Figura 21:Ejemplodemodelodeclase.Fuente:Wong,2017.

Las clases se denotan en tres partes: la primera muestra el nombre de la clase; la segunda, los atributos; y la tercera, las acciones.

EnelejemplotenemoslaclaseAutos,acontinuacinsusatributosy,finalmente,lasacciones,lascuales,alfinaldecadaunadeellas,muestranunparntesis,yaquerepresentanfuncionesquedevuelven valores.

3.2.2. Diagrama de casos de uso

Estediagramadescribelasaccionesquesedanentreelsistemaylasentidadesexternas(actoresosistemas);sedescribenlasactividadesfuncionalmenteparaunmejorentendimientodelusuariofinal.Muestralosescenariosprincipalesyalternativosdelsistema.La notacin de los casos de uso es la siguiente:

Tabla 6 Notacin de los casos de uso


Caso_de_usoCaso de uso: representa la funcin del sistema.

Actor: representa a la entidad externa del sistema.


A continuacin, se muestra un ejemplo de diagrama de caso de uso de un sistema de Biblioteca en donde hay tres actores y cuatro casos de uso.

33



Usuariode la biblioteca

Personalde la biblioteca

Bsquedade artculos

Impresinde artculos

Administracinde usuarios

Serviciosdel catlogo

Figura 22:Ejemplodecasodeuso.Fuente:Sommerville,2005.

3.2.3. Diagramas de secuencia

Muestra la interaccin de objetos en el sistema y en el tiempo, y los mensajes que se transmiten entreobjetos.Adiferenciadelcasodeuso,quemuestraelescenariodelflujoprincipalyescena-rios alternativos del sistema, el diagrama de secuencia muestra el detalle del escenario a nivel de actividades.

34

ATMBase

de datos

Validar tarjeta

Tratar peticin

Completartransaccin

TarjetaNmero de la Tarjeta

Peticin de saldo

Cagar (cantidad)

Tarjeta OK

Saldo

Respuesta de la carga

PIN

Peticin de cantidad

Cantidad

Tarjeta extrada

Dinero retirado

Peticin de cantidad

Tarjeta

Dinero

Recibo

Peticin de PIN

Opciones del men

tarjeta no vlida

insuficiente dinero

Figura 23: Ejemplo de diagrama de secuencia de retiro de dinero de cajero automtico. Fuente:Sommerville,2005.

El tiempo es representado en forma vertical, cada interaccin se incrementa hacia abajo, y los mensajesseremitenentrelosobjetosmedianteflechas.

35



Lectura seleccionada n. 1SWEBOK V3.0. (SWEBOK Guide). Leercaptulo5SoftwareMaintenanceapartado1,2y3,pp.5-1a5-8.165.

Bourque,P.,&Fairley,R.(2014).SWEBOK V3.0. Guide to the Software Engineering Body of Knowle-dge.NewJersey:IEEE.Disponibleenhttp://bit.ly/2zcSdFX

Actividad n. 1Foro de discusin sobre el modelamiento de datos.

Instrucciones:

Ingrese al foro y participe con comentarios crticos y analticos del tema Modelos de siste-mas.

Lea y analice el tema n. 1 y 2 del manual Responda en el foro a las preguntas acerca del modelado de sistemas:

Cul es propsito del modelamiento de sistemas? Cul es la relacin que existe entre el modelamiento de sistemas y el modelamiento

de datos?

36

Fundamentos del anlisis

Tema n. 3

El modelo de anlisis debe cumplir lo siguiente:

Describir las necesidades del cliente. Establecerlabaseparaeldesarrollodeunanlisisfuncionalydiseodesoftware. Definirlasreglasfuncionalesynofuncionalesquepodrnservalidadasporelusuarioalculmi-

nareldesarrollodesoftware.

El anlisis describe a nivel de sistema lo siguiente:

Describe el modelo de negocio, transformndolo en requisitos de sistemas que detallan la fun-cionalidadnecesariaparaeldesarrollodesoftwareybasededatos.

Sedesarrollanlosdiferentesdiagramasespecificadosenelmodeloestructuradooenelmo-delo orientado a objetos; asimismo, los diagramas de datos que servirn de base para el de-sarrollo del sistema.

Seelaboranlasinterfacesdelsistemaconbaseenlosestndaresespecificadosdelaorga-nizacinaniveldediseo.Serecomiendaquelasmismasseanvalidadasporelusuariofinalantes de su desarrollo.

Detallalaarquitecturaaniveldeaplicacindesoftwareydatos.Asimismo,eldesarrolloy/oconsumo de servicios.

Modelo deNegocio

Modelo deAnlisis

Modelo deDiseo

Figura 24:Anlisisdesoftware.Fuente:Wong,2017.

Debe considerarse que la participacin activa del usuario en la etapa de anlisis es sumamente importante, ya que constituye una garanta de la captura adecuada de que los requerimientos fun-cionalesynofuncionaleshansidoidentificadosydescritosdemaneracorrecta.Laaprobacindeldocumento de anlisis por el usuario garantiza un adecuado desarrollo futuro de la aplicacin.

1. Modelado basado en escenarios

ParaelmodelamientodelanlisisdeescenariosgeneralmenteseutilizaUML(UnifiedModelingLan-guage),queeslatcnicaempleadapordefectoenelmodelamientodeentregables.Aqusetraba-ja con los diagramas de casos de uso y diagramas de actividades.

2. Modelado orientado al flujo

Enestetipodemodeladoseutilizaeldiagramadeflujodedatos,quedetallaelflujodelsistemaanivel de procesos. Cabe mencionar que este tipo de diagrama toma como base el diagrama de contextoydesarrollaamayordetallelasfuncionalidadesdescritasdecadanivel.Eldiagramadeflujode datos tambin puede complementar a los diagramas UML.

37



3. Modelado basado en clases

Estaactividadiniciaconeldesarrollodelcasodeuso;apartirdeellosedefinelalistadeobjetosquesern denominados como clases del sistema.

Inicialmente, probablemente no se puedan determinar todas las clases; sin embargo, durante el desa-rrollodelanlisisydiseosepodrirafinandoestaidentificacindemaneramsprecisa.Sedefinenlas siguientes clases:

Clasesdeentidad:serefierenalalosdatosdelsistemayqueseidentificanenloscasosdeuso. Clasesdeinterfacedeusuario:muestralainteraccinconelusuariofinal. Clasesdecontrol:muestralastransaccionesycontroldelosobjetosdefinidosenloscasode

uso.

Lectura seleccionada n. 2Wiegers,K.,&Beatty,J.(2013).Software Requirements(3aed.).Washington:MicrosoftPress.Dis-

ponible en http://bit.ly/2ghNk6M

Actividad n. 2Foro de discusin sobre fundamentos de anlisis.

Instrucciones:

Ingrese al foro y participe con comentarios crticos y analticos del tema modelos de sistemas.

Lea y analice el tema n. 3 del manual.

Responda en el foro a las preguntas acerca del modelado de sistemas:

1. Cul es el propsito del modelamiento de anlisis?

2. Cules consideras que son las tcnicas de modelamiento ms utilizadas en la fase de anlisis? Por qu?

38

Tarea acadmica n. 1Genereuncasodeusodeunsistemadeventas,ysusflujosalternativosconsiderandolosiguiente:

El supermercado Ventas Rpidas requiere vender sus productos y llevar un control de sus ventas; los productos pueden venderse directamente en las cajas de los supermercados en efectivo o mediante tarjeta de crdito Visa o Mastercard. Asimismo, el cliente puede solicitar un deliverydeproductosmediantelapginawebdelsupermercado.Enesteltimocaso,elclientedebeefectuarelpagodirectamentevawebcontarjetaVISAoMastercardantesdeque se programe el envo del producto. Para que los clientes puedan efectuar compras por delivery deben estar registrados previamente en la base de datos del supermercado.

Enunciado

Complete el documento de Plantilla de casos de uso.

1. Nombre del caso de uso del sistema2. Descripcin del caso de uso

3.Actor(es)

[Actores que interactan con el caso de uso.]

4. Precondiciones[Condiciones previas a la realizacin del caso de uso.]

5. Poscondiciones[Consecuencias luego de la realizacin.]

6a. Flujo principal [Pasos que describen la realizacin del caso de uso. Empieza con la primera accin del actor y el sistema emitir una respuesta]

N. Accin del actor Respuesta del sistema123..

6b. Flujo alternativo [Pasos que describen la realizacin del caso de uso alternativo]N. Accin del actor Respuesta del sistema123..

7.Requisitoasociado(funcional,nofuncional)

8. Prototipo de interfaz de usuario

39



I. Rbrica

n Rbrica Descripcin Min. puntaje Mx. puntaje

1 Documento El trabajo escrito debe presentar to-das las pautas expuestas. 0 15

2 VideoArchivo de texto donde se encuen-tra la URL del video en Youtube, don-de se explican los casos de pruebas.

0 5

II. Indicaciones

Todos los puntos de la rbrica debern ser subidos a la plataforma en formato ZIP y como nombre del archivo debern tener el siguiente formato: APELLIDO_NOMBRE.zip

Encasodeplagio,eltrabajoserinvalidadoylanotaserde00. Cualquier duda, consultar al docente por el foro de consultas

40

Glosario de la Unidad IA

Atributo: Algunas caracterticas de una entidad. Puede haber muchos atributos en una entidad (Kendall&Kendall,2011).

C

Caso de uso:Especificacindeuntipodeinteraccinconelsistema(Sommerville,2011).

Clase: Una plantilla comn para un grupo individual de objetos con atributos comunes y compor-tamientocomnenelanlisisydiseoorientadoaobjetos(Kendall&Kendall,2011).

D

Diagrama de secuencia: Diagrama que muestra la secuencia de interacciones necesarias para completar alguna operacin. En UML, los diagramas de secuencias se pueden asociar con los casosdeuso(Sommerville,2011).

E

Escenario: Modelo de anlisis que describe una serie de acciones o tareas que responden a un evento.Cadaescenarioesuna instanciadeuncasodeuso (International Instituteof BusinessAnalysis,2009).

M

Modelo del ciclo de vida: Marco de referencia que contiene los procesos, actividades y tareas involucradaseneldesarrollo,operacinymantenimientodeunproductodesoftwareyqueabar-catodalavidadelsistemadesdeladefinicindesusrequerimientoshastaelfinaldesuuso(Inde-copi,2006).

O

Objeto: En el enfoque orientado a objetos, un objeto es una representacin por computadora de algoocosadelmundoreal;puedeteneratributosycomportamientos(Kendall&Kendall,2011).

R

Requerimiento: Una condicin o capacidad requerida por una parte interesada para resolver un problema o alcanzar un objetivo. Una condicin o capacidad que debe cumplir un componente desolucino solucinpara satisfaceruncontrato,norma,especificacin,uotrosdocumentosformalmenteimpuestos(InternationalInstituteofBusinessAnalysis,2009).

U

UML (Unifed Modeling Language): Proporciona un conjunto estandarizado de herramientas para documentarelmodeloorientadoaobjetosenelanlisisydiseodeunsistemadesoftware(Ken-dall&Kendall,2011).

41



Bibliografa de la Unidad IArisholm,E.,Gallis,H.,Dyba,T.,&DagI.K.Sjoberg.(2007).Evaluatingpairprogrammingwithres-

pect to system complexity and programmer expertise. IEEE Transactions on Software Engi-neering, 33(2),65-86.Disponibleenhttp://ieeexplore.ieee.org/document/4052584/

Bourque,P.,&Fairley,R.(2014).SWEBOK V3.0. Guide to the Software Engineering Body of Knowle-dge.NewJersey:IEEE.Disponibleenhttp://bit.ly/2zcSdFX

IBM(1998),RationalUnifiedProcessBestPracticesforSoftwareDevelopmentTeams.Recuperadode https://www.ibm.com/developerworks/rational/library/253.html

IBM. (s/f). Plataforma para desarrollo de software. Lima: autor. Disponible en https://ibm.co/2y5q05Bhttps://www-01.ibm.com/software/pe/rational/rup.html

Kendall,K.&Kendall,J.(2013).Systems analysis and design(9aed.).NewYersey:PrenticeHall.

Pressman, R. (2005). Ingeniera del Software. Un enfoque prctico (6a ed.). D.F., Mxico:Mc-Graw-Hill.

Sommerville,Ian.(2011).Software Engineering(9aed.).Madrid:PearsonEducation.

Wiegers,K.,&Beatty,J.(2013).Software Requirements(3aed.).Washington:MicrosoftPress.Dis-ponible en http://bit.ly/2ghNk6M

42

Autoevaluacin n.o 11. Marque la respuesta correcta: Cmo se le llama a la persona que es duea del modela-

mientodesistemas,anlisisydesarrollodesoftware?a)Clienteb)Propietarioc) Usuariod)Proveedore)Analista

2. Seleccione la alternativa correcta en relacin con los tipos de modelos de sistemas.a)Modelo de contexto b)Modelo de base de datosc)Modelo de diseod)Modelo de algoritmose)Modelo de anlisis

3. Seleccione la alternativa correcta en relacin con los tipos de modelo de datos:a) Flujo de datosb)Relacionalc) Base de datosd) Entidadrelacine)Atributos

4. La creacin de escenarios en qu fase del ciclo de vida se utiliza?Seleccione la alternativa correcta.a)Diseob)Programacinc)Anlisisd)Calidade) Pase a produccin

5. Seleccionelaafirmacincorrectaenrelacinconelmtodoestructurado:a)Proporciona un marco para el modelado detallado de sistemas como parte de la elicita-

cin y anlisis de requerimientos.b)Muestra una perspectiva funcional en donde cada transformacin representa un nico

proceso o funcin.c) Se utilizan para describir el comportamiento del sistema en su totalidad.d)Describe cmo responde un sistema a eventos internos o externos.e)Muestra las entidades de datos, sus atributos asociados y las relaciones entre estas entida-

des.

43



Seleccione la alternativa correcta.

6. Cul es la diferencia entre el modelo relacional y el modelo entidad-relacin?. a) La diagramacin del modelo relacional es mediante entidades y atributos, la diagrama-

cin del modelo entidad-relacin es mediante tablas.b) La diagramacin del modelo relacional es mediante entidades y atributos, la diagrama-

cin del modelo entidad-relacin es mediante datos.c) La diagramacin del modelo relacional es mediante tablas, la diagramacin del modelo

entidad-relacin es mediante entidades y atributos.d) La diagramacin del modelo relacional es mediante cardinalidades, la diagramacin del

modelo entidad-relacin es mediante datos.e) La diagramacin del modelo relacional es mediante entidades, la diagramacin del mo-

delo entidad-relacin es mediante una base de datos.

7. Un escenario es parte de:a)Caso de usob) Entidadc)Atributod) Especificacine) Requerimiento

8. Muestra la relacin entre los actores y el caso de uso:a)Diagramadeflujob)Diagrama de secuenciac)Diagrama de clasesd)Diagrama de caso de usoe)Diagrama de estado

9. Muestra los objetos que participan en la interaccin y la secuencia de mensajes que inter-cambian:a)Diagramadeflujob)Diagrama de secuenciac)Diagrama de clasesd)Diagrama de caso de usoe)Diagrama de estado

10.Las cardinalidades de un modelo relacional o entidad-relacin pueden ser:a) 2 tiposb) 3 tiposc) 4 tipos d) 5 tipose) 1 tipo

45



UNIDAD II ELICITACIN DE REQUERIMIENTOS

DIAGRAMA DE PRESENTACIN DE LA UNIDAD II

CONTENIDOS EJEMPLOS ACTIVIDADES

AUTOEVALUACIN BIBLIOGRAFA

ORGANIZACIN DE LOS APRENDIZAJESRESULTADO DE APRENDIZAJE: Alfinalizarlaunidad,elestudiantesercapazdeelicitarlosrequerimien-tosdesoft-wareparasuproyecto.

CONOCIMIENTOS HABILIDADES ACTITUDESTema n. 1: Fundamento de los requerimientos1. Anlisis de negocio2. Ingeniera de requisitos

2.1. Inicio2.2. Obtencin

2.2.1. Problemas de mbito2.2.2. Problemas de comprensin2.2.3. Problemas de volatilidad

2.3. Elaboracin2.4. Negociacin2.5. Especificacin2.6. Validacin2.7. Gestin de requisitos

Tema n. 2: Origen de los requerimientos1. Definicinderequisito2. Esquemadeclasificacinderequisitos

2.1. Requisitos de negocio2.2. Requisitos de partes interesadas2.3. Requisitos de la solucin

2.3.1. Requisitos funcionales2.3.2. Requisitos no funcionales

3. Requisitos de transicin

Lectura seleccionada n. 3BABOK Guide v2.0(pp.99-117).

Tema n. 3: Tcnicas de elicitacin de requerimientos1. Tormentadeideas(Brainstorming)2. Anlisis de documentos3. Focus group4. Anlisis de interfaces5. Entrevistas6. Observacin 7. Prototipos8. Talleres de requisitos9. Encuestas/cuestionarios10.Tcnicas grupales de toma de decisiones11. Estudios comparativos

Lectura seleccionada n. 4Definicin de perfiles en herramientas de gestin de re-quisitos(Mcdonald,2005).

Autoevaluacin de la Unidad II

1. Administrar la obtencin de los requerimientos de software.

Actividad n. 1Los estudiantes participan en el foro de discusin sobre modelos de sistemas y modelos de anlisis.

Tarea acadmica n. 2

1. Concuerda con su equi-po de trabajo la prioriza-cin de los requerimien-tosdesoftware.

46

Fundamento de los requerimientosTema n. 1

En el siguiente captulo, usted comprender los diferentes conceptos de anlisis de negocio, ingenie-ra de requisitos y tcnicas de elicitacin, que servirn de base para la obtencin de requerimientos de la fase inicial del ciclo de vida.

Losrequerimientosdesoftwaresurgendelanecesidaddeautomatizacindeunprocesomanual;sin embargo, muchas veces a pesar de que el usuario sabe y conoce su proceso, trasladar su idea a unproductodesoftwaretomamuchotiempo;porello,comopartedelciclodevidadeldesarrollodelsoftwaresehangeneradoalgunasramasdeespecializacin,talescomoelanlisisdenegocioylaingenieraderequisitos,lascualesseorientanaobtenerunadefinicinconcretadelanecesidaddelusuarioparaluegoprocesarlaygenerarunproductodesoftwarequecubralasexpectativasdelcliente.Acontinuacin,mostraremoseldetalledeestasdefiniciones.

1. Anlisis de negocio

ElInternationalInstituteofBusinessAnalysis(2009)definelosiguienteenrelacinconelanlisisdene-gocio:

El anlisis de negocios es el conjunto de tareas y tcnicas utilizadas para trabajar como enlace entrelaspartesinteresadasafindecomprenderlaestructura,laspolticasylasoperacionesde una organizacin y recomendar soluciones que permitan a la organizacin alcanzar sus objetivos(p.3)

El anlisis de negocio consigna el desarrollo del modelo de proceso del negocio. En esta fase, el analista de negocios busca un entendimiento del negocio de la organizacin; no considera an el re-querimiento en s, solo busca conocer el sector de negocio que, por ejemplo, puede ser banca, retail, telecomunicaciones, gobierno, minera, entre otros; luego buscar comprender con ms detalle el reaquenecesitaunamejoraydefinirelrequerimientoespecficoporautomatizar.Elconocimientodel negocio implica conocer a la organizacin, cmo funciona, cul es su meta, visin, qu productos ofrece,fortalezasydebilidades.Asimismo,quinessonlosusuariosfinalesdelosproductososerviciosycanalesdecomunicacin.Siconsideramosquehoyendalasredessocialesylasaplicacioneswebymviles han cobrado mayor relevancia, el canal de comunicacin hacia el cliente es un factor crtico que debe ser analizado por el analista de negocios.

Enalgunasocasiones,lasmetas,objetivosovisindelaorganizacinnoseencuentranbiendefinidos,loquedificultaeltrabajodelanalistadenegocio.Todaaccindemejoraidentificada,indicadoresde desempeo, debe estar alineada con las metas y objetivos de la organizacin, por lo cual a veces esta es la primera tarea del analista de negocio.

Lasoportunidadesdemejoraidentificadasdentrodelasunidadesdenegociodebenestaralineadasa los objetivos y metas de negocio de la organizacin; en ese sentido, los directivos tomarn las deci-siones para la priorizacin de requerimientos de automatizacin.

ElInternationalInstituteofBusinessAnalysis(IIBA)eslaasociacininternacionalquemantieneelestn-dardemejoresprcticasparalaejecucindeanlisisdenegocios,tienemsde29000miembrosanivelinternacional,proveeunacertificacinparatodoslosprofesionalesquedeseenespecializarseen anlisis de negocios, y provee una Gua, que es el BABOK, en donde se pueden visualizar todas las mejores prcticas. Asimismo, tiene una comunidad que apoya y colabora activamente para enrique-cer esta gua.

47



Project Management Institute, una de las organizaciones ms grandes de profesiones de direccin de proyectos, dentro de sus prcticas incluye un rea de proceso de recopilacin de requisitos, la misma que difunde las mejores prcticas para la obtencin de requisitos desde etapas tempranas. Incluye, entre ellas, herramientas que ayudan a la elicitacin de requisitos y recalca la importancia de las mis-maseneldesarrollodelosproyectosydelosproductosdesoftwarequesegenerencomopartedelas mejoras propuestas en la organizacin. Asimismo, hace nfasis en la alineacin estratgica que debe existir entre las oportunidades de mejora y los objetivos estratgicos de la organizacin.

PlaneacinEstratgica

Reqs. del Negocio

Reqs. del Usuarios

Reqs. del Solucin

Reqs. del Sistemay/o Proceso

Identificacin delProblema oNecesidad de Negocio

Traz

abilid

ad Definicin de la Necesidad de Negocio

Definicin de la Solucin de Negocio, Proceso y/o Solucin de TI

Diseo del Proceso y/o Solucin de TI

Figura 25:Anlisisdenegocio.Fuente:Almeida,2012.

Elgrficodescribe laperspectivade lagestindeanlisisdenegociospara lageneracindede-finicionesde solucionesde TI. Tambin,muestracmo todos los requisitos, desde las unidadesdenegociohastaelsoftwaregenerado,debenobedeceralosobjetivosplanteadosenlaPlaneacinestratgica organizacional.

2. Ingeniera de requisitos

La ingeniera de requisitos ayuda a plasmar los requisitos funcionales de los usuarios en diagramas tcnicosquepermitanalosanalistasyprogramadoresdesoftwareunmejorentendimientodelpro-ductodesoftwarequetienenquedesarrollar.Enestaprimeraetapa, losdiagramasdecontextoydiagramasdeflujodedatossonlosprimerosporelaborarparapoderlograrunentendimientoconelusuario de lo que se requiere.

48

Laingenieraderequisitosconstituyelafaseinicialdeldesarrollodesoftware,puesayudaagenerarlasespecificacionespreliminaresparataldesarrollo.

En esta primera etapa pueden elaborarse incluso pruebas de concepto preliminares para evaluar latecnologaporaplicarylafactibilidaddecontinuarconeldesarrollodelsoftware.Igualmente,seaplican tcnicas de experiencia de usuario para que el usuario en esta primera etapa conozca a alto nivel cmo quedarn sus interfaces. El riesgo en esta etapa es la indecisin del usuario, pues si an nosabeconcretamenteloquequiereotienemuchadificultadparatomardecisiones,estaetapapuede tomar mucho tiempo.

Pressman(2005)precisaque

La ingeniera de requisitos se lleva a cabo a travs de siete funciones que en algunos casos pueden ejecutarse de manera paralela, sin embargo las mismas se adaptarn a la metodo-logaautilizarporlaorganizacinyalanecesidaddelproyecto,lafinalidadesdefinirclara-mentelanecesidaddelusuariofinaldemodoquepuedadesarrollarseadecuadamenteunanlisis,diseoyconstruccinquereflejeloqueelusuariosolicit(p.157).

LasfuncionesquedefinePressmansemuestranenelsiguientegrfico:

Validacin

Especificacin

Obtencin

Elaboracin

Gestin

Inicio

Negociacin

Figura 26:FuncionesdelaingenieraderequisitossegnPressman.Fuente:Wong,2017.

2.1. Inicio

Lamayoradeproyectos inicianconla identificacindeunanecesidaddenegocio,mercadonuevo o servicio potencial. Luego de haber comprobado la factibilidad del proyecto, el personal funcional y tcnico del proyecto efecta preguntas libres al cliente con el objetivo de obtener una comprensin bsica del problema y establecer una solucin de alto nivel; esta puede constituir la primera comunicacin con el cliente.

49



2.2. Obtencin

Selistanlosproblemasquedificultandelaobtencindelosrequisitos;enesesentido,seclasificancomo problemas de mbito, de comprensin y volatilidad.

Problemas de Comprensin

Problemas de mbito

Problemas de Volatilidad

Obtencin de Requisitos

Figura 27:Problemasdelaobtencinderequisitos.Fuente:Wong,2017.

A continuacin, se detallan cada uno de ellos:

2.2.1. Problemas de mbito

Secatalogandeestamaneracuandoelalcancedelsistemanoestbiendefinido;losusuarioshacen referencia a diferentes temas sin establecer claramente los lmites del sistema. En este caso, esnecesarioqueelanalistaestablezcaloslmitesmediantesupuestosyrestricciones,definiendoaquello que ser parte del sistema y aquello que no ser parte del sistema.

2.2.2. Problemas de comprensin

Elusuariofinalnosabeconcretamenteloquenecesita,notieneconocimientodeelementostec-nolgicos, es muy funcional. Tambin entran en esta categora los usuarios que no saben transmitir claramente sus necesidades o la indican a muy alto nivel porque no disponen de mucho tiempo; por tanto, omiten informacin necesaria para el desarrollo del sistema. Existen usuarios que tam-binespecificanrequisitosquecorrespondenaotrasunidadesdenegociooaotrossistemassinuna coordinacin previa a nivel funcional.

50

2.2.3. Problemas de volatilidad

Existen casos en donde los usuarios por cada sesin de relevamiento de informacin en lugar de complementar,modificanlainformacinantesprecisadaparaeldesarrollodelsistema;portanto,esnecesarioqueseconcretenactasdetrabajoendondeseespecifiquenlostemastratadosyacuerdos.Estaactividadtambinsepuededificultarcuandolosusuariosfuncionalescambiandeuna reunin a otra; por ello, es necesario que se solicite la interaccin con un usuario represen-tativoquepuedaexpresarlasnecesidadesdelaunidad,organizacionesyverifiqueelproductoculminado.

2.3. Elaboracin

En esta etapa se desarrolla el diseo tcnico y las reglas de negocios, se acota el alcance, y se definenlasrestriccionesdelsoftware.Asimismo,seelaboranlosescenariosylosflujosprincipalesyalternativosdelsoftware.EstaetapapuedesersoportadaporlosdiagramasdescritosenelUML.

2.4. Negociacin

Resultacomnquedurantelaespecificacinydesarrollodesoftwareseencuentrenmuchosin-teresados en el proyecto y cada uno de ellos con una visin y perspectiva diferente del desarrollo del requerimiento, razn por la cual se deber conciliar con los interesados y solicitar aprobadores especficosdenivelfuncionalytcnico;conellossedebernevaluarlosriesgos,estimacionesdeproyecto, costos y plazos de entrega.

2.5. Especificacin

Algunosautoressugierenqueeldesarrollodelaespecificacindelrequerimientodebeserplas-madoenunaplantillaestndar;sinembargo,lacapturadelaespecificacinderequerimientosdebeserflexibleysedebenaplicarlastcnicasdeelicitacinnecesariasafindelograrunenten-dimientoentrelosanalistasdesistemasyelusuariofinal.Entodosloscasoslasbuenasprcticasrefierenaldesarrollodegrficosfuncionalesquepermitanalusuariovisualizardemaneragrficasu proceso y validarlo. Igualmente, el desarrollo de prototipos le permitir visualizar de manera anticipada las interfaces del sistema solicitado.

2.6. Validacin

Refiereaunaactividaddecalidadquerevisalasespecificacionesdelosrequisitosdelsoftware.Estaetapasirveparavalidarpreviamentesi los requisitoscumplencon lasespecificacionesdelusuario. Si producto de esta revisin se detectan no conformidades, la validacin deber revisar si lasmismashansidolevantadas,antesdeiniciarelprocesodedesarrollodelsoftware.Muchasve-ces este proceso de validacin de los productos de trabajo es efectuado por el lder del proyecto yluegoporelusuariofinal;conelloseestableceelcompromisodequeeldesarrollocontemplartodo aquello que ha sido solicitado por el cliente.

2.7. Gestin de requisitos

Losrequisitosdeunsistemapuedenvariar,sepuedeampliar,reduciromodificarelalcanceinicial,razn por la cual es necesario establecer una bitcora de cambios de los mismos, ya que durante todoelciclodevidadeldesarrollodelsoftware,estepuedesufriralteraciones.

51



Origen de los requerimientos

Tema n. 2

Losrequerimientosdesoftwarenacenarazdeunanecesidaddeunaautomatizacin,enlamayorade los casos se describe una regla funcional a alto nivel y se describe una idea de manera global. Con lafinalidaddedefiniramayordetallelosrequerimientos,sedescribenmediantereglasdenegociosy,en muchos casos, se hacen uso de los diagramas de procesos para que el personal de desarrollo pue-daentenderconunmayorniveldedetallelasespecificacionesfuncionales.Elpersonaldesistemases el encargado de trasformar los requerimientos funcionales en requerimientos de sistemas y, de esta manera,generarunnivelmstcnicodeespecificacionesparaeldesarrollodelsoftware.

1. Definicin de requisito

ElInternationalInstituteofBusinessAnalysis[IIBA](2009)defineeltrminorequisito segn lo siguiente:

The termrequirement isone thatgeneratesa lotofdiscussionwithin thebusinessanalysiscommunity.Manyofthesedebatesfocusonwhatshouldorshouldnotbeconsideredare-quirement,andwhatare thenecessarycharacteristicsofa requirement.When readingtheBABOKGuide,however,itisvitalthatrequirementbeunderstoodinthebroadestpossiblesense. Requirements include, but are not limited to, past, present, and future conditions or ca-pabilities in an enterprise and descriptions of organizational structures, roles, processes, policies, rules, and information systems. A requirement may describe the current or the future state of anyaspectoftheenterprise.(p.005).

Muchos autores que escriben en relacin con el anlisis de negocios, precisan que los requisitos ha-cen referencia al desarrollo de un sistema de informacin; otros indican que se deben incluir funciones empresarialesfuturas.Loimportanteesdefinirespecficamentelamejora,lacualpuedeconsiderarel perfeccionamiento de un proceso, el desarrollo de sistema, una automatizacin, entre otros. En el caso de que se considere una mejora tecnolgica, es importante tener en cuenta la evolucin de la misma y el tiempo de vida de la solucin, pues con el constante cambio tecnolgico actual, puede ser que cuando la solucin salga al mercado ya sea obsoleta; por tanto, los cambios tecnolgicos implicarn acciones a corto plazo.

2. Esquema de clasificacin de requisitos

ElIIBAmuestralasiguienteclasificacinparadescribirlosrequisitos:

Requisitos de negocio Requisitos de las partes interesadas Requisitos de la solucin Requisitos de transicin

Laclasificacinderequisitosconsideradiferentesenfoquesporqueesnecesariocubrirtodaslaspers-pectivas de lo requerido por el usuario y, de esta manera, poder generar una propuesta adecuada (p.5).

A continuacin, se detallan cada uno de ellos:

2.1. Requisitos de negocio

Se describen a alto nivel las necesidades de la organizacin, sus metas y objetivos. Esto implica precisar los antecedentes y objetivos del proyecto, indicadores de desempeo de gestin y ope-racin para el seguimiento del proyecto.

52

Algunos de los requisitos de negocio son:

o Debemos ser lderes en el mercado en el uso de aplicaciones mviles para las gestiones de nuestras operaciones.

o El40%delasoperacionesgeneradaspornuestrosclientesdebesergestionadapornuestrapginaweb.

2.2. Requisitos de las partes interesadas

Son las declaraciones de las necesidades de un interesado o clase particular de partes interesa-das. Describen las necesidades que tiene un determinado actor y cmo interactan las partes interesadas con la solucin. El anlisis de requisitos describe los requerimientos de dichas partes.

A modo de ejemplo, podemos mencionar dos requisitos de partes interesadas:

o El estatus de contratacin de personal debe ser visualizado por cada una de las unidades de negocio.

o El rea de tesorera debe tener acceso a la informacin de pagos que se generan por rdenes de compra en el rea de logstica.

2.3. Requisitos de la solucin

Describe las caractersticas de una solucin que cumpla con los requerimientos del negocio y los requerimientosdelaspartesinteresadas.Sedesarrollanydefinenatravsdelanlisisderequisitos.Con frecuencia se dividen requisitos funcionales y no funcionales, especialmente cuando los re-quisitosdescribenunasolucindedesarrollodesoftware.

2.3.1. Requisitos funcionales

Describen el comportamiento y los datos que el sistema administrar. Tambin, las capacidades que el sistema podr realizar en trminos de comportamientos o acciones o respuestas de aplica-cindetecnologadelainformacinespecficasdelasoperaciones.

Algunos ejemplos de requisitos funcionales son:

El sistema debe permitir el registro de todos los clientes de la tienda. El sistema debe permitir el registro de las marcas de los productos y el movimiento logstico

del almacn y la tienda. El sistema debe permitir la generacin de la boleta de venta y factura. Generacin del clculo automtico de IGV

2.3.2. Requisitos no funcionales

Este tipode requisitosestn relacionadoscon laoperacindel softwareyhacen referenciaalcomportamiento de la solucin, describen condiciones ambientales bajo las cuales la solucin debe permanecer activa por determinados perodos de tiempo o cualidades que los sistemas de-ben tener a nivel operacional. Los requisitos no funcionales estn relacionados con la capacidad, experiencia de usuario, disponibilidad, velocidad, seguridad y arquitectura de la informacin.

A continuacin se muestran ejemplos de requisitos funcionales:

El sistema debe funcionar en Explorer 7 y 8, tambin en Chrome. Elsistemawebdebetenerdisponibilidadpermanenteparalosusuarios;debeser7x24.

53



Las interfaces del aplicativo mvil deben ser amigables e intuitivas. Elnivelderespuestadelosreportesdelsistemanodebesermayora30segundos.

2.4. Requisitos de transicin

El IIBA describe lo siguiente:

Las capacidades que debe tener la solucin para facilitar la transicin desde el estado ac-tual de la empresa a un estado futuro deseado, pero que no ser necesario una vez que la transicin est completa. Se diferencian de otros tipos de requisitos porque son siempre de naturalezatemporalyporquenopuedendesarrollarsehastaquesedefinenunasolucinnueva y existente. Normalmente cubren la conversin de datos de los sistemas existentes, las brechas de habilidades que deben ser abordadas y otros cambios relacionados para alcanzarelestadofuturodeseado.Sedesarrollanydefinenmediantelaevaluacinyvali-dacindesoluciones(p.006).

Como ejemplos de requisitos de transicin pueden mencionarse los siguientes:

Antesdeejecutarelpaseaproduccinsedebencorrerlosbacheros(sistemasporlotes)de la migracin de datos, ya que sin ellos no se podr tener informacin para efectuar las pruebas de la aplicacin.

El pago de los empleados se hace mediante el servicio de VISA con el banco, por tanto nuestro sistema de recursos humanos debe interconectarse con ese servicio antes de di-fundir al personal al que ya se abon su pago.

La implementacin de la nueva tecnologa implica la capacitacin previa de los desarro-lladores; asimismo el acompaamiento de la empresa para la elaboracin del producto.

Lectura seleccionada n. 3A Guide to the Business Analysis Body of Knowledge(BABOKGuide)v2.0.

Leerelcaptulo6,RequirementsAnalysis,pp.99-120.Disponibleenhttp://bit.ly/2hzVszh

Actividad n. 3Foro de discusin sobre el modelamiento de datos.

Instrucciones:

Ingrese al foro y participe con comentarios crticos y analticos del tema modelos de sistemas.

Lea y analice los temas 1 y 2 del manual.

Responda en el foro a las preguntas acerca de los fundamentos de los requerimientos:

Mencione cuatro requisitos funcionales y dos requisitos no funcionales por considerar en un sistema de biblioteca.

54

Tcnicas de elicitacin de requerimientos

Tema n. 3

La actividad de elicitacin de requisitos constituye una actividad clave dentro del ciclo de vida de desarrollodelproducto;estodebidoaqueeslabaseparaladefinicindelalcancedelamejoraporefectuar dentro la organizacin. El xito de la mejora residir en la participacin activa de los usuarios yenladefinicinasertivadelosrequisitos.

TheInternationalInstituteofBusinessAnalysis(2009)ensuGua de los fundamentos del conocimiento del anlisis del negocio(AGuidetotheBusinessAnalysisBodyofKnowledge:BABOK)mencionalastcnicas de elicitacin ms aceptadas, que reseamos a continuacin.

1. Lluvia de ideas (Brainstorming)

Esta tcnica, segn el PMI, est catalogada como una tcnica grupal de creatividad, es utilizada para generar y recopilar varias ideas relacionadas con un mismo tema. Para efectos de la gestin de requisitos, se utiliza para generar ideas relacionadas con los requisitos del producto para, posterior-mente, profundizar a mayor detalle en el tema. Esta tcnica es efectuada por un facilitador que dirige algrupo.Lassesionespuedenserabiertasoestructuradasconlafinalidadderefinarlasdefiniciones.Esta tcnica no establece orden de prioridades; sin embargo, pueden complementarse con otras tcnicas que s lo hacen.

LLUVIA DE IDEASTODAS LAS IDEAS SE EXPRESAN EN TARJETAS Y SE COLOCAN EN EL PAPELON

LASTARJETASSE ORDENANPOR TEMA

UNA SOLA IDEA POR TARJETA

3 LINEAS MAXIMO - SE DEBE LEER A DISTANCIA

SI:

SI:

NO:

NO:

FALTA DE AGUA

POTABLE

BAJO PRECIODEL MAIZ

TECNICOS EDUACINORGANI-ZATIVOSECONO-MICOS

MEDIO AMBIENTE

PROBLEMAS

FALTADE

LEA

FALTA DE AGUA,LEA NO HAY

CREDITO

PROBLEMAS DE LA COMUNIDAD

Figura 28:Procesodelluviadeideas.Disponibleenhttp://bit.ly/2wDkeVo

55



Elgrficomuestraunprocesodelluviadeideasestructuradoyguiadoporfacilitadores.Seaprecialamotivacin para la generacin de ideas, las reglas de redaccin de las ideas y el ordenamiento para llegar a un consenso de una idea general.

Lalluviadeideasparasuclasificacinpuedecomplementarseconotrastcnicasgrupalesdecrea-tividad, tales como:

Tcnicas de grupo nominal, que mediante la votacin y jerarquizacin seleccionan las ideas ms tiles.

Mapaconceptualomental,queconsolidanlainformacindelalluviadeideas,ylaclasificanen ideasque tienenpuntosencomne ideasque tienendiferencias. Laclasificacin sirvecomo base para la generacin de nuevas ideas pero de manera ms estructurada en su se-gunda iteracin.

Diagramasdeafinidad,queclasificaalasideasdeacuerdoconsusimilitud. Anlisisdedecisionesconmltiplescriterios,queclasificaalainformacinconbaseenuna

serie de criterios.

2. Anlisis de documentos

Esta tcnica involucra el anlisis de la documentacin existente que pueda servir de base para el anlisisderequisitos,sebuscaidentificarinformacinrelevanteparaobtenerrequisitos, involucralarevisin de documentacin de productos similares, planes de negocios, estudios de mercado, con-tratos, solicitudes de propuestas, memorandos, directivas existentes, procedimientos, guas de capa-citacin, entre otros.

El objetivo es obtener la mejor cobertura de los requisitos y, de esta manera, describir correctamente el producto por desarrollar.

3. Focus group

Un grupo focal se genera para intercambiar ideas acerca del producto, servicio o resultado pro-puesto. El grupo es guiado por un facilitador y los participantes son expertos en el tema por tratar, se genera un espacio para discutir del tema y que cada uno exprese su perspectiva basado en su ex-periencia. Tambin pueden participar otras personas pero limitadas solo a observar y no a participar activamente de la sesin.

El facilitador tiene la misin de guiar al grupo para obtener un resultado cualitativo satisfactorio y ge-nerarelinformefinal.

Esta tcnica de elicitacin puede ser utilizada en cualquier fase del ciclo de vida del desarrollo del software,yaseaanlisis,diseo,construccin,pruebasoantesdelpaseaproduccin;enestecasoel tema de discusin del grupo estar relacionado con los requisitos establecidos previamente, con el objetivodeaclarar,modificarelrequisitoexistenteogenerarnuevosrequisitos

4. Anlisis de interfaces

La interfaz es el punto de interconexin entre dos partes del sistema. Los sistemas poseen ms de una interfaz en su desarrollo. Las interfaces se catalogan de la siguiente manera:

Interfacesdeusuario:refierealosusuariosqueinteractanconelsistema,yaseaenelregistrode informacin, operaciones o consulta. A cada interfaz de interaccin se le considera una interface de usuario. Considerando que el usuario tendr un papel relevante en su uso, ser necesario que estas sean previamente revisadas y validadas por el usuario antes de su elabo-racin.

56

Enlafigura29puedeapreciarse,amododeejemplo,lainteraccindirectadelusuarioconelsistema,a nivel de la operacin del sistema.

Servidor

Figura 29:Interfazdeusuario.Fuente:Wong,2017.

Interfaces con aplicaciones externas: pueden ser mediante base de datos, a nivel de opera-cin o por el consumo de servicios.

En el ejemplo que se muestra a continuacin, se observa la interaccin del sistema principal, Sistema de Recursos Humanos, con el servidor de servicios, y un segundo sistema, Sistema de Tesorera. Esta interaccin se da a nivel de aplicacin y a nivel de base de datos.

Base de Datos 1

RED USUARIOSDMZ1

(Lgica del Negocio o informacin)

análisis y requerimientos de software · químico, electrónico, magnético, electro-óptico, por...

Documents