Este documento describe el modelado de requerimientos, incluyendo qué es, quién lo hace, por qué es importante y los pasos involucrados. Explica el modelado orientado al flujo, la creación de modelos de flujo de datos y control, y la especificación de procesos y comportamiento. También cubre consideraciones especiales para el modelado de requerimientos de aplicaciones web.
El curso Ingeniería de Software tiene como objetivo que el estudiante comprenda, mediante el análisis, lectura e interpretación, la forma en que interactúan los elementos y componentes de un sistema de información, e ingeniar y proponer modelos de alternativas de solución a necesidades y problemas encontrados o que permitan aprovechar oportunidades tecnológicas.
En este contexto, la temática presentada en este objeto de aprendizaje está orientada hacia el modelado de comportamiento de un producto software, particularmente a partir del diseño de Casos de Uso, modelo que se utiliza de forma actual para describir la ‘historia de uso de un sistema’, que permite entender y describir requerimientos para el diseño de un producto software.
UML. un analisis comparativo para la diagramación de softwareYaskelly Yedra
El propósito de este trabajo fue realizar un análisis comparativo entre el Lenguaje de Modelado Unificado (UML) con el desarrollo estructurado y los métodos orientados a objetos, a partir de los bloques de construcción de UML, con la finalidad de observar como surgió, evolucionó y se consolidó el UML como herramienta para la construcción de software. Los bloques de construcción de UML y los métodos de desarrollo estructurado y orientados a objetos se conforman con: elementos, relaciones y diagramas. A partir de esas similitudes, este trabajo utiliza el método de análisis comparativo para descubrir las semejanzas y diferencias de los distintos métodos cuando se construye software. Como conclusión del análisis se tiene que UML no garantiza el éxito de un proyecto, pero permite a los ingenieros centrarse en la entrega de un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es soportado directamente por las mejores herramientas de software en una forma unificada.
El curso Ingeniería de Software tiene como objetivo que el estudiante comprenda, mediante el análisis, lectura e interpretación, la forma en que interactúan los elementos y componentes de un sistema de información, e ingeniar y proponer modelos de alternativas de solución a necesidades y problemas encontrados o que permitan aprovechar oportunidades tecnológicas.
En este contexto, la temática presentada en este objeto de aprendizaje está orientada hacia el modelado de comportamiento de un producto software, particularmente a partir del diseño de Casos de Uso, modelo que se utiliza de forma actual para describir la ‘historia de uso de un sistema’, que permite entender y describir requerimientos para el diseño de un producto software.
UML. un analisis comparativo para la diagramación de softwareYaskelly Yedra
El propósito de este trabajo fue realizar un análisis comparativo entre el Lenguaje de Modelado Unificado (UML) con el desarrollo estructurado y los métodos orientados a objetos, a partir de los bloques de construcción de UML, con la finalidad de observar como surgió, evolucionó y se consolidó el UML como herramienta para la construcción de software. Los bloques de construcción de UML y los métodos de desarrollo estructurado y orientados a objetos se conforman con: elementos, relaciones y diagramas. A partir de esas similitudes, este trabajo utiliza el método de análisis comparativo para descubrir las semejanzas y diferencias de los distintos métodos cuando se construye software. Como conclusión del análisis se tiene que UML no garantiza el éxito de un proyecto, pero permite a los ingenieros centrarse en la entrega de un producto, utilizando un lenguaje de modelación estándar que además de ser consistente es soportado directamente por las mejores herramientas de software en una forma unificada.
La Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software. Integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería. Define paradigmas de desarrollo estructurado como base a seguir en un proyecto de Software. Si ninguno de estos paradigmas se adecua al problema por resolver, entonces el desarrollador se verá obligado a combinar los paradigmas o definir uno nuevo.
libro conabilidad financiera, 5ta edicion.pdfMiriamAquino27
LIBRO DE CONTABILIDAD FINANCIERA, ESTE TE AYUDARA PARA EL AVANCE DE TU CARRERA EN LA CONTABILIDAD FINANCIERA.
SI ERES INGENIERO EN GESTION ESTE LIBRO TE AYUDARA A COMPRENDER MEJOR EL FUNCIONAMIENTO DE LA CONTABLIDAD FINANCIERA, EN AREAS ADMINISTRATIVAS ENLA CARREARA DE INGENERIA EN GESTION EMPRESARIAL, ESTE LIBRO FUE UTILIZADO PARA ALUMNOS DE SEGUNDO SEMESTRE
en la formacion del personal de emergencia en industrias, no debe limitarse al sistema fijo de extincion con o sin medio de impulsion propia, tambien debe de conocer los elementos que permiten el abastecimiento externo o no a la industria y su clasificacion para su debida identificacion
EDT (Estructura de Desglose de Trabajo).pdffranco14021
• EDT: Estructura Desagregada del Trabajo
(Desagregar: Separar dos cosas que estaban unidas)
• WBS: Work Breakdown Structure
• Representa TODO el trabajo que se debe realizar en un Proyecto
•Equivale al índice de un libro
1. MODELADO DE LOS REQUERIMIENTOS:
¿Qué es? El modelode requerimientostienemuchasdimensionesdiferentes.Eneste capítulo,el lector
aprenderáacerca de modelosorientadosal flujo,de modelosde comportamientoyde las
consideracionesespecialesdelanálisisde requerimientosque entranenjuegocuandose desarrollan
webapps.
¿Quiénlo hace?Un ingenierode software (avecesllamadoanalista) construyeel modeloconel usode
losrequerimientosrecabadosentre variosparticipantes.
¿Por qué es importante? La perspectivade losrequerimientosdel software crece enproporcióndirecta
al númerode dimensionesdistintasdel modeladode losrequerimientos.Aunque quizánose tengael
tiempo,losrecursosola inclinaciónparadesarrollarcadarepresentaciónsugeridaeneste capítuloyen
el anterior, debe reconocerseque cadaenfoque diferentede modeladoproporcionaunaformadistinta
de ver el problema.Enconsecuencia,el lector(yotrosparticipantes) estarámejorpreparadopara
evaluarsi ha especificadoenformaapropiadaaquelloque debe lograrse.
muchasdimensionesdiferentes.Eneste capítulo,el lectoraprenderáacercade modelosorientadosal
flujo,de modelosde comportamientoyde lasconsideracionesespecialesdelanálisisde requerimientos
que entranenjuegocuandose desarrollanwebapps.Cadaunade estasrepresentacionesde modelado
complementaloscasosde uso,modelosde datosymodelosbasadosenclasesque se estudiaronenel
capítulo6.
¿Quiénlo hace?Un ingenierode software (avecesllamadoanalista) construyeel modeloconel usode
losrequerimientosrecabadosentre variosparticipantes.¿Porqué esimportante?Laperspectivade los
requerimientosdel software crece enproporcióndirectaal númerode dimensionesdistintasdel
modeladode losrequerimientos.Aunquequizánose tengael tiempo,losrecursosolainclinaciónpara
desarrollarcadarepresentaciónsugeridaeneste capítuloyenel anterior,debe reconocerse que cada
enfoque diferente de modeladoproporcionaunaformadistintade verel problema.Enconsecuencia,el
lector(yotros participantes) estarámejorpreparadoparaevaluarsi haespecificadoenformaapropiada
aquelloque debe lograrse.¿Cuálessonlospasos?El modeladoorientadoal flujodaunaindicaciónde la
formaen laque las funcionesde procesamiento transformanlosobjetosde datos.El modeladodel
comportamientoilustralosestadosdel sistemaysusclases,así comoel efectoque tienenloseventos
sobre dichosestados.El modeladobasadoenpatronesutilizael conocimientodel dominioexistente
para facilitarel análisisde losrequerimientos.Losmodelosde requerimientosconwebappsestán
adaptadosespecialmentepararepresentarrequerimientosrelacionadosconcontenido,interacción,
funciónyconfiguración.
¿Cuál esel producto final? Para el modeladode losrequerimientos,esposible escogerunagran
variedadde formasbasadasentextoy diagramas.Cadauna de estas representacionesdauna
perspectivade unoomás de loselementosdel modelo.¿Cómome asegurode que lohice bien?Debe
revisarse si losproductosdel trabajodel modeladode losrequerimientossoncorrectos,completosy
congruentes.Debenreflejarlasnecesidadesde todoslosparticipantesyestablecerlosfundamentos
desde losque se llevaráacabo el diseño.
2. MODELADO ORIENTADOAL FLUJO Aunque algunosingenierosde softwarepercibenel modelado
orientadoal flujocomounatécnicaobsoleta,sigue siendounade lasnotacionesmásusadas
actualmente parahacerel análisisde losrequerimientos.1Si bienel diagramade flujode datos (DFD) y
la informaciónrelacionadanosonunaparte formal del UML, se utilizanparacomplementarlos
diagramasde éste y amplíanla perspectivade losrequerimientosydel flujodel sistema.El DFDadopta
un puntode vistadel tipoentrada-proceso-salidaparael sistema.Esdecir,losobjetosde datosentranal
sistema,sontransformadosporelementosde procesamientoylosobjetosde datosque resultande ello
salendel software.Losobjetosde datosse representanconflechasconleyendasylastransformaciones,
con círculos (tambiénllamadosburbujas).El DFDse presentaenformajerárquica.Es decir,el primer
modelode flujode datos(enocasionesllamadoDFDde nivel 0o diagramade contexto) representaal
sistemacomoun todo.Los diagramasposterioresde flujode datosmejoranel diagramade contextoy
dan cada vezmás detallesenlosnivelessiguientes.
Creaciónde un modelode flujode datosEl diagramade flujode datospermite desarrollarmodelosdel
dominiode lainformaciónydel dominiofuncional.A medidaque el DFDse mejoracon mayoresniveles
de detalle,se efectúaladescomposiciónfuncional implícitadel sistema.Al mismotiempo,lamejoradel
DFD da como resultadoel refinamientode losdatosconforme avanzanporlosprocesosque constituyen
la aplicación.
7.2.2 Creaciónde un modelode flujode control Paraciertostiposde aplicaciones,el modelode datosy
el diagramade flujode datosestodolo que se necesitaparaobtenerunavisiónsignificativade los
requerimientosdel software.Sinembargo,comoyase dijo,ungran númerode aplicacionesson
“motivadas”poreventosyno por datos,produceninformaciónde control enlugarde reporteso
pantallas,yprocesaninformaciónconmuchaatenciónenel tiempoyel desempeño.Talesaplicaciones
requierenel usodel modeladodelflujode control,ademásde modelarel flujode datos.Se dijoque un
eventooaspectodel control se implementacomovalorbooleano(porejemplo,verdaderoofalso,
encendidooapagado,1 o 0) o como una listadiscretade condiciones(vacío,bloqueado,lleno,etc.).Se
sugierenloslineamientossiguientesparaseleccionareventoscandidatospotenciales:•Enlistartodos
lossensoresque son“leídos”porel software.• Enlistartodaslascondicionesde interrupción. •Enlistar
todoslos“interruptores”que sonactivadosporun operador.• Enlistartodaslascondicionesde los
datos.• Revisartodoslos“aspectosde control”como posiblesentradasosalidasde especificacióndel
control,segúnel análisisgramatical de sustantivosyverbosque se aplicóala narracióndel
procesamiento.•Describirel comportamientode unsistemaconlaidentificaciónde susestados,
identificarcómose llegaa cada estadoy definirlastransicionesentreestados.•Centrarse enlas
posiblesomisiones,errormuycomúnal especificarel control;porejemplo,se debe preguntar:“¿hay
otro modode llegara este estadoo de salirde él?”
La especificaciónde control Unaespecificaciónde control (CSPEC) representade dosmanerasdistintas
el comportamientodel sistema(enel nivel desde el que se hizoreferenciaaél).3La CSPECcontiene un
diagramade estadoque esunaespecificaciónsecuencial delcomportamiento.Tambiénpuede contener
una tablade activacióndel programa,especificacióncombinatoriadel comportamiento.
3. La especificacióndelprocesoLaespecificacióndelproceso(PSPEC)se utilizaparadescribirtodoslos
procesosdel modelodel flujoque aparecenenel nivel final de lamejora.El contenidode la
especificacióndel proceso incluyeel textonarrativo,unadescripcióndellenguajede diseñodel
programa5 del algoritmodel proceso,ecuacionesmatemáticas,tablasodiagramasde actividadUML. Si
se da una PSPEC
7.3 CREACIÓN DE UN MODELO DE COMPORTAMIENTOLa notaciónde modeladoque hemosestudiado
hasta el momentorepresentaelementosestáticosdel modelode requerimientos.Eshorade hacerla
transiciónal comportamientodinámicodel sistemaoproducto.Parahacerlo,dichocomportamientose
representacomofunciónde eventosy tiempoespecíficos.El modelode comportamientoindicala
formaen laque responderáel software aeventosoestímulosexternos.Paragenerarel modelodeben
seguirse lospasossiguientes:1.Evaluartodosloscasos de uso para entenderporcompletolasecuencia
de interaccióndentrodel sistema.2.Identificarloseventosque conducenlasecuenciade interaccióny
que entiendenel modoenel que éstosse relacionanconobjetosespecíficos.3.Crearuna secuencia
para cada caso de uso.4. Construirundiagramade estadopara el sistema.5. Revisarel modelode
comportamientoparaverificarlaexactitudyconsistencia.
7.5 MODELADO DE REQUERIMIENTOS PARA WEBAPPS14 Es frecuente que losdesarrolladoresde web
manifiestenescepticismocuandose plantealaideadel análisisde losrequerimientosparawebapps.
Acostumbrandecir:“despuésde todo,el procesode desarrolloenwebdebe serágil yel análisistoma
tiempo.Nosharáser lentosjustocuandonecesitemosdiseñaryconstruirlawebapp”.El análisisde los
requerimientosllevatiempo,peroresolverel problemaequivocadotomaaúnmás tiempo.Lapregunta
que debe respondertododesarrolladorenwebessencilla:¿estássegurode que entiendeslos
requerimientosdel problema?Si larespuestaesun“sí” inequívoco,entoncestal vezseaposibleomitir
el modeladode losrequerimientos,perosi larespuestaes“no”,entonceséstadebe llevarseacabo.
7.5.1 ¿Cuántoanálisisessuficiente?El gradoenel que se profundice enel modeladode los
requerimientosparalaswebappsdependede losfactoressiguientes:•Tamañoy complejidaddel
incrementode lawebapp.•Númerode participantes(el análisisayudaaidentificarlosrequerimientos
conflictivosque provienende distintasfuentes).•Tamaño del equipode lawebapp.•Grado enel que
losmiembrosdel equipohantrabajadojuntosantes(el análisisayudaadesarrollarunacomprensión
comúndel proyecto).• Medidaenla que el éxitode laorganizacióndepende directamente deléxitode
la webapp.El inversode lospuntosanterioresesque amedidaque el proyectose hace más chico,que
el númerode participantesdisminuye,que el equipode desarrolloesmáscohesivoyque laaplicación
esmenoscrítica, esrazonable aplicarunenfoque másligeroparael análisis.Aunque esunabuenaidea
analizarel problemaantesde que comience el diseño,noesverdadque todoel análisisdebaprecedera
todoel diseño.Enrealidad,el diseñode unaparte específicade lawebappsólodemandaunanálisisde
losrequerimientosque afectanasóloesaparte de la webapp.Comounejemploproveniente de
CasaSegura,podríadiseñarse convalidezlaestéticageneral del sitioweb(formatos,colores,etc.) sin
tenerque analizarlosrequerimientosfuncionalesde lascapacidadesde comercioelectrónico.Sólose