UNIVERSIDAD NACIONAL DEL CENTRO DEL PERU

FACULTAD DE INGENIERA DE SISTEMAS TESIS SOFTWARE INTEGRAL PARA LA MEJORA DEL TIEMPO DE ACCESO A LA INFORMACION INTEGRAL DEL DESEMPEO DEL ALUMNO APLICANDO LA INTEGRACIN DE LA METODOLOGA SISTEMICA BLANDA Y LA INGENIERA DE REQUERIMIENTOS EN LA I.E NUESTRA SEORA DEL ROSARIO

PRESENTADO POR: PAUCAR BONIFACIO, BHRRING

PARA OPTAR EL TTULO PROFESIONAL DE: INGENIERO DE SISTEMAS

HUANCAYO PER 2013

1

ASESOR: ING. JOS OLIVERA MEZA

ii

AGRADECIMIENTOS:
Al finalizar un trabajo tan arduo y lleno de dificultades como el desarrollo de una tesis es inevitable que te asalte un muy humano egocentrismo que te lleva a concentrar la mayor parte del mrito en el aporte que has hecho. Sin embargo, el anlisis objetivo te muestra inmediatamente que la magnitud de ese aporte hubiese sido imposible sin la participacin de personas e instituciones que han facilitado las cosas para que este trabajo llegue a un feliz trmino. Por ello, es para m un verdadero placer utilizar este espacio para ser justo y consecuente con ellas, expresndoles mis agradecimientos. Debo agradecer de manera especial y sincera a todos los docentes de la Facultad de Ingeniera de Sistemas por haber contribuido en mi formacin profesional durante estos cinco aos, da tras da al ir compartiendo sus conocimientos y experiencias de tipo profesional y personal que fueron de gran valor. Y, por supuesto, el agradecimiento ms profundo y sentido va para mi familia. A mis padres, Victoria y Rubn, por su ejemplo de lucha y honestidad; a mis hermana Silvia y Nohelia por su apoyo incondicional.

iii

DEDICATORIA:
A Dios, por permitirme llegar a este momento tan especial en mi vida. Por los triunfos y los momentos difciles valorarlo que me han enseado a

cada da ms, a mis padres por

haberme acompaado durante todo mi trayecto estudiantil y en mi vida. A mis profesores, gracias por su tiempo, por su apoyo as como por la sabidura que me transmitieron en el desarrollo de mi formacin profesional. Bhrring

iv

RESUMEN
La presente tesis trata el desarrollo de un software integral para la gestin educativa que busca ayudar a incrementar el nivel acadmico de las alumnas de la I.E. Nuestra Seora del Rosario a travs de una mejor disponibilidad de la informacin, que tomo como eje la integracin de dos metodologas que ayudaron a encontrar los requerimientos que debe atender el software para poder alcanzar el objetivo propuesto, las metodologas utilizadas fueron la Ingeniera de Requerimientos y la Soft System Methodology. A travs de la metodologa Sistema Blanca integrada con la Ingeniera de Requerimientos se encuentra una imagen de la de la situacin a partir de la cual se van desprendiendo las necesidades que al ser atendidas por el software tienen incidencia sobre la situacin encontrada.

ABSTRACT
The present thesis deals with the development of a comprehensive software for the educational management that aims to help increase the academic level of the students of the our Lady of the Rosary I.E. through better availability of information, which I take as axis the integration of two methodologies that helped find the requirements that software must meet to be able to achieve the proposed objectivethe methodologies used were the Soft System Methodology and requirements engineering. Through the white system integrated with the requirements engineering methodology is an image of the situation from which the needs will evolve that to be met by the software have incidence on the found situation.

INDICE
PORTADA ASESOR AGRADECIMIENTO DEDICATORIA RESUMEN ABSTRACT INDICE INTRODUCCIN CAPTULO I GENERALIDADES 1.1 Planteamiento del Problema 1.2 Formulacin del Problema 1.3 Objetivos 1.4 Justificacin 1.5 Hiptesis 1.6 Diseo Metodolgico 1.7 Sistema de Referencia 1.8 Operacionalizacin de variables CAPTULO II MARCO DE REFERENCIA 2.1 Antecedentes A1. Requirements Engineering, Soft Systems Methodology and Workforce Empowerment A2. An Approach to Integrating Soft Systems Methodology and Object Oriented Software Development A3. Application of soft systems methodology to the real world process of teaching and learning A4. Soft Systems Methodology for transforming organizations to product-service systems A5. A Case Study Using Soft Systems Methodology in the Evolution of a Mathematics Module 2.2 Marco Terico 2.2.1 Soft System Methodology 2.2.2 Ingeniera de Requerimientos 2.3 Modelo Aplicativo 2.4 Marco Conceptual i ii iii iv v v vi 1

2 2 5 5 5 6 6 6 6 7 7 8 10 11 12

12 17 22 23

vi

INTRODUCCIN
La educacin es un factor esencial para el desarrollo humano, social y econmico y fomenta un mundo sostenible en el que se aprecie el conocimiento. En el Per sin embargo es uno de los sectores ms desatendidos por el estado, con muchas carencias y deficiencias que se ven reflejadas en el nivel acadmico de los alumnos. En el presente trabajo se hace un estudio para el desarrollo de un software de apoyo acadmico en la Institucin Educativa Nuestra Seora del Rosario, con la finalidad de ayudar a mejorar la disponibilidad de informacin integral del desempeo de las estudiantes. El primer captulo contempla el Planteamiento del Problema que describe la realidad actual y se enfoca en la situacin problemtica. La informacin mostrada presenta aspectos generales relacionados con el sector de educacin, del mismo modo presenta datos relacionados con el rendimiento acadmico dentro la Institucin Educativa Nuestra Seora del Rosario. Luego se realiza la Formulacin del Problema, se incluye el Objetivo que se persigue a travs del presente trabajo, la Justificacin, Hiptesis metodolgicos que guan la investigacin. En el segundo captulo se muestra el Marco de Referencia el mismo que contiene los Antecedentes o investigaciones anteriores relacionadas con el estudio, el Marco Terico que est ligado a la Metodologa Sistmica Blanda y a la Ingeniera de Requerimientos, as como el Modelo Aplicativo, el mismo que pretende mostrar la secuencia metodolgica con la cual se pretende resolver el problema. Culmina este captulo con el Marco Conceptual correspondiente. y dems elementos

Bhrring Paucar Bonifacio

CAPITULO I GENERALIDADES
En el presente capitulo se comenzara con el planteamiento y formulacin del problema, lo cual involucra la contextualizacin respectiva, tomado como referencias la realidad mundial y nacional, respecto a temas de educacin, para a continuacin abordar la situacin en la Institucin Educativa Nuestra Seora del Rosario. A continuacin se muestran los objetivos e hiptesis correspondientes. Tambin dentro de este captulo se realizara el diseo metodolgico y el sistema de referencia. 1.1 PLANTEAMIENTO DEL PROBLEMA a. La educacin en el mundo La educacin es uno de los instrumentos ms poderosos para reducir la pobreza y la desigualdad y sienta las bases para un crecimiento econmico sostenido. El Banco Mundial compila datos sobre los insumos, participacin, eficiencia y resultados del sector. La informacin sobre el tema es recolectada por el Instituto de Estadstica de la Organizacin de las Naciones Unidas para la Educacin, la Ciencia y la Cultura (UNESCO) a partir de respuestas oficiales a encuestas y de informes provistos por las autoridades sectoriales en cada pas. A continuacin se muestra un grfico de repetidores, de escuela primaria, solo con respecto a mujeres, en el mundo y en el Per. En el grafico se puede notar que en el Per encontramos un porcentaje de nios inscriptos en el mismo grado en el que estaban inscriptos el ao anterior, que es ms alto que el que se presenta en los otros pases del mundo.

GRAFICO N 1 ALUMNAS REPITENTES

Fuente: Indicadores del desarrollo mundial Elaboracin: Instituto de Estadstica de la Organizacin de la UNESCO.

b.

La educacin en el Per Pese al crecimiento sostenido que ha experimentado el Per en la ltima dcada y la boyante economa del pas, en trminos generales, los niveles de aprendizaje de nuestros escolares no han mejorado durante el quinquenio asado y la mayora de los alumnos evaluados no alcanzaron los niveles esperados para su grado. En el caso de Matemtica, la ECE-2011 muestra que, a escala nacional, solo el 13,2% logr los aprendizajes esperados, lo que significa que por tres aos consecutivos, del 2009 al 2011, este resultado, prcticamente, no ha variado. En el caso de Comprensin lectora, la titular de Educacin seal que solo un 29,8% alcanz el nivel esperado para el grado, mientras que el 47,1% solo responde las preguntas ms fciles de la prueba y el 23,2% tiene dificultades incluso con las preguntas ms sencillas. Estos resultados no representan una diferencia significativa respecto a la ECE-2010, en la que se obtuvieron porcentajes semejantes.

c.

La Institucin Educativa Nuestra Seora del Rosario La I. E. Nuestra Seora del Rosario brinda educacin en el nivel primario y secundario a sus alumnas. En la tabla siguiente se muestra un cuadro de la cantidad de alumnas por cada saln.

iii

TABLA N 1 CANTIDAD DE ALUMNAS

Grado 1ro 2do 3ro 4to 5to 6to 1ro 2do 3ro 4to 5to PRIMARIA N Salones 2 2 2 3 2 2 SECUNDARIA 8 9 10 8 10 Total Alumnas 33 33 33 33 33 33 33 33 33 33 33 1914

Fuente: Departamento de Informtica de la I.E. Nuestra Seora del Rosario Elaboracin: Propia

Del cuadro anterior se desprende que la I.E. Nuestra Seora del Rosario tiene mayor cantidad de alumnas en el nivel secundario, al tener ms salones habilitados. De la cantidad de alumnas mostrada se sac el promedio de notas por nivel educativo y se muestra en la siguiente tabla. TABLA N 2 PROMEDIO DE NOTA POR NIVEL EDUCATIVO
Nivel Primario Secundario Promedio de nota B 12.146

Fuente: Departamento de Informtica de la I.E. Nuestra Seora del Rosario Elaboracin: Propia

En la tabla anterior encontramos que el promedio de notas que presentan las alumnas de la la I.E. Nuestra Seora del Rosario no es el ms deseable, siendo esta una evidencia que se deben de tomar medidas para mejorar el nivel acadmico de las alumnas. A continuacin se muestra una tabla con el promedio de alumnas repitentes por nivel educativo. TABLA N 3 PROMEDIO DE ALUMNAS REPITENTES POR NIVEL EDUCATIVO
Nivel Primario Secundario Promedio de repitentes 8 11

Fuente: Departamento de Informtica de la I.E. Nuestra Seora del Rosario Elaboracin: Propia

De la tabla anterior, vemos que anualmente 19 alumnas repiten de grado. Siendo esto una cifra alta comparada con lo que encontramos en el grafico mostrado en 4

el anlisis mundial, en cual el promedio mundial es de 4 alumnas repitentes por ao, y a nivel nacional el promedio es de 6 alumnas repitentes por ao. 1.2 FORMULACIN DEL PROBLEMA b. Problema General Cmo influye la disponibilidad de informacin integral del desempeo del estudiante, sobre el tiempo de acceso por parte de los integrantes de la Institucin Educativa Nuestra Seora del Rosario? Tiempo de acceso = f (Disponibilidad de informacin integral)

c.

Problema Especfico Qu requerimientos debe de satisfacer el software integral de gestin educativa para disminuir el tiempo de por parte de los integrantes de la I.E. Nuestra Seora del Rosario? Qu impacto tendr la utilizacin del software integral de gestin educativa sobre el tiempo de acceso por parte de los integrantes de la I.E. Nuestra Seora del Rosario?

1.3

OBJETIVOS a. Objetivo General Disminuir el tiempo de acceso a la informacin integral del desempeo del estudiante en la I.E. Nuestra Seora del Rosario

b.

Objetivos Especficos Capturar los requerimientos a travs de la integracin de la metodologa sistmica blanda y la ingeniera de requerimientos. Mejorar el acceso a la informacin por parte de los integrantes de Ia I.E. Nuestra Seora del Rosario.

1.4

JUSTIFICACIN Justificacin Terica Con la realizacin del presente trabajo de investigacin, servir de modelo de aplicacin para las diferentes organizaciones para obtener los requerimientos para el desarrollo de un sistema de informacin a travs de la integracin de las dos metodologas que se proponen, Metodologa Sistmica Blanda e Ingeniera de Requerimientos. 5

 Justificacin Prctica La captura de requerimientos para el desarrollo del software de apoyo acadmico de la I.E. Nuestra Seora del Rosario es importante para las alumnas y dems involucrados, asimismo es importante porque busca a travs de la Metodologa Sistmica Blanda entender la situacin actual de la empresa y con la ayuda de la Ingeniera de Requerimientos obtener las necesidades de que tienen incidencia sobre la situacin actual. Justificacin Metodolgica El presente trabajo de investigacin propone incorporar la Metodologa de Sistemas Blandos que proviene del enfoque sistmico con la Ingeniera de Requerimientos que est dentro del campo de desarrollo de sistemas de informacin para alcanzar los propsitos del trabajo de investigacin.

1.5

HIPTESIS a. Hiptesis General La disponibilidad de informacin integral sobre el desempeo del estudiante a travs del uso del software integral de gestin educativa ayuda a disminuir el tiempo de acceso por parte de los integrantes de la Institucin Educativa Nuestra Seora del Rosario. b. Hiptesis Especficas La aplicacin de la integracin de la Metodologa Sistmica Blanda y la ingeniera de Requerimientos permite entender las necesidades de las alumnas de Ia I.E. Nuestra Seora del Rosario. El software integral de gestin educativa tiene un impacto sobre la cultura de Ia I.E. Nuestra Seora del Rosario

1.6

DISEO METODOLGICO a. Tipo de Investigacin El tipo de investigacin es aplicada de nivel cualitativo mediante la Metodologa del Modelo de Sistmica Blanda y la Ingeniera de Requerimientos en la I.E. Nuestra Seora del Rosario. b. Nivel de Investigacin Se trata de una investigacin descriptiva ya que pretende a travs de la Metodologa de Sistmica Blanda y la Ingeniera de Requerimientos, determinar los requisitos que el sistema de informacin que se desarrollara debe satisfacer.

vi

1.7

SISTEMA DE REFERENCIA El sistema de referencia est delimitado por la Institucin Educativa Nuestra Seora del Rosario, ubicada en la Av. Paseo la Brea 331 Huancayo. Actualmente la directora a cargo es la Hna. Irma Aguirre vila. Es un colegio de mujeres, que brinda formacin con una slida base cristiana, humanista, cientfica y tecnolgica.

1.8 OPERACIONALIZACION DE VARIABLES TABLA N 4 OPERACIONALIZACIN DE VARIABLES Variable Descripcin Indicadores Fuentes de informacin Instrumentos de medicin Reportes generados de la diferencia entre el tiempo de publicacin de la informacin y el momento en que llega al destinatario Tiempo de acceso Tiempo y cantidad de personas que acceden a la informacin Tiempo y cantidad de personas Reportes de la Institucin Educativa Nuestra Seora del Rosario

Variable Descripcin

Disponibilidad de informacin Informacin til para satisfacer las necesidades por parte de los integrantes de la Institucin Educativa

Indicadores Fuentes de informacin Instrumentos de medicin

Cantidad y calidad de informacin Reportes de la Institucin Educativa Nuestra Seora del Rosario

Reportes generados de la cantidad de accesos que ha tenido determinada informacin.

Fuente: Propia Elaboracin: Propia

vii

CAPITULO II MARCO DE REFERENCIA

2.1 ANTECEDENTES A1. Nandish V. Patel (2010). Application of soft systems methodology to the real world process of teaching and learning. Reino Unido. La Metodologa Sistmica Blanda es una metodologa muy productiva para el estudio de cualquier actividad humana organizada existente para lograr un determinado propsito o propsitos. Un conjunto de tales actividades humanas con propsito puede denominarse un sistema, en el que las diversas actividades estn interrelacionadas. Metodologa sistmica blanda (SSM) se refiere a un conjunto de actividades como un sistema de actividad humana. La Metodologa sistmica blanda tiene un enfoque que se ha aplicado a la educacin en el nivel de la escuela secundaria, pero fue probar la hiptesis de que los directores son ms gestores de recursos de lo que son los directores. SSM puede utilizarse tambin para el autoanlisis de enseanza y aprendizaje de los mtodos utilizados por un profesor de educacin superior. Puede ser utilizado para llevar a cabo una auto-auditora de la enseanza y el aprendizaje de estrategias para entregar a materias acadmicas a los estudiantes. Por lo tanto, SSM es particularmente buena, debido a la actividad intelectual que implica de modelado conceptual, como herramienta de autoanlisis para el practicante reflexivo en la educacin superior. En este artculo el autor busca obtener una comprensin ms profunda del proceso de enseanza y aprendizaje en pregrado, de manera tal que puedan adoptarse medidas adecuadas para mejorar ese proceso.

viii

Se analiza el proceso de enseanza y aprendizaje aplicando SSM a esta rea, definiendo este proceso conceptualmente en trminos de un sistema de actividad humana de mundo real. El anlisis se basa exclusivamente en el conocimiento acadmico y vivencial del autor del proceso y se lleva a cabo para obtener una visin en el proceso de enseanza y aprendizaje con vistas a mejorar. Hay ms de una metodologa de sistemas blandos disponible desde que el ms adecuado puede ser elegido para realizar un autoanlisis o auditora. La metodologa que se usa en esta investigacin para analizar el proceso de enseanza y aprendizaje es la metodologa de Checkland de siete etapas. En el trabajo de investigacin anterior, se encuentra una referencia de cmo se aplic la Metodologa Sistmica Blanda para entender el procesos de enseanza aprendizaje en escuelas de pregrado, con vistas mejorar el mismo. Para esta intervencin se utiliz la metodologa propuesta por Peter Checkland la cual est compuesta por siete etapas. La aplicacin de esta metodologa es adecuada debido a que permite realizar el estudio de los sistemas de actividad humana y sus interrelaciones. A2. S.K. Probert (1999). Requirements Engineering, Soft Systems

Methodology and Workforce Empowerment. Londres. Nos muestra que en los ltimos aos, ha surgido un creciente inters en los posibles usos del enfoque blando en la ingeniera de requerimientos. Mencionando que probablemente hay muchas razones para esto, pero un motivo claro surge de los cambios que las organizaciones han tenido que realizar para adaptarse al entorno cambiante de los negocios, las organizaciones del sector pblico tambin han tenido que hacer cambios para poder llegar a ser ms receptivas y responsables. La Soft System Methodology (SSM) se ha propuesto como una base sobre la que proceder con el anlisis de datos para los requisitos de ingeniera. Uno de los objetivos claros de la utilizacin SSM a este respecto es capacitar a la fuerza de trabajo para hacer una mayor contribucin a la ingeniera de los requisitos que (se supone) se puede lograr mediante mtodos estructurados como SSADM. En este caso, se argumenta las graves objeciones filosficas (a veces errneamente presentado como objeciones tcnicas) que

actualmente limitan tanto la fidelidad y el sentido prctico de los intentos de utilizar SSM para estos fines. Adems, se argumenta que la idea de usar SSM como base para la ingeniera de requisitos se basa, fundamentalmente,

ix

en la verosimilitud de la idea de que los sistemas de informacin son construcciones subjetivas. En la investigacin referida menciona como se han ido dando intentos de usar la Soft System Methodology en la Ingeniera de Requerimientos, debido a que las organizaciones actualmente son parte de un entorno constantemente cambiante y complejo. Tambin se sustenta el porqu de la factibilidad de usar la SSM y la Ingeniera de Requerimientos, siendo un motivo el hecho de que los sistemas de informacin son construcciones subjetivas.

A3. Wade, Steve (2004). An

Approach to Integrating Soft Systems

Methodology and Object Oriented Software Development. Reino Unido. Desde los aos setenta un nmero de mtodos de desarrollo de software han sido ampliamente utilizados. Algunos de estos, como SSADM (anlisis de sistemas estructurados y mtodo de diseo) (Ashworth y Goodland, 1990) tiene una reputacin de ser burocrtico y no han sido generalmente popular con los programadores. Estas disciplinas pusieron un gran nfasis en la necesidad de dedicar mucho tiempo a la planificacin antes de construir cualquier cosa. El enfoque de ingeniera se caracteriza por trabajar en una serie de modelos donde hay que indicar precisamente cmo debe construirse un sistema de software. Este enfoque es atractivo a la gestin, porque permite la identificacin de tareas que deben llevarse a cabo y de las dependencias entre estas tareas, lo que sugiere la posibilidad de un horario predecible y presupuesto para el desarrollo de sistemas. Un argumento clave contra este enfoque es que anima a jefe de proyecto a planificar una gran parte del proceso de desarrollo de software con gran detalle durante mucho tiempo por delante, esto hace que el enfoque y el software desarrollado no tengan en cuenta el constante cambio que se da. En los ltimos aos ha habido un gran inters en mtodos ligeros o "giles", los cuales han sido fuertemente influenciados por el aumento de popularidad de los lenguajes de programacin orientada a objetos, como C++ y Java apoyado por bases de datos objetos-relacionales y orientado a objetos. Estas herramientas permiten a los programadores a desarrollar soluciones de software rpidamente, por lo tanto, tienen menor necesidad de pasos de diseo detallado del proceso de desarrollo. La ubicuidad de la tecnologa de objetos en el nivel de programacin est representada en el nivel de diseo por el modelado de lenguaje unificado (UML) (Fowler y Scott, 2000) que ha sido ampliamente adoptado como una notacin estndar para el diseo de software.
x

SSM (Checkland, 1981; Checkland y Scholes, 1990; Checkland y Howell, 1998) es un medio establecido de resolucin de problemas que se centra en el desarrollo de modelos idealizados de los correspondientes sistemas que luego pueden ser comparados con sus homlogos del mundo real. El enfoque puede aplicarse en una amplia gama de situaciones incluyendo anlisis de requerimientos para el diseo de sistemas de informacin. La mayora de los trabajos en esta rea se refiere a los intentos de integrar SSM con el tipo de mtodos de desarrollo estructurado que precedi la tecnologa orientada a objetos (Mingers, 1988; Avison y Wood-Harper, 1990; Teclas y Roberts, 1991; Millas, 1992; Antes, 1990; CCTA, 1993; Stowell y West, 1994). Ms recientemente, algunos investigadores han explorado la relacin entre SSM y objecin de tcnicas de anlisis y diseo orientadas en general (avutarda, D et al., 1996; Lai, L.S. 2000). Actualmente, sin importar que tan gil sea una metodologa de desarrollo, todos los mtodos modernos reconocen que los requisitos de software de negocios son altamente voltiles. En el pasado haba una tendencia a metodlogos abordar este problema invirtiendo mucho tiempo obtener una imagen detallada de requisitos, antes de proceder a las fases de diseo y construccin. Este enfoque es errneo porque los usuarios cada vez ms se encuentran en situaciones de negocio cambiantes y, por tanto, son incapaces de identificar requisitos inalterables. El modelo de desarrollo de software como un proceso adaptativo, en el que requisitos detallados iterativamente emergen como un proyecto avanza y se modifican como aprendizaje lleva a cabo, parece mucho ms apropiado. Sin embargo hay un problema con este enfoque porque todas las otras tareas de software son conducidos por los requisitos. Si no podemos conseguir los requisitos estables que no podemos conseguir un plan predecible. Esto plantea la cuestin de cmo nosotros podramos ejercer algn control sobre la imprevisibilidad. La respuesta a esta pregunta, adoptada por casi todos los mtodos de desarrollo moderno, ha sido un mayor nfasis en tcnicas de desarrollo "iterativos" y "casos de uso". De la investigacin a la cual se hace mencin, se pueden destacar los siguientes aspectos, en primer lugar, los requisitos de software son altamente voltiles debido a que una organizacin siempre se encuentra frente a situaciones cambiantes. Y una forma de enfrentar esta situacin compleja es haciendo uso de la Metodologa Sistmica Blanda, con la cual se puede
xi

entender la situacin y de esa manera poder ejercer algn control sobre la imprevisibilidad de estos cambios. A4. Maged Morcos and Michael Henshaw (2010). A Soft Systems

Methodology for transforming organizations to product-service systems. Reino Unido. Hoy en da las organizaciones de los diferentes sectores de actividad y contrastantes con los enfoques de gestin dan cada vez ms prioridad a la satisfaccin de las necesidades de los clientes a travs de la prestacin de servicios. La transformacin generalmente implica la transferencia de algunas de las actividades de una parte de la cadena de suministro a otro y, en algunos casos, lo que implica la transferencia de actividades previamente realizadas por el cliente para el producto de la empresa de servicio. En este trabajo se describe la aplicacin de SSM (Metodologa sistmica blanda) a esta transformacin de manera que los puntos de vista de las partes interesadas en la cadena de suministro puedan ser capturados y las expectativas contradictorias y puntos de vista pueden ser resaltados. En el trabajo de investigacin se encuentra un modelo inicial para el desarrollo de un MSE en las organizaciones en construccin para demostrar que el

enfoque general es relevante para esta caracterstica particular de la transformacin. El enfoque SSM dar lugar a la identificacin de los obstculos a la transformacin, la comprensin de las implicaciones en el rendimiento general y an ms importante, el examen conjunto de estos temas y la generacin de solucin por parte del cliente y el proveedor de una manera no conflictiva. El objetivo general es hacer recomendaciones que alivian las preocupaciones identificadas, las barreras y los obstculos para esta transformacin. Los resultados de la investigacin muestran cmo los modelos conceptuales SSM pueden ayudar a los administradores en cualquier sector para realizar las actividades necesarias requeridas para realizar la transformacin de una manera exitosa. El trabajo de investigacin presentado, contribuye al entendimiento de la importancia de los clientes (alumnas) en las decisiones que se tomen para hacer una transformacin de manera no conflictiva la cual se da por conocer los puntos de vista de los dueos de la situacin as como los clientes. Los modelos conceptuales que se obtienen de aplicar la Soft System Methodology ayudaran a realizar las actividades necesarias para conseguir una transformacin exitosa en el sistema.

xii

A5. Jon Warwick (2010). A Case Study Using Soft Systems Methodology in the Evolution of a Mathematics Module. London. En este trabajo se describe la aplicacin de la Metodologa Sistmica Blanda como una herramienta para facilitar la evaluacin de un mdulo de matemticas por el profesor, para que los puntos de vista de quienes se dedican al mdulo podra ser capturado y destac las expectativas y puntos de vista contradictorios. Metodologa Soft Systems Checkland se utiliza, ya que permite la captura de opiniones de los interesados y aborda tanto los aspectos "duros" y "blandos" de la experiencia de aprendizaje. Etapas en la aplicacin de la Metodologa de sistemas blandos se ilustran incluyendo el desarrollo de una pintura rica y modelos conceptuales y el trabajo se realiz con un grupo de actores que inclua a los estudiantes que toman el mdulo y discusin con el personal involucrado en el diseo y entrega del material. Los cambios realizados en la entrega del mdulo se describen particularmente en la forma en que el apoyo estudiante se entrega. Los beneficios derivados de la aplicacin de esta metodologa se ilustran con mdulo de control y los mecanismos de control que ayudan a trazar el desarrollo de los estudiantes. El documento sostiene que la aplicacin de este enfoque puede mejorar el entendimiento de que los profesores tienen percepciones de estudiantes de un mdulo, permite a los puntos de vista individuales de entender y desafiado y que este tipo de ciclo de aprendizaje realizada peridicamente se puede utilizar para estructurar la evolucin de una ensea mdulo. En el trabajo de investigacin anterior, se encuentra una referencia de cmo se aplic la Metodologa Sistmica Blanda para entender el procesos de enseanza aprendizaje en un mdulo de matemtica, de esta manera ayuda a comprender que el mismo , debe ser realizada con la participacin de todos los involucrados, quienes aportan con sus puntos de vista, con lo cual se puede obtener cual es el ciclo de aprendizaje que se debe de llevar a cabo para alcanzar los objetivos. 2.2 MARCO TERICO 2.2.1 Soft System Methodology La Metodologa Sistmica Blanda de Checkland (MSB), tambin conocida como SSM por sus siglas en ingls (Soft Systems Methodology), es una forma de pensamiento racional sistmico apropiado para lidiar con situaciones humanas complejas, particularmente las llamadas situaciones blandas. (Andrade H., Dyner I., Espinoza A., Lpez-Garay H., Sotaquir R., 2007).

xiii

El tipo de situaciones apropiadas para ser abordadas por la MSB, es decir, las situaciones blandas, son situaciones que surgen como producto de la dinmica que se genera en una organizacin humana por la existencia de mltiples y diferentes puntos de vista e intereses de los diferentes miembros de la organizacin sobre los fines de la organizacin o sobre alguna situacin particular que se les presenta en su vivir organizacional. La necesidad de abordar las situaciones problemticas blandas con la MSB en lugar de hacerlo con cualquier mtodo identificado con la ciencia clsica reduccionista, surge del hecho de que el mtodo analtico reduccionista busca, segn Andrade et al.(2007), reducir la variedad interpretativa existente en toda situacin humana a una sola perspectiva, la cual considera y acepta como verdadera. Al hacer esta reduccin deja de lado la compleja interaccin de puntos de vista que frecuentemente existen en el seno de toda organizacin humana y que son los que la constituyen como tal.Dado que cada situacin organizacional es particular y tiene sus propias caractersticas, la MSB de Checkland hace una marcada distincin entre mtodo y metodologa, resaltando que para cada situacin problemtica debe haber una metodologa de abordaje que considere su especificidad. Una metodologa, segn Checkland (1981) (citado por Andrade et al., 2007), es un conjunto de principios de mtodo que en una situacin particular son adaptados para que generen un mtodo apropiado a la situacin en cuestin. Un mtodo, es entonces entendido como algo ms cercano a una tcnica. Una tcnica tiene las siguientes caractersticas: consiste en una secuencia de acciones que si se ejecutan en el orden apropiado y bajo las condiciones apropiadas siempre da el mismo resultado, independientemente de quien lo realice. La Metodologa De Checkland gua al que desea aplicarla en una situacin problemtica, es decir una situacin en la que no est claro entre los diversos actores de la situacin organizacional cuales son los fines a seguir, ni cul es el problema que consideran vital resolver para la organizacin (y esto puede deberse a que precisamente hay diversas percepciones de los fines y del sentido de la situacin que estn viviendo en un proceso de estructurarla sistmicamente-). Esto quiere decir comenzar a ordenarlas distintas perspectivas en trminos de modelos conceptuales de sistemas humanos o ms comnmente Sistemas de Actividades Humanas (Human Activity Systems -HAS-en ingls).

xiv

Este proceso de estructuracin sistmica puede esquematizarse como lo mostramos en el Grfico N 01. GRFICO N 02. FORMA GENERAL DE LA METODOLOGA SISTMICA BLANDA (MSB) DE CHECKLAND

Fuente: Soft Systems Methodology in Action Elaboracin: Propia

En el grafico anterior, podemos ver que en su forma general la MSB ayuda inicialmente al usuario de la misma a desarrollar una comprensin general de la situacin problemtica, en los trminos propios de la situacin misma, es decir sin imponer de antemano ninguna estructura sistmica sobre dicha situacin. En este primer paso, el usuario de la MSB adopta una actitud similar a la del antroplogo que llega a estudiar por primera vez una cultura desconocida. Resulta de sentido comn entender que si el antroplogo se acerca a la cultura objeto de estudio con esquemas preconcebidos (Por ejemplo, esperando encontrar artefactos y tecnologas propias de la cultura occidental, formas de socializar y comportamientos occidentales), entonces no va a poder descubrir las caractersticas propias de la cultura objeto de estudio. Esta comprensin inicial de la situacin organizacional en sus propios trminos le permite al usuario de la MSB identificar las distintas perspectivas, valores, e intereses en juego, y por ende la diversidad interpretativa y problemtica que constituye la situacin objeto de estudio y que le da su identidad, es decir que hace que ella sea lo que es y no se

xv

parezca a otra. Pues vale la pena anotar que en estos primeros pasos el usuario (por ejemplo el Ingeniero de Sistemas) est a la caza de las singularidades de la situacin, pues estas son las que le dan su identidad especifica. El usuario da por concluida esta etapa cuando es capaz de formular un primer in-forme en el que sintetiza estas primeras impresiones que ha captado de la situacin. Como ya se dijo, este informe debe ser redactado en los trminos de la cultura organizacional y no en trminos de la Ingeniera de Sistemas. En el siguiente paso el usuario procede, ahora s, a pensar sistmicamente la situacin. Qu quiere decir esto? Lo que esto implica es que el usuario se pregunta: si yo adoptase alguna de las perspectivas organizacionales que parecen estar en juego en esta situacin, cul sera el Sistema de Actividades Humanas que la realizara ptimamente desde un punto de vista racional? Es decir: Cul sera el mnimo nmero de actividades que ese sistema, idealmente, tendra que realizar para hacer efectivas las tareas fundamentales que esa perspectiva organizacional implique? Es vital entender entonces que cuando Checkland habla de Modelos Conceptuales de Sistemas Humanos l no se est refiriendo a un modelo de la organizacin bajo estudio en el sentido ingenieril: una representacin lo ms cercana posible a la realidad objeto del modelaje. No es pues un retrato anlogo de esa realidad como cuando un ingeniero civil construye el modelo anlogo de un rio cuya dinmica quiere estudiar. Los modelos HAS" son instrumentos conceptuales, constructos sistmicos, para ayudar a pensar a los involucrados en una situacin organizacional acerca de las complejas perspectivas que estn en juego y como ellas de algn modo constituyen su realidad organizacional diaria. En este sentido un buen HAS" podra ser uno que contraste radicalmente con la situacin actual. En el siguiente paso de la Metodologa De Checkland el usuario prepara la escena para conducir con los involucrados una comparacin entre la situacin como es percibida y los constructos conceptuales HAS. Esa comparacin permite iniciar un debate que busca expandir la comprensin de la situacin problemtica y a comen-zar entonces a idntica un conjunto de cambios para la organizacin que sean sistmicamente deseables y culturalmente factibles. La MSB tiene la particular bondad de ser flexible en su aplicacin, cosa que se hace 16

evidente cuando tras obtener una situacin problemtica mejorada es posible comenzar una nueva iteracin en la aplicacin de la metodologa para consecutivamente obtener mejoras en la situacin problemtica. A continuacin, en el Grfico N 02 se puede observar en detalle la Metodologa Sistmica Blanda, como fue concebida inicialmente por Checkland. Es bueno observar la lnea que divide el llamado mundo real" del mundo de la reflexin o Pensamiento Sistmico". El conjunto de actividades que est del lado del mundo real" son las que el usuario de la MSB lleva a cabo en contacto directo con los involucrados en la situacin

organizacional. Esas actividades comprenden, como hemos dicho, comenzar a conocer la organizacin y la cultura organizacional, y buscar conjuntamente con los involucrados en la situacin, identificar un conjunto de cambios sistmicamente deseables y culturalmente factibles. Por el lado del mundo del pensamiento sistmico, el usuario trabaja con su equipo estructurando sistmicamente la situacin, en trminos de modelos conceptuales HAS. GRFICO N 03 LA METODOLOGA SISTMICA BLANDA (MSB) ORIGINAL DE CHECKLAND

Fuente: Soft Systems Methodology in Action Elaboracin: Propia

17

2.2.2 Ingeniera de Requerimientos A travs de los aos se ha podido constatar que los requerimientos o requisitos son la pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeacin, bsicamente en lo que se refiere a las estimaciones de tiempos y costos, as como la definicin de recursos necesarios y la elaboracin de cronogramas que ser uno de los principales mecanismos de control con los que se contar durante la etapa de desarrollo. Adems la especificacin de requerimientos es la base que permite verificar si se alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades de los clientes o usuarios del sistema y es contra lo que se va a estar verificando si se estn cumpliendo las metas trazadas. Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas de computadoras), que un gran nmero de los proyectos de software fracasan por no realizar una adecuada definicin, especificacin, y administracin de los requerimientos. Dentro de esa mala administracin se pueden encontrar factores como la falta de participacin del usuario, requerimientos incompletos y el mal manejo del cambio a los requerimientos. La Ingeniera de Requerimientos (IR) cumple un papel primordial en el proceso de produccin de software, ya que se enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, las necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestin de los requerimientos en el desarrollo de sistemas. El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniera de requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. Algunos otros conceptos de ingeniera de requerimientos son: - Ingeniera de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo

18

- interactuarn los usuarios finales con el software . (Pressman, 2006: 155) - La ingeniera de requerimientos es el proceso de desarrollar una especificacin de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. (Sommerville, 2005: 82) En sntesis, el proceso de ingeniera de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento,

documentacin y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendr a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtencin y anlisis de requerimientos, su especificacin formal, para finalizar con el subproceso de validacin donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente. Conceptos y Caractersticas Como se mencion anteriormente, la ingeniera de requerimientos sirve como una base slida en el proceso de desarrollo de software, por lo que antes de pasar a tratar los aspectos referentes a la administracin adecuada de los requerimientos, es importante primero definir lo que es un requerimiento y cules seran las caractersticas deseables que deberan de tener. Qu son Requerimientos? Se presenta a continuacin la definicin existente en el glosario de la IEEE de lo que es un Requerimiento: - Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (Std 610.12-1900, IEEE: 62) - Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (Std 610.12-1900, IEEE: 62) Tambin, Ian Sommerville presenta una definicin acerca de lo que es un Requerimiento: - Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste. (Sommerville, 2005: 108) Analizando las definiciones anteriores, un requerimiento es una descripcin de una condicin o capacidad que debe cumplir un sistema, ya sea derivada de una necesidad de usuario identificada, o bien, 19

estipulada en un contrato, estndar, especificacin u otro documento formalmente impuesto al inicio del proceso. Tipos de Requerimientos Los requerimientos de software pueden dividirse en 2 categoras: requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales son los que definen las funciones que el sistema ser capaz de realizar, describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Es importante que se describa el Qu? y no el Cmo? se deben hacer esas transformaciones. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema. Por otra parte los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo),

mantenimiento, seguridad, portabilidad, estndares, etc. Caractersticas de un Requerimiento Es importante no perder de vista que un requerimiento debe ser: Especificado por escrito: Como todo contrato o acuerdo entre dos partes. Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces cmo se sabe si se cumpli con l o no? Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es

contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Dificultades para definir los requerimientos Durante la etapa de especificacin de requerimientos se pueden presentar muchos inconvenientes los cuales son importantes de 20

identificar y prevenir, a continuacin se presenta un listado con los problemas ms comunes en este proceso: Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. El usuario no puede explicar lo que hace Tiende a recordar lo excepcional y olvidar lo rutinario Hablan de lo que no funciona Los usuarios tienen distinto vocabulario que los desarrolladores. Usan el mismo trmino con distinto significado

Importancia de la ingeniera de requerimientos Segn la autora Lizka Johany Herrera en su documento de la ingeniera de requerimientos, los principales beneficios que se obtienen de la Ingeniera de Requerimientos son (2003: 3): Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos

(funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso.

21

Evita

rechazos

de

usuarios

finales:

La

ingeniera

de

requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto. Actividades de la ingeniera de requerimientos Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice que dentro de la IR existen cuatro actividades bsicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificacin y administracin adecuada de los requerimientos de los clientes o usuarios. Las cuatro actividades son: extraccin, anlisis, especificacin y validacin, y sern explicadas a continuacin cada una de ellas. Extraccin Esta fase representa el comienzo de cada ciclo. Extraccin es el nombre comnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aqu, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Es importante, que la extraccin sea efectiva, ya que la aceptacin del sistema depender de cuan bien ste satisfaga las necesidades del cliente. Anlisis Sobre la base de la extraccin realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un anlisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos. Especificacin En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.

22

En la prctica, esta etapa se va realizando conjuntamente con el anlisis, se puede decir que la especificacin es el "pasar en limpio" el anlisis realizado previamente aplicando tcnicas y/o estndares de documentacin, como la notacin UML (Lenguaje de Modelado Unificado), que es un estndar para el modelado orientado a objetos, por lo que los casos de uso y la obtencin de requerimientos basada en casos de uso se utiliza cada vez ms para la obtencin de requerimientos. Validacin La validacin es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripcin, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los

requerimientos sean consistentes y que estn completos. Se puede apreciar que el proceso de ingeniera de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificacin de requerimientos, que es el documento final, de carcter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso nico que sea vlido de aplicar en todas las organizaciones. Cada organizacin debe desarrollar su propio proceso de acuerdo al tipo de producto que se est desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniera de requerimientos. Hay muchas maneras de organizar el proceso de ingeniera de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva ms objetiva que las personas involucradas en el proceso.

23

2.3

MODELO APLICATIVO Para el desarrollo de la investigacin se contara con tres etapas, la primera consistir en la captura de los requerimientos de la Institucin Educativa Nuestra Seora del Rosario a travs de la integracin metodolgica de la Ingeniera de Requerimientos y la Soft System Methodology. En la segunda etapa se realizara la implementacin del Software Integral para la gestin educativa, tomando como base para su desarrollo los requerimientos obtenidos en la primera etapa. Finalmente, en la tercera etapa se pasara al periodo de prueba y anlisis de resultados. A continuacin en el grfico, se muestra la secuencia que se seguir como parte del modelo aplicativo. GRFICO N 04 MODELO APLICATIVO Intervencin con la Soft System Methodology Ingeniera de Requerimientos

Implementacin

Prueba y anlisis de resultados

Fuente: Autor Elaboracin: Propia

2.3.1 Intervencin con la Soft System Methodology A travs de la intervencin en la Institucin Educativa Nuestra Seora del Rosario con la Soft System Methodology, se busca entender la situacin problemtica haciendo uso de las herramientas propias de esta metodologa tales como la pintura rica, los modelos conceptuales, la definicin de los grupos culturales, sistemas pertinentes y definiciones raz. 2.3.2 Ingeniera de Requerimientos A travs de la Ingeniera de Requerimientos, una vez que ya se tiene definido la situacin problemtica de la Institucin Educativa Nuestra Seora del 24

Rosario, se irn transformando las necesidades de informacin en requerimientos que posteriormente sern implementados en el software integral propuesto. 2.3.3 Implementacin Tras la aplicacin de la Soft System Methodology y la Ingeniera de Requerimientos en la Institucin Educativa Nuestra Seora del Rosario se comenzar con la implementacin del software integral haciendo uso de los requerimientos encontrados en la situacin problemtica intervenida. 2.3.4 Prueba y Anlisis de Resultados En este momento se pondr en uso el software integral de gestin educativa y se irn obteniendo datos del impacto que ha tenido sobre la situacin problemtica inicial encontrada.

2.4

MARCO CONCEPTUAL Complejidad: Es el nmero de estados observados en un sistema, puede ser expresada como el nmero de distinciones hechas por un observador en una situacin y esto depende del observador(Es la medida de la variedad). Desarrollo iterativo: es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos ms famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es tambin una parte esencial de un tipo de programacin conocido como Extreme Programming y los dems frameworks de desarrollo rpido de software. Problema: Discrepancia negativa entre la situacin actual y la situacin deseada. Cuestin cientfica que debe resolverse. Cuestin difcil de solucionar. Cuestin existencial que se reitera en la vida. Requerimiento: en la ingeniera de sistemas, un requerimiento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniera de sistemas o la ingeniera de software. Situacin: accionar y las consecuencias de situar o de situarse (colocar a una persona o a una cosa en un cierto lugar). Sistema de actividad humana: Conjunto de actividades o acciones

interactuantes realizados por una persona o grupo de personas en el mundo real. Variedad: El nmero de posibles estados de un sistema. 25