El Diagnstico Participativo: Es el proceso que permite identificar y explicar los problemas que afectan a la poblacin de una realidad social

que se requiere intervenir en un momento determinado, con la participacin de los ciudadanos y las comunidades organizadas. Caractersticas: Conocer mejor el lugar donde vivimos y a nuestros vecinos. Priorizar los problemas con un criterio racional. Concientizar a la comunidad de los problemas que los aqueja. Crear espacios para la organizacin y la participacin de toda la comunidad. Identificar las fortalezas y oportunidades de la comunidad. Edificar una base slida sobre la cual elaborar un plan nico de trabajo dirigido a la solucin de los problemas comunitarios. Recolectar datos que soporten un sistema de seguimiento, control y evaluacin. Pasos: El primer paso para llevar a cabo el diagnstico participativo es la conformacin de un equipo promotor, el cual deber hacer: Convocatoria abierta: * La convocatoria a las diferentes reuniones debe ser abierta y atractiva a todos los habitantes de la localidad sin distingo alguno. * Para realizar la convocatoria es conveniente apoyarse en los lderes naturales de la comunidad. * No limitar la participacin es un elemento clave para llevar a buen trmino la actividad y obtener resultados de calidad. Reunin inicial: Los objetivos de este primer encuentro buscan informar a los asistentes acerca de: * La importancia de realizar el Diagnstico Participativo. * Determinar la metodologa a utilizar. * Delimitar los linderos reales o imaginarios de la comunidad para efectos del diagnstico. * Realizar una fotografa de la comunidad. Fotografa de la comunidad: El objetivo de esta actividad es describir la situacin en la que se encuentra la comunidad de una manera detallada: La imagen debe reflejar informacin acerca de: nmero de habitantes, nmero de viviendas, escuelas, centros de salud, calles, caminos, manzanas, nmero de nios, jvenes, adultos y ancianos, oficio o profesin de los habitantes, actividades econmicas, productivas, recursos fsicos y naturales con los que se cuenta y otra informacin que se considere importante.

 Fuentes de informacin: Tanto para la elaboracin de la fotografa de la comunidad como para los proyectos que luego puedan plantearse se puede obtener informacin de: 1. Los datos recogidos en la historia de la comunidad. 2. El censo demogrfico y socio econmico. 3. El croquis. 4. Otros estudios realizados acerca de la comunidad. Problemas y potencialidades: * De acuerdo con la metodologa sugerida para realizar el diagnstico participativo, la identificacin de los problemas y potencialidades de la comunidad se debe hacer mediante consenso. * Se debe estimular a todos a que participen, opinen, comenten, reflexionen y debatan sobre su realidad. * Es una tarea colectiva. Jerarquizar problemas: Los criterios para jerarquizar los problemas dependen del objetivo perseguido. Sin embargo los siguientes pueden servir de orientacin: * Jerarquizar considerando la cantidad de personas a las que afecta dichos problemas * Jerarquizar con base a su gravedad o intensidad * Jerarquizar de acuerdo a la capacidad de resolucin que tenga la propia comunidad Plan de desarrollo comunitario: La jerarquizacin de los problemas ser el punto de partida para la definicin del Plan de Desarrollo Comunitario, y como parte de l, de los principales Proyectos y Acciones a emprender.Deber convertirse en el plan nico de trabajo para sus habitantes.Para facilitar su cumplimiento debern asignarse claramente las responsabilidades y emplear mecanismos para evaluar avances. Aplicacin: Puede realizarse en cualquier momento del ao. Es el inicio de un proceso o accin para intervenir una determinada realidad social, es decir: un barrio, un sector de un barrio o un municipio. Es el punto de partida para la elaboracin de los proyectos que necesita una comunidad. Tambin puede ser realizado por cualquier grupo de personas interesadas en intervenir una determinada realidad social con el fin de lograr cambios en la misma. Para efectos del consejo comunal es imprescindible que ste sea elaborado por la comunidad, con la participacin de todos sus habitantes o, en su defecto, con un nmero significativo de ellos. Resultados esperados: Obtener informacin acerca de los problemas, necesidades, recursos y oportunidades de desarrollo en las comunidades. 2) Investigacin Accin:

Proviene del autor Kurt Lewis y fue utilizado por primera vez en 1944. Describa una forma de investigacin que poda ligar el enfoque experimental de la ciencia social con programas de accin social que respondiera a los problemas sociales principales de entonces. Mediante la investigacin accin, Lewis argumentaba que se poda lograr en forma simultneas avances tericos y cambios sociales. El concepto tradicional de investigacin accin proviene del modelo Lewis sobre las tres etapas del cambio social: descongelacin, movimiento, recongelacin. En ellas el proceso consiste en: Insatisfaccin con el actual estado de cosas. Identificacin de un rea problemtica. Identificacin de un problema especfico a ser resuelto mediante la accin. Formulacin de varias hiptesis. Seleccin de una hiptesis. Ejecucin de la accin para comprobar la hiptesis. Evaluacin de los efectos de la accin. Generalizaciones. (Lewis 1973). Las fases del mtodo son flexibles ya que permiten abordar los hechos sociales como dinmicos y cambiantes, por lo tanto estn sujetos a los cambios que el mismo proceso genere. Determinacin de requerimientos Para estudiar esta fase, primero debemos comenzar por conocer lo que son los requerimientos. Por lo que sabemos un requerimiento es una caracterstica o funcin que el cliente desea que se incluya en el sistema. De lo anterior podemos establecer que en la determinacin de requerimientos debemos plasmar la visin y las expectativas del cliente con respecto al sistema. El primer paso a la determinacin de los requerimientos sera entonces la primera entrevista con el cliente, en donde este nos indicara de forma verbal sus deseos y expectativas con respecto al sistema. Ahora bien, el primer problema que nos surge es que podemos errneamente pensar que el cliente sabe lo que quiere, pero la realidad es que el cliente solo conoce sus necesidades y su problemtica, nuestro trabajo sera determinar y aclarar en su caso la lista de funciones que nuestro sistema deber incorporar para cubrir esas necesidades y en su caso ayudar a solucionar la problemtica que se presenta. La determinacin de requerimientos requiere de una seria de tcnicas de investigacin, que aunque parecieran bastante comunes, es la forma de

emplearlas lo que determinara su eficiencia en la bsqueda de la informacin que nos ayudara a determinar los requerimientos. Entrevista La entrevista es una tcnica a travs de la cual se obtiene informacin de primera mano de las personas involucradas en las actividades, pero es una de las tcnicas que mas habilidades requiere. Pudiera parecer muy sencilla pero hay una serie de puntos que debemos considerar para tener una entrevista efectiva, veamos algunos. 1. Recordar que una entrevista no es un interrogatorio sino una conversacin. 2. El lenguaje corporal es de suma importancia para mantener interesado y enfocado al entrevistado. 3. El concertar citas y cumplir con ellas es vital para aprovechar el tiempo en la entrevista, dado que estamos el tiempo de trabajo de el entrevistado. 4. La toma de notas de la entrevista debe realizarse de forma gil y rpida. 5. La presentacin y las normas de etiqueta son fundamentales para no predisponer al entrevistado y tener una entrevista cordial. Como vemos esta tcnica requiere de un gran conocimiento de la interaccin humana. Encuestas Los encuestas son guas de preguntas con los que podemos enfocar la recoleccin de informacin, al ser distribuidos a las personas que nos proporcionaran la informacin es una tcnica rpida que garantiza el anonimato de las personas que contestan pero que muchas veces no nos proporciona informacin fidedigna si no es estructurado de forma lgica y clara. Para que un cuestionario sea eficiente deber: Al inicio explicar el motivo y la finalidad del cuestionario para obtener la colaboracin de la personas. La cantidad de preguntas es fundamental ya que una encuesta demasiado larga producir tedio y desinters en el encuestado. Las preguntas abiertas solo deben ser usadas en los casos en que necesitemos conocer la opinin del encuestado o informacin de carcter subjetivo Las preguntas cerradas aunque son buenas, no hay que abusar de ellas, porque limitan la opinin del encuestado. Actualmente podemos modernizar esta actividad a travs de los servicios de encuestas electrnicas como e-encuestas, que nos permiten disear encuestas que sern contestadas por internet, y que podemos enviar a los encuestados por correo electrnico o por alguna red social.

Obervacin

Esta tcnica pudiera parecer muy simple, pero tiene una dificultad que la hace ser poco fiable, y es que las personas no actan de la misma forma cuando saben que son observados. Y es que tendemos a cambiar nuestros hbitos y nuestros comportamientos cuando nos sabemos observados, adems de que en ciertos ambientes laborales la observacin se toma como una seal de cambio o de despidos, situaciones que con llevan a que los observados no realicen sus actividades de forma normal. Para que esta tcnica funcione se pueden tomar algunas estrategias: 1. Platicar con el personal a ser observados para aclarar los motivos de la observacin. 2. Promover los beneficios de un nuevo sistema, para eliminar la resistencia a la observacin. 3. Concertar citas con el personal a observar, para no interferir en momentos crticos o de extremo trabajo. Anlisis de documentacin. Esta tcnica consiste en revisar la documentacin de la empresa, y por documentacin nos referimos a reportes, listados y dems documentos que se espera el sistema genere, as como los documentos de donde se tomen los datos que el sistema deber almacenar y procesar. Esta tcnica es muy reveladora en cuanto al manejo de los datos y el procesamiento de la informacin.Sin embargo recuerde que en algunas ocasiones la informacin y la documentacin que usted estar manejando, es informacin sensible. Por lo que es altamente recomendable, manejar copias de la documentacin de la empresa y debidamente canceladas por la misma empresa. Recuerde no insistir mucho con el uso de esta tcnica para no perder la colaboracin del personal de la empresa. Clasificacin de los Requerimientos REQUERIMIENTOS ESPECFICOS. Los requerimientos deben exponerse en la forma ms precisa posible, pero sin que la descripcin de un requisito individual resulte demasiado extensa. Si fuera necesario, puede darse una descripcion resumida y hacer referencia a un apndice con la descripcin detallada. Es importante no incluir en los requerimientos aspectos de desarrollo o diseo. Los requerimientos son lo mnimo que se impone al sistema, y no hay que describir soluciones particulares que no sea obligatorio utilizar (excepto como aclaracin o sugerencia).

Es ventajoso enunciar los requerimientos en forma de una lista numerada, para facilitar su seguimiento y la validacin de sistema. Cada requerimiento debe ir acompaado de una indicacin del grado de cumplimiento necesario, es decir, si es obligatorio, recomendable o simplemente opcional.

Funcionales. Lo que el software debe de hacer. Se encuentran muy ligados al modelo conceptual propuesto. Se concretarn las operaciones de tratamiento de informacin que realiza el sistema, tales como almacenamiento de informacin, generacin de informes, clculos, estadsticas, operaciones, etc. Qu har el sistema? Cundo lo har? Existen varios modos de operacin? Cmo y cundo puede cambiarse o mejorarse el sistema? Existen restricciones de la velocidad de ejecucin, tiempo de respuesta o rendimiento? Ambiente fsico. Dnde est el equipamiento que necesita el sistema para funcionar? Existe una localizacin o varias? Existen restricciones ambientales, tales como temperatura, humedad o interferencia magntica? Usuarios y factores humanos. Quin usar el sistema? Habr varios tipos de usuario? Cul es el nivel de habilidad de cada tipo de usuario? Qu clase de entrenamiento requerir cada tipo de usuario? Qu tan fcil le ser a un usuario comprender y utilizar el sistema? Desempeo. Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperacin, etc. Interfaz. Elemento de interaccin con la gente, hardware u otro software. Se incluyen por lo tanto, bases de datos, protocolos, formatos de ficheros, sistemas operativos, datos, etc. La entrada proviene de uno o ms sistemas? La salida va a uno o ms sistemas? Restricciones de diseo. Estndares establecidos para el desarrollo. Operacin. Son los referentes al uso del sistema en general e incluyen los requisitos de la interfase de usuario (mens de pantalla, manejo de mouse, teclado, etc.). el inicio y fin, copias de seguridad, requisitos de instalacin y configuracin. Recursos. Son los referentes a elementos de hardware, software, instalaciones, etc., necesarios para el funcionamiento del sistema. Es muy

importante estimar los recursos con cierto coeficiente de seguridad en previsin de necesidades de ltima hora no provistas inicialmente. Verificacin. Son los que debe cumplir el sistema para que sea posible verificar y certificar que funciona correctamente el sistema (funciones de autotest, emulacin, simulacin, etc.). Prueba de aceptacin. Son los que deben cumplir las pruebas de aceptacin a que se someter el sistema. Documentacin. Son los referentes a la documentacin que debe formar parte del producto a entregar. Seguridad. Son los referentes a la proteccin del sistema contra cualquier manipulacin o utilizacin indebida (confidencialidad, integridad, virus, etc.). Transportabilidad. Son los referentes a la posible utilizacin del sistema en diversos entornos o sistemas operativos de una forma sencilla y barata. Calidad. Son los referentes a aspectos de calidad que no se incluyan en otros apartados Fiabilidad. Son los referentes al lmite aceptable de fallos o cadas durante la operacin del sistema. Mantenibilidad. Son los que debe cumplir el sistema para que se pueda realizar adecuadamente su mantenimiento durante la fase de explotacin. Capacidad. Son los referentes a los volmenes de informacin a procesar, tiempo de respuesta, tamaos de ficheros o discos, etc. Estos requerimientos deben expresarse mediante valores numricos e incluso, cuando sea necesario, se darn valores para el peor, el mejor y el caso ms habitual. No funcionales. Describen atributos del sistema o atributos del ambiente del sistema y generalmente no son establecidas por el usuario. Implcitos. Son los que se asumen que el software debe de tener. Extras. Agregados que generan valor al producto de software. rafa: REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES A menudo, los requerimientos de sistemas software se clasifican en funcionales y no funcionales, o como requerimientos del dominio: 1. Requerimientos funcionales. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que ste debe reaccionar a entradas particulares y de cmo se debe comportar en situaciones particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin pueden declarar explcitamente lo que el sistema no debe hacer. 2. Requerimientos no funcionales. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estndares. Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad. Normalmente apenas se aplican a caractersticas o servicios individuales del sistema.

3. Requerimientos del dominio. Son requerimientos que provienen del dominio de aplicacin del sistema y que reflejan las caractersticas y restricciones de ese dominio. Pueden ser funcionales o no funcionales. En realidad, la distincin entre diferentes tipos de requerimientos no es tan clara como sugieren estas definiciones. Por ejemplo. un requerimiento del usuario sobre seguridad podra parecer un requerimiento no funcional. Sin embargo, cuando se desarrolla en detalle, puede generar otros requerimientos que son claramente funcionales, como la necesidad de incluir en el sistema recursos para la autentificacin del usuario. REQUERIMIENTOS FUNCIONALES Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del software y del enfoque general tomado por la organizacin al redactar requerimientos. Cuando se expresan como requerimientos del usuario, habitualmente se describen de una forma bastante abstracta. Sin embargo. los requerimientos funcionales del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etctera. Los requerimientos funcionales para un sistema software se pueden expresar de diferentes formas. A continuacin se presentan algunos ejemplos de estos requerimientos funcionales para un sistema de biblioteca universitario, denominado LIBSYS y utilizado por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas. l. El usuario deber tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella. 2. El sistema deber proporcionar visores adecuados para que el usuario lea documentos en el almacn de documentos. 3. A cada pedido se le deber asignar un identificador nico (ID_PEDIDO), que el usuario podr copiar al rea de almacenamiento permanente de la cuenta. Estos requerimientos funcionales del usuario definen los recursos especficos que el sistema debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los requerimientos funcionales (contraste los requerimientos l y 3). El sistema LIBSYS es una interfaz nica para diferentes bases de datos de artculos. Esto permite a los usuarios descargar copias de artculos publicados en revistas, peridicos y publicaciones cientficas. Una descripcin ms detallada de los requerimientos para el sistema en el cual se basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre ingeniera de requerimientos (Kontonya y Sommerville, 1998). La impresin en la especificacin de requerimientos es la causa de muchos de los problemas de la ingeniera del software. Para un desarrollador de sistema es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin. Sin embargo, a menudo no es lo que el cliente

desea. Se deben establecer nuevos requerimientos y hacer cambios en el sistema. Por supuesto, esto retrasa la entrega de ste e incrementa los costes. Considere el segundo ejemplo de los requerimientos para el sistema de biblioteca que se refiere a los visores adecuados que debe proporcionar el sistema. El sistema de biblioteca puede mostrar documentos en diferentes formatos; la intencin de este requerimiento es que los visores para todos estos formatos estn disponibles. Sin embargo, el requerimiento est ambiguamente redactado; no clarifica que se deben proporcionar los visores de cada formato. Un desarrollador bajo la presin del tiempo sencillamente podra proporcionar un visor de texto y atinar que se ha cumplido el requerimiento. En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser consistente. La completitud significa que todos los servicios solicitados por el usuario deben estar definidos. La consistencia significa que los requerimientos no deben tener definiciones contradictorias. En la prctica, para sistemas grandes y complejos, es prcticamente imposible alcanzar los requerimientos de consistencia y completitud. Una razn de esto es que es fcil cometer errores y omisiones cuando se redactan especificaciones para sistemas grandes y complejos. Otra razn es que los stakeholders del sistema tienen necesidades diferentes, y a menudo contradictorias. Estas contradicciones pueden no ser obvias cuando los requerimientos se especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la especificacin. Es posible que los problemas surjan solamente despus de un anlisis ms profundo o, a veces, despus de que se termine el desarrollo y el sistema se entregue al cliente. REQUERIMIENTOS NO FUNCIONALES Los requerimientos no funcionales, como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones especficas que proporciona el sistema, sino a las propiedades emergentes de ste como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y las representaciones de datos que se utilizan en las interfaces del sistema. Los requerimientos no funcionales rara vez se asocian con caractersticas particulares del sistema. Ms bien, estos requerimientos especifican o restringen las propiedades emergentes del sistema. Por lo tanto, pueden especificar el rendimiento del sistema, la proteccin, la disponibilidad, y otras propiedades emergentes. Esto significa que a menudo son ms crticos que los requerimientos funcionales particulares. Los usuarios del sistema normalmente pueden encontrar formas de trabajar alrededor de una funcin del sistema que realmente no cumple sus necesidades. Sin embargo. el incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizable. Por ejemplo, si un sistema de vuelo no cumple sus requerimientos de fiabilidad,

no se certificar como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requerimientos de rendimiento, las funciones de control no funcionarn correctamente. Los requerimientos no funcionales no slo se refieren al sistema software a desarrollar. Algunos de estos requerimientos pueden restringir el proceso que se debe utilizar para desarrollar el sistema. Ejemplos de requerimientos de procesos son la especificacin de los estndares de calidad que se deben utilizar en el proceso, una especificacin que el diseo debe producir con una herramienta CASE particular y una descripcin del proceso a seguir. LEVANTAMIENTO DE LA INFORMACION Proceso mediante el cual el analista recopila datos e informacin de la situacin actual de un sistema con el propsito de identificar problemas y oportunidades de mejoras. Procesamiento de la informacin obtenida. Una vez seleccionada la informacin que resulta de inters, el problema queaparece es como procesar la misma de forma tal que resulte til para el trabajoque se va a realizar. En este punto hay que considerar que la mayora de lasveces la informacin slo puede ser consultada en el centro de informacin y nosiempre se puede obtener copia impresa o electrnica de la misma, por lo cual laconfeccin de fichas bibliogrficas resulta de gran importancia, por las mismasrazones con que se justificaba la existencia de las fichas en una biblioteca o centrode documentacin : para servir de sustituto al libro o documento completo .Adems, incluso en los casos en que se dispone del libro o documento completo,resulta muy conveniente contar con un resumen adecuado del contenidofundamental de dicho documento, resaltando los aspectos que son de especialimportancia para el tema en que se realiza la investigacin, para lo cual se debenseguir procedimientos muy similares a los que los especialistas en informacincientfico tcnica utilizan para confeccionar las fichas de los libros y documentosen general.Como gua fundamental tiene que estar el concepto de que la ficha debe ser capaz de sustituir, al menos parcialmente, el documento que cataloga , demanera tal que a la hora de redactar ya sea el proyecto de investigacin, elartculo cientfico, la ponencia a un congreso o el informe final de la investigacin,la lectura de las fichas pueda hacer posible realizar las citas correspondientes yconfeccionar las referencias bibliogrficas necesarias para cada tipo de trabajo. Lamayor o menor cantidad de informacin que se incorpore en las fichas depende decada caso particular, pero siempre debe ser la mayor posible, sin que llegue a se 31 tanta que dificulte el uso de la ficha y reduzca por lo tanto su capacidad desustituto del documento en cuestin.El otro problema que se presenta con las fichas es la forma de conservarlas y depoder procesarlas adecuadamente para la confeccin de las citas y las referenciasbibliogrficas y hasta no hace

tanto tiempo, esto se resolva con la confeccin defichas en cartulina y su almacenamiento en gavetas, con tarjetas separadoras quefacilitaban su consulta. Sin embargo en la actualidad, la disponibilidad ypot encialidad creciente de las computadoras, ha hecho que esta tarea se realicecasi exclusivamente en forma electrnica, utilizando las bases de datos o softwarede uso especfico.La manera ms simple de procesar electrnicamente la informacin obtenida, esmediante la creacin de una base de datos, para la cual se definan los camposnecesarios y cada registro sea una referencia bibliogrfica en particular. Para estose pueden utilizar las listas del Microsoft Exce l o mejor an las bases de datos del Access , tambin de Microsoft , por mencionar slo los ms conocidos ydifundidos en la actualidad.Sin embargo, existen software especficos que permiten no slo procesar lainformacin acopiada como una base de datos, sino que tambin facilitan labsqueda en las bases de datos de bibliotecas, centros de informacin e Internet yla confeccin de las citas y referencias en los documentos que se deben elaborar en las distintas etapas de la investigacin. Como ejemplo de estos software setiene el EndNote (11) , que ser el que se utilice en las clases prcticas de esteTema.
Tcnicas de Anlisis y Procesamiento de Datos: En esta parte se describen las distintas operaciones a las que sern sometidos los datos que se obtengan, en funcin de las bases tericas que orientarn el sentido del estudio y del problema investigado.En esta fase de desarrollo de la investigacin, comprende la incorporacin de algunos lineamientos generales para el anlisis e interpretacin de los datos, su codificacin,tabulacin, tcnicas de presentacin y el anlisis estadstico que se introducirn a los mismos.