Resumen del 1° Parcial de Análisis de Sistemas de Información PDF

Capítulo I: Repaso de SyPN ========================== 1. Metodología para la Ingeniería en S.I ---------------------------------------- [La **metodología** es un proceso genérico para resolver problemas en el que:] - Se decide **qué** hacer ([es decir, cuál es el problema para resolver]) -...

Capítulo I: Repaso de SyPN ========================== 1. Metodología para la Ingeniería en S.I ---------------------------------------- [La **metodología** es un proceso genérico para resolver problemas en el que:] - Se decide **qué** hacer ([es decir, cuál es el problema para resolver]) - Se decide **cómo** hacerlo - Se **hace** el producto que resuelve el problema - Se **prueba** el producto - Se **utiliza** el producto [Desarrollar un sistema de información (S.I)] utilizando una adecuada metodología [permite definir por cada fase] ciertas cosas como: [estándares de documentación, actividades y tareas, técnicas y herramientas.] *Además, entre las fases se divide el estudio, la construcción y la evolución del sistema* 2. Etapas de la metodología --------------------------- El siguiente gráfico permite ilustrar todas las etapas de la metodología que serán descritas debajo: ### 2.1 Reconocimiento Implica un primer contacto con la organización (con su tamaño y distribución geográfica), su estructura (formal e informal), su cultura, sus necesidades e intereses. En esta etapa, se conocen los **requerimientos** y **expectativas** del cliente, así también como las áreas afectadas por el problema del usuario y las restricciones del proyecto. #### 2.1.1 Técnicas y herramientas - La técnica para **obtener** información es la *entrevista*. - Las técnicas para **documentar** información son el *informe de reconocimiento* y los *organigramas*. ### 2.2 Relevamiento Se obtiene un conocimiento exhaustivo de los **procedimientos** de la organización. El objetivo de esta etapa es construir un **modelo de la realidad** que será la base del modelo solución, ahondando en los procesos involucrados. Aquí se analiza el modo en que el sistema de información se desarrolla en la *actualidad* y cómo el cliente querría que se *comportase* (La idea es acortar esa brecha con el producto). #### 2.2.1 Técnicas y herramientas Las técnicas para **obtener** información son: - Entrevista, cuestionario, observación personal y la medición del trabajo administrativo. Las técnicas para **documentar** información son: - Cursograma, Tabla de Decisión, DFD, DER, Casos de Uso ### 2.3 Diagnóstico Se determinan las **causas** que generan los problemas que dieron origen al trabajo y luego se presentan **alternativas** en base al modelo de la realidad (construido previamente). ### 2.4 Estudio de Factibilidad Se analizan de forma individual cada una de las alternativas planteadas en el diagnóstico para elegir la que sea más **viable** para la organización en particular. *[El análisis es hecho conjuntamente entre el ingeniero en S.I y el cliente.]* Los **criterios** de análisis son: Económico - Financiero - Técnico - Operativo - Político - Legal Luego de hacer el análisis correspondiente, se elige la mejor propuesta, que ahora pasará a llamarse **alternativa solución**. La alternativa solución disparará un conjunto de proyectos asociados a la solución, como podrían ser: - La **construcción** o **adquisición** de software y hardware - La **capacitación** del personal - **Tercerización** de procesos (contratar servicios externos) - **Formalización** de procesos no informatizados. #### 2.4.1 Técnicas y herramientas Las herramientas son las alternativas, las cuales pueden ser analizadas a través de un *cuadro de doble entrada* (lo que da lugar al *benchmark*). ### 2.5 Análisis de Requisitos Informáticos En esta etapa se definen los requisitos informáticos, para ello, veamos su [[definición]](#cap%C3%ADtulo-iv-requerimientos). #### 2.5.1 Tipos de requisitos Los requisitos se caracterizan en función de: - Quien lo define: [Usuario] o [Grupo] de proyecto - Utilidad: [Funcional] o [**NO** funcional] - Nivel de Obligatoriedad: [Obligatorio] o [Deseado]. ### 2.6 Diseño En esta etapa se **crea** el **modelo solución** basado en el modelo de análisis (o de realidad) y la alternativa solución Para ello, se realizan las siguientes actividades: - Se definen las bases de datos, los módulos o programas, interfaces y procedimientos administrativos - Se adecuan las estructuras organizativas - Se hace el prediseño de documentos y formularios - Se preparan manuales de normas y procedimientos *[A mejor esté diseñado el modelo solución, más fácil será su implementación y su mantenimiento tendrá menores costos. ]* #### 2.6.1 Técnicas y herramientas Las técnicas para **documentar** información son: - **DFD**, DER, Diagrama de Clases, Diagrama de Casos de Uso, **Diccionario de Datos** ### 2.7 Desarrollo En esta etapa se **construye** lo diseñado como propuesta solución (es decir, el modelo de solución). Para ello, se realizan las siguientes actividades: - Se lleva a cabo la programación necesaria - Se convoca la adquisición de hardware y software - Se formalizan todos los procesos no informatizados - Se inicia la capacitación del personal - Se parametriza el software adquirido *Algunos de estos procesos podrían culminar en etapas posteriores, como la implementación* ### 2.8 Pruebas Su **objetivo** es encontrar la mayor cantidad de errores y corregirlos, incluso a sabiendas de que no se puede lograr la perfección, para acercarse a los estándares de calidad deseados. El proceso de pruebas debe estar bien planificado para garantizar calidad, estimar futuras y repetir o modificar validaciones posteriores. Si las pruebas las realiza alguien externo es más objetivo. Existen dos enfoques posibles para la realización de las pruebas: - **Caja negra**[: no se analiza el cómo se llegó al resultado, solo se cotejan las entradas con sus salidas] (con las salidas esperadas). - **Caja blanca**: [es más costoso pues justamente, se analiza el procesamiento interno.] #### 2.8.1 Técnicas y herramientas Existen diferentes tipos de prueba: - **Unidad o** **módulo**: Verifica el funcionamiento de componentes individuales del software. - **Integración**: Evalúa la interacción entre múltiples módulos integrados. - **Sistema**: Prueba el sistema completo para asegurar que cumple con los requisitos especificados. - **Aceptación**: Valida que el software satisface las necesidades del usuario final y está listo para su implementación (hace participar al usuario). La herramienta por excelencia es el Bug Tracking System, que es la aplicación que le permite al usuario hacer un seguimiento de los defectos del software. ### 2.9 Implementación La implementación puede ser **total** o **gradual** (**por módulos, paulatina;** respectivamente). Esta etapa se dedica a instalar la propuesta desarrollada y probada en la organización. Ello implica desactivar productos previos, lo que [puede generar *resistencia al cambio* (es por esto que conviene una implementación gradual). ] Para esto, se suele promover que el producto antiguo y el nuevo funcionen temporalmente de forma paralela, con la finalidad de generar confianza en los empleados de la organización. Esto puede requerir capacitaciones para hacer un buen uso del artefacto. +-----------------------------------------------------------------------+ | **Importante:** Es crucial que los ajustes en los procedimientos, los | | cambios en los procesos habituales y la introducción de innovaciones | | se comprendan y **apliquen en todos los niveles de la organización**. | | | | *La implementación debe ser hecha en todos los sectores donde se haya | | acordado su instalación.* | +-----------------------------------------------------------------------+ ### 2.10 Mantenimiento Se busca sostener la viabilidad de la solución con el tiempo, aquí se pone en juego la calidad del desarrollo, en todo sentido. Su **objetivo** es asegurar la validez del producto desarrollado. El producto debe evolucionar a la par que lo hacen las necesidades del usuario. Se realizan entonces, acciones ***correctivas*** (corrigen lo que no se cubrió en la prueba), ***perfectivas*** (mejoran la solución en base a nuevos requerimientos tecnológicos) *y* ***adaptativas*** (realizan cambios una vez que el usuario haya incorporado la solución en su rutina). ### 2.11 Sustitución Se cancela la solución implementada. Consta de migraciones, conversión de procedimientos, interconexión de sistemas informáticos. Las razones de una sustitución pueden responder a factores económicos, tecnológicos, culturales, políticos, etc. Lo esencial, es que ya no es viable para la organización y se debe cambiar. Se debe planificar el **momento oportuno** de la salida del producto solución de forma que paralice lo menos posible el funcionamiento en la empresa, y que sea de forma paulatina para tener una buena implementación. 3. Ciclos de Vida del Software ------------------------------ Todos los sistemas tienen una vida útil atravesada por un ciclo, de modo tal que nacen, crecen y mueren. De acuerdo con el modo en que se organice la secuencia de tareas en las distintas etapas de la metodología de sistemas, se pueden reconocer cuatro tipos de ciclos de vida: - **En cascada** - **En espiral** - **Prototipado** - **Iterativo incremental ágil** El ciclo de vida de software entonces es una ruta crítica que garantiza que el software no solo cumpla con las expectativas iniciales, sino que también se adapte al cambio. En un mundo tecnológico que evoluciona tan rápido es necesario esta flexibilidad y adaptabilidad. ### 3.1 Ciclo de vida en cascada (o tradicional) Se pretende definir el modo en el que el producto evoluciona hacia el resultado esperado, teniendo en cuenta los [*[requerimientos del usuario]*](#cap%C3%ADtulo-iv-requerimientos), que pueden mutar incluso cuando ya inició el ciclo de vida. En este enfoque metodológico, se ordenan rigurosamente las etapas del ciclo de forma tal que el inicio de cada etapa debe esperar a la finalización de su anterior inmediato (justamente [como si fuese una cascada]). La información se sigue secuencialmente. Por eso, se debe concebir desde temprano un modelo de análisis que también se adelante a ciertos eventos para minimizar riesgos y ser más adaptable a cambios.  Algunas características de este tipo de modelo son las siguientes: - Se aprovechan en **proyectos pequeños,** donde las tareas se pueden organizar y administrar fácilmente. - Los **requerimientos son conocido**s, no pueden ser inciertos. Por esa razón hay poco margen de cambio. - Los **desarrolladores tienen experiencia** en los problemas a resolver. Hay una administración estricta, que proporciona resultados tangibles. - Se pueden **"congelar" los requisitos** del sistema durante todo el proceso de desarrollo. - Las **fases no se pueden superponer**, **no son saltables ni repetibles**. Al finalizar cada fase, se lleva a cabo una **revisión** para verificar si el proyecto va por buen camino, y se decide si **continuarlo** o **descartarlo** por completo. Es importante recordar que las pruebas de software solo se iniciarán una vez finalizado el desarrollo. En resumen, no es el mejor ciclo de vida, pero si se utiliza de forma correcta puede llegar a dar muy buenos resultados. Es un ciclo extenso, pero bien estructurado. ### 3.2 Ciclo de vida en espiral El modelo en espiral tiene un enfoque muy distinto al modelo de cascada, pues su enfoque principal está sobre el análisis de riesgos. El modelo de ciclo de vida en espiral consiste en realizar diversas **iteraciones**, pasando por cada una de sus fases una y otra vez. A diferencia del modelo cascada que no tiene vuelta atrás, en el modelo en espiral se pueden hacer las iteraciones que se consideren necesarias Consta de cuatro fases, de las cuales un proyecto pasa repetidamente (en forma de espiral). En la espiral principal, se recopilan los requisitos y se evalúa el riesgo. Cada espiral posterior se basa en la espiral base. Las fases son: - **Planificación**: - **Análisis de riesgo**: - **Implementación:** - **Evaluación:** Entre las principales ventajas está la reducción de riesgos, los cuales se van disminuyendo conforme avanzan los ciclos o iteraciones. No se puede avanzar a un ciclo nuevo si no se ha dado solución a todos los riesgos latentes. El ciclo se mantiene hasta que el riesgo que signifique ciclar una vez más, el tiempo que insume y los costos que involucre, sean significativos en vistas al beneficio que puede obtenerse con respecto de un nuevo ciclo posterior. Algunas características: - **No se conoce el dominio** de aplicación del problema. - Los desarrolladores tienen **poca experiencia.** - **No hay suficiente precisión del problema.** - **Requisitos inestables** - **Condicionamientos estrictos** en cuanto a recursos (tiempo y costo). Por desgracia el modelo es realmente costoso y es difícil tener un alto nivel de eficacia en la evaluación final del proyecto con este ciclo de vida. ### 3.3 Ciclo de vida prototipado (o incremental) Se nos permite crear un **diseño rápido** que se centra en una representación de esos aspectos del software que serán visibles para el **usuario**/**cliente**. Esto lleva a la construcción de un **prototipo**, que es un modelo de alguna actividad que permite diseñar software. Se espera que el prototipo entonces sea evaluado por el usuario, cuya retroalimentación se utiliza para refinar los requisitos del software a desarrollar. Es por ello, que se busca que esta **retroalimentación** ocurra de la manera más **temprana** posible. Entonces, se mantiene así una **repetición** de **ciclos** que reproducen las mismas fases, pero arrojando resultados mejores que los ciclos anteriores. Mientras se repita este ciclo, es posible adentrarse más aún en el proyecto, **pues por cada iteración se van refinando los requerimientos** del proyecto. Es por eso que estos prototipos generados pueden llegar a ser el producto final, lo cual lo hace relevante y destacable. Un sistema creado mediante este tipo de ciclo de vida tiende a casi no fallar, lo cual es garantía de satisfacción. Las fases de este ciclo entonces son: 1. **Inicialización** 2. **Iteración** 3. **Lista de Control** Los prototipos pueden ser **desechables**, lo cual significa que se utilizan solo para un propósito específico y luego se descartan; o bien pueden ser **incrementales**, lo que significa que se utilizan y luego se van perfeccionando para llegar a un sistema final. A fines prácticos, termina resultando muy parecido a un modelo en espiral, pero en este caso **los riesgos en cada iteración no se toman en cuenta** (se desprecian). ### 3.4 Ciclo de vida Iterativo Incremental Ágil El proceso de software consiguió modelos cada vez más adaptables con el paso del tiempo gracias a los paradigmas de programación como la orientación a objetos que cambian radicalmente. Se comenzó a suponer que es más rentable escribir código, que los usuarios lo evalúen y si hay un error, corregirlo rápidamente. El Manifiesto Ágil tiene los siguientes **dos principios**: - Nuestra mayor prioridad es satisfacer al cliente mediante **la entrega temprana** **continua** de software con **valor** - **Aceptamos que los requisitos cambien**, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Basado en los 12 principios del Manifiesto Ágil (aunque veremos estos 2) es que nace el **ciclo de vida iterativo incremental ágil**. Se define inicialmente una gran idea de lo que se va a construir, pero el detalle de los requerimientos se va relevando y entregando en períodos cortos de tiempo. Las entregas tempranas generan valor para el usuario, es decir, que pueda **interactuar** con el software entregado, **probarlo** y dar **feedback** sobre las cosas que se podrían hacer para próximas iteraciones. Asimismo, la entrega anticipada sirve para minimizar el riesgo de errores en la solución final.  El ciclo de vida es recomendable cuando: - El proyecto puede dividirse en entregables que siempre generen valor y se van incrementando cada vez. - El cliente puede involucrarse durante todo el proyecto (para dar el feedback) - El cliente va descubriendo lo que necesita a medida que va avanzando el proyecto. - El equipo es multidisciplinario y el objetivo es de todos, y no de cada rol en particular. Se destaca la **colaboración**. - El proyecto es de alta incertidumbre, los requerimientos pueden cambiar constantemente y hay que adaptarse a esos cambios #### 3.4.1 Diferencias con Ciclo de Vida en Cascada - **Requerimientos**: [En cascada los requerimientos son fijos desde el principio], si hay errores o cambios, se arrastran hasta el final del proyecto lo que genera retrabajo. [En Incremental Ágil los requerimientos se relevan y son flexibles.] - **Valor:** [En Cascada, el valor al usuario se entrega al final del proyecto]. [En Iterativo Incremental ágil, se va entregando valor al usuario en cada iteración.] - **Concurrencia:** [En Cascada, se trabaja secuencialmente etapa por etapa de la metodología]. [En Iterativo Incremental ágil, se van paralelizando todas las etapas.] ####  #### #### 3.4.2 Diferencias con Ciclo de Vida en Espiral [En Espiral, se van creando entregas parciales, sin embargo, estas no tienen valor para el usuario] porque no satisfacen su necesidad. En Incremental Ágil sí tienen valor. ### 3.5 Cuadro comparativo Próxima página: +-----------------+-----------------+-----------------+-----------------+ | **Modelos** | **Ventajas** | **Desventajas** | **Cuando | | | | | usarlo** | +-----------------+-----------------+-----------------+-----------------+ | **Cascada** | Simple y | Una vez que una | Este modelo se | | | sencillo de | aplicación está | utiliza sólo | | | entender y | en la etapa de | cuando los | | | usar. | prueba, es muy | requisitos son | | | | difícil volver | claros y fijos. | | | Es fácil de | atrás y cambiar | | | | manejar debido | algo que no | Cuando se | | | a su rigidez | estaba pensado | implementan | | | del modelo, | en la etapa de | tecnologías | | | cada fase tiene | diseño. | conocidas, es | | | resultados | | decir, no se | | | específicos y | Solo se | innova nada. | | | un proceso de | programa una | | | | revisión. | sola vez | No hay | | | | durante el | requisitos | | | En este modelo | ciclo de vida. | ambiguos. Los | | | las fases son | | recursos están | | | procesadas y | El riesgo y la | disponibles | | | completadas una | incertidumbre | libremente. | | | a la vez. | son grandes. | | | | | | Para proyectos | | | Las fases no se | No es un buen | cortos. | | | superponen. | modelo para | | | | Ideal para | proyectos | | | | proyectos | complejos y | | | | pequeños. | orientados a | | | | | objetos. | | | | | | | | | | Modelo | | | | | deficiente para | | | | | proyectos | | | | | largos y en | | | | | curso. | | | | | | | | | | No es adecuado | | | | | para los | | | | | proyectos en | | | | | los que los | | | | | requisitos | | | | | están sujetos a | | | | | cambios. | | +-----------------+-----------------+-----------------+-----------------+ | **Incremental | Genera | Necesita buena | Este modelo | | Ágil** | tempranamente y | planificación y | puede | | | rápidamente | diseño. | utilizarse | | | software | | cuando los | | | durante el | Necesita una | requisitos del | | | ciclo de vida. | definición | sistema | | | Es más | clara y | completo están | | | flexible, los | completa de | claramente | | | costos de los | todo el sistema | definidos y | | | cambios son | antes de que | comprendidos, | | | menores. | pueda modularse | sin embargo, | | | | y empezar a | algunos | | | Es más fácil | construir de | detalles pueden | | | probar y | forma | evolucionar con | | | depurar durante | incremental. | el tiempo. | | | una iteración | | | | | menor. | El costo total | Cuando hay | | | | es más alto que | necesidad de | | | En este modelo | el modelo | tener una | | | el cliente | cascada. | versión previa | | | puede responder | | lista. | | | en cada | | | | | despliegue. | | Se está | | | | | utilizando una | | | Riesgo más | | nueva | | | fácil de | | tecnología (se | | | manejar porque | | va a innovar). | | | las piezas de | | | | | riesgo son | | Cuando muchos | | | identificadas y | | recursos no | | | manejadas | | están | | | durante su | | disponibles. | | | iteración. | | Cuando el | | | | | riesgo es | | | | | medio. | +-----------------+-----------------+-----------------+-----------------+ | **Espiral** | Las | Limitantes en | Cuando los | | | estimaciones | la | costos y la | | | (es decir, el | reutilización y | evaluación del | | | presupuesto, el | la | riesgo son | | | cronograma, | personalización | importantes. | | | etc.) se |. | | | | vuelven más | | Para proyectos | | | realistas a | Se debe aplicar | de mediano a | | | medida que el | de forma | alto riesgo. | | | trabajo avanza, | diferente en | | | | porque | cada | Cuando el plazo | | | tempranamente | aplicación. | del proyecto es | | | se van | | incierto, | | | descubriendo | Riesgo alto de | debido a | | | problemas. | no cumplir | posibles | | | | expectativas, | cambios por | | | Es capaz de | presupuestos y | prioridades | | | hacer frente a | horarios (si no | económicas. | | | la evolución | se planea | | | | del modelo, | bien). | Los usuarios no | | | generando un | | están seguros | | | modelo de | | de sus | | | software de | | necesidades. | | | desarrollo muy | | | | | realista. | | Los requisitos | | | | | son complejos. | | | Se puede | | | | | empezar a | | Cuando se | | | trabajar en un | | tratará con | | | proyecto sin | | nueva línea de | | | tener una | | productos. Se | | | definición | | esperan cambios | | | completa del | | significativos | | | ciclo. | | (investigación | | | | | y exploración). | +-----------------+-----------------+-----------------+-----------------+ | **Prototipado** | Este modelo es | Requiere la | Ideal cuando no | | | útil cuando el | participación | se tiene claro | | | cliente conoce | del usuario, al | el diseño del | | | los objetivos | menos, para | sistema y se | | | generales para | evaluar el | necesita | | | el software, | prototipo. Y | validar ideas | | | pero no | mucho más | con los | | | identifica los | involucramiento | usuarios. | | | requisitos | si queremos que | | | | detallados de | participe en su | Útil para | | | entrada, | creación. | proyectos | | | procesamiento o | | innovadores o | | | salida. | Una desventaja | con alta | | | | importante a | incertidumbre | | | También ofrece | tener en cuenta | en los | | | un mejor | es la falta de | requisitos. | | | enfoque cuando | experiencia que | Recomendado | | | el responsable | tienen muchos | cuando se | | | del desarrollo | Analistas | espera obtener | | | del software | Funcionales en | retroalimentaci | | | está inseguro | programación y | ón | | | de la eficacia | en actividades | temprana y | | | de un | de diseño de | frecuente de | | | algoritmo, de | interfaces de | los usuarios. | | | la | usuario | | | | adaptabilidad | | | | | de un sistema | | | | | operativo o de | | | | | la forma que | | | | | debería tomar | | | | | la interacción | | | | | humano-máquina. | | | +-----------------+-----------------+-----------------+-----------------+ **Cascada:** Modelo simple y estructurado. Ideal para proyectos pequeños y con requisitos claros y fijos. Cada fase se completa antes de empezar la siguiente. Difícil hacer cambios una vez avanzadas las etapas. **Incremental:** Permite construir el software en partes, facilitando pruebas y cambios menores. Se necesita una planificación inicial sólida y es más caro que Cascada. Útil cuando se conocen la mayoría de los requisitos, pero se espera que algunos evolucionen. **Espiral:** Se enfoca en la evaluación continua y la gestión de riesgos. Ideal para proyectos complejos y de alto riesgo. Permite ajustes y mejoras a lo largo del desarrollo. Requiere mucha planificación y puede ser difícil de gestionar. **Prototipado:** Se construye un prototipo rápido para obtener retroalimentación y clarificar requisitos. Ideal cuando los requisitos no están bien definidos. Necesita participación del usuario para evaluar y ajustar el prototipo. 4. Procesos de Negocio ---------------------- ### 4.1 Normas ISO Las **normas ISO** son un conjunto de estándares con reconocimiento internacional que fueron creados con el objetivo de ayudar a las empresas a **establecer** unos niveles de **homogeneidad** en relación con la **gestión**, prestación de **servicios** y **desarrollo** de productos en la industria. ### 4.2 Proceso y proceso de negocio Para *ISO*, un **proceso** es una serie de actividades mutuamente relacionadas o que interactúan entre ellas, las cuales [transforman elementos de entrada en salidas.] En otras palabras, describen un flujo de actividades en una organización con el objetivo de hacer un trabajo. Para los *Laudon*, los **procesos de negocio** son el conjunto de **tareas** y **comportamientos** ordenados y **relacionados en forma lógica**, que las organizaciones desarrollan para producir resultados de negocio. Lo que separa una actividad de un proceso, son los niveles de agregación. ### 4.3 Conceptos clave La **visión funcional o departamental** es la observación de una organización desde la **perspectiva** de las **funciones** que hace y qué **estructura** las dirige (donde las áreas y sus sistemas de información son las responsables de interactuar con otras áreas y hacer el trabajo). La **cadena de valor** identifica un conjunto de actividades que realiza la empresa para **generar valor** para su cliente. Las actividades pueden ser ***primarias*** ([efecto] inmediato sobre la producción, venta y prestación de servicios) o de ***apoyo***, que c[omplementan] a las primarias. Mintzberg planteó un modelo de estructuración de las organizaciones que divide la tecnoestructura del personal de apoyo como elementos de la estructura central (ápice estratégico, línea media y núcleo operativo).  Esta estructura consolidó las bases sustanciales de la nueva perspectiva de las organizaciones, ya no como áreas que interactúan sino como procesos que son resultado de un trabajo en conjunto de las áreas. Otros modelos como el de *gestión industrial* también fueron necesarios para este cambio. De esta forma la organización puede ser observada como un conjunto de **procesos de negocio**. *El desempeño de una empresa depende de qué tan bien están diseñados sus procesos de negocio.* ### 4.4 Clasificación de procesos Los procesos son clasificados en: estratégicos, operativos y de soporte/apoyo. #### 4.4.1 Procesos estratégicos Los **procesos estratégicos** se encuentran vinculados al ámbito de las responsabilidades de la dirección a **largo plazo.** Son todos los procesos de planificación y los que se considere que están ligados a los factores clave y estratégicos. **Guían** a los operativos mediante las pautas de gestión o estratégicas. #### 4.4.2 Procesos operativos Los **procesos operativos** están vinculados con la **realización** del **producto** o **servicio**. Cuentan con una visión del cliente muy completa, desde el conocimiento de los requisitos, hasta la realización de un análisis de satisfacción. #### 4.4.3 Procesos de soporte Los **procesos de soporte** **auxilian** a los procesos operativos. Se suelen referir a todos los procesos que están relacionados con los **recursos** utilizados y las mediciones realizadas. Una de las características es que [pueden ser *fácilmente tercerizados*]. ### 4.5 Estructura del modelo de gestión de procesos La estructura de niveles superiores de un modelo de gestión de procesos es la siguiente:  #### 4.5.1 Declaraciones Las **declaraciones** representan las definiciones de la organización, su *misión*, *visión*, el *alcance* *de sus actividades* y demás información relacionada con los actores que se vincula y los sectores que operan. Permiten **conocer la empresa** para poder entender sus procesos y macroprocesos (que requieren para obtener resultados). #### 4.5.2 Macroprocesos Los **macroprocesos** agrupan procesos que comparten un objetivo en común. Cada macroproceso debe tener un objetivo bien definido que esté vinculado con los objetivos de la empresa. El criterio de agrupamiento depende totalmente de la empresa, que lo realizan a su gusto. Los macroprocesos no tienen una actividad más que agrupar a otros procesos. Algunos ejemplos son: gestión financiera, seguridad informática, gestión de recursos humanos, etc. *No tiene sentido volver a nombrar a los procesos, consulta su definición y características [[aquí]](#proceso-y-proceso-de-negocio).* ### 4.6 Fases de la gestión por procesos Para la documentación de la gestión por procesos se proponen las siguientes fases: #### 4.6.1 Identificar las declaraciones Implica identificar, obtener y conocer todo el material que permite la caracterización de la organización (para posteriormente, saber los macro/procesos). #### 4.6.2 Identificar los macroprocesos Identificar los macroprocesos deriva de las declaraciones y representa una decisión respecto al primer nivel de análisis de la gestión por procesos. Por cada macroproceso se debe identificar claramente el objetivo. #### 4.6.3 Identificar los procesos Por cada macroproceso, se deben identificar de los procesos asociados, esta información: - Su nombre, el nombre del macroproceso, el tipo de proceso (estratégico, operativo, soporte) y el área responsable del proceso. Con *área responsable* se refiere a aquella que realiza el seguimiento general del proceso y se asegura de su cumplimiento (porque como tal, involucra varias áreas). #### 4.6.4 Detallar los procesos Es definir a cada proceso tal cual como dice el **modelado de procesos** ### 4.7 Modelado de procesos Para modelar procesos, se deben documentar e identificar macroprocesos, y luego, sus procesos (para finalizar detallándolos). Para cada uno de los niveles de procesos previstos se presentan diferentes herramientas para su documentación y modelado. #### 4.7.1 Mapa de procesos El mapeo de procesos consiste en organizarlos según el tipo, pudiendo ser desarrollado a diferentes niveles; nivel uno son los macroprocesos, nivel dos los procesos asociados, etc. *Como primero se identificar los macroprocesos, el primer mapa a diseñar es ese, de esta forma:*  #### #### #### 4.7.2 Identificación de procesos Una vez identificados y mapeados los macroprocesos, se identifican los procesos con lo [[anteriormente mencionado]](#identificar-los-procesos). #### 4.7.3 Detalle de procesos Finalmente, se presentan las ideas preliminares acerca de cómo documentar un proceso, es decir, cómo se puede conocer a detalle las actividades que llevan a cabo. Se representan así: ---------- ---------- ------------- --------- ----------------------- Procesos Entradas Actividades Salidas Valor para el cliente ---------- ---------- ------------- --------- ----------------------- Adicionalmente, un proceso también puede ser descrito utilizando herramientas como un cursograma. Si no también, existen otros modelos como el de BPMN. ### 4.8 Gestión de procesos en la metodología de sistemas Entendiendo que el **reconocimiento** resulta la primera aproximación a la organización, al problema y al sistema de información actual y que, entre otras actividades, desde la visión tradicional por funciones requiere conocer la estructura formal de la organización y obtener un conocimiento general de las áreas, entonces es esa etapa de la metodología de sistemas donde se llevan adelante también las primeras actividades asociadas a la gestión de procesos: **identificar** las **declaraciones** de la organización; identificar los **macroprocesos** e identificar los **procesos**. El detalle de los procesos, última fase presentada, no resulta ya una aproximación y comprensión inicial de la organización sino un análisis más detallado, por lo cual se considera, en el marco de la metodología de sistemas, dentro de la etapa de **relevamiento**. 5. Teoría General de Sistemas ----------------------------- La **teoría general de sistemas** (TGS) surge para desarrollar una teoría global e interdisciplinaria. Su objetivo es producir la ley de leyes, y el orden de órdenes, aplicable a la realidad, que tenga una visión del mundo como una totalidad orgánica (sin elementos aislados). El primero fue Ludwig, quien dijo que había que construir un campo de acción integrado por las ciencias sociales y naturales, y eliminar el reduccionismo de los enfoques mecanicistas anteriores. El paradigma **mecanicista** sustentaba la explicación del mundo en base a lo siguiente: el *análisis* ([desintegrar algo para poder estudiarlo]), el *reduccionismo* (entender el mundo por las propiedades de sus partes para juntarlo en un todo ["el todo es igual a la suma de sus partes"]) y el *determinismo* (cadenas de [causa y efecto]). ### 5.1 Clasificación de sistemas según su relación con el entorno Con la teoría general de sistemas surgieron varias definiciones de los sistemas, que se pueden clasificar según su relación con el entorno: - **Abiertos**: realizan **intercambios** de **energía** y **materia** con el exterior, ejerciendo influencia sobre él y siendo influenciados por él. Se **adaptan** para sobrevivir, en un continuo proceso de aprendizaje y autoorganización, pueden crecer, cambiar, e incluso reproducirse - **Cerrados**: No hay **intercambio** de materia con el entorno, pero sí de **energía**. Tienen un comportamiento **determinístico** (por ende, su salida es invariable) - **Aislados**: No existe **ningún** **intercambio**, son herméticos al entorno. Un ejemplo de esto es el universo. ### 5.2 Conceptos fundamentales #### 5.2.1 Sinergia La **sinergia** es la cooperación, acción colectiva entre varios elementos de un sistema para realizar una función. #### 5.2.2 Homeostasis La **homeostasis** es la capacidad de mantener el ambiente interno estable. En este caso define a los sistemas frente a los cambios que se producen en el contexto que los rodea y se adaptan para sobrevivir (equilibrio del sistema interno). #### 5.2.3 Entropía La **entropía** es la tendencia de los sistemas a desgastarse (a desaparecer), a distanciarse del funcionamiento programado, del "equilibrio". La entropía máxima es la muerte del sistema. #### 5.2.4 Interrelación La **interrelación** son redes de relaciones intrasistémicas entre los elementos que los componen. Definen sus características, propiedades y naturaleza. #### 5.2.5 Retroalimentación La **retroalimentación** es que cuando un elemento del sistema se modifica, también modifica el estado de los demás (es decir, del *sistema en sí*). #### 5.2.6 Isomorfismo El **isomorfismo** es la existencia de semejanzas formales entre diversos tipos de sistemas. También refiere al diseño de modelos sistémicos similares al modelo original. *El Isomorfismo es "la misma forma"*. #### 5.2.7 Equifinalidad La **equifinalidad** es que a partir de condiciones iniciales diferentes es posible alcanzar el mismo estado final (solo se aplica **en sistemas abiertos** y especialmente vivos). #### 5.2.8 Frontera límite La **frontera límite** (o contexto, como veremos en el *diagrama de sistemas del DFD*) es una línea abstracta, dinámica e imaginaria que separa al sistema de su entorno y define lo que pertenece al sistema y lo que no. #### 5.2.9 Ambiente El **ambiente** es el escenario que se dibuja a partir de un conjunto de situaciones, objetos y condiciones que rodean al sistema influyéndolo, donde el mismo sistema también interviene. *Existen el **macroentorno*** *que influye indirectamente al sistema y el **microentorno** que lo influye directamente.* #### 5.2.10 Permeabilidad La **permeabilidad** es la capacidad interactiva que tenga un sistema con el medio, cuanto más permeable sea un sistema, más abierto está. #### 5.2.11 Subsistema Un **subsistema** es un elemento de un sistema que a su vez es un sistema. #### 5.2.12 Suprasistema Un sistema es **suprasistema** si entre sus elementos tiene otros *subsistemas*. #### 5.2.13 Rango El **rango** es la jerarquización estructural de acuerdo con el grado de complejidad de los sistemas. #### 5.2.14 Recursividad La **recursividad** en sistemas significa que todo sistema **contiene dentro de sí otros subsistemas** que poseen funciones y características similares al sistema grande. #### 5.2.15 Input Un **input** es una entrada de materia que el sistema necesita y que será sometida a procesos de transformación de caja negra o blanca. #### 5.2.16 Throughput El **throughput** es el proceso en el que las entradas se convierten en salidas para ser utilizadas por el sistema o el entorno. #### 5.2.17 Output El **output** es la corriente de productos procesados por el sistema a partir de las entradas ingresadas. 6. Ingeniería en Sistemas de Información ---------------------------------------- ### 6.1 Definición de Ingeniería en Sistemas La **ingeniería en sistemas** consiste en la construcción de **artefactos**, **mecanismos** o **dispositivos** cuyo **buen uso** **soluciona** **problemas** determinados. Para dicha construcción se sigue una **metodología** específica que utiliza **técnicas** y **herramientas** **fundamentadas** en las propiedades de las **ciencias** **básicas** como la matemática y la física. ### 6.2 El rol del ingeniero en sistemas de información El ingeniero **utiliza** la **ciencia** para modificar un estado de la realidad indeseado. Observa la brecha entre la situación real y la deseada y trabaja en el desvío de un punto al otro. Para ello **construye un objeto** que permite adaptar la realidad a esa situación. Dicha **solución debe ser creativa**, interesante, **tecnológica** y **económicamente** **viable** para la organización. Sus funciones varían según el tipo de actividad: - **Empresarial administrativa**: Puede [gestionar procesos, proyectos y recursos; planificar; optimizar el manejo de la información; o delegar tareas.] - **Académicas**: Se dedica a la [capacitación y la investigación.] - **Resolución de problemas**: Se enfoca en [detectarlos, idear soluciones y determinar estrategias.] Las responsabilidades del ingeniero en sistemas son: **construir** el artefacto que solucione el problema, **instruir** al usuario para su buen uso y **monitorear** el funcionamiento de este. ### 6.3 Definición de técnica y herramienta Una **herramienta** es un **instrumento** que **realiza una actividad** de la mejor manera posible en el marco de un método y cuyo producto final será mejor si se utiliza en el momento preciso. Una **técnica** es un **procedimiento** que tiene como objetivo **alcanzar** un **resultado** determinado ### 6.4 Definición de ciencia La **ciencia** es un **conjunto** sistematizado de **conocimientos** **adquiridos** mediante un riguroso **método**. Un conjunto de conocimientos obtenidos mediante la observación o el razonamiento, sistemáticamente organizado. Por ende, podríamos pensar en el científico como un ingeniero aplicando un método para construir algo (conocimiento propio de su dominio) ### 6.5 Definición de sistema Un **sistema** es un **conjunto** de **elementos** **interrelacionados** con un **objetivo en común**. ### 6.6 Definición de sistema de información Un **sistema de información** es un conjunto de elementos interrelacionados con un objetivo en común [^1^](#fn1){#fnref1.footnote-ref} cuyas funciones son **recolectar**, **almacenar**, **procesar** y **distribuir** **información** en sus diferentes estados en tiempo y forma para la **toma de decisiones** dentro de una organización. ### 6.7 Definición de organización Una **organización** es **conjunto** de **individuos**, con un **objetivo común**, que **desarrollan** **actividades**, **utilizan** **medios** y están **inmersos** **dentro de un contexto**. En toda organización se pueden observar los siguientes sistemas: *Decisión - Información - Planificación - Control* 7. Estados de la Información ---------------------------- La información tiene diferentes estados, que se ordenan de forma ascendente como en una pirámide: - **Dato**: es la representación formal de un hecho o concepto. - **Noticia**: Resulta de la carga de significado puesta en un dato, es decir, el producto del análisis de un dato, que incluye su recolección, clasificación e interpretación. - **Conocimiento**: Es el resultado de un proceso de síntesis en el cual las noticias se comparan y se combinan entre sí. - **Sabiduría**: Comprende la capacidad de aplicar sentido, emitir juicios de valor y dotar a los conocimientos de una ética. Esta capacidad es propia de los humanos y no se aplica en los sistemas de información.  8. Técnicas de Recolección de Información (Revisar) --------------------------------------------------- Encuentran su principal propósito en las etapas iniciales de la metodología (Reconocimiento y Relevamiento) en las que [un correcto y eficiente proceso de recolección de información sienta un marco que dará rumbo a la actividad profesional posterior.] ### 8.1 Según su naturaleza Según su naturaleza, la información puede ser: - **Cualitativa**: opiniones, políticas, actitudes, reflexiones, problemas, situaciones no cuantificables en general. Luego están las técnicas para su recolección como entrevistas u observación del participante. - **Cuantitativa**: análisis de datos numéricos, frecuencias, porcentajes o cantidades, en general, hechos mensurables que puedan contabilizarse. Las técnicas son las encuestas, estadísticas u sondeos de opinión. ### 8.2 Según cómo se involucra el profesional Según cómo se involucra el profesional, las técnicas pueden clasificarse en: - **Técnicas interactivas: quien recolecta** la información **forma parte** del proceso **induciendo** directa o indirectamente **las respuestas que necesita** (como las entrevistas, diseños y cuestionarios). - **Técnicas no intrusivas**: es decir, que **no se involucra** para no influir en la información (como el muestreo, la investigación y la observación). ### 8.3 Métodos de recolección de información más efectivos #### 8.3.1 Muestreo Se elige un universo y se analizan los elementos más representativos de su población. Es efectivo, barato, ágil y sencillo. Su diseño requiere identificar qué información se recolecta, a quienes le afecta, su período, y cómo se selecciona la población. A mayor tamaño de la muestra, mayor exactitud de los datos recolectados. A menor tamaño de la muestra, menor costo de realización. #### 8.3.2 Entrevista Una conversación o sucesión de preguntas para obtener la información que posee el entrevistado. Son individuales o grupales, con preguntas abiertas/cerradas o averiguaciones que generan un vínculo entre los que la componen. Su preparación requiere investigar el tema y establecer el tipo de preguntas. La estructura puede ser piramidal (método inductivo / de particular a general), de embudo (método deductivo / contrario al inductivo) o mixto (entre ambos). Se debe documentar, puede ser mediante grabación o transcripción por escrito. #### 8.3.3 Cuestionarios Documentos eje para toda entrevista con formato de pregunta/respuesta. Su principal utilidad radica en los sondeos generales de información. Se pueden catalogar por tipo de preguntas como cuestionarios abiertos o cerrados según se requiera más o menos detalle en las respuestas; o bien por tipo de modalidad que puede ser presencial o a distancia. #### 8.3.4 Encuestas Gran cantidad de preguntas cerradas a efecto de cuantificar efectivamente sus resultados. Interesa conocer opiniones concretas. Capítulo II: Informe de Reconocimiento ====================================== El **informe de reconocimiento** (IR) o también *informe preliminar* es una técnica para **documentar información** que se utiliza en la etapa de [*[reconocimiento]*](#reconocimiento) (es decir, documenta la información de esa etapa). El informe de reconocimiento está compuesto por los siguientes elementos: 1. Objetivo de la organización ------------------------------ En esta sección **se describe la organización** que nos ha llamado para que resolvamos el o los problemas que tienen. Se incluyen datos como el *nombre* de la organización, su *tipo* (S.A, S.R.L, S.H), a *qué se dedica* y *cómo está distribuida físicamente* (si tiene sucursales, donde están). 2. Sponsor ---------- El **sponsor** es quien impulsa el proyecto (que le interesa que sea exitoso). Generalmente es la persona que nos contrata (aunque podría no serlo). 3. Objetivo de mandato ---------------------- En esta sección se transcriben los **problemas** y **necesidades** que nos plantea el cliente. Debe tenerse en cuenta que solamente indicaremos aquellos que **pueden solucionarse con el desarrollo de un sistema de información.** Para ello, en esta etapa hay que ponerse de acuerdo con el cliente sobre sus expectativas sobre nuestro trabajo, informando lo que se escapa del alcance de nuestra tarea. *Debe indicarse claramente **cuál es el alcance del problema.*** 4. Estructura de la organización -------------------------------- Se adjunta el organigrama de la organización confeccionado por nosotros. Aquí algunas consideraciones: ### 4.1 Confección de organigramas Un **organigrama** es una representación parcial, mediante un diagrama, de la estructura formal de una organización. En él se muestran las funciones, sectores, jerarquías y dependencias internas. *Todos los modelos tienen limitaciones que dependen de la capacidad del observador* Los organigramas destacan por mostrar parte de la estructura formal y así relucir los defectos de la organización, sin embargo, no se puede ver su totalidad y son estáticos. #### Algunas definiciones previas **División del trabajo**: es la separación de una actividad compleja en componentes, con el objetivo de que [las personas sean responsables de un conjunto limitado de actividades y no de la actividad como un todo.] *El trabajo se expande mediante técnicas que evitan el aburrimiento de los empleados por la repetición.* **Departamentalización**: agrupación de actividades con un criterio predeterminado. Estos criterios se determinan según una necesidad, por ende, no se pueden mezclar en un mismo sector. \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- - La **división del trabajo** se centra en **desagregar tareas**, mientras que la **departamentalización** se enfoca en **agruparlas** en unidades organizacionales. - La **división del trabajo** es un **proceso**, mientras que la **departamentalización** es un **resultado**. - La **división del trabajo** busca la **eficiencia**, mientras que la **departamentalización** busca la **formalización y coordinación**. \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- Los diferentes tipos de **criterios** son: funcional, producto/servicio, área geográfica, segmento de mercado, cliente, volumen de venta. *Si se departamentaliza mal, se desequilibra la estructura, hay mala remuneración, falta la unidad de mando, se impide la comunicación, y se superponen las funciones.* #### 4.1.1 Errores en los organigramas - **Dualidad de mando**: si [un sector recibe órdenes de dos sectores diferentes] (falta unidad de mando). - **Delegación efectiva**: [lo que hace tal sección, lo puede hacer otra.] - **Alcance de control**: [un jefe recibe más subordinados de los que puede manejar.] - **Homogeneidad operativa**: [una tarea no puede ser hecha por alguien que no le corresponda.] #### 4.1.2 Simbología de los organigramas - Entegrama: es un [recuadro con el nombre de la entidad.] - Líneas de dependencia: son [entre entegramas], de manera vertical (jerárquica) u horizontal (funcional). - Líneas de asesoría: [líneas punteadas horizontales entre entegrama-asesoría.] #### 4.1.3 Terminología de los organigramas - Línea de mando: flujo de relaciones e información en una organización. - Estructura organizacional: [vertical] (dada por la autoridad) u [horizontal] (por la funcionalidad). - Excesiva departamentalización: muchas gerencias saliendo de una sola gerencia. - Excesiva burocracia: una única tarea debe pasar por más sectores de los necesarios. #### 4.1.4 Convenciones y reglas de los organigramas - **Mismo tamaño** de entegramas - **Mayor nivel jerárquico a nivel superior** (igual nivel, igual altura) - **No aislar entegramas** - A un **entegrama** se llega o se sale por una sola **línea vertical** - **No puede haber un entegrama que tenga una línea sin conexión** - Gráfico como **pirámide** - Siempre que sea una **S.A** deben graficarse **A.G.A** y **Directorio** - Secretarias sin acento no se grafican - **Jerarquía de mayor a menor**: - [Gerente general] - [Gerencias] - [Departamentos] - [Secciones] - [Oficinas]. 5. Áreas y funciones ==================== En esta sección deben detallarse **todas las áreas de la organización** y qué hacen (es decir, sus funciones). El prototipo sería algo como esto: +-----------------------------------------------------------------------+ | **Departamento de compras:** | | | | - Seleccionar los posibles proveedores | | | | - Realizar compra de productos | +-----------------------------------------------------------------------+ **Importante:** Se deben especificar las funciones que tiene cada área (es decir **qué** hace cada una), no *cómo* lo hace. Tampoco se debe incluir las tareas que hace como, por ejemplo: archivar, enviar un documento a otro sector, etc. (pues son *medios para una tarea*). **No debemos confundir tareas con funciones**. Las **tareas** suelen ser más **rutinarias** mientras que las **funciones** se identifican por ser **únicas en su área o sector.** 6. Problemas y/o necesidades ============================ Si durante la entrevista detectamos que existen otros **problemas** que el cliente no planteó como necesidad inicial, lo listamos aquí para después corroborarlo con él, puede ser que se incluya en el objetivo de mandato o el cliente no esté interesado o no pueda incluirlo en este momento. Tengamos en cuenta que nuevamente estos problemas y/o necesidades deben poderse satisfacer desde el punto de vista de sistemas de información y deben estar dentro del alcance del sistema que se definió con el cliente. 7. Conclusión ============= Con la información obtenida en la etapa de reconocimiento podemos planificar cuáles serán las **áreas para relevar** que están vinculadas con la problemática planteada, donde la búsqueda de información del funcionamiento de la organización debe ser exhaustiva. En esta sección indicaremos cuáles serán esas áreas, utilizando el siguiente prototipo: -------------------------------------------------------------------------------------------------------------- *"Consideramos que es necesario relevar las áreas \_\_\_\_\_, \_\_\_\_\_ y su relación con las demás áreas"* -------------------------------------------------------------------------------------------------------------- 8. Datos faltantes ================== Esta sección **NO** se incluye en un informe real, si nos falta algún dato (como por ejemplo la dependencia de algún área o la función) debemos ir a obtenerlo del cliente. A los efectos didácticos, como no podemos ir a consultar, lo dejamos indicado aquí, para marcar que es información que debemos ir a buscar. *Por ejemplo: faltan las funciones del sector \_\_ o no se indica la dependencia del departamento \_\_.* Capítulo III: Diagrama de Flujo de Datos ======================================== Para introducir el **diagrama de flujo de datos**, primero debemos hablar del *análisis estructurado de sistemas*. 1. Análisis estructurado de sistemas (ADS) ------------------------------------------ Es una metodología que permite establecer **qué es lo que el sistema hace** o deberá hacer, **sin importar** **cómo** lo hace o hará (es abstraerse de la complejidad de situaciones). Permite **definir** un modelo lógico del problema en estudio. El *modelo lógico* es el resultado de un proceso mental de representación abstracta de la realidad, es decir separar el *qué* del *cómo*, no es lo usual para el humano (por eso el primer requisito de esta metodología es cambiar la mentalidad). Es una forma específica de hacer el **análisis funcional lógico**, es decir, estudiar un sistema teniendo en cuenta que estará compuesto de funciones lógicas que se relacionan entre sí (a través de datos). En términos programáticos, se utiliza el *paradigma de programación estructurada*. 2. Diagrama de Flujo de Datos (DFD) ----------------------------------- El **diagrama de flujo de datos** es una técnica de análisis estructurado mediante la cual el profesional de sistemas puede reunir en una representación gráfica, los procesos de datos de la organización. Permite modelar todo tipo de sistemas, concentrándose en las funciones que realiza y la información que intercambia con el contexto (es decir, lo ajeno a la organización). Para realizar un DFD, se deben hacer algunos pasos que van de lo general a lo específico, son: ### 2.1 Diagrama de contexto (DC) El **diagrama de contexto** permite representar el sistema en estudio de forma tal que de un vistazo se pueda apreciar el **sistema** y su **interacción** con el medio conocido. *Es una instancia inicial de un DFD (se lo conoce como DS de nivel 1). Es posible hacer un DC y nunca pasar a la siguiente instancia: tabla de eventos.* #### #### 2.1.1 Elementos del DC El diagrama de contexto tiene los siguientes tres elementos: - **Sistema**: función que representa el sistema modelado. Su representación gráfica es: +-----------------------------------+-----------------------------------+ | | **Representación gráfica** | | | | | | - Se identifica con el número | | | cero | | | | | | - Tiene un *nombre* (es una | | | breve descripción de lo que | | | hace) | +-----------------------------------+-----------------------------------+ - **Entidad externa**: Es todo lo que se relaciona con el sistema pero que **no opera** en el sistema (no significa que no pertenezca), solo brinda o recibe información del sistema. +-----------------------------------+-----------------------------------+ |  | **Representación gráfica** | | | | | | - Tiene una *letra* que lo | | | identifica | | | | | | - Tiene un *nombre* que lo | | | representa | +-----------------------------------+-----------------------------------+ - **Flujo de datos**: Representan el movimiento de datos entre el sistema y su contexto. Se dibujan a través de una flecha (en sentido hacia donde va el flujo). El nombre indica la *información* que transporta, no el medio: **Importante**: No deben ponerse nombres de **formularios físicos** (factura, remito) ni tampoco utilizarse las palabras **datos** o **información**. -- -- ### 2.2 Tabla de eventos (TE) Un **evento** es un **suceso** **que provoca que el sistema tenga una reacción** y tenga que emitir alguna **respuesta**. La **tabla de eventos** identifica y enumera los eventos (es decir, los sucesos donde el sistema ante determinada acción externa o interna genere respuestas para el sistema o el contexto). Esta tabla se usará como base para diseñar los diagramas de sistemas, por ende, un error en la definición de eventos significará tantos errores como cantidad de diagramas de sistemas. #### 2.2.1 Entradas de la tabla de eventos La tabla tiene este prototipo: ------------- ------------- ---------- ----------- ------------------ Tipo Descripción Estímulo Respuesta Proceso Asociado Externo Temporal Desconocido ------------- ------------- ---------- ----------- ------------------ - **Tipo**: representa quién o qué inicia el evento, es ***externo*** (si lo inicia una entidad externa) y es ***temporal*** (si comienza por acción del tiempo; *todos los viernes...*) *Se agrega también el tipo **desconocido** para cuando se desconoce quién lo inicia, sin embargo, es tarea del profesional de sistemas indagar sobre esto para clasificarlo.* - **Descripción**: es una breve descripción del evento (*Cuando el cliente se presenta en caja.. Todos los lunes..*) - **Estímulo**: en caso de ser un evento **externo**, se indica el flujo activador del evento (que coincida con el *DC*). Si es un evento **temporal**, se pone "-" ya que el estímulo es el tiempo, si es **desconocido** un "?" para preguntar quién lo inicia. - **Respuesta**: se indican todos los flujos de datos que genera como salida el evento al terminar (deben coincidir con el *DC*). - **Proceso asociado**: es el nombre del proceso a la que asociamos el evento. Tiene que ser un **verbo en infinitivo** (*Recibir productos*) y luego será el nombre de los sistemas del *DS*. ### 2.3 Diagrama de sistemas (Nivel I) En el **diagrama de sistemas** (DS) se busca documentar con mayor grado de detalle el sistema. Los flujos de entrada y salida del nivel 0 se mantienen en todos los diagramas siguientes. Ahora, el *proceso 0* se reemplaza por el primer proceso asociado de la tabla y los demás (enumerando *2,3...*). En el nivel 1 van a aparecer nuevos flujos de datos, ya sean los que se desconocían del *DC* o las salidas del sistema de las que se desconocía su paradero. Al ampliar el proceso 0 para representar subprocesos, el analista comienza a completar los detalles de los movimientos de datos, para lo que se incorpora la **demora**. #### 2.3.1 Demora Una **demora** indica un depósito de datos, el cual permite la adición y acceso de los datos, es información que tiene diferencia de tiempos entre su generación y su utilización. +-----------------------------------+-----------------------------------+ |  | **Representación gráfica** | | | | | | - Se identifica con una D*n* | | | (*n* es el identificador de | | | demora) | | | | | | - Tiene un *nombre* que | | | representa la información que | | | contiene (no puede coincidir | | | con ningún flujo ni elemento) | +-----------------------------------+-----------------------------------+ *Los flujos que entran y salen de una demora tienen que ser los mismos, porque la información solo se almacena, no se transforma.* #### 2.3.2 Vinculación de procesos En este nivel aparecen los flujos que vinculan procesos. Todos los procesos deben estar vinculados a través de demoras (por eso, la cantidad de flujos del *DS* siempre es mayor a la del *DC*). Los procesos se identificarán con un número (*comenzando por el 1*) y su nombre será el mismo que el proceso asociado en la *tabla de eventos*. #### 2.3.3 Inicialización de procesos Si el evento es *externo*: +-----------------------------------+-----------------------------------+ | | **Evento externo** | | | | | | - Se debe marcar el flujo | | | externo *activador* con una | | | flecha doble | | | | | | *La flecha es doble para | | | diferenciarla del resto de | | | flujos.* | +-----------------------------------+-----------------------------------+ Si el evento es *temporal*: +-----------------------------------+-----------------------------------+ |  | **Evento temporal** | | | | | | - Se le coloca la letra **T** | | | en un círculo en la esquina | | | derecha | | | | | | *Esto sucede ya que no tiene un | | | flujo activador, sino que es el | | | tiempo quien activa.* | +-----------------------------------+-----------------------------------+ Si el evento es *desconocido*: +-----------------------------------+-----------------------------------+ | | **Evento desconocido** | | | | | | - El flujo activador no tiene | | | nombre, y viene de un "?" | +-----------------------------------+-----------------------------------+ #### 2.3.4 Disposición del dibujo La disposición del dibujo debe ser de manera tal que en el centro se dibujen los procesos y demoras del sistema y por fuera queden las entidades externas. *Debo poder delimitar con línea punteada el contexto del sistema de esta forma:*  Las demoras deben pertenecer al sistema, y cada proceso demora los datos hasta el momento en que los necesite, siendo que los flujos que van hacia el contexto externo no se demoran (no nos interesa cómo administran el retardo de una información, en tal caso, se verá en su *DS*). ------------ ------------------------ **Así si** **Así no**  ------------ ------------------------ Por otro lado, la manera correcta de vincular procesos es que uno genere información para la demora y el otro la utilice, no es necesario que todos los procesos se vinculen entre sí, pero si levanto imaginariamente un proceso el resto deben estar enganchados a ese a través de demoras. ------------------------  ------------------------ #### 2.3.5 Consideraciones del DFD - Los **procesos** deben **transformar información**. Si no detectamos la transformación y la función solamente consiste en transmitir una información demorada, entonces NO es un proceso. - Todos los **procesos** **deben ser activados**, o por un flujo activador (doble línea) o por el tiempo. - Cada evento detectado en la tabla de eventos es un proceso descrito en el Nivel 1. - **Todos los procesos deben relacionarse con al menos uno de los demás procesos** a través de una o varias demoras. - Todos los **procesos** deben tener **al menos una entrada y al menos una salida** que represente la transformación de la información. - Tanto el **DC, la TE y el Nivel 1** **deben tener consistencia de información**, es decir, respetar los mismos nombres descritos para cada flujo, entidad o proceso, sino es erróneo. - Todas las entradas en un Nivel 1 deben estar demoradas, **excepto el flujo activador de un evento externo**, y un **flujo de tipo Consulta/Respuesta.** - Ninguna salida hacia Entidades Externas debe ser demorada. - **Si una Entidad se repite** dentro del gráfico, (por una cuestión de claridad), entonces **debe marcarse con una línea en la esquina** superior en todas las repeticiones correspondientes. - **Si una Demora se repite dentro del gráfico**, (por una cuestión de claridad), entonces **debe marcarse con una doble línea** que separe el número y el nombre, en todas las repeticiones correspondientes. - **Todas las demoras deben tener al menos una entrada y una salida**, si no existe tal situación debe colocarse un flujo de entrada o salida (según corresponda) con un **signo de interrogación** indicando que se desconoce la entrada/salida de esa demora. Si la demora se repite no hace falta volver a indicar la entrada o la salida #### 2.3.6 Otros niveles además del 1 Cada proceso del Diagrama de Sistemas puede a su vez ser explotado para crear un diagrama más detallado. No es necesario explotar todos los procesos, solo se realizará esta acción en aquellos procesos cuyo nivel de complejidad así lo ameriten. En el nivel siguiente, llamado Nivel 2, la vinculación entre los procesos (que llamaremos hijos, los cuales surgieron de explotar un proceso padre del nivel 1), se realiza a través de un Flujo de Datos que va directo de proceso a proceso. Los procesos que aparecen en el Nivel 2 son numerados usando el número del proceso que se había utilizado en el Diagrama de Sistema y se le agrega un punto decimal y un número único para cada proceso. Por ejemplo, si el proceso 3 se explotó en el Nivel 2 en 3 procesos, la numeración de cada uno de ellos será: 3.1, 3.2, 3.3 ### 2.4 Diccionario de datos El **diccionario de datos** (DD) es un listado organizado de todos los datos que pertenecen a un sistema. El objetivo es dar precisión sobre los datos que se manejan en un sistema (para evitar malas interpretaciones o ambigüedades). El diccionario recopila y coordina términos de datos específicos y confirma lo que cada término significa para las diferentes personas de la organización. Los elementos por definir en el DD son las ***demoras*** y los ***flujos de datos*** (distinguiendo cuáles pasan por demora y cuáles no) #### 2.4.1 Ejemplo Si se tiene el siguiente ejemplo:  Así se definen la demora y el flujo de datos (que pasa por demora y el que no): +-----------------------------------+-----------------------------------+ | **Definición de la *demora*** | **Especificaciones** | | | | | SOCIO\_CLUB (DEM) | Toda la estructura de datos | | | (**ED**) debe tener una clave | | D1 | para ser identificada. | | | | | S\_CLUB | La *clave* es un dato o grupo de | | | datos que resulten lo | | S\_CLUB (ED) | suficientemente significativos | | | para representar la estructura en | | [ID\_SOCIO] | forma única y mínima | | | | | APELLIDO Y NOMBRE | | | | | | DIRECCIÓN | | | | | | LOCALIDAD | | | | | | CÓDIGO POSTAL | | | | | | TELÉFONO PARTICULAR | | | | | | CELULAR | | +-----------------------------------+-----------------------------------+ +-----------------------------------+-----------------------------------+ | **Definición de *FD* *que pasa | **Definición de *FD* no *que pasa | | por demora*** | por demora*** | | | | | SOC (FD) | PED\_CONV (FD) | | | | | ?-D1 | A - 1 | | | | | D1-1 | P\_CONV | | | | | S\_CLUB | P\_CONV (ED) | | | | | | [ID\_CONV] | | | | | | NOMBRE CONVOCATORIA | | | | | | FECHA CONVOCATORIA | | | | | | FECHA VENCIMIENTO | +-----------------------------------+-----------------------------------+ Como vemos en el ejemplo, los flujos de datos que entran o salen de demoras contienen la misma estructura de datos que la demora, esto tiene sentido ya que la información que contiene la demora es transportada hacia o desde la misma por el flujo de datos de entrada o salida, sería impensable que los FD transporten otra información. *Por último, como cualquier diccionario, el diccionario de datos debe estar ordenado alfabéticamente.* **2.5 Definición de procesos** La definición de procesos es una herramienta de modelado de sistemas, que permite definir qué sucede en los procesos o funciones de un sistema. El objetivo es definir **qué** **debe hacerse** **para transformar ciertas entradas en ciertas salidas**. No hay una única forma de realizar la definición de procesos; existen múltiples herramientas que facilitan esta tarea. Algunas herramientas utilizadas para generar definiciones de procesos son: - Lenguaje estructurado: define un algoritmo con un lenguaje de pocas palabras que [agrega precisión y claridad] (evitando ambigüedades) - Tablas de decisiones: se deben [definir condiciones, acciones y reglas]. Además la tabla debe ser [lo más simple posible.] - Otras herramientas son los *DFD*, lenguaje narrativo, etc. Capítulo IV: Requerimientos =========================== Un **requerimiento** es una **necesidad** o solicitud **cuyo objetivo es resolver un problema** (ej. *requiero un nuevo integrante para el grupo*) Un **requisito** es una **condición** o característica necesaria para algo (ej. *para entrar en la UTN se debe hacer el curso de ingreso*). Por lo tanto, los **requisitos** son condiciones que debe tener un sistema (*requerimientos del sistema*) para satisfacer las necesidades del usuario (*requerimientos del usuario*) 1. Requerimientos en la metodología ----------------------------------- - En el **reconocimiento**, a partir del objetivo de mandato [se detectan los *requerimientos del usuario*] - En el **relevamiento** [se relevan y documentan los *requerimientos del usuario*.] - En **análisis de requisitos**, [se definen los *requerimientos del sistema*] que deberá tener [para cumplir con los *requerimientos del usuario*.] 2. Importancia de los requerimientos ------------------------------------ Malos procesos de ingeniería de requisitos hacen fallar proyectos (de forma in/directa) ya que no reflejan las necesidades reales, son ambiguos, difíciles de implementar o muy costosos de dinero. En la mayoría de las organizaciones se comienza a programar demasiado pronto, tratando de producir código velozmente pero **poco eficaz** (lo que lleva a tener que rehacer algo que podrían haber definido mejor desde un principio, es *retrabajo*) respecto de los requisitos del sistema. Un requerimiento *correctamente definido* tiene que ser **completo** (la información no está dividida), **no ambiguo**, **verificable** (se debe probar su cumplimiento) y **consistente** (sin contradecir otros requerimientos). ### 2.1 Ventajas de un requerimiento correctamente definido - Se identifican riesgos de manera temprana - Análisis y desarrollo claro y rápido (evitando el *retrabajo*) - Generan buenas bases que desembocan en un buen diseño - Implementación más amena de casos de prueba 3. Tipos de requerimientos -------------------------- Existen dos tipos, funcionales y no funcionales. ### 3.1 Funcionales Los **requisitos funcionales** **describen** **funcionalidades** del sistema, es decir, **qué hace** el sistema (su comportamiento específico). Describen la transformación de entradas en salidas. Deben estar redactados de forma comprensible para el usuario, sin tecnicismos. *A veces conviene describir lo que **no** hace el sistema*. ### 3.2 No funcionales Los **requisitos no funcionales** son **atributos** o características que **definen cómo** el sistema hará su trabajo. Son las restricciones de los requerimientos funcionales. En otras palabras, describen cómo será el sistema. Se clasifican de las siguiente forma: #### 3.2.1 De producto o calidad Son restricciones sobre cómo se comporta el sistema: - **Mantenibilidad**: debe poder cambiar sin generar mucho impacto - **Usabilidad**: debe ser amigable para el usuario - **Performance**: debe ser eficiente - **Disponibilidad**: debe estar disponible a todas horas, todos los días - **Seguridad**: debe proteger la información sensible que maneja el sistema #### 3.2.2 Organizacionales Se derivan de políticas y procedimientos de la organización - **De entorno u organizacionales**: describen cómo debe ser usado el sistema en la organización - **De diseño, desarrollo e implementación**: lenguaje de programación, estándares de código y herramientas varias para el manejo de software. - **Externos**: Pueden ser **regulatorios** (leyes que debe cumplir el sistema), **éticos** (se adapte a la sociedad) y **legislativos** (características del sistema para el cumplimiento de las leyes). ###### Observación No siempre será fácil distinguir entre requerimientos funcionales y no funcionales, por ejemplo: La seguridad puede interpretarse inicialmente como un requerimiento no funcional al principio. No obstante, su elaboración puede conducir a nuevos requerimientos funcionales, como la necesidad de autentificar a los usuarios del sistema. ::: {.section.footnotes} ------------------------------------------------------------------------ 1. ::: {#fn1} Def. de sistema[↩](#fnref1){.footnote-back} ::: :::