Análisis y requerimientos de software · químico, electrónico, magnético, electro-óptico, por...
Transcript of 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
Lectura seleccionada n. 2 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
Organizacin de los aprendizajes 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
Lectura seleccionada n. 3 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
Lectura seleccionada n. 4 63
Actividad n. 4 63
Tarea acadmica n. 2 64
Glosario de la Unidad II 65
Bibliografa de la Unidad II 66
Autoevaluacin n. 2 67
U - III ESPECIFICACIN DE REQUERIMIENTOS DE SOFTWARE 69
Diagrama de organizacin de la unidad III 69
Organizacin de los aprendizajes 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
Lectura seleccionada n. 5 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
Tarea acadmica n. 3 91
Glosario de la Unidad III 92
Bibliografa de la Unidad III 93
Autoevaluacin n. 3 94
U - IV VALIDACIN DE REQUERIMIENTOS 97
Diagrama de organizacin de la unidad IV 97
Organizacin de los aprendizajes 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
Lecturaseleccionadan.7 103
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
Lecturaseleccionadan.8 120
Actividadn.8 120
Tarea acadmica n. 4 121
Glosario de la Unidad IV 122
Bibliografa de la Unidad IV 123
Autoevaluacin n. 4 124
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
-
10
-
11
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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.
Alfinalizarlaunidad,elestudiante ser capaz de
elicitar los requerimientos de softwareparasuproyecto.
Alfinalizarlaunidad,elestudiante ser capaz de
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
-
12
-
13
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
Representacin grfica Descripcin
Nombre_Entidad Entidad
Nombre_Atributo Atributo
11 1
N
NN
Cardinalidad
Nombre_Relacin Decisin S/NO
Nota:TomadodeWong,2017.
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
Representacin grfica Descripcin
Nombre de estado Estado
Estado inicial
Estadofinal
Transicin
Nota:TomadodeWong,2017.
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
Representacin grfica Descripcin
Caso_de_usoCaso de uso: representa la funcin del sistema.
Actor: representa a la entidad externa del sistema.
Nota:TomadodeWong,2017.
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
-
44
-
45
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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
MANUAL AUTOFORMATIVO INTERACTIVO
Anlisis y requerimientos de software
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)