Informática Médica 2015 Agregarse al grupos fb Web: https://www.facebook.com/groups/infor maticamedica.unt.2015 https://www.facebook.com/groups/infor maticamedica.unt.2015https://www.facebook.com/groups/infor.

Slides:



Advertisements
Presentaciones similares
SISTEMAS DE INFORMACIÓN I
Advertisements

Fundamentos de Diseño de Software INFT.1
Gestión de los recursos informáticos Unidad Nº 1: Introducción y proceso de la administración estratégica.
La investigación La construcción del conocimiento.
DISEÑO ORIENTADO AL OBJETO
TEMA 8: DIAGRAMAS EN UML.
Conceptos generales metodología levantamiento de procesos
Es una secuencia lógica de actividades, u ordenamiento de actividades para producir un resultado.
Interacción Persona ordenador
PROCESOS EN INGENIERÍA INDUSTRIAL
PARADIGMAS DE LA EVALUACIÓN
INGENIERIA DE REQUERIMIENTOS
Unidad I: CONCEPTOS FUNDAMENTALES
Una Introducción a UML El Modelo de Proceso de Negocio
DSOO - María Eugenia Valencia
Capítulo 3 Etapas de un Proyecto de simulación
Sistemas Evolutivos Introduccion.
UNIDAD I Conceptos Básicos.
“Especificación de Requerimientos”
Propuesta de una metodología para el desarrollo de proyectos informáticos empleando la herramienta para el diseño automatizado GeneXus Autor: Dipl.-Ing.
Arquitectura de una aplicación
Ingeniería de Software Orientado a Objetos
Técnicas para la obtención de requerimientos
Las etapas de un proyecto
Fundamentos de Ingeniería de Software Facultad de Ingenieria Universidad Distrital Francisco José de Caldas ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS.
INVESTIGACIÓN CIENTÍFICA
5.3 APROXIMACIONES AL DISEÑO
 La Monografía El Informe.
AUDITORIAS DE SEGURIDAD
Planteamiento del problema y Justificación
UNIDAD 2. ALGORITMOS Y ESTRUCTURAS DE DATOS.
CONCEPTOS BÁSICOS Diseño de Sistemas.
Ingeniero de Software. MODELO DE LA Descripción del Proyecto “Software para la Administración de un Foro Conversacional” Escrito de acuerdo a la Norma.
Análisis de Sistemas.
Organización y Estructuración de Datos
Universidad Central de Venezuela Facultad de Ciencias Postgrado en Ciencias de la Computación Sistemas Distribuidos Albany Márquez.
FUNDAMENTOS DE PROGRAMACION
PLANEAMIENTO DE LA INVESTIGACIÓN
Organización y Estructuración de Datos Profesor Titular: Mg Carlos G. Neil 2009.
Diseño De Sistemas Catedrático: Ing. Ezequiel Santillán A. Miércoles, Febrero09, 2011 T í t u l o: ANALISIS DE SISTEMAS (REQUERIMIENTOS)
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
Trainning DFD.
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
conjunto de elementos que interactúan con un objetivo común
Tecnologías para el Aprendizaje
ELEMENTOS DE CONTENIDO Y ALCANCE
El Proyecto     Proyectar acciones sistemáticas y fundamentadas, con un objeto definido y metas claras y factibles. Surge como una intervención grupal.
PRESENTACIÓN Este trabajo se desarrolla sobre el tema de competencias, y basado en el Marco de Fundamentacion Conceptual Especificaciones de la Pruebas.
Ingeniería de Software
PROYECTO TECNOLÓGICO Mateo Guerra Alzate Cristian Herrera 9-D I
Ciclo de vida de un sistema
Introducción al análisis de sistemas
Ingeniería de Requisitos
Proyecto:”ZeuSystem Clínica Madre de Dios”
Unidad I: CONCEPTOS FUNDAMENTALES
Análisis y Diseño de Aplicaciones
Elementos de información
Actividades en el Proceso de desarrollo de Software
ANÁLISIS ESTRUCTURADO
Dra. Ma. Candelaria Ochoa A.
COMPETENCIA: planifica los procesos de enseñanza/aprendizaje atendiendo el enfoque por competencias y los ubica en contextos disciplinares, curriculares.
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Los proyectos de Ingeniería
ANALISIS SEGURO DE TRABAJO (AST)
República Bolivariana de Venezuela Universidad Nacional Experimental Politécnica de la Fuerza Armada (UNEFA) Carrera: Ingeniería de Sistemas Cátedra: Análisis.
Maestría en Gerencia en Tecnología de la Información Cátedra Ingeniería de Software Profesora: Mary Carmen Milano. Integrantes: Rosa Arellano Osbaldo Goitia.
Identificación de entradas, salidas y herramientas de procesos de gestión del PMI Jairo A. Orozco L.
Fundamentos de Ingeniería de Software
Presentación De UML Lenguaje estándar para escribir planos de software Se usa para visualizar, especificar, construir y documentar los artefactos de un.
Entregables del Proyecto
Transcripción de la presentación:

Informática Médica 2015 Agregarse al grupos fb Web: maticamedica.unt maticamedica.unt.2015https:// maticamedica.unt.2015 O buscarlo en fb como: Informática Médica UNT 2015

Contenidos  Modelos  Sistemas  Evaluación de requisitos informáticos

MODELOS En términos generales cualquier aspecto de la realidad circundante es extremadamente complejo. No podemos comprenderlo con la sola percepción. Imaginemos por ejemplo: Nuestro primer día en la Universidad, u observemos una plaqueta circuital como la Mother Board de una PC. Además hay diferentes puntos de vista desde los que se puede ver la realidad, y eso responde a necesidades. Punto de vista Nivel de profundidad

MODELOS: Ejemplo Universidad Rectorado Facultad de Medicina Facultad de Cs. Ex. Y Tec. Facultad.... Departamentos Cátedras Punto de vista 1: Estructura académica Punto de vista 2: ingresos y egresos Fondos del Estado Nacional Aportes por convenios de Transferencia al medio Aportes de Alumnos Financiamiento Externo UNT Sueldos Material Didáctico Equipamiento, mobiliario Financiamiento Proyectos de Investigación En cualquier caso, además de distintas, no son descripciones completas, son solo simplificaciones que nos ayudan a entender una organización compleja como es la Universidad. Son dos modelos distintos de la misma Universidad. También cambiar el nivel de detalle ( “granularidad del modelo”): quiero ver los egresos generales de la UNT, o analizar en profundidad la planilla salarial.

Realidad Representaciones MODELOS: Representación

SISTEMAS Vamos a dirigir nuestra atención a sistemas informáticos aplicados a la salud o a la administración de la salud. Tenemos que ver entonces: Que es un sistema Sistemas de información en el ámbito de la salud Definición: Sistema: Es un conjunto de componentes actúan en forma interrelacionada para algún propósito determinado.

SISTEMAS Podemos subdividirlos en: Sistemas Naturales Sistemas Artificiales En todos los casos, y partiendo de la definición, nos interesa analizar: Componentes de un sistema Interacciones de componentes entre sí (y también con otros sistemas) Propósito de un sistema

SISTEMAS Componentes: Corazón Arterias Venas Capilares Interacciones: Corazón bombea sangre por el circuito arterio- venoso Propósito: Intercambio de elementos Interacciones con otros sistemas: Intercambia elementos con diferentes tejidos. Recibe estímulos del SNC.

SISTEMAS INFORMÁTICOS (SI) Los SI son sistemas hechos por el hombre y en general tienen los siguientes componentes: Hardware Software Información Procedimientos Además interactúan entre si, y tienen por objetivo procesar la información en algún sentido particular.

SISTEMAS DE INFORMACION Ingeniería de sistemas: proceso de diseño, desarrollo y producción sistemas artificiales de forma lógica y ordenada. Especificando los componentes y sus interrelaciones, en función de una especificación de interacción con el medio (propósito). En el caso particular de la ingeniería de sistemas informáticos (SI), el medio es la organización cuyos procesos de información se propone automatizar.

MODELOS Y SISTEMAS DE INFORMACION Ninguna organización de salud actual puede procesar la información que debe manejar al margen de la informática. Nuestro objetivo es poder pensar un sistema de información automatizado (sistema informático - SI), que responda al modelo de sistema de organización en que estamos insertos. Para eso debemos conocer la organización real, lo hacemos a través de modelos que expresen los aspectos del sistema de información subyacente en la organización.

 La organización (de salud, por ejemplo) tiene protocolos, costumbres, etc.: Como se compran insumos. Como se compran insumos. Como se gestiona la reparación de equipos Como se gestiona la reparación de equipos Como se resuelve una emergencia Como se resuelve una emergencia Como se deriva un paciente de un sector a otro Como se deriva un paciente de un sector a otro Como se organizan turnos de guardias Como se organizan turnos de guardias Etc. Etc. MODELOS Y SISTEMAS DE INFORMACION

Roles (algunos) informáticos y el modelo de información: Analista Diseñador Programador Modelo II: Expresado en lenguaje de máquina Modelo I: Organización actual Modelo II: Organización automatizada Modelo II: Expresado como diseño de sistema Modelo II: Expresado en lenguaje de programación Representaciones

Construir un Sistema de Información (SI) requiere de la comprensión del dominio a informatizar. Nuestra comprensión se expresa en modelos, así que nuestro primer objetivo es construir un modelo del dominio. El dominio se define por los límites de lo que tenemos en cuenta para informatizar: Dominio no necesariamente es una organización completa (Hospital por ejemplo), puede ser Consultorios Externos, Laboratorio, Historias Clínicas, Administración de personal, etc. O sea, un subsistema de la organización. El dominio es algo que tenemos que definir con quienes requieren el sistema informatizado: Clientes, Sponsors, etc. (stakeholders) Organización Dominio Modelo de dominio

SISTEMAS INFORMÁTICOS – INGENIERIA DE REQUISITOS Tarea inicial: Definir los límites del SI, y desde ahí su interacción con otros sistemas. Esto significa definir el dominio a abarcar por el SI. Suele ser un proceso Con quienes requieren el sistema informatizado: Clientes, sponsors, etc. (stakeholders) Herramienta para definirlo: Diagrama de contexto

Diagrama de Contexto: Hospital Pacientes Gobierno Obras Sociales Otras Fuentes Hospital Entidades No Gubernamentales, aportes externos, etc. Requieren informes de la institución, de resultados, uso de fondos, etc. Fondos, insumos, designación de personal, etc. Requieren informes de la institución, de resultados, uso de fondos, etc. Requiere atención, certificados. Entrega documentación personal, médica, insumos, medicamentos, etc. Reciben facturación por servicios. Pagan servicios. Un Servicio de salud es un sistema que tiene la misión de atender requerimientos de salud en un contexto social determinado

Diagrama de Contexto: Hospital Permite hacer abstracción del contenido del sistema (caja negra). Permite ver el sistema en su relación con el medio externo: Su propósito Que componentes (o actores) externos interactúan con el sistema Que es lo que intercambia (dinero, servicios, información, insumos, etc.) A partir de esto, la pregunta es: ¿que ocurre en el sistema para dar respuesta a esas interacciones? ¿Para que hacer un diagrama de contexto?

SI – INGENIERIA DE REQUISITOS Participantes en el desarrollo de un SI: Cliente Financiador Usuario Otros expertos del dominio Informáticos

¿ Por qué participan “todos” en la construcción del modelo? Cada uno es el experto en sus tareas. El desempeño del futuro sistema de información va a afectar el modo en que realizan sus tareas. Al convocar a la participación hay que tener en cuenta que: Son diferentes intervinientes, cada uno con sus visiones del problema y sus intereses. Provenientes de formaciones diferentes, cuando no de culturas diferentes. SI – INGENIERIA DE REQUISITOS Modelo Conceptual Necesitamos una comprensión común del dominio, que lo describa y que permita interactuar con los interesados (stakeholders). Esto es, un modelo descripto con lenguaje y símbolos de fácil comprensión. Ese modelo se denomina MODELO CONCEPTUAL. Hay que tener en cuenta que el modelo conceptual es nuestro punto de partida, si nos equivocamos con el, lo que construyamos será equivocado.

 Modelo de dominio es un modelo, bajo cualquier tipo de representación, referido al dominio en cuestión: Los modelos técnicos con los que trabajan los programadores. Los modelos técnicos con los que trabajan los programadores. Los modelos de organización (organigramas, workflows, etc.) Los modelos de organización (organigramas, workflows, etc.) Los modelos conceptuales Los modelos conceptuales  Modelo conceptual: no es necesariamente técnico, ni restringido a una representación, pero que expresa los componentes, interrelaciones y propósito del sistema. ¿Modelo de dominio? ¿Modelo conceptual?

SI – INGENIERIA DE REQUISITOS Modelo Conceptual El modelo conceptual tiene por objeto la comunicación entre los stakeholders, y su representación debe tener en cuenta eso. Definimos que es el modelo conceptual y su importancia en el proceso de informatización. Ahora vamos a ver como se construye.

SI – INGENIERIA DE REQUISITOS Modelo Conceptual La construcción de modelo es un proceso, con los stakeholders, de carácter incremental. Esquemáticamente: Se toma conocimiento: Se elicita Se construye el modelo: Se especifica Se comprueba con los stakeholders: Se valida Cuando el objetivo es informatizar, junto a la construcción del modelo actual, se desarrollan las especificaciones del modelo futuro. La disciplina que estudia el modelo actual y genera el modelo futuro se conoce como Ingeniería de Requerimientos o Requisitos

Elicitación Elicitar Del inglés: To Elicit sonsacar.(De son- y sacar) 1.tr. Sacar arteramente algo por debajo del sitio en que está. 2.tr. Procurar con maña que alguien diga o descubra lo que sabe y reserva. 3.tr. Solicitar secreta y cautelosamente a alguien para que deje el servicio u ocupación que tiene en alguna parte y pase a otra a ejercer el mismo o diferente empleo. Real Academia Española

Ingeniería de Requerimientos - Técnicas Entrevistas (Elicitación) Observación (Elicitación) Estudio de documentación (Elicitación) Diccionario, LEL (Elicitación, Especificación) Análisis de tareas (Elicitación, Especificación) Metas y objetivos (Elicitación, Especificación) Casos de Uso (Elicitación, Especificación) Escenarios (Elicitación, Especificación) Prototipado (Elicitación, Especificación, Validación) Es una tarea eminentemente social, más que de implementación tecnológica. Entre las técnicas para llevarla a cabo:

Elicitación - Técnicas - Entrevistas Pueden realizarse con cualquiera de los interesados. Sus características varían de acuerdo a nuestro estado de conocimiento:  Entrevistas para obtener conocimiento general de algunos aspectos del dominio. P.Ej.: ¿Que información se requiere del paciente cuando solicita ser atendido por un médico? ¿Cuántos turnos por médico se dan diariamente? ¿Dónde y como se guardan las Historias Clínicas?  Con un conocimiento del dominio más avanzado, las entrevistas puedes ser más específicas respecto de dudas puntuales. P.Ej.: si el paciente pertenece a una obra social, ¿Qué documentación se requiere para después poder facturarle?

Elicitación - Técnicas - Entrevistas En la mayoría de los casos hay aspectos comunes a tener en cuenta: Previamente conviene: Elaborar cuestionarios. Planificar la entrevista. Durante conviene: Documentar: grabando, anotando. Posteriormente conviene: Elaborar después, reestructurando las preguntas y respuestas.

Elicitación - Técnicas - Estudio de documentación Estudio de documentación En muchos casos es la base del sistema de información actual, consiste de formularios, reglamentos que fijan el alcance de tareas, documentación a cumplimentar, etc. También puede agregarse el análisis de sistemas informáticos viejos (p.ej. el que está por reemplazarse).

Elicitación - Técnicas - Observación Son siempre técnicas complementarias (En SI). Observación In Situ Permite tener un panorama de actores, concurrencia de tareas sobre esos actores, insumos y documentación más utilizada. En general es para una observación superficial, que luego es profundizada por otras técnicas. Para objetivos no específicamente informáticos, a veces es una técnica importante (estudo de tránsito de pacientes por zonas de una clínica, concentración de tareas, etc.) Se la complementa a veces con filmaciones.

Elicitación - Técnicas - Diccionario, LEL Cada disciplina o actividad desarrollada por el hombre tiene subyacente al menos una jerga propia, es decir una palabra o frase que tiene un significado particular, en ese dominio, reconocido por los participantes de la actividad. (Por ejemplo Resistencia, en electricidad, en ciencias sociales, en la geografía Argentina) El reconocimiento de la jerga es imprescindible para entender el dominio ya que encierra una gran cantidad de nociones del modelo: Paciente horizontal, giro cama. Son ejemplos de uso habitual en los hospitales. No Docente: tiene un significado particular en la Universidad.

Elicitación - Técnicas - Diccionario La generación de un diccionario de esa jerga conlleva un conocimiento importante del dominio. Y requiere previamente de informarse mediante lectura, entrevistas, consultas puntuales a expertos, etc. Una forma básica: Palabra: Significado Ejemplo: Paciente horizontal: Persona que se encuentra internada en el hospital Una forma mas elaborada (Léxico Extendido del Lenguaje): Palabra: Significado, impacto Ejemplo: Paciente horizontal: Persona que se encuentra internada en el hospital Impacto: Cuando se produce el fin de la internación puede ser por alta médica o continuar tratamiento en forma ambulatoria. Implica que se desocupa una cama.

Elicitación - Técnicas - Diccionario, LEL El LEL está compuesto por:  Nombre: palabra o frase que identifica algo en el contexto del dominio.  Noción: Definición, explicación del significado del nombre, en forma de oración (u oraciones) con palabras de uso general o existentes en el LEL (principio de circularidad).  Impacto: Acciones relacionadas al nombre en el contexto del dominio. Si una Noción se aplica a más de un nombre, estamos en presencia de un sinónimo. En general, los nombres identifican:  Sujetos: Personas o grupos  Objetos: Cosas  Estados: Situación a la que se arriba mediante alguna acción  Acciones: Cambios de estados LEL- Léxico Extendido del Lenguaje

Análisis de tareas Requiere: Descubrir las tareas. Ej.: Confeccionar Historia Clínica (HC) del paciente Descubrir las metas de cada tarea: Ej.: Generar un documento con los datos relevantes del paciente a los fines de la evaluación médica y legal. Quienes intervienen: Ej.: Médico, [administrativo], [SI] Que requieren: información e insumos de entrada (producto en muchos casos de otras tareas). Ej.: [Documento escrito | Acceso a Base de Datos], estudios complementarios Como la realizan (que procesos hacen). Ej.: En una 1ª entrevista el médico o secretaria da de alta una HC, el médico mediante la entrevista escribe anamnesis básica, más motivo de consulta ……. Examen clínico:…, Solicitud de estudios complementarios: …. Escritura de diagnóstico presuntivo:…. En una forma más estructurada: basada en reglas Elicitación - Técnicas - Análisis de tareas

Metas y objetivos Está emparentado con el análisis de tareas, aunque desde un punto de vista más jerárquico, relacionándolas: Objetivos: son los fines últimos de la organización, aquello para lo cual se ejecutan las tareas. Hospital: Proveer servicios de salud en todas las especialidades a la población en general Certificar estados de salud a organismos del estado Metas: son los fines de cada tarea. Hospital: Recepción en guardias Turnos para consultorios Etc. El método consiste básicamente en: Indagar acerca de los objetivos organizacionales (para que está, en el marco de su contexto social) Analizar la articulación de las tareas en función de los objetivos. Elicitación - Técnicas - Metas y objetivos

Casos de Uso Pertenece a un conjunto de técnicas de generación de modelos vinculadas a una metodología moderna de construcción de software denominada Tecnología Orientada a Objetos. Se trata de una técnica donde se identifican actividades (casos de uso) con los roles de quienes intervienen (actores). Elicitación - Técnicas - Casos de Uso

El diagrama es una parte del modelo, la otra es el “diálogo” entre los actores y los casos de uso, que es donde se construye la especificación del modelo. Ejemplo: CU: Consulta Médica Actores: Médico (M), Administrativo (A), Paciente (P) Recursos: Historia Clínica (HC) 1.A entrega HC a M 2.M revisa HC 3.M anota fecha en HC 4.M entrevista y revisa a P 5.M anota estudios clínicos realizados a P en HC 6.M anota diagnóstico y tratamiento de P 7.M entrega HC a A 8.Administrativo archiva HC El contenido real del CU está en el diálogo. IR - Técnicas - Casos de Uso

 Es una secuencia de acciones protagonizada por los actores.  La secuencia de acciones se denomina diálogo y tienen siempre como protagonista al menos a un actor y un recurso del CU (HC por ejemplo) u otro actor.  Hay autores que denominan CU al diagrama y escenarios a los diálogos.

IR - Técnicas - Casos de Uso  Toda acción necesita de condiciones para que se ejecute.  El CU al ser una secuencia de acciones, necesita de condiciones previas, en el dominio para que pueda llevarse a cabo.  En el ejemplo de la consulta: debe haber una HC de P, P debe haber traído estudios clínicos.  Estas condiciones se denominan Precondiciones del CU.

IR - Técnicas - Casos de Uso Precondiciones Desarrollo del CU

IR - Técnicas - Casos de Uso  Las acciones producen modificaciones en algún elemento del CU, en alguna actividad de los actores, etc.  La acción: M anota fecha en HC, produce un cambio en la HC, con el que se inician las actualizaciones restantes en la fecha.  La situación en que queda el CU, una vez realizadas todas las acciones se denominan Poscondiciones.

IR - Técnicas - Casos de Uso Precondiciones Poscondiciones Desarrollo del CU

Elicitación - Técnicas - Casos de Uso CU: Consulta Médica Actores: Médico (M), Administrativo (A), Paciente (P) Recursos: HC, Estudios complementarios Precondiciones: P ya tiene HC elaborada por M 1.A entrega HC a M 2.M revisa HC 3.M anota fecha en HC 4.M entrevista y revisa a P 5.M anota estudios clínicos realizados a P en HC 6.a) M anota diagnóstico y tratamiento de P | b) M anota diagnóstico presuntivo 7.[Si 6 b): M indica nuevos estudios a P] 8.M entrega HC a A 9.A archiva HC Poscondiciones: La HC está actualizada Si 6a) P tiene tratamiento prescripto | Si 7) & 6b) P tiene indicación de nuevos estudios

Precondiciones Poscondiciones Desarrollo del CU 1 Acciones que modifican el desarrollo interno 2 Acciones que modifican las postcondiciones (Puden ser obligatorias u opcionales) IR - Técnicas - Casos de Uso

Para modelar una organización, aunque sea pequeña, hay que acudir a varios CU. Un CU se debe usar para modelar un proceso (conjunto de acciones con un objetivo definido) simple. Si el proceso es complejo, conviene separarlo en subprocesos más fácilmente manejables. Un proceso es complejo cuando: Tiene muchas acciones Tiene muchos condicionantes para las acciones Los condicionantes son interdependientes

Elicitación - Técnicas - Casos de Uso CU: Consulta Médica Actores: Médico (M), Administrativo (A), Paciente (P) Recursos: HC, Estudios complementarios Precondiciones: P ya tiene HC elaborada por M 1.A entrega HC a M 2.M revisa HC 3.M anota fecha en HC 4.M entrevista y revisa a P. 5.M anota estudios clínicos realizados a P en HC 6.a) M anota diagnóstico y tratamiento de P | b) M anota diagnóstico presuntivo | c) M considera debe internar a P 7.[Si 6 b): M indica nuevos estudios a P] | [Si 6 c) CU: Generar orden de internación a P] 8.M entrega HC a A 9.A archiva HC Poscondiciones: La HC está actualizada Si 6a) P tiene tratamiento prescripto | Si 6b) P tiene indicación de nuevos estudios

Elicitación - Técnicas - Casos de Uso

Cada aspecto que hace a la funcionalidad del sistema admite un caso de uso, relacionando una entidad externa al sistema mismo (como una persona u otro sistema) con el caso de uso. Los casos de Uso nos permiten abordar el sistema desde el concepto inicial de la caja negra instalado en el diagrama de contexto. Los actores en este caso son otros sistemas o personas que interactúan con la caja negra: La persona que despacha medicamentos al hospital: trae medicamentos, revisados en la recepción del hospital Trae remito que debe ser firmado en la recepción Esto nos permite empezar a descubrir, desde la interacción con el medio externo, acerca de las funcionalidades internas.

Conclusiones  Los métodos son en algunos casos complementarios. P.ej. Diccionario + CU, Metas y objetivos + análisis de tareas.  En otros casos usados en etapas distintas de análisis. P.ej. La entrevista y el análisis documental suele preceder cualquier método.  Siempre buscan conocer, documentar y modelar.  Existen variadas razones para elegir una u otra (experiencia del analista, condiciones de la organización, momento y nivel de profundidad encarado, etc.)

Ubicación en el ciclo de vida de desarrollo del sistema informático.  Es importante que no perdamos de vista que estamos en una etapa inicial hacia el desarrollo de un sistema.  Los desvíos que se produzcan en cuanto a la comprensión pueden generar grandes problemas más adelante.  Para evitar esto se han ideado nuevos modelos de desarrollo de software.