Sistemas I

De Computacion

Sistemas I, es una asignatura que se encuentra ubicada en el eje técnico metodológico del perfil curricular de la Carrera Ingeniería en Informática, se la ofrece en el tercer ciclo, para cursarla se requiere tener aprobada la asignatura de Metodología y Tecnología de la Programación II, impartida en el segundo ciclo. El creciente adelanto científico y tecnológico obliga a que los(as) profesionistas del área de Informática tengan conocimientos sólidos en el desarrollo de Sistemas de Información, ello les permitirá participar activamente en el estudio de factibilidad, análisis, diseño, implantación, ejecución y control de los proyectos informáticos aplicables en cualquier institución. En sistemas I, se presta especial atención al análisis y diseño de aplicaciones informáticas de gestión, se las aborda con técnicas y metodologías apropiadas acompañadas por una precisa gestión de proyectos y una eficaz gestión de calidad. A la asignatura de Sistemas I, se ha estructurado la materia en ocho capítulos, así:

Capítulo I.

“Teoría de Sistemas”, capítulo que tiene como objetivo presentar el enfoque sistémico a fin de llegar a determinar la incidencia de los sistemas en las actividades diarias.

Capítulo II.

“Sistemas Socio Técnicos desde la Ingeniería de Software”, partiendo de la definición de sistemas se llega a establecer lo que es ingeniería de sistemas o ingeniería de software, se detalla lo que es producto, proceso y se especifica las diferentes modelos de desarrollo para la elaboración de productos software.

Capítulo III.

“Análisis de requerimientos”, aquí se enfoca la manera de descubrir, expresar, organizar y documentar los requerimientos de usuario(a) y de sistema; así como también, los requerimientos funcionales, no funcionales y de dominio, esto con el fin de tener un panorama completo de los requerimientos de información de una determinada organización.

Capítulo IV.

“Ingeniería de Requerimientos (IR)”, para poder hacer un adecuado diseño de software, es preciso validar los requerimientos con el fin de eliminar al máximo las inconstancias que puedan existir. Aquí también se enfoca la manera en que se debe proceder para gestionar los cambios que hubieren cuando el producto software este en cualquiera de las fases subsiguientes.

Capítulo V.

“Modelos de Sistemas”, en este capítulo se exponen los diferentes modelos de sistemas que pueden desarrollarse durante el proceso de ingeniería de requerimientos.

Al momento de definir un determinado modelo de sistema se hace necesario definir sus limites (dominio de la aplicación) y modelar su contexto, teniendo claro el contexto se pueden elaborar modelos de comportamiento y/o modelos estructurales.

Capítulo VI.

“Diseño Arquitectónico”, habiendo realizado el modelo del sistema es necesario realizar el diseño arquitectónico, para poder hacer esto se debe definir los estilos de descomposición modular y los estilos de control para poder llegar a establece el tipo de arquitectura más conveniente. En este capítulo, se presentan tres estilos arquitectónicos que abarcan la organización del sistema, así mismo, se presentan las principales arquitecturas de los sistemas distribuidos.

Capítulo VII.

“Diseño Orientado a Objetos”, en este capítulo se presenta la manera de diseñar objetos, en que se define clases, objetos, atributos y relaciones, es necesario señalar que el diseño de datos traduce los objetos de datos a estructuras de datos que residen dentro del software.

Capítulo VIII

“Diseño de Interfaces de Usuario(a)”, el diseño de la interfaz de usuario(a) empieza con la identificación de los requisitos, la tarea y el ambiente del usuario(a); identificadas las tareas se crean y analizan los escenarios con el fin de definir los objetos y las acciones para la interfaz, lo que servirá de base para la creación de formatos de pantalla que representan el diseño gráfico y la ubicación de ícono, la definición del texto descriptivo, la especificación y asignación de nombres a ventanas, además de la especificación de los principales elementos de los menús.

Debemos puntualizar que los capítulos I, II, III, y IV corresponden al primer bimestre y los capítulos V, VI, VII y VIII corresponden al segundo bimestre.

El capítulo I (primer bimestre) y no consta en el libro texto base, pero se encuentra desarrollado en la presente guía didáctica. Esperamos le sean de fácil comprensión.

Objetivo General

Conocer la manera de realizar análisis de requerimientos y el diseño de los Sistemas de Información.

Objetivos Especificos

Los objetivos específicos de la materia, en función de los capítulos que se van a desarrollar son:

Manejar adecuadamente el enfoque sistémico a fin de llegar a determinar la incidencia de los sistemas en cada una de las actividades.

Analizar e identificar los diferentes modelos de desarrollo para la elaboración de productos software.

Conocer, expresar y organizar los requerimientos para el desarrollo de un producto software.

Determinar las actividades implicadas en el proceso de ingeniería de requerimientos en el desarrollo de un producto software.

Manejar el modelamiento de sistemas para el desarrollo de software.

Conocer, las perspectivas estructurales para el diseño de software para una ejecución centralizada y para una ejecución distribuida.

Realizar análisis y diseño orientado a objetos de un sistema de información.

Manejar los diferentes aspectos de diseño de interfaces de usuario(a).

Manejar el modelamiento de sistemas para el desarrollo de software.

Conocer, las perspectivas estructurales para el diseño de software para una ejecución centralizada y para una ejecución distribuida.

Realizar análisis y diseño orientado a objetos de un sistema de información.

Manejar los diferentes aspectos de diseño de interfaces de usuario(a).

Bibliografia

Texto Base

SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005

Este es el texto básico que será utilizado como guía para el estudio de la asignatura de sistemas. Ian Sommerville, presentan una obra completamente didáctica en la que acentúa aspectos básicos de la Ingeniería de Software poniendo especial énfasis en el Análisis y diseño de sistemas.

El texto esta dividido en seis partes, veinte y nueve capítulos. En esta asignatura de Sistemas I se va ha estudiar hasta el capítulo dieciséis.

Bibliografía complementaria

PRESSMAN Roger S., adaptado por INCE Darre. Ingeniería de Software. Un enfoque práctico. Quinta Edición. Editorial McGraw-Hill. España. 2002

El libro gira en torno a la Ingeniería de Software y se estructura en cinco partes. En la parte uno se enfoca lo que es el proceso de desarrollo de software, en la segunda parte presenta de forma práctica la manera de realizar ingeniería de software, presenta métodos de análisis, diseño y pruebas con especial interés en las técnicas orientadas a objetos y al modelado UML.

La tercer parte, se enfoca las aplicaciones de la ingeniería Web, realiza un enfoque completo para el análisis, diseño y prueba de aplicaciones Web.

La cuarta parte contiene temas relacionados a la planeación, gestión y control de proyectos software. En la quinta parte, se presentan los métodos formales para la ingeniería del software y las tendencias futuras dentro de esta rama.

WEITZENFELD Alfredo.
Ingeniería de Software Orientada a Objetos con UML Java e Internet. Editorial Thomson. Ciudad de México. 2004

El texto enfoca la Ingeniería de Software desde el estándar UML. Presenta de forma detallada cada uno de diagramas que se utilizan dentro de esta notación.

Nos permitimos sugerir que se lo revise ya que contiene algunas conceptos y diagramas que permitirán comprender los esta manera de modelar productos software.

ANDREU Rafael, RICAT Joan E., VALOR Josep.
Estrategia y Sistemas de Información. 2da. edición., Editorial McGraw-Hill/Interamericana de España, S. A. U. Madrid. 1999

Este libro expone las oportunidades que las Tecnologías de la Información ofrecen para conseguir los objetivos organizacionales y ventajas competitivas. Abarca lo siguiente:

Introducción al concepto de Sistemas de Información ,y Tecnologías de Información, sistematización de los Sistemas de Información, Fundamentos de una metodología para diseñar la estrategia de Tecnologías de la Información en paralelo con la estrategia de negocio, Planificación y Sistemas de Información a nivel corporativo.

Recomendamos el libro de Rafael Andreu, Joan Ricar, Joseph Valor; por ser de lenguaje sencillo, de fácil comprensión, didáctico y discernible.

CABERA Gregorio, MONTOYA Guillermo.
Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión. Grado Superior, Editorial McGraw-Hill/Interamericana de España, S.A.U. Madrid 2001

La organización y estructuración de los contenidos de la presente obra se articulan al rededor de las diferentes fases de Métrica para el desarrollo de Sistemas de Información partiendo de las necesidades de los usuarios y desarrollando posteriormente los modelos conceptuales y físicos necesarios que conforman la parte vertebral del diseño de los programas y pruebas requeridas para la implantación de un sistema de información empresarial.

BARROS V. Oscar.
Tecnologías de la Información y su Uso en Gestión. Una visión moderna de los sistemas de información. Editorial McGraw-Hill. Santiago de Chile 1998

Este Libro es una aproximación a cómo las Tecnologías de la Información, posibilitan la innovación de procesos, las nuevas formas organizativas y la nueva naturaleza del trabajo en la empresa, conceptos que están irrumpiendo en al actual mundo empresarial.

Recomendamos la revisión de este libro ya que contiene respuestas muy valederas a los retos que actualmente afrontan las empresas y que requieren formas de gestión cada vez más ingeniosas.

GORDON Davis. Sistemas de Información Gerencial. Editorial McGraw-Hill. Bogotá 2003

La presente obra se encuentra enfocada a los usuarios finales de los Sistemas de Información en las diferentes posiciones administrativas o directivas en áreas funcionales de los negocios, tales como la contaduría, las finanzas, el mercado, la dirección de personal y la producción, administradores de organismos gubernamentales, de la salud o de la educación.

Es un libro bastante comprensible, hace una presentación equilibrada de los temas, se sintetizan los objetivos de aprendizaje al inicio de cada capítulo y emplea cierto estilo humorístico con el ánimo de mantener el interés de quienes lo lean.

Desarrollo del aprendizaje

Capitulo 1: Teoria de Sistemas

Datos Generales:

Guia Didactica	Guarderas Rodrigo, Jara Roa Dunia Inés, Sistemas I, Universidad Técnica Paticular de Loja. Loja ISBN 18302
Capítulo	1. Teoría de Sistemas
Páginas	15 – 28
Horas de estudio empleadas para el desarrollo del contenido	4 horas

Proposito:

Manejar el enfoque sistémico a fin de llegar a determinar la incidencia de los sistemas en cada una de las actividades.

Conceptos Clave:

Para iniciar a conocer el apasionante mundo de los sistemas y la forma de desarrollarlos, es necesario tener clara la diferencia entre dato, noticia, conocimiento e información ya que comúnmente se utilizan los términos como sinónimo, pero en realidad no es así.

Definiciones: dato, noticia, información, conocimiento

DATO

Los datos son una representación formalizada de hechos o ideas capaz de ser comunicadas y/o manipuladas por algún proceso. Según las normas INOR, un dato es una representación de hechos o conceptos, realizada de una manera formalizada, apta para la comunicación, interpretación o elaboración, para seres humanos, como para medios automáticos. Los datos denotan hechos y conceptos sin refinar expresados en forma de sentencias declarativas y constan de valores y figuras para su proceso. Los datos son los ingredientes para las noticias, éstos se recolectan, clasifican e interpretan. Quién conozca sólo datos no puede actuar sobre ellos sin un proceso adicional.

Ejemplo: 3.141592…..

Documentos contables que respaldan una operación.

NOTICIAS

Noticia es la significación que un ser inteligente expresa o extrae de los datos por medio de convenciones conocidas o de la representación particular usada, por consiguiente, la característica más importante de la noticia es el aspecto semántico. Las noticias son una acumulación de datos refinados que pueden ser una mercancía efímera. Generalmente las noticias se usan durante un tiempo limitado y con un alcance limitado.

Ejemplo: El día de hoy se confirma que Alan García fue reelecto como presidente en el Perú.

La venta de mercaderías realizada el día de hoy a INAPESA esta respalda por la factura y la letra de cambio.

CONOCIMIENTO

La síntesis constituye conjuntos de noticias producidas durante el análisis, los conocimientos surgen de la capacidad de crear un modelo fidedigno que describa el objeto y ejemplifique las acciones que pueden ejecutarse sobre y con el objeto.

Ejemplo: A = 2 * π

Para obtener el valor de A es necesario conocer el valor de π

Los documentos contables que respaldan la venta de mercaderías realizada el día de hoy a INAPESA, producen movimiento en las cuentas: Venta de Productos Terminados y Documentos por Cobrar.

INFORMACIÓN

Existe información cuando al transmitir el contenido de un mensaje o el resultado de una medición, éste es desconocido para el receptor antes de la recepción. Un mensaje cuyo contenido se conoce antes de haberlo leído no aporta información, debe haber más de una secuencia de símbolos, patrones, o valores antes de la recepción. Durante la recepción la incertidumbre se elimina y la elección queda limitada a una secuencia particular. Con el fin de recibir información verdadera, se puede exigir, que el receptor pueda entender el significado del mensaje; y no es conveniente dar el nombre de información a ciertos modos de adquisición de conocimientos que no pueden describirse explícitamente. No puede existir información más que a propósito de un elemento variable, el que se puede presentar en diferentes estados, la única cosa que se puede decir de ese fenómeno es cuál de esos estados se esta produciendo. Se puede definir la información como un fenómeno variable cualquiera, hay información cuando se designa el estado actual del fenómeno. Hace muchos años, Boulenger dijo: “Soporte de los conocimientos y las condiciones humanas, la información aparece como un hecho elemental presentándose bajo la forma de un conjunto de elementos numéricos, alfabéticos, alfanuméricos, gráficos, incluso símbolos a los que es posible darles sentido gracias a una definición o por referencia a una tabla”. En este caso la información es el texto y no el sentido asociado. La información es distinta de los conocimientos, es la fórmula escrita a la cual un ser inteligente asocia un sentido, por consiguiente es necesario señalar la acción de informar o de dar forma a unos conocimientos para permitir la comunicación o manipulación. La informática se encuentra sistemáticamente conformada con el problema de las relaciones entre estructura y sentido, es decir entre semántica y soporte. La semántica es el elemento esencial de la información (forma de transmisión verbal de la información), el soporte de la información es un fenómeno físico, que puede ser descrito en términos objetivos y es una operación técnica simple de discernir si los soportes de dos informaciones son diferentes (forma de transmisión escrita de la información).

Es importante resaltar dos aspectos fundamentales de la información:

1. El punto de vista humano de la información, donde, es importante el uso que se va dar a la información y la manera de interpretarla.

2. El punto de vista de las máquinas, lejos de cualquier interpretación semántica, lo único importante es la manera de almacenar y recuperar la información.

Ejemplo: ¿EL VALOR DE A = 6.283184?

¡EL SALDO DE VENTAS DEL DÍA DE HOY ES 2’890.000 USD!

La información aparece día a día en diferentes formas; datos, noticias y conocimientos se usan en distinta forma, en distintos contextos, con distintos o equivalentes significados. Por lo antes señalado podemos decir que se conocen tres niveles de información: (1) el sintáctico o de datos, (2) el semántico o de noticias, y (3) el pragmático o de conocimientos. En este sentido, una información se basa en datos o indicios, provoca noticias y va hacia consignaciones de hechos.

Sistema, Subsistema y Suprasistema

SISTEMA

El concepto de sistema ha sido utilizado por dos líneas de pensamiento diferentes. La primera es la teoría general de sistemas, corriente iniciada por Von Bertalanffy y continuada por Boulding, el esfuerzo central de este movimiento es llegar a la integración de las ciencias. El segundo enfoque es más práctico y se conoce con el nombre de “Ingeniería de Sistemas” o “Ciencia de Sistemas” iniciada por la Investigación de Operaciones” y seguida por la “Administración Científica” y finalmente por la “Administración de Sistemas”. Todos los que han definido la palabra sistemas están de acuerdo en que se trata de un conjunto de partes coordinadas y en interacción para alcanzar un conjunto de objetivos. Otra definición agrega algunas características adicionales, señala que un sistema es un grupo de partes y objetos que interactúan y que forman un todo y que se encuentran bajo la influencia de fuerzas en alguna relación definida.

Ejemplo: La AGD, la UTPL, la familia, la sociedad, etc.

Hall, define un “sistema como un conjunto de objetivos y las relaciones entre los objetos y sus atributos. Los objetos son simplemente las partes o componentes de un sistema y estas partes pueden obtener una variabilidad limitada”. En la mayoría de los sistemas estás partes son físicas, como por ejemplo, átomos, estrellas huesos, genes, músculos, aunque también, se incluye objetos abstractos tales como: variables matemáticas, ecuaciones, reglas, leyes, procesos, etc. los atributos son las propiedades de los objetos.

Ejemplo: El ser humano, es un sistema maravillosamente constituido y diseñado con muchas partes diferentes que contribuyen de distinta forma a mantener su vida, acción y reproducción.

Las estrellas tienen tempera, altura, distancia de unas a otras, velocidad, etc.

La definición que admite un carácter legalizado y aceptado por la General System Society for Research y que la vamos a utilizar define a los sistemas como un conjunto de partes o elementos interrelacionados entre sí y con el medio o entorno que lo rodea, de tal manera que forman una suma total o totalidad.

Para aclarar la presente definición, podemos detallar a que se refiere cada uno de los conceptos:

Conjunto. Colección de elementos dentro de un cierto marco referencial.

Elementos. Componentes o partes que constituyen el sistema.

Medio o entorno. Lo constituye todo lo que esta fuera del control del sistema y tiene alguna influencia sobre él.

Totalidad. Atributo definido por una cosa o un ser. Es la unidad o la suma total.

Para esclarecer lo que es un sistema puede ser útil identificar lo que no es un sistema:

Un sistema no es un objetivo o un fin. Todos los grupos sociales persiguen valores, salud, riqueza, justicia, etc., los cuales toman expresión en los fines: conservar la salud del pueblo; de los fines se desprenden una serie de propósitos concretos como: dar atención médica gratuita. Como puede observarse, los fines y los objetivos se encuentran en mismo continuo hacia lo que se pretende alcanzar. Un sistema no es una función. Por supuesto que los sistemas tienen influencia del medio ambiente, del que proviene una serie de insumos que a través de un proceso de conversión se traducen en acciones que de acuerdo con el dinamismo y capacidad administrativa y operativa del sistema son traducidos en bienes o servicios, en cambio, la función se identifica en el quehacer organizacional.

SUBSISTEMA Y SUPRASISTEMA

Cada una de las partes que encierra un sistema pueden ser consideradas como subsistemas, es decir, un subsistema es un conjunto de partes e interrelaciones que se encuentran estructuralmente y funcionalmente, dentro de un sistema mayor y que por lo tanto posee sus propias características. Así los subsistemas son sistemas más pequeños dentro de sistemas mayores. Los conceptos de sistema, subsistema y suprasistema llevan implícita la idea de recursividad, por cuanto los subsistemas y los suprasistemas son además sistemas. En este sentido las propiedades generales de los tres elementos son semejantes y fácilmente se pueden encontrar o derivar analogías y homologías. Para identificar sistemas, subsistemas y suprasistemas, es necesario primeramente definir el sistema y la frontera (línea imaginaria que permite definir lo que se queda dentro y fuera del sistema), luego definir los subsistemas (elementos) y por último definir a quien pertenece el sistema (suprasistema).

Ejemplo: Sistema: UTPL

Subsistemas: estudiantes, profesores, unidades académicas, plantas de producción, CITTES, almacén universitario, departamento financiero, departamento de recursos humanos, etc.

Suprasistema: CONESUP.

Es fácil crear un error cuando buscamos identificar los subsistemas de un sistema, porque no todas sus partes componentes pueden considerarse subsistemas, si es que queremos respetar el principio de recursividad, los sistemas como los supersistemas requieren cumplir ciertas características sistémicas como:

1. El principio de recursividad ya nos indica algo. Lo que es aplicable al sistema lo es para el suprasistema y subsistema.

2. La viabilidad es un criterio para determinar si una parte es o no un subsistema y entendemos por viabilidad la capacidad de sobrevivencia y adaptación de un sistema en un medio en cambio. Evidentemente, el medio de un subsistema será el sistema o gran parte de él.

3. Los subsistemas funcionales como: a) subsistema de producción, cuya función es la transformación de las corrientes de entrada en el bien y/o servicio que caracteriza al sistema y su objetivo es la eficiencia técnica. Ejemplo: el taller; b) subsistema de apoyo, busca proveer desde el medio al sistema de producción con aquellos elementos necesarios para esa transformación, luego son encargados de la exportación del bien y/o servicio en el medio, con el fin de recuperar o regenerar las corrientes de entrada, y, finalmente son las encargadas de lograr que el medio acepte o legalice la existencia misma del sistema; en concreto su objetivo es la manipulación del medio. Ejemplo: ventas, compras, relaciones públicas, etc.; c) subsistema de mantenimiento, encargado de lograr que las partes del sistema permanezcan dentro del sistema. Ejemplo: departamento de relaciones industriales; d) subsistema de adaptación, que buscan llevar a cabo los cambios necesarios para sobrevivir en un medio en cambio. Ejemplo: estudios de mercado, capacitación, investigación, desarrollo; e) subsistema de dirección, encargado de coordinar las actividades de cada uno de los restantes subsistemas y tomar decisiones en los momentos en que aparece necesaria una elección. Ejemplo: la línea ejecutiva.

La complejidad de un sistema esta dada por las interacciones entre sus componentes y subsistemas del sistema y por la variedad de cada uno de los subsistemas. Entendiendo por variedad el número de estados posibles que puede alcanzar un sistema o un componente. Un sistema tiende a ser más complejo cuando tanto las interrelaciones y la variedad aumentan; de esto puede desprenderse que a medida que integramos sistemas vamos pasando de una complejidad menor a una complejidad mayor.

En la medida que desintegramos sistemas en subsistemas vamos pasando de una complejidad mayor a una complejidad menor, a la inversa, a medida que integramos subsistemas en sistemas mayores (o sistemas en suprasistemas) vamos ganando comprensión del todo y las interrelaciones de sus partes. Además, a medida que desintegramos vamos perdiendo información del todo (o el sistema original) y nos vamos aproximando al método reduccionista, mientras que la integración presenta el enfoque de sistemas.

Apliquemos el método reduccionista al ejemplo anterior.

Ejemplo: Para conocer el funcionamiento de las unidades académicas con que cuenta nuestra universidad es necesario primeramente conocer el funcionamiento de cada una de las unidades, como: el funcionamiento de la escuela de administración en banca y finanzas, el funcionamiento de la escuela de ciencias de la computación, ….., hasta llegar a tener el conocimiento total del funcionamiento de las unidades académicas.

El método reduccionista es uno de los principales principios del informático y que nos permitimos compartirlo con ustedes: “divide y vencerás”. Para llegar a conocer algo se hace necesario dividirlo (el sistema en subsistemas) e ir conociendo poco a poco el todo. El momento que conocemos cada uno de los subsistemas es necesario integrarlos para conocer el todo.

En el ejemplo propuesto conociendo el funcionamiento de la escuela de administración en banca y finanzas, podemos pasar a conocer el funcionamiento de la escuela de ciencias de la computación, y así todas y cada una de las unidades académicas. Cuando conozcamos el funcionamiento de cada una de las unidades académicas que tiene la UTPL, podemos decir que conocemos el funcionamiento del sistema unidades académicas de la UTPL.

Fronteras de un Sistema

Por frontera de un sistema se entiende aquella línea que separa el sistema de su entorno o suprasistema y que define lo que le pertenece y lo que queda fuera de él. Esta definición puede no ser un problema simple de resolver. La dificultad de fijar fronteras de los sistemas se debe a las siguientes características de los sistemas:

Es difícil aislar los aspectos estrictamente mecánicos de un sistema.

El intercambio o relación entre sistemas no se limita exclusivamente a una familia de sistemas, existe un contacto permanente con el mundo exterior.

Existe un continuo intercambio de interrelaciones tiempo-secuencia, pensamos que cada efecto tiene su causa, de modo que las presiones del medio sobre el sistema modifican su conducta, y a la vez, este cambio de conducta modifica el medio y su comportamiento.

En todo caso, para la definición de un sistema siempre contaremos con dos conceptos que pueden ser de gran ayuda: la idea de un suprasistema y la idea de un subsistema, de este modo podemos definir al sistema en relación con su medio inmediato y en relación con sus principales componentes.

Clases de Sistemas

Kenneth Boulding, siguiendo la idea de complejidad creciente, ha formulado una escala jerárquica de sistemas, partiendo desde los más simples para llegar a los más complejos, estos son:

1. Estructuras Estáticas. Boulding lo denomina marco de referencia, en este nivel se encuentra la geografía y la anatomía del universo; es el conocimiento teórico organizado de todos los campos. Ejemplo: la estructura de los electrones al rededor del núcleo, los átomos en una fórmula molecular, la anatomía de la planta, de la célula, del gene, etc.

2. Sistemas Dinámicos Simples. Se caracterizan por sus movimientos predeterminados, en este nivel, se encuentran desde las máquinas más simples a las más complejas. Ejemplo: los movimientos del reloj, el sistema solar…

3. Sistemas Cibernéticos o Mecanismos de Control. Estos difieren de los sistemas con equilibrios estables simples por el hecho que la transmisión e interpretación de la información constituyen su parte esencial. La posición de equilibrio no se encuentra determinada por las ecuaciones del sistema, sino que el sistema se moverá para mantenerse dentro de cualquier estado de equilibrio, pero dentro de ciertos límites.

4. Sistemas Abiertos. En este nivel empieza a diferenciarse la vida de las materias inertes y puede ser denominado por el nombre de células, se reconoce la automantención y autoreproducción.

5. Sistema Genético Social. Se encuentra tipificado por las plantas. Las características más importantes en este nivel son: a) la división del trabajo entre las células para formar una sociedad de células con partes diferenciadas y mutuamente dependientes como las raíces, hojas, semilla, etc. b) una profunda diferencia entre fenotipo y genotipo, asociada con el fenómeno de la equifinidad, es decir, los sistemas llegan al mismo objetivo aunque difieran sus estados iniciales. En este nivel no existen órganos de los sentidos altamente especializados y los receptores de información son difusos e incapaces de recibir mucha información. No se puede decir que un árbol pueda distinguir entre el día y la oscuridad, días largos y días cortos, el frío y el calor, etc. pero es un hecho que distinguen cambios en el entorno como por ejemplo el girasol y el movimiento del sol.

6. Sistema Animal. Esta caracterizado por un incremento en la movilidad, en la conducta teleológica (propósito) y en la conciencia. Aquí se encuentran desarrollados receptores de información especializados: ojos, nariz, oídos, etc. que conducen a un enorme aumento de recepción de información. Existe también un gran desarrollo del sistema nervioso, terminado en el cerebro como un organizador de información recibida como imágenes o conocimientos estructurados.

7. Sistema Humano. Aquí se encuentra el hombre, considerado como sistema. Además de casi todas las características del nivel anterior, el hombre posee una conciencia que es algo diferente a la conciencia animal. Sus imágenes, a parte de ser mucho más complejas, se caracterizan por la reflexión. El hombre no sólo sabe, sino también reconoce que sabe, en su capacidad de hablar, en su habilidad de producir, absorber e interpretar símbolos complejos, aquí se encuentra la distinción más clara del hombre y de los animales.

8. Organizaciones Sociales. Prácticamente no existe el hombre aislado de sus semejantes. Tan importante es la imagen simbólica en la conducta humana que se puede sospechar que un hombre verdaderamente aislado no sería humano. En las organizaciones sociales, no importa el individuo (el ser humano como tal), sino el papel que desempeña, o de aquella parte de la persona que se preocupa de la organización o la situación. A las organizaciones sociales se las puede definir como un conjunto de roles interconectados por canales de comunicación, en este nivel, debemos preocuparnos del contenido y significado de los mensajes, de la naturaleza, y dimensión de los sistemas de valores, de la transcripción de imágenes en los registros históricos, de la simbolización del arte, música y poesía y de todo el complejo de las emociones humanas. Aquí el universo empírico es la vida humana y la sociedad con toda su complejidad y riqueza.

9. Sistemas Trascendentales. Aquí se encuentra la esencia, lo final, lo absoluto, y lo inexplicable como señala Boulding “Será un día triste cuando nadie pueda hacer una pregunta que no tenga una respuesta”.

10. Sistemas Ecológicos. Comprende la interacción de todos los niveles antes señalados. A la ecología se la puede definir como una disciplina biológica especializada que se ocupa de las relaciones de los organismos con su mundo circundante. A. F. Tienemann, define a la ecología como una ciencia natural situada por encima de las especialidades y coordinación de los fenómenos naturales, dice que la ecología es la ciencia de la economía de la naturaleza.

La clasificación que hace Boulding de los sistemas parte del universo, lo sitúa luego al hombre seguido por las plantas, los animales, seguidamente hace mención de la conciencia del hombre, de la organización del hombre, los sistemas inexplicables y por último inmiscuye al sistema ecológico; una visión muy realista de nuestra existencia. Para poder comprender y manejar los sistemas se hace necesario conocer la primer división que ha dado origen a dos tipos de sistemas: sistemas abiertos y sistemas cerrados.

Sistemas abiertos y cerrados

Dtarres y Forreste, los dos autores cuando hablan de sistema cerrado, tienen en mente un sistema con circuito cerrado. Así mismo, Von Bertalanffy, señala que un sistema cerrado es aquel que no intercambia energía con su medio (ya sea de importación o de exportación) y el sistema abierto es el que transa con su medio. Persegain, define un sistema abierto como aquel en que existe un intercambio de energía y de información entre el subsistema (sistema) y su medio o entorno. El intercambio es de tal naturaleza que logra mantener alguna forma de equilibrio continuo (o estado permanente) y las relaciones con el entorno son tales que admiten cambios y adaptaciones, como el crecimiento en el caso de los organismos biológicos. Según este autor un sistema es abierto cuando interactúa con su medio, importando energía, transformando de alguna forma esa energía y finalmente exportando la energía convertida. De acuerdo con este autor, un sistema es cerrado cuando no intercambia energía ni información con su medio, aunque pueda experimentar toda clase de cambios, es decir, el sistema se encuentra totalmente aislado, como podría ser el caso del universo total.

Importancia de los Sistemas

La administración de una organización consiste fundamentalmente en la capacidad de manejar sistemas complejos en mayor o menor grado. Para la práctica administrativa, actualizada y adecuada, serán los sistemas utilizados los que así lo determinen, por lo tanto deben ser realistas, objetivos y flexibles de modo que vayan acordes con el momento histórico y la situación en que sean implantados. Así mismo, se hace necesario que sean claros y que den la posibilidad a cambios estructurales. La administración es en sí una metodología efectiva aplicable a las actividades y a las relaciones humanas, siendo los sistemas un medio de acción y de resultados. Mediante los sistemas se evita que se pierdan de vista los objetivos primordiales de la organización, de no ser por los sistemas es posible que se caiga en divagaciones. Los sistemas que se elaboran sin haber considerado posibles situaciones de cambio corren el riesgo de quedar obsoletos e inservibles, por esto se hace necesario hacer modificaciones paulatinas, cada vez que aparezcan factores que ameriten ajustes. Como ejemplo se puede tomar la organización como un sistema, que a la vez se rige por un sistema de planes. El conjunto de planes elegidos para regir una empresa constituye, asimismo, un sistema jerárquico excesivamente complejo. Estamos, por lo tanto, rodeados de sistemas y no tiene importancia el hecho de que lo sean, o sólo se los perciban y si algún tipo de sistema necesario no existiera, sería imprescindible inventarlo.

Caracteristicas de los Sistemas

La característica inicial de un sistema consiste en estar compuesto por partes que ejercen interacción, sin esas interacciones el estudio de sistemas sería poco interesante, ya que son las interacciones las que nos dan el comportamiento de un sistema y hacen de su análisis una tarea muy compleja. Los componentes de un sistema están integrados por subpartes y, a su vez, éstas están ligadas mediante diversas interfases. La descripción completa del comportamiento del sistema exige la descripción del comportamiento de cada componente, así como las interrelaciones de esos componentes. Los límites de un sistema son necesariamente arbitrarios, o sea, cualquier rama de la jerarquía de un sistema puede ser considerada como un sistema en sí mismo. En general, existen interacciones entre un sistema y su medio ambiente, pero las variables exógenas se tratan como si fueran incontrolables, se considera que sólo las variables endógenas, que se emplean para describir un sistema, son susceptibles de cierto grado de control significativo. La fijación de un límite esencial arbitrario entre un sistema y su medio ambiente entraña el peligro de que las interacciones significativas no se consideran en forma explícita, tal fracaso introduce a la penalidad tradicionalmente asociada con las suboptimizaciones, es decir, la de lograr que sus metas locales no guarden coherencia con las metas superiores o globales. La estructura interna de un sistema como un límite con el medio ambiente, es un tanto cuanto convencional. En resumen, podemos decir que todo sistema, cualquiera que sea su naturaleza, tiene tres características básicas:

Todo sistema contiene otros sistemas (subsistemas) y a la vez está contenido en otros sistemas de carácter superior. Lo que da como resultado una auténtica categorización de suprasistemas, sistemas y subsistemas.

Todos los componentes de un sistema, así como sus interrelaciones, actúan y operan orientados en función de los objetivos del sistema. Se puede deducir que los objetivos constituyen el factor o elemento que direcciona todas las partes del conjunto. Todos lo componentes de un sistema son funcionalmente divisibles pero estructuralmente indivisibles.

La alteración o variación de una de las partes o de sus relaciones inciden en las demás y en el conjunto. Sin dejar de reconocer la importancia de otras características, ésta constituye uno de los soportes básicos para la construcción del modelo o matriz de análisis administrativo.

Todo sistema debe tener las siguientes características:

Estabilidad. Permite que el sistema funcione eficazmente a las acciones de los factores externos del mismo.

Adaptabilidad. Es la capacidad que tiene el sistema para evolucionar dinámicamente con arreglo a su entorno.

Eficiencia. Por lo cual el sistema obtiene su objetivo.

Sinergia. Es la capacidad de actuación del sistema total en mayor magnitud que la suma de las partes que lo componen.

Principios de los Sistemas

La integración o coherencia y la independencia o actividad no son propiedades separadas, puesto que son los extremos de una misma propiedad. Integración e independencia son fenómenos de calidad, pero aún no se cuenta con un método sensible para la medición de esta propiedad en una escala de proporcionalidad, sin embargo, esta propiedad es de utilidad en su idea general, puesto que todos los sistemas presentan necesariamente un grado de integración. La teoría general de sistemas es análoga al principio de las partes integrantes dentro de un todo. Por tanto, el principio de integración es vital en el concepto de sistemas. Los principios según Johnson, Kast y Rosenzwing son los siguientes:

El todo es primero y las partes son secundarias.

La integración es la condición de la interrelacionalidad de las muchas partes dentro de una.

Las partes así constituidas forman un todo indisoluble en el cual ninguna parte puede ser afectada sin afectar todas las otras partes.

El papel que juegan las partes depende del propósito para el cual existe el todo.

La naturaleza de la parte y su función se derivan de su posición dentro del todo y su conducta es regulada para relación del todo a la parte.

El todo es cualquier sistema o complejo o configuración de energía y se conduce como una pieza única, no importando qué tan compleja sea.

La totalidad debe empezar como una premisa y las partes, así como sus relaciones, deberán evolucionar a partir del todo.

El todo se renueva a sí mismo constantemente mediante un proceso de transposición, la identidad del todo y su unidad se preserva, pero las partes cambian. Este proceso continúa indefinidamente, algunas veces es planeado y observado, en otras ocasiones, ocurre sin notarlo, a menudo es alentado, pero otras veces se le resiste.

Para poder entender lo antes indicado podríamos decir que una organización es un todo integrado en donde cada sistema y subsistema están relacionados con la operación total. Su estructura, por tanto es creada por cientos de sistemas dispuestos en orden jerárquico. La salida del más diminuto de los sistemas resulta la variable de entrada para el próximo sistema mayor, que a su vez proporciona la variable para un nivel superior.

Componentes de un Sistema

Un sistema cualquiera que sea, se puede conceptualizar por cinco partes básicas, siendo:

ENTRADA.

Es la fuerza de arranque que suministra al sistema sus necesidades operativas. Puede ser materia, energía, personas o información.

PROCESO.

Es lo que transforma una entrada en salida. Puede ser una máquina, un individuo, una computadora, un producto químico, una tarea realizada, etc.

SALIDA.

Es el resultado del funcionamiento del proceso, es decir, el propósito para el cual existe el sistema. Puede ser un producto, un servicio, energía, etc.

RETROALIMENTACIÓN.

Representa una reintroducción de una parte de la salida de un sistema como entrada del mismo sistema. El objetivo de la retroalimentación es mantener la salida bajo ciertas condiciones deseadas.

La retroalimentación es un tipo especial de información que tiende a mantener al sistema dentro de un plan. Es decir, puede hacerse que los sistemas se muevan en dirección a una salida específica, mediante la regulación de las entradas con un mecanismo controlado llamado retroalimentación. La retroalimentación se usa para controlar que el sistema alcance el resultado deseado (producto o servicio), con esta retroalimentación se debe ajustar continuamente la combinación de insumos y tecnologías necesarias para lograr los productos deseados.

Retroalimentación positiva

Con este tipo de retroalimentación, la multiplicación entre la entrada y la salida es tal que la salida aumenta con incrementos en la entrada. La retroalimentación positiva generalmente conduce a la inestabilidad del sistema. En otras palabras, la retroalimentación positiva indica que se debe mantener constante la acción y se debe modificar los objetivos.

Retroalimentación negativa

Con este tipo de retroalimentación, la salida disminuye al aumentar la entrada. La retroalimentación negativa se usa para proporcionar un control de sistema estable. En otras palabras, la retroalimentación negativa indica que se debe modificar las acciones y mantener los objetivos.

MEDIO AMBIENTE.

Es aquella parte que se encuentra la margen del control completo del sistema y que determina de algún modo el desempeño del mismo. Ejerce, asimismo, una influencia considerable y significativa en el comportamiento del sistema.

Funciones de un Sistema

Al estudiar un sistema o subsistema podemos identificar la realización de alguna de las siguientes funciones:

1. Conseguir los objetivos y fines planteados.

2. Adaptarse al medio y a la situación dentro de la que a de desenvolverse.

3. Considerar un equilibrio interno o lo que es lo mismo, mantener los puntos, reglas o modelos sobre los que está constituido.

4. Mantener una cohesión interna, es decir, permanecer integrado.

5. Establecer un ambiente creativo entre las personas que forman el grupo.

Aumentar la capacidad casi continua de descubrir nuevas oportunidades para el negocio, pero manifestadas sobre todo en aquellos momentos en los que la oportunidad de la elección decida el futuro de la empresa a un plazo más o menos largo.

Esquema de Estudio:

La siguiente plantilla consta de: el tema a estudiar, la descripción del contenido y un conjunto de actividades que usted debe realizar para afianzar sus conocimientos. Además, a la derecha se han dispuesto tres columnas para llevar el control del tiempo que dedica a cada tema y marcar las actividades que estima necesita tutoría, y un espacio en donde usted puede realizar sus anotaciones personales.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
1.1 Sistema, subsistema y suprasistema	Describir lo que es sistema, subsistema, suprasistema. No olvide que debe presente el principio de recursividad.	Aplique los conceptos asimilados, para el efecto proponga un sistema, a partir del ejemplo propuesto describa el suprasistema y los subsistemas
1.2 Clases de sistemas	Revisar las clases de sistemas propuestas por Boulding.	Elabore un cuadro sinóptico en donde presente las clases de sistemas y la manera como se tipifica cada sistema
1.3 Componentes de un Sistema	Se detalla las partes básicas de los sistemas.	Al sistema propuesto en el literal 1.1 encuentre las partes básicas

Capitulo 2: Sistemas Socio-Tecnicos desde la Ingenieria del Software

Datos Generales:

Texto Base	SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005
Capítulo	2. Sistemas socio – técnicos 4. Procesos de software
Páginas	20 – 37 60 - 83
Horas de estudio empleadas para el desarrollo del contenido	8 horas

Proposito:

Analizar e identificar los diferentes modelos de desarrollo para la elaboración de productos software.

Conceptos Clave:

Sistemas socio – técnicos:
Comprenden uno o más sistemas técnicos, incluyen conocimiento de cómo debe usarse un sistema para alcanzar algún macro objetivo.

Estos sistemas definen los procesos operativos, incluyen personas (los(as) operadores(as) como partes inherentes del sistema, son gobernados por políticas y reglas organizacionales y pueden verse afectados por restricciones externas, como: leyes nacionales y políticas reguladoras.

Propiedades emergentes de los sistemas:
Las propiedades emergentes de los sistemas emergen sólo cuando los componentes del sistema han sido integrados, ya que algunas de estas propiedades pueden derivar directamente de las propiedades comparables de los subsistemas.

Propiedades emergentes funcionales:
Las propiedades emergentes funcionales se presentan cuando todas las partes de un sistema trabajan de forma conjunta para cumplir algún objetivo.

Propiedades emergentes no funcionales:Se refieren al comportamiento de los sistemas en su entorno operativo.

Ingeniería de sistemas:
La ingeniería de sistemas es la actividad de especificar, diseñar, implementar, validar, utilizar y mantener los sistemas socio – técnicos.

Requerimientos del sistema:
Las definiciones de requerimientos del sistema especifican qué es lo que el sistema debe hacer (sus funciones) y sus propiedades esenciales y deseables. Una parte importante de la fase de definición de requerimientos es establecer un conjunto completo de objetivos que el sistema debe cumplir.

Modelado de sistemas:El modelado de un sistema es un conjunto de componentes y de relaciones entre los componentes.

Sistemas herederos:
Son sistemas informáticos socio-técnicos que han sido desarrollados en el pasado, a menudo utilizando tecnología antigua. Estos sistemas no solamente incluyen hardware y software sino también procesos y procedimientos heredados.

Modelos de proceso de software:
Un modelo de proceso de software es una representación abstracta de un proceso del software. Cada modelo de proceso representa un proceso desde una perspectiva particular, y proporciona únicamente información de ese proceso.

Diseño de software:
Un diseño de software es una descripción de la estructura del software que se va a implementar, los datos que son parte del sistema, las interfaces entre los componentes del sistema y los algoritmos a utilizar.

Validación del software:
Implica procesos de comprobación, como las inspecciones y revisiones, en cada etapa del proceso de software desde la definición de los requerimientos hasta el desarrollo del programa.

Esquema de Estudio:

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
2.1 Propiedades emergentes de los sistemas	En este apartado se revisa las características esenciales de los sistemas socio-técnicos y las diferentes propiedades que los sistemas deben tener.	A partir de los ejemplos de las propiedades emergentes presentados en la figura 2.1, pág. 22 del texto base, establezca las principales propiedades emergentes de los sistemas de información.
2.2 Ingeniería de sistemas	Se refiere al proceso de la ingeniería de sistemas y el proceso de desarrollo del software.	Indique ¿Cuáles son las características del proceso de ingeniería de sistemas y cuáles son las características del proceso de desarrollo de software?
2.3 Diseño de sistemas	Constan las actividades que se realizan el en proceso de diseño de sistemas.	Mencione si ¿las actividades que se llevan a efecto en el diseño de sistemas son dependientes o interdependientes?
2.4 Sistemas heredados	Observar los componentes de los sistemas heredados.	Señale las partes lógicas de los sistemas heredados, tome como base la figura 2.11 de las páginas 35 – 36.
2.5 Modelos de proceso de software	Se refiere a los modelos de procesos genéricos utilizados en la ingeniería de software.	Argumente si los procesos de modelos genéricos se excluyen, o si por el contrario se usan juntos.
2.6 Enfoques para el desarrollo del sistemas	Se examina los diferentes modelos de proceso de desarrollo de software.	Sugiera el modelo de proceso de software que se podría utilizar para gestionar el desarrollo de un sistema de control tributario en una empresa textil.

Capitulo 3: Analisis de Requeremientos

Datos Generales:

Texto Base	SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005
Capítulo	6. Requerimientos de software
Páginas	108 – 127
Horas de estudio empleadas para el desarrollo del contenido	8 horas

Proposito:

Conocer, expresar y organizar los requerimientos para el desarrollo de un producto software.

Conceptos Clave:

Especificación del sistema:
La obtención de requerimientos se enfoca en la descripción del propósito del sistema. El(a) cliente, los(as) desarrolladores(as) y los(as) usuarios(as) identifican un área problema y definen un sistema para solucionar el problema; a dicha definición se la denomina especificación del sistema y sirve como contrato entre el(a) cliente y los(as) desarrolladores(as).

A medida que se va definiendo las especificaciones del sistema se hace referencia a diferentes tipos de requerimientos entre ellos los requerimientos de usuario(a) y de sistema.

Requerimientos:
Un requerimiento es una característica que debe tener el sistema o una restricción que se debe satisfacer para que sea aceptado por el(a) cliente, constituyéndose así en un puente entre el(a) cliente y el diseño y desarrollo del sistema.

Requerimientos de usuario(a):
Los requerimientos de usuario(a) son declaraciones que se espera que el sistema cumpla y de las restricciones bajo las cuales debe operar.

Requerimientos de sistema:
Los requerimientos del sistema hacen referencia a la forma de operar del sistema (funciones, servicios y restricciones).

Requerimientos funcionales:
Los requerimientos funcionales describen lo que el sistema debe hacer sus entradas, salidas y excepciones, deben ser completos y consistentes. Entendiéndose por completo, que se han definido todos servicios solicitados por el(a) cliente; lo consistente se refiere a que no deben existir definiciones contradictorias.

Requerimientos no funcionales:
Los requerimientos no funcionales hacen referencia a propiedades emergentes del producto software que estamos desarrollando como: fiabilidad, tiempo de respuesta y capacidad de almacenamiento; se puede decir que son los requerimientos que especifican o restringen las propiedades del sistema.

Requerimientos de dominio:
Como su nombre lo indica se derivan el domino de aplicación del sistema, o lo que es lo mismo, de las características del suprasistema.

Especificación de la interfaz:
Se habla de especificación de la interfaz cuando el producto software a desarrollar va a funcionar con otros sistemas ya implementados en la organización en la que va a funcionar en software a desarrollar.

Documento de requerimientos de software:
Los documentados de requerimientos de software representan una declaración oficial de lo que deben implementar los(as) desarrolladores(as) de software.

El documento de requerimientos sirve a un espectro muy variado de usuarios(as) por lo que debe presentar un equilibrio entre la comunicación de los requerimientos a los(as) clientes y a los(as) desarrolladores(as).

Notación para la especificación de requerimientos:
Existen diferentes notaciones para la especificación de requerimientos, entre otros: a) lenguaje natural estructurado, b) lenguajes de descripción de diseño, c) notaciones gráficas, y d) especificaciones matemáticas; se puede utilizar la combinación de diferentes notaciones para documentar debidamente lo requerimientos del sistema.

Esquema de Estudio:

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
3.1 Ingeniería de requerimientos	Se examina los requerimientos de usuario(a) y del sistema y las personas que tienen acceso a los diferentes tipos de especificaciones.	Piense en un sistema de control de recursos humanos para una institución pública, y redacte los requerimientos de usuario(a) y las especificaciones de los requerimientos del sistema. Considere el ejemplo presentado en la pág, 109 del texto base.
3.2 Requerimientos funcionales y no funcionales	Revisar lo que constituyen requerimientos funcionales, no funcionales y de dominio.	Para el sistema propuesto en el literal 3.1 describa los requerimientos funcionales, no funcionales y de dominio.
2.3 Diseño de sistemas	Constan las actividades que se realizan el en proceso de diseño de sistemas.	Mencione si ¿las actividades que se llevan a efecto en el diseño de sistemas son dependientes o interdependientes?
3.3 Requerimientos del sistema	Observar las diferentes notaciones que se pueden usar para la especificación de requerimientos.	Elabore un cuadro sinóptico en donde describa las diferentes notaciones para la especificación de requerimientos.
3.4 Notaciones gráficas	Examinar la forma de elaborar casos de uso.	Desarrolle los casos de uso para el sistema propuesto en el literal 3.1, considerando los requerimientos definidos en el literal 3.2.
3.5 Documento de requerimientos de software	Revisar los diferentes tipos de usuarios(as) que pueden acceder a un documento de requerimientos de software.	Mencione los tipos de usuario(a) que pueden acceder a un documento de requerimientos de software y la forma como cada tipo de usuario(a) utilizan éste documento.

Capitulo 4: Ingenieria de Requerimientos

Datos Generales:

Texto Base	SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005
Capítulo	7. Procesos de la Ingeniería de Requerimientos
Páginas	130 – 151
Horas de estudio empleadas para el desarrollo del contenido	8 horas

Proposito:

Determinar las actividades implicadas en el proceso de ingeniería de requerimientos en el desarrollo de un producto software..

Conceptos Clave:

Proceso de ingeniería de requerimientos:
El proceso de ingeniería de requerimientos es crear y mantener un documento de requerimientos del sistema. El proceso general abarca cuatro subprocesos de alto nivel de ingeniería de requerimientos. Éstos tratan de la evaluación de si el sistema es útil para el negocio (estudio de viabilidad); el descubrimiento de requerimientos (obtención y análisis); la transformación de los requerimientos en formularios estándar (especificación), y la verificación de que los requerimientos realmente definen el sistema que quiere el(a) cliente (validación).

Entradas y resultados de un estudio de viabilidad:
La entrada de un estudio de viabilidad es un conjunto de requerimientos de negocio preliminares, una descripción resumida del sistema y de cómo el sistema pretende contribuir a los procesos del negocio. Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema.

Obtención y análisis de requerimientos:
En esta actividad, los(as) ingenieros(as) de software trabajan con los(as) clientes y los(as) usuarios(as) finales del sistema para determinar el dominio de la aplicación, qué servicios debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones hardware, etc.

Stakeholder:
El término stakeholder se utiliza para referirse a cualquier persona o grupo de personas que se verá afectado, directa o indirectamente, por el sistema.

Descubrimiento de requerimientos:
Es el proceso de recoger información sobre el sistema propuesto y los existentes y extraer los requerimientos del(de la) usuario(a) y del sistema a partir de esta información.

Etnografía:
La etnografía es una técnica de observación que se puede utilizar para entender los requerimientos sociales y organizacionales. El valor de la etnografía es que ayuda a los(as) analistas a descubrir los requerimientos implícitos que reflejan los procesos reales mas que los formales en los que las personas están involucradas.

Validación de requerimientos:
La validación de requerimientos trata de mostrar que los requerimientos realmente definen el sistema que el(a) cliente desea, y es importante debido a que los errores en el documento de requerimientos pueden conducir a importantes costos al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema está en uso.

Gestión de requerimientos:
Es el proceso de comprender y controlar los cambios en los requerimientos del sistema. Es necesario mantenerse al tanto de los requerimientos particulares y mantener vínculos entre los requerimientos dependientes de forma que se puede evaluar el impacto de los cambios en los requerimientos. Hay que establecer un proceso formal para implementar las propuestas de cambios y vincular éstos a los requerimientos del sistema. El proceso de gestión de requerimientos debería empezar en cuanto esté disponible una versión preliminar del documento de requerimientos, pero se debería empezar a planificar cómo gestionar los requerimientos que cambian durante el proceso de obtención de requerimientos.

Esquema de Estudio:

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
4.1 Estudio de viabilidad	Se analiza lo que es un estudio de viabilidad y las cuestiones que esta orientado a resolver.	Indique las preguntas a las que debe responder un estudio de viabilidad.
4.2 Obtención y análisis de requerimientos	Se presenta las personas que intervienen en este proceso y las actividades que se deben cumplir.	Señale las actividades a seguir para la obtención y análisis de requerimientos.
4.3 Descubrimiento de requerimientos	Se detallan las fuentes de información y las técnicas más usadas para el descubrimiento de requerimientos.	Elabore un cuadro sinóptico dónde presente fuentes de información y las diferentes técnicas de descubrimiento de requerimientos.
4.4 Validación de requerimientos	Se refiere a las verificaciones sobre requerimientos en el documento de requerimientos.	Mencione las verificaciones que se pueden llevar a efecto en el documento de requerimientos, así como las diferentes técnicas de validación. Defina un sistema que haga falta en su localidad y solicite los requerimientos a diferentes stakeholders, luego proceda con la validación de cada uno de los requerimientos.
4.5 Gestión de requerimientos	Se presenta la manera como los requerimientos de los sistema deben evolucionar	Establezca la diferencia entre requerimientos duraderos y requerimientos no duraderos y mencione la forma en que se debe gestionar cada tipo de requerimientos

Capitulo 5: Modelo de Sistemas

Datos Generales:

Texto Base	SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005
Capítulo	8. Modelos de sistemas
Páginas	154 – 172
Horas de estudio empleadas para el desarrollo del contenido	8 horas

Proposito:

Manejar el modelamiento de sistemas para el desarrollo de software.

Conceptos Clave:

Modelado de sistemas:
El modelado de sistemas no es otra cosa que la construcción de una abstracción del sistema, se enfoca en aspectos interesantes e ignora los detalles irrelevantes, lo que es interesante o irrelevante varía de acuerdo a la tarea que se este realizando.

Los modelos constituyen un puente entre el proceso de análisis y el diseño; en el proceso de análisis se pueden usar modelos para comprender el sistema existente que debe ser reemplazado, o mejorado, o para especificar el nuevo modelo de sistema que es requerido.

Perspectivas a utilizar en el modelado de sistemas:
En el desarrollo de sistemas se usa el modelado para presentar el sistema desde diferentes perspectivas, por ejemplo:

Un modelo de flujo de datos (muestran cómo se procesan los datos en el sistema en diferentes etapas).

Un modelo de composición (también llamado de agregación muestra cómo las entidades del sistema están compuestas por otras entidades).

Un modelo arquitectónico (muestran los principales subsistemas que componen un sistema)

Un modelo de clasificación (constituyen los diagramas de clases / herencia de objetos, muestran las características comunes de las entidades.

Un modelo estímulo – respuesta (también llamados diagrama de transición de estados, muestran como el sistema reacciona a eventos internos y externos.

Modelos de contexto:
Un modelo de contexto contiene únicamente un proceso que representa el sistema completo, al que se ligan cada una de las entidades externas, es un modelo bastante simple de construir, una vez que se ha recolectado la información a través de las diferentes técnicas anotas (entrevistas, elaboración de escenarios, revisión de documentos, etnografía, ….).

Modelo de comportamiento:
Los modelos de comportamiento describen la manera como se comporta el sistema en su totalidad. En el libro texto base se presentan dos tipos de modelos: a) el modelo de flujo de datos, y b) el modelo de máquinas de estado.

El modelo de flujo de datos, modela el procesamiento de los datos en el sistema, mientras que el modelo de máquinas de estado, modelan cómo el sistema reacciona a los eventos. Cuando el sistema a desarrollar usa poco procesamiento de eventos externos es conveniente modelar el comportamiento del sistema con el modelo de flujo de datos; mientras que los sistemas en tiempo real están dirigidos por eventos con un mínimo de procesamiento de datos, en este caso el comportamiento del sistema es conveniente hacerlo con un modelo de máquinas de estado. Cuando un sistema esta dirigido por datos o por eventos es necesario modelar el comportamiento del sistema con el modelo de flujo de datos o con el modelo de máquinas de estado.

Modelo de datos:
Los modelos de datos definen la forma lógica de los datos procesados por el sistema y comúnmente se los denomina modelos semánticos de datos, éstos modelos presentan las entidades de datos, sus atributos asociados y las relaciones entre los enlaces.

El modelado de datos más difundido es el modelo Entidad – Relación – Atributo (modelado ERA), para mantener sus detalles se usa el diccionario de datos; es decir, una descripción de los datos acerca de los datos.

Modelo de objetos:
En el modelado de objetos los requerimientos del sistema utilizando un modelo de objetos, es conveniente diseñar orientando objetos y desarrollar el sistema en un lenguaje de programación orientado a objetos.

Un estándar para el modelado de objetos es el Lenguaje Unificado de Modelado (UML). Dentro de UML existen diferentes notaciones para diferentes modelos de sistemas, como por ejemplo, modelos de casos de uso, diagramas de secuencia, modelos de máquinas de estado, diagramas de colaboración, etc.

Métodos estructurados:
Los métodos estructurados proporcionan un marco para el modelado detallado de sistemas como parte de la elicitación y análisis de requerimientos. La mayoría de los métodos estructurados tienen su propio conjunto preferido de modelos de sistemas.

Esquema de Estudio:

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
5.1 Modelos de contexto	Se analiza como definir los límites de un sistema y la forma como elaborar un modelo arquitectónico de alto nivel.	Piense en un sistema de gestión académica que se encuentre funcionando en una institución educativa de su ciudad. Defina los aspectos sociales y organizacionales que definen los límites del sistema. A continuación elabore un modelo de contexto para dicho sistema.
5.2 Modelos de comportamiento	Se presenta la forma como describir el comportamiento del sistema, se menciona los modelos de flujo de datos, y los modelos de máquinas de estado.	Para el sistema presentado en el literal anterior (5.1) elabore el modelo de proceso que realiza el sistema.
5.3 Modelos de datos	Se detalla el modelo semántico de datos y el uso de diccionario de datos.	Mencione lo que entiende por diccionario de datos y las ventajas del mismo.
5.4 Modelos de objetos	Se refiere a los modelos de herencia, a la agregación de objetos, al modelo de comportamiento de objetos.	Elabore el modelado de objetos, para el sistema propuesto en el literal 5.1.
5.5 Métodos estructurados	Se presenta como los métodos estructurados son soportados por herramientas CASE, incluyendo la edición de modelos y la comprobación y generación de código.	Busque en Internet una herramienta Case para el que permita realizar análisis y diseño de sistemas, fíjese en las ventajas y limitaciones, Así mismo, considere los requerimientos de hardware software, y en el costo de dicha herramienta. Con la información recolectada elabore una síntesis.

Capitulo 6: Diseño Arquitectonico

Datos Generales:

Texto Base	SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005
Capítulo	11. Diseño arquitectónico 12. Arquitecturas de sistemas distribuidos
Páginas	220 – 239 242 - 262
Horas de estudio empleadas para el desarrollo del contenido	12 horas

Proposito:

Conocer, las perspectivas estructurales para el diseño de software para una ejecución centralizada y para una ejecución distribuida.

Conceptos Clave:

Diseño Arquitectónico:
El diseño arquitectónico es un proceso creativo, al momento de definirlo se debe elegir la estructura más adecuada pudiendo ser cliente – servidor, o por capas; para descomponer las unidades del sistema estructural en módulos hay que decidir sobre la estrategia

para descomponer subsistemas en componentes o módulos; y dentro del proceso de modelado de control, se toman decisiones sobre cómo se controla la ejecución de los subsistemas.

El diseño arquitectónico es difícil evaluarlo ya que la verdadera prueba de una arquitectura consiste en averiguar el grado de satisfacción de los requerimientos funcionales y no funcionales una vez que ha sido desarrollado.

Como resultado de un proceso arquitectónico se tiene un documento de diseño, el que puede contener varias representaciones gráficas junto con texto descriptivo asociado, debería incluir como se estructura el sistema en subsistemas, la aproximación adoptada y cómo se estructura cada sistema en módulos.

Organización arquitectónica:
Para la organización arquitectónica de los sistemas se pueden utilizar tres estilos organizacionales, estos son: a) estilo de repositorio de datos; b) estilo de servicios y servidores compartidos; y c) estilo por capas. Estos estilos se los puede utilizar juntos o por separado.

En la actualidad uno de los estilos más utilizados para el desarrollo de productos software es la aplicación en capas. Este modelo presenta algunas ventajas como: a) desarrollos paralelos (en cada capa); b) aplicaciones más robustas debido al encapsulamiento; c) mantenimiento y soporte más sencillo (es más fácil cambiar un componente que modificar una aplicación); d) alta escalabilidad.

Como tecnología, las arquitecturas n-capas proporcionan una gran cantidad de beneficios para las empresas que necesitan soluciones flexibles y fiables para resolver problemas complejos inmersos en cambios constantes.

El desarrollo en n-capas es un concepto estratégico que ayuda a la construcción y despliegue lógico de un sistema distribuido. Los sistemas de n-capas subdivididos ayudan a facilitar el desarrollo rápido de aplicaciones y su posterior despliegue, con beneficios incrementales.

Estilos de descomposición modular:
Una vez que se haya decidido la organización total del sistema, es necesario resolver la forma como se piensa descomponer los subsistemas en módulos. Si bien es cierto que los estilos mencionados (repositorio de datos, servicios y servidores compartidos, n-capas) se los puede utilizar en este nivel, es necesario precisar que se trata de componentes más pequeños por lo que se puede utilizar estilos alternativos de descomposición.

Al momento de descomponer un subsistema en módulos, se puede realizar una descomposición orientada a objetos, o una descomposición orientada a flujos de funciones.

Estilos de control:
En el texto base, se mencionan dos estilos de control genérico que se pueden usar en productos software, siendo: a) un control centralizado, y b) un control basado en eventos.

Un control centralizado se diseña un subsistema como controlador del sistema y tiene la responsabilidad de gestionar los otros subsistemas y las decisiones de control se determinan por los valores de algunas variables de estado del sistema; mientras que, los modelos de control dirigidos por eventos se rigen por eventos generados externamente.

Arquitecturas de sistemas distribuidos:
Se entiende por sistema distribuido al sistema en el que el procesamiento de información se distribuye sobre varias computadoras, cuando se diseña este tipo de sistemas debe considerarse los ventajas y los inconvenientes.

Las arquitecturas de los sistemas distribuidos pueden ser: a) arquitecturas de cliente – servidor, y b) arquitecturas de objetos distribuidos.

Arquitectura cliente - servidor:
En el diseño de la arquitectura cliente – servidor se hace referencia a procesos lógicos y se entiende como una aplicación que se modela como un conjunto de servicios proporcionados por los servidores y un conjunto de clientes que utilizan dichos servicios.

Arquitectura de objetos distribuidos:
Una arquitectura de objetos distribuidos puede ser usada como un modelo lógico que permite estructurar y organizar un producto software en la que se debe: a) pensar en cómo proporcionar las funcionalidades de la aplicación en términos de servicios y combinaciones de servicios, y b) se debe identificar cómo proporcionar los servicios utilizando varios objetos distribuidos diseñados a alto nivel.

CORBA:
Son un conjunto de estándares para middleware que soportan arquitecturas de objetos distribuidos. Incluyen definiciones de modelos de objetos, definiciones de un intermediario de peticiones de objetos y definiciones de servicios comunes.

Esquema de Estudio:

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
6.1 Decisiones de diseño arquitectónico	Se analiza las decisiones que los(as) arquitectos(as) de sistemas deben tomar en el proceso de desarrollo del software.	Mencione al menos cuatro interrogantes a las que debe responder el(a) arquitecto de sistemas, durante el desarrollo del software.
6.2 Organización del sistema	Se presenta el modelo de repositorio, modelo cliente – servidor y modelo de capas.	Sugiera un modelo estructural adecuado para un sistema de venta automática de boletos a ser implementado en la Terminal Terrestre de Quito. A continuación, diseñe una arquitectura para el sistema propuesto, haga suposiciones razonables sobre los requerimientos del sistema.
6.3 Estilos de descomposición modular	Se refiere a la diferencia entre subsistema y módulo y a las estrategias que se usan para descomponer un subsistema en módulos.	Defina los subsistemas y los módulos para el sistema presentado en el literal 6.2
6.4 Estilos de control	Se detallan los estilos de control genéricos que se usan en sistemas software: control centralizado, control basado en eventos.	Para el sistema presentado en el literal 6.2 presente el modelo de control más adecuado.
6.5 Arquitecturas multiprocesador, arquitecturas cliente – servidor, arquitecturas de objetos distribuidos	Se consideran las características de cada una de las arquitecturas	Proponga un sistema en donde sería conveniente aplicar la arquitectura se sistemas distribuidos. Para el ejemplo propuesto justifique la arquitectura distribuida que emplearía

Capitulo 7 Diseño Orientado a Objetos

Datos Generales:

Texto Base	SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005
Capítulo	14. Diseño Orientado a Objetos
Páginas	286 – 305
Horas de estudio empleadas para el desarrollo del contenido	8 horas

Proposito:

Realizar análisis y diseño orientado a objetos de un sistema de información.

Conceptos Clave:

Objetos y clases:
Un objeto se define como una entidad que tiene un estado y un conjunto de operaciones definidas que operan sobre ese estado. El estado se representa como un conjunto de atributos del objeto. Las operaciones asociadas a los objetos proveen servicios a otros objetos (clientes) que solicitan estos servicios cuando se requiere llevar a cabo algún cálculo.

Objetos concurrentes:
Los objetos concurrentes solicitan un servicio a otro objeto enviándole un mensaje de “solicitud de servicio” a ese objeto.

Proceso de diseño orientado a objetos:
El proceso de diseño orientado a objetos requiere: a) comprender y definir el contexto y los modos de utilización del sistema, b) diseñar la arquitectura del sistema, c) identificar los objetos principales en el sistema, d) desarrollar los modelos de diseño, e) especificar las interfaces de los objetos.

Diseño de la arquitectura:El diseño de la arquitectura reconoceremos tres capas:

:a) capa de interfaz,
:b) capa de recogida de datos,
:c) capa de instrumentos.

En términos generales se debe tratar de descomponer un sistema de tal modo que las arquitecturas sean lo más sencillas posibles. Una regla que siempre funciona es que no debe haber más de siete entidades fundamentales, en un modelo arquitectónico.

Modelos de diseño:Los modelos de diseño pueden estáticos y dinámicos.

1. Modelos estáticos, describen la estructura estática del sistema en términos de las clases del sistema y sus relaciones.

2. Modelos dinámicos, describen la estructura dinámica del sistema muestran las interacciones entre los objetos del sistema (no entre las clases).

Especificación de la interfaz de los objetos:
Una parte muy importante del diseño es la especificación de las interfaces entre los diferentes componentes de diseño. Es muy necesario identificar las interfaces para que los objetos y otros componentes se puedan diseñar en paralelo.

Evolución del diseño:
Una ventaja importante del modelo orientado a objetos es que simplifica el proceso de realizar cambios en dicho sistema, esto se debe esencialmente a la que la representación de un estado del objeto no influye en el diseño, y cambiar los diseños internos de cada objeto es un cambio interno y no afecta a ningún otro objeto.

Esquema de Estudio:

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
7.1 Diseño Orientado a Objetos	Se analiza lo que es análisis orientado a objetos, diseño orientado a objetos, programación orientada a objetos.	Establezca las características de los sistemas orientados a objetos. Señale la diferencia entre objeto y clase, para el efecto utilice ejemplos.
7.2 Objetos y clases	Se examina objetos, clases y los objetos concurrentes.	Identifique los objetos que permitan modelar un sistema para automatizar el proceso contable (jornalización, mayorización, estados financieros)
7.3 Proceso de diseño orientado a objetos	Se ilustra el proceso de diseño Orientado a Objetos por medio de un ejemplo.	Con el ejemplo que propuso en el literal 7.2 complete el diseño orientado a objetos.

Capitulo 8 Diseño de Interfaces de Usuario (a)

Datos Generales:

Texto Base	SOMMERVILLE Ian. Ingeniería de Software. 7ma. Edición. Editorial Pearson Addison Wesley. Madrid. España. 2005
Capítulo	16. Diseño de interfaces de usuario
Páginas	332 – 352
Horas de estudio empleadas para el desarrollo del contenido	6 horas

Proposito:

Manejar los diferentes aspectos de diseño de interfaces de usuario(a).

Conceptos Clave:

Preguntas a las que debe responder el usuario:
Cuando se diseñan interfaces de usuario(a) se deben tener algunas consideraciones que se resumen en dos preguntas clave, que son:

¿Cómo debe actuar el(a) usuario(a) con el sistema informático?

¿Cómo se debe presentar la información del sistema informático al(a la) usuario(a)?

Interacción del usuario(a):
Interacción del usuario(a), significa emitir comandos y datos asociados al sistema informático.

Se han definido formas de interacción en cinco estilos principales, éstos son:

- Manipulación Directa

- Selección de menús

- Rellenado de formularios

- Lenguaje de comandos

- Lenguaje natural

Presentación de la información:
Los sistemas interactivos tienen que proporcionar alguna forma de presentar la información a los(as) usuarios(as). Esta presentación de la información puede ser simplemente una representación directa de la información de entrada o presentar la información gráficamente.

Mensajes de error:
Los mensajes de error deben ser formales, concisos, uniformes, y constructivos. No deben ser ofensivos ni tener sonidos asociados. En la medida de lo posible, el mensaje debe sugerir cómo se podría corregir el error. El mensaje de error debe vincularse a un sistema de ayuda en línea sensible al contexto.

Proceso de diseño de interfaz de usuario(a):
Existen tres actividades esenciales en el proceso de diseño de interfaz de usuario(a), éstas son: a) análisis del usuario(a), b) prototipado del sistema, y c) evaluación de la interfaz.

Análisis del usuario(a):
Una de las actividades críticas es el análisis de actividades del(de la) usuario(a) que deben ser soportadas por el sistema informático, es necesario entender y conocer lo que necesitan y quieren hacer los(as) usuarios(as) con el sistema.

Para desarrollar ésta comprensión se puede utilizar varias técnicas cono. análisis de tareas, entrevistas de usuario(a) , y cuestionarios, estudios etnográficos, y observaciones, o comúnmente, una mezcla de todas ellas.

El análisis de tareas y las entrevistas se cent4ran en una sola persona (el(a) usuario(a)) y en su trabajo, mientras que, la etnografía adopta una perspectiva más general y considera cómo interactúan las personas, cómo organizan su entorno de trabajo, y cómo cooperan para resolver problemas.

Prototipazo de la interfaz de usuario(a):
El prototipado evolutivo o explicativo con la implicación de usuarios finales es la única forma práctica de diseñar y desarrollar interfaces gráficas para usuarios de sistemas software.

Evaluación de la interfaz:
La evaluación de la interfaz es el proceso de evaluar la forma en que se utiliza una interfaz y verificar que cumple los requerimientos del(de la) usuario(a).

Esquema de Estudio:

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas
8.1 Diseño de interfaces	Se analizan los factores humanos que se deben considerar en el diseño de interfaces de usuario(a) y los principios de diseño de interfaces de usuario(a) que se deben considerar.	Relacione los factores humanos que se debe considerar en el diseño de interfaces con los principios propuestos. Tome en cuenta que a un factor humano puede aplicarse varios principios.
8.2 Asuntos de diseño	Se detallan algunos asuntos de diseño que tienen que ser considerados por los(as) diseñadores(as) de interfaz de usuario(a) como: tipo de interacción del(de la) usuario(a) y presentación de la información.	Para el sistema ideado en el literal 7.2 del capítulo 7, redacte las definiciones precisas de las interfaces de usuario(a)
8.3 Análisis de usuario(a)	Se examina el proceso interactivo del diseño de la interfaz de usuario(a) y se presentan las actividades que se deben desarrollar, como: análisis del(de la) usuario(a), prototipado del sistema y evaluación de la interfaz.	a. Sugiera las formas en que se podría adaptar la interfaz de usuario(a) para el sistema mencionado en el literal anterior (8.2) . b. Diseñe las interfaces de usuario(a) considerando las sugerencias vertidas anteriormente.
8.4 Evaluación de la interfaz	Se analiza la forma en que se verifican y validan las interfaces.	Evalué las interfaces diseñadas utilizando los diferentes atributos de usabilidad

Obtenido de "http://www.utpl.edu.ec/ecc/wiki/index.php/Sistemas_I"

Sistemas I

De Computacion

Tabla de contenidos

Objetivo General

Objetivos Especificos

Bibliografia

Desarrollo del aprendizaje

Capitulo 1: Teoria de Sistemas

Datos Generales:

Proposito:

Conceptos Clave:

Definiciones: dato, noticia, información, conocimiento

Sistema, Subsistema y Suprasistema

Fronteras de un Sistema

Clases de Sistemas

Importancia de los Sistemas

Caracteristicas de los Sistemas

Principios de los Sistemas

Componentes de un Sistema

Funciones de un Sistema

Esquema de Estudio:

Capitulo 2: Sistemas Socio-Tecnicos desde la Ingenieria del Software

Datos Generales:

Proposito:

Conceptos Clave:

Esquema de Estudio:

Capitulo 3: Analisis de Requeremientos

Datos Generales:

Proposito:

Conceptos Clave:

Esquema de Estudio:

Capitulo 4: Ingenieria de Requerimientos

Datos Generales:

Proposito:

Conceptos Clave:

Esquema de Estudio:

Capitulo 5: Modelo de Sistemas

Datos Generales:

Proposito:

Conceptos Clave:

Esquema de Estudio:

Capitulo 6: Diseño Arquitectonico

Datos Generales:

Proposito:

Conceptos Clave:

Esquema de Estudio:

Capitulo 7 Diseño Orientado a Objetos

Datos Generales:

Proposito:

Conceptos Clave:

Esquema de Estudio:

Capitulo 8 Diseño de Interfaces de Usuario (a)

Datos Generales:

Proposito:

Conceptos Clave:

Esquema de Estudio:

Vistas

Herramientas personales

Navegación

Sitios UTPL

Sitios ECC

Buscar

Herramientas