Analisis de Sistemas i

WORK PAPER #

FACULTAD DE CIENCIA Y TECNOLOGA

RED NACIONAL UNIVERSITARIA

SYLLABUS

Facultad de Ciencia y Tecnologa

Ingeniera de SistemasQUINTO SEMESTRE

Gestin Acadmica II/2013

UDABOL

UNIVERSIDAD DE AQUINO BOLIVIA

Acreditada como PLENA mediante R.M. 288/01

VISIN DE LA UNIVERSIDADSer la Universidad lder en calidad educativa.MISIN DE LA UNIVERSIDADDesarrollar la Educacin Superior Universitaria con calidad y competitividad al servicio de la sociedad.SYLLABUS

Asignatura:ANALISIS DE SISTEMAS I

Cdigo:CMP316

Requisito:CMP228

Carga Horaria:80 Horas

Crditos:6

I. OBJETIVOS GENERALES DE LA ASIGNATURA. Justificar la utilizacin de los diferentes mtodos a partir de la interpretacin de los conceptos tericos y su aplicacin a la realidad.

Definir los elementos de un sistema mediante el modelado, diseo e implementacin de diferentes mtodos y su seleccin adecuada a un nivel aplicativo.

Evaluar proyectos relacionados al modelado y diseo a partir de la correcta interpretacin de la teora y la prctica.II. PROGRAMA ANALTICO DE LA ASIGNATURA.

MDULO 1: ANALISIS Y DISEO DE SISTEMAS1.1 Enfoque de Sistemas1.1.1 Introduccin a la Teora General de Sistemas Informacin1.1.2 Descripcin formal de Sistemas1.1.3 Principios, propiedades y paradoja de sistemas1.1.4 Ciclo bsico de un sistema1.1.5 Supervivencia de Sistemas

1.2 Introduccin

1.2.1 Qu es un Sistema?1.2.2 Estrategia para el desarrollo de sistemas1.2.3 Herramientas para el desarrollo de Sistemas1.2.4 Mtodo de desarrollo por anlisis estructurado1.2.5 Paradigma tradicional de desarrollo de sistemas1.2.6 Mtodo del prototipo de sistemas

Paradigma Tradicional del Desarrollo de SistemasVisin GeneralEtapas del anlisis y desarrolloEstudio de factibilidadDeterminacin de RequerimientosEspecificacin del diseo e implementacinEspecificacin de prueba

MDULO 2: DESARROLLO POR ANALISIS ESTRUCTURADO

2.1 Estrategia de desarrollo por anlisis estructurado

2.1.1 Anlisis estructurado2.1.2. Notacin

2.1.3 Actividades paralelas2.1.4 Desarrollo del diagrama de flujo de datos (DFD)

2.1.5 Proceso de desarrollo2.1.6 Reglas generales para el dibujo de los diagrama2.1.7 Evaluacin de DFD para verificar que es correcto2.1.8 Descripcin de las estructuras de datos

2.1.9 Definicin de la estructura de datos2.1.10 Descripcin de procesos2.1.11 Diccionario de datos

MDULO 3: DESARROLLO POR PROTOTIPO DE APLICACIONES

3.1 Que es un prototipo3.2. Razones para el empleo de prototipos

3.3 Etapas del mtodo de prototipos

3.4 Identificacin de requerimientos conocidos

3.5 Desarrollo de un modelo de trabajo

3.6 Uso de prototipos

3.7 Abandono de la aplicacin

3.8 Herramientas para el desarrollo de prototipos

3. 9 Bibliotecas de cdigo reutilizable.

MDULO 4: HERRAMIENTAS PARA EL DESARROLLO DE SISTEMAS

4.1 Importancia de las herramientas para el desarrollo4.2 Beneficios del empleo de herramientas4.3 Clasificacin de herramientas4.4 Aplicacin de herramientas4.5 Implementacin del proyecto en la herramienta seleccionada

III. BIBLIOGRAFIA

Senn James Anlisis de Sistemas de Informacin (McGraw Hill, 1999).

Kendall & Kendall Anlisis y Diseo de Sistemas (Prentice Hall, 1997).

Pressman S. Roger Ingeniera de Software (McGraw Hill. 1997).

Laudon, Laudon "Administracin de Sistemas de Informacin" (Prentice Hall. 1996).

APUNTES: Adicionalmente el estudiante dispondr de los Work papers y DIFs entregados por el docente, los que forman parte del texto de la asignatura.IV. CONTROL DE EVALUACIONES

1 evaluacin parcial

Fecha: Nota:

2 evaluacin parcial

Fecha: Nota:

Examen final

Fecha:

Nota:

APUNTES

WORK PAPER # 1

PROGRAMA DE CONTROL DE CALIDAD

Nro DE PROCEDIMIENTO: APRO 012 Nro. DE HOJAS: 6

ELABORO: CDIGO:

TITULO WORK PAPER: Teora General de Sistemas

DPTO: UDABOL LA PAZ

DESTINADO A:

DOCENTE ALUMNOS xADMINISTRATIVOSOTROS

OBSERVACIONES:

FECHA DE DIFUSIN:

FECHA DE ENTREGA:

TEORIA GENERAL DE SISTEMAS

WORK PAPER 1

La mayor fuente de entropa

el hombre es la ignorancia

Pablo Suazo

Para poder empezar a hablar de anlisis y diseo de sistemas, inicialmente debemos entender la Teora General de Sistemas, que sus partes ms relevantes referencia a que la integracin de las diversas ciencias se orienta al rumbo de los sistemas.

1. INTRODUCCIN A LA TEORA GENERAL DE SISTEMASLa teora general de sistemas se presenta como una forma sistemtica y cientfica de aproximacin y representacin de la realidad y al mismo tiempo como una orientacin hacia una prctica de trabajo interdisciplinaria, es un mtodo que nos permite unir y organizar los conocimientos con la intencin de lograr una mayor eficacia de accin, la primera formulacin conocida es atribuida al bilogo Ludwing von Bertalanffy en 1940, como un intento de obtener un modelo nico para el tratamiento de los problemas que los enfoques analtico reduccionistas y sus principios causales no poda resolver.

Estos enfoques por ejemplo basados en los principios cartesianos aplicados al estudio de un fenmeno decan que se deba dividir un fenmeno en elementos simples, luego analizar cada elemento simple y finalmente reunir todos los elementos simples para reconstruir el fenmeno inicial. Pero como nadie indic las reglas de subdivisin vlidas poda en la mayora de los casos incrementar la dificultad, por tanto naci la necesidad de una nueva teora.

1.1 Caractersticas

En 1954 la Society for General Systems Research (Sociedad para la bsqueda de Sistemas Generales), enumera las siguientes caractersticas de la TGS:

a. Investigar el isomorfismo (misma forma cristalina y distinta composicin qumica) de conceptos, leyes y modelos en varios campos y facilitar las transferencias entre aquellos.

b. Promocin y desarrollo de modelos tericos en campos que carecen de ellos.

c. Reducir la duplicacin de los esfuerzos tericos

d. Promover la unidad de la ciencia a travs de principios conceptuales y metodolgicos unificadores.

La TGS se caracteriza por su perspectiva holstica (holismo es la comprensin de la totalidad a partir de leyes especficas) e integradora, donde lo importante son las relaciones y los conjuntos que a partir de ellas emergen.

1.2 Objetivos

Los objetivos de la Teora General de Sistemas son los siguientes:

a. Impulsar el desarrollo de una terminologa general que permita describir las caractersticas, funciones y comportamientos sistmicos.

b. Desarrollar un conjunto de leyes aplicables a todos estos comportamientos y, por ltimo,

c. Promover una formalizacin (matemtica) de estas leyes.

1.3. Conceptos Bsicos de la Teora General de Sistemas.

1.3.1. Descripcin Formal de Sistemas.El trmino sistema proviene de la palabra griega systema que significa un todo organizado, a continuacin brindamos algunas definiciones de sistemas

Es un conjunto organizado de cosas o partes interactantes e interdependientes, que se relacionan formando un todo unitario y complejo.

Conjunto de elementos que guardan estrecha relacin entre s y que mantienen al sistema directa o indirectamente unido de modo ms o menos estable y cuyo comportamiento global persigue normalmente algn objetivo.

Todas estas definiciones nos permiten extraer una definicin general que dice:

Un sistema es un conjunto de elementos relacionados entre si en funcin de un objetivo comn.

Bsicamente todo se puede analizar desde la perspectiva de sistemas, por ejemplo, vivimos en un sistema social y econmico, nos comunicamos utilizando un lenguaje que es un sistema formado por palabras y smbolos, conjunto de smbolos, una organizacin es un sistema sus componentes mercadotecnia, manufactura, ventas, investigacin, embarques, contabilidad y personal, trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los accionistas de las compaas.

1.3.2. Objetivos

Los objetivos del sistema son las metas o fines hacia los cuales se quiere llegar. Por ello la bsqueda del objetivo es muy importante. Son la razn de la existencia de los mismos. En general cualquier sistema carece de razn de ser si no cuenta con objetivos

Por ejemplo el sistema de arranque de un automvil tiene el claro propsito de quemar el combustible para crear la energa que emplean los dems sistemas del mismo.

1.3.3. Componentes de los sistemas

Cualquier sistema se puede descomponer en los siguientes elementos componentes:

Subsistemas

Medio AmbienteRelaciones

Frontera

1.3.3.1 Medio Ambiente

El Medio ambiente es todo aquellos que esta fuera del sistema, pero es muy importante pues nos provee los insumos necesarios para que el sistema funcione y recibe los egresos del sistema

Los insumos o recursos pueden ser: humanos (personas), materiales (maquinas, equipos, materia prima), tecnolgicos, administrativos (planificacin, direccin), financieros, siendo los egresos productos o servicios.

1.3.3.2 Relaciones:

Las relaciones son los enlaces que vinculan entre s a los objetos o subsistemas que componen a un sistema complejo.

Podemos clasificarlas en :

- Simbiticas: es aquella en que los sistemas conectados no pueden seguir funcionando solos. A su vez puede subdividirse en unipolar o parasitaria, cuando un sistema no puede vivir sin el otro sistema por ejemplo una planta, un bebe sin la madre; y bipolar o mutual, cuando ambos sistemas dependen entre si como ocurre con los subsistemas del cuerpo humano.

- Sinrgica: es una relacin que no es necesaria para el funcionamiento pero que resulta til, ya que su presencia mejora el desempeo del sistema. Sinergia significa "accin combinada" interpretndose como esfuerzo cooperativo, por ejemplo el aditivo que se coloca en los motores a gasolina.

Superflua: Son relaciones que repiten otras relaciones, su razn es intentar garantizar que el sistema funcione casi todo el tiempo, si se podran expresar en una sola palabra podras decir que estamos hablando de redundancia.

1.3.3.3 Subsistemas

Al ser sistemas ms pequeos se acogen a la definicin de sistemas brindada con anterioridad.

Por ejemplo, el cuerpo humano esta compuesto por subsistemas como ser el respiratorio y circulatorio y un automvil tiene los subsistemas elctrico, de combustin e hidrulico.

1.3.3.4 Frontera

Se puede decir que la frontera del sistema es aquella lnea imaginaria que separa al sistema de su entorno y que define lo que le pertenece y lo que queda fuera de el, su determinacin es fundamental para determinar lo que queda dentro del sistema y lo que esta fuera de el.

1.3.4 Operacin de un Sistema

Todos los sistemas tienen una entrada, realizan un proceso y generan un salida.Entradas

Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o informacin, constituyen la fuerza de arranque que suministra al sistema sus necesidades operativas.

Las entradas pueden ser:

- en serie: es el resultado o la salida de un sistema anterior con el cual el sistema en estudio est relacionado en forma directa.

- aleatoria: es decir, al azar, donde el termino "azar" se utiliza en el sentido estadstico. Las entradas aleatorias representan entradas potenciales para un sistema.

- retroalimentacin: es la reintroduccin de una parte de las salidas del sistema en s mismo.

Proceso:

Proceso es todo aquello que transforma una entrada en salida, como una mquina, un individuo, una computadora, un producto qumico, una tarea realizada por un miembro de la organizacin, etc.

Si en la transformacin sabemos exactamente los pasos que se siguen para transformar una entrada en una salida, el proceso recibe el nombre de caja blanca, por el contrario si desconocemos el proceso, pero sabemos que ante una determinada entrada se produce una determinada salida, entonces estamos ante una caja negra.

Salidas:

Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas, pueden adoptar la forma de productos, servicios e informacin.

Clasificacin de los Sistemas

Existen varias formas de clasificar los sistemas a continuacin mencionamos alguna de ellas:

Segn su naturaleza los sistemas pueden ser agrupados:

Reales asumen una existencia independiente del observador (quien los puede descubrir). (Los animales)

Ideales son construcciones simblicas, como el caso de la lgica y las matemticas.

Modelos son abstracciones de la realidad donde se combina lo conceptual con las caractersticas de los objetos.

De acuerdo a su origen se clasifican en naturales o artificialesDe acuerdo a la relacin con el medio ambiente o el grado de aislamiento se pueden clasificar en:

Sistemas Abiertos son aquellos que constantemente estn intercambiando insumos y productos con el medio ambiente. Un sistema es cerrado cuando ningn elemento de afuera entra y ninguno sale fuera del sistema, por ejemplo una reaccin qumica en un frasco cerrado y aislado En realidad no existen sistemas cerrados, pero el concepto es muy importante porque ilustra el objetivo del diseo de sistemas, construir sistemas que necesiten la menor intervencin del medio externo para mantener un nivel de desempeo aceptable.

Otros tipos de clasificaciones son las siguientes:

Sistemas duros son aquellos en los cuales el aspecto humano esta en segundo plano.

Sistemas suaves son aquellos que toman en cuenta el aspecto humano.

Caractersticas de los Sistemas

Adaptabilidad:

Es la propiedad que tiene un sistema de aprender y modificar un proceso, un estado o una caracterstica de acuerdo a las modificaciones que sufre el contexto. Esto se logra a travs de un mecanismo de adaptacin que permita responder a los cambios internos y externos a travs del tiempo.

Por ejemplo el ser humano puede adaptarse a diversos tipos de climas

Mantenibilidad:

Es la propiedad que tiene un sistema de mantenerse constantemente en funcionamiento. Para ello utiliza un mecanismo de mantenimiento que asegure que los distintos subsistemas estn balanceados y que el sistema total se mantiene en equilibrio con su medio.

Ejemplo: La alimentacin humana.

Estabilidad:

Esta propiedad es resultado de la anterior y dice que un sistema es estable cuando puede mantenerse en equilibrio a travs del flujo continuo de materiales, energa e informacin.

Homeostasis:

La homeostasis es la propiedad de un sistema que define su nivel de respuesta y de adaptacin al contexto.

Entropa:

La entropa de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. Los sistemas altamente entrpicos tienden a desaparecer por el desgaste generado por su proceso sistmico. Los mismos deben tener rigurosos sistemas de control y mecanismos de revisin, reelaboracin y cambio permanente, para evitar su desaparicin a travs del tiempo.

La Permeabilidad

La permeabilidad de un sistema mide la interaccin que este recibe del medio, se dice que a mayor o menor permeabilidad del sistema el mismo ser mas o menos abierto.

Los sistemas que tienen mucha relacin con el medio en el cul se desarrollan son sistemas altamente permeables, estos y los de permeabilidad media son los llamados sistemas abiertos.

Por el contrario los sistemas de permeabilidad casi nula o impermeables se denominan sistemas cerrados.

Sinergia: Cualidad por la cual la capacidad de actuacin del sistema es superior a las de sus componentes sumados individualmente.

Bibliografa

1. Arnold, M. "Teora de Sistemas, Nuevos Paradigmas: Enfoque de Niklas Luhmann". 1989.

2. Bertalanffy Von, L. "The Theory of Open Systems in Physics and Biology". 1959. 3. Rodrguez, D. & M. Arnold. Sociedad y Teora de Sistemas 1991.

Cuestionario

c. Mencione algunos ejemplos de relaciones simbiticas, sinrgicas y superfluas

c. Mencione algunos ejemplos de sistemas y explique por qu los considera como tal?

c. De las caractersticas de los sistemas estudiadas, cual le parece la ms importante y por qu?

WORK PAPER # 2



ELABORO: CDIGO:

TITULO WORK PAPER: Los Sistemas de Informacin

DPTO: UDABOL LA PAZ

DESTINADO A:


OBSERVACIONES:

FECHA DE DIFUSIN:

FECHA DE ENTREGA:

LA INFORMACION Y LOS SISTEMAS

La suerte de una persona

Es dividendo de su trabajo

Ray Kroc

La Informacin tiene su origen en las palabras in y formare, es decir, "instruir hacia adentro". A partir de estas dos palabras, y debido a la importancia que en pocas recientes han cobrado, se ha generado una enorme cantidad de variantes, cada una con un significado muy preciso, aplicable a ciertos tipos de situaciones.

La informacin es coleccionable, almacenable o reproducible. Se utiliza para tomar decisiones, conduce tambin a conclusiones acertadas o equivocadas, puesto que puede ser interpretada de diversas formas por distintos individuos, dependiendo de muchos factores subjetivos y del contexto en que se encuentre la persona que la recibe e interpreta, tambin tiene que ser Exacta, Estructurada y sobre todo a tiempo

Uno de los aspectos ms abstractos e importantes de la informacin es que su valor puede disminuir a lo largo del tiempo. Es decir, en un momento determinado a alguien le puede interesar contar con cierta informacin, pero ese inters puede decrecer o incluso desaparecer algn tiempo despus. Es por este motivo que el correo nocturno ya no es suficientemente rpido, de ah el motivo que el Internet haya cobrado ltimamente tanta importancia

Ahora bien si tenemos en cuenta que para manejar correctamente la informacin se requiere de sistemas de informacin, el desarrollo de sistemas de informacin viene jugando un papel muy importante en el progreso de esta nueva economa y de esta nueva era, La era de la Informacin.2.1 Qu es un Sistema de Informacin?

Habiendo estudiado la definicin de sistema en el work paper anterior, podemos decir que un Sistema de Informacin en el sentido ms amplio es un conjunto de elementos que interactan entre s para apoyar las actividades de una empresa o negocio.

Entrando a una definicin ms formal podemos decir que es un conjunto formal de procesos que, operando sobre una coleccin de datos estructurada segn las necesidades de la empresa, recopilan, elaboran y distribuyen la informacin (o parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de direccin y control correspondientes (decisiones) para desempear su actividad de acuerdo a su estrategia de negocio.

un conjunto integrado de personas y equipos que tiene por objetivo proveer a una organizacin de la informacin necesaria para apoyar las operaciones, la administracin y la toma de decisiones.

El objetivo de un Sistema de Informacin es proporcionar informacin de calidad, es decir ayudar al desempeo de las actividades en todos los niveles de la organizacin, mediante el suministro de la informacin adecuada, con la calidad suficiente, a la persona apropiada, en el momento y lugar oportunos, y con el formato ms til para el receptor.

2.2 Elementos de un Sistema de Informacin

Entre los principales componentes de un sistema de informacin podemos mencionar a las personas, la informacin como tal , el equipo de soporte para la comunicacin, el procesamiento y el almacenamiento de la informacin.2.3 Valor de un Sistema de Informacin

El valor de un Sistema de Informacin depende de su eficacia, su extensin, su aceptacin por parte de los que lo utilizan, su coste, la calidad de la informacin que trata y produce.

2.4 Clasificacin de los Sistemas de Informacin

Los sistemas de informacin no necesariamente tienen que contar con el apoyo de la computadora, en ese sentido los sistemas de informacin pueden ser inicialmente clasificados como manuales y/o automatizados. Los primeros no cuentan con el soporte informtico y los segundos si.

Otra forma de clasificar a los sistemas de informacin es a partir de las funciones a las cuales dan soporte dentro de una empresa u organizacin, ya sea en el control y gestin , la comercializacin y o la fabricacin de productos o servicios. As por ejemplo tenemos las siguientes clasificaciones:2.4.1 Sistemas para el procesamiento de transacciones (TPS)

Los sistemas de procesamiento de transacciones tienen como finalidad mejorar las actividades rutinarias de una empresa y de las que depende toda la organizacin. Una transaccin es cualquier suceso o actividad que afecta a toda la organizacin. (facturacin, pago a empleados, depsitos). Cambian de una organizacin a otra.

Los sistemas de procesamiento de transacciones brindan velocidad y exactitud; adems se pueden programar para seguir rutinas sin ninguna variacin.

2.4.2 Sistemas de Informacin Administrativa (MIS)

Ayudan a los directivos a tomar decisiones y resolver problemas, utilizan datos relacionados con las transacciones as como cualquier informacin que sea generada dentro o fuera de la compaa. Estos sistemas estn diseados para dar soporte a todos aquellos asuntos donde es necesario tomar decisiones y que se presentan con frecuencia.

2.4.3 Sistemas para el soporte de decisiones (DSS)

Ayudan a los directivos que deben tomar decisiones no muy estructuradas o semiestructuradas. (una decisin se considera no estructurada si no existen procedimientos claros para tomarla y tampoco es posible identificar con anticipacin todos los factores que deben considerarse en la decisin) de problemas nicos. Un aspecto es considerar que informacin se debe considerar por lo que no se pueden elaborar reportes de antemano. Son sistemas flexibles capaces de adecuarse a las necesidades de los directivos

2.4.4 Sistemas de Automatizacin de la Oficina (OAS)

Dan soporte a los trabajadores de datos, que generalmente no crean nuevo conocimiento sino que se usan para analizarla y transformar los datos o para manejarla en alguna forma y luego compartirla o diseminarla. (Hojas electrnicas, procesamiento de palabras, calendarizacin).

2.4.5 Otras Formas de Clasificacin

Los sistemas de informacin tambin se pueden clasificar en No integrados (que desarrollan aplicaciones que responden a necesidades especficas de un departamento sin prever sistemas existentes y mucho menos venideros, aportan beneficios a corto plazo, pero pueden generar inconsistencias o duplicidad de informacin); Integrados ( Cubren todas las actividades desarrolladas y todos los datos que se precisan); parcialmente integrados que dividen por un lado el rea de trabajo en elementos manejables y por otro, se define, planifica y controla los mismos)

2.5 Implementacin

Para la implementacin de un sistema de informacin se deben seguir una serie de etapas entre las cuales podemos citar la planificacin, Diseo, Creacin de subsistemas y Aplicacin.

2.5.1 Planificacin

Esta etapa cosiste en crear un marco que recoja los objetivos de la organizacin, establece los requisitos de informacin y de procedimientos que se necesitan para obtenerla, determina el papel de la tecnologa en el soporte de dicho Sistema de Informacin, produce polticas y planes para el desarrollo e implementacin de los mismos.

2.5.2- DiseoUna vez obtenido un marco real en donde se aplicar el sistema, se deben definir las entidades y los procesos (Quin hace qu?), las tareas asignadas se evalan en forma global, se agrupan los procesos similares, se disean las bases de datos y sus aplicaciones.

.2.5.3- Creacin de SubsistemasSe procede a la creacin de Procesos Mnimos: Tareas individuales o por equipos, definidas por los propsitos, congruentes con los objetivos planteados para el sistema en la fase de diseo. Evaluacin, agrupacin, reordenamiento de las tareas segn un orden lgico, que permita su realizacin y por ltimo, se obtiene de esta agrupacin de actividades y tareas las aplicaciones..

2.5.4 Aplicaciones

Con los procesos mnimos ordenados en tiempo, responsables, orden lgico; se realiza una prueba de campo para verificar si realmente estas actividades son eficaces. Es decir comprobar si el sistema es operativo o no y los cambios necesarios para ponerlo en marcha.

2.6 Bibliografa

1. Senn, J. "Anlisis y Diseo de Sistemas de Informacin. 1999.

2. Sommerville, I. "Ingeniera de Software ". 2002.

3. Kendall & Kendall. Anlisis y Diseo de Sistemas. 1997.

Cuestionario

1. Mencione algunos ejemplos de sistemas de informacin de acuerdo a la clasificacin brindada en lneas anteriores.

2. Cree usted que los sistemas de informacin se pueden clasificar en manuales y automatizados?. Justifique su respuesta.

WORK PAPER # 3



ELABORO: CDIGO:

TITULO WORK PAPER: Desarrollo de Sistemas de Informacin

DPTO: UDABOL LA PAZ

DESTINADO A:


OBSERVACIONES:

FECHA DE DIFUSIN:

FECHA DE ENTREGA:

DESARROLLO DE SISTEMAS DE INFORMACION

No basta saber, se debe tambin aplicar. .

No es suficiente querer, se debe tambin hacer.

Johann Wolfgang vonGoethe

3.1 Qu es el Desarrollo de Sistemas?

El desarrollo de sistemas es el conjunto de procedimientos, tcnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a producir nuevo software. Es el proceso de examinar la situacin de una empresa u organizacin con el propsito de mejorarla con mtodos y procedimientos ms adecuados, esta formado por dos grandes componentes: el anlisis y el diseo de sistemas.

El anlisis de sistemas es el proceso de clasificar e interpretar los hechos, diagnostico de problemas y el empleo de la informacin para recomendar mejoras al sistema.

El diseo de sistemas es el proceso de planificar, reemplazar o complementar un sistema organizacional existente, para lo cual se debe comprender en su totalidad el viejo sistema y determinar la mejor forma de hacer la operacin ms eficiente.

3.2 Estrategias para el Desarrollo de Sistemas.

Los sistemas de informacin basados en computadora sirven para diversas finalidades que van desde el procesamiento de las transacciones de una empresa hasta proveer de la informacin necesaria para decidir sobre asuntos que se presentan con frecuencia y asistencia a los altos funcionarios para la toma de decisiones.

Existen varios enfoques para el desarrollo de sistemas de informacin basados en computadoras, en el presente documento presentaremos tres de ellas: El mtodo del ciclo de vida para el desarrollo de sistemas, el mtodo del desarrollo del anlisis estructurado y el mtodo del prototipo de sistemas.

3.2.1 Ciclo de vida clsico del desarrollo de sistemas

Son una serie de pasos que se siguen para desarrollar software, consta de las siguientes actividades: Investigacin preliminar, Determinacin de los requerimientos del sistema, diseo del sistema, desarrollo del software, prueba de los sistemas e Implantacin y evaluacin.

Toda solicitud se inicia con la peticin, esto desencadena la primera actividad.

3.2.1.1 Investigacin Preliminar.

Tiene por finalidad la aclaracin de la solicitud y la verificacin de la factibilidad de la solicitud y posteriormente la consiguiente aprobacin de la misma

3.2.1.2 Determinacin de Requerimientos del Sistema

Se debe comprender las caractersticas de la parte de la empresa que se halla bajo estudio, estudiar los procesos y esto se logra bsicamente respondiendo algunas preguntas que nos ayuden a entender el sistema: Qu es lo que hace?, cmo se hace?, Con qu frecuencia se presenta?, Qu tan grande es el volumen de transacciones o decisiones?, Cul es el grado de eficiencia con el que se realizan las tareas?, Existe algn problema?, Cul es la causa que lo origina?.

Para contestar a esta preguntas se recurre a una serie de herramientas que me permiten interactuar con los usuarios y de esta manera obtener la informacin buscada y asi comprender como funciona el sistema, lo que finalmente derivar en la determinacin de requerimientos (es decir las caractersticas deseables a incorporar en el nuevo sistema).

3.2.1.3 Diseo del sistema

Establece como el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Se disea las salidas, entradas y procesos.

3.2.1.4 Desarrollo de software

Se escriben los programas necesarios y para ello el responsable elige el lenguaje, eleccin que depende de varios factores entre los cuales podemos citar: costo de cada alternativa, el tiempo disponible para escribir el software y la disponibilidad de los mismos. Es responsabilidad de esta etapa la documentacin de los programas.

3.2.1.5 Prueba de Sistemas

En esta fase el sistema se emplea de manera experimental para asegurarse que no tenga fallas, es decir funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimenta con datos de prueba para su procesamiento y despus se analizan los resultados

3.2.1.6 Implantacin y Evaluacin.

Es el proceso de verificar e instalar el nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla.

Dependiendo del tamao y el riesgo asociado a su uso a veces se decide implementar solo en un rea (prueba piloto), otras se deja que el viejo y el nuevo sistema trabajen juntos (paralelo) para comparar resultados o finalmente se puede decidir por una implementacin en (vivo), es decir el sistema viejo deja de funcionar determinado da y empieza a trabajar el nuevo.

3.2.2 Mtodo de desarrollo por anlisis estructurado

Muchas veces es necesario reconocer la dificultad de comprender de manera completa sistemas grandes y complejos. Este mtodo tiene como finalidad superar esta dificultad por medio de 1) la divisin del sistema en componentes y 2) la construccin de un modelo del sistema.

El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicacin, No establece como se cumplirn los requerimientos o la forma en que se implantar la aplicacin. Se representa el funcionamiento general del sistema como una nica transformacin de informacin que produce informacin de salida

3.2.2.1 Elementos del anlisis estructurado.

Los elementos bsicos del anlisis estructurado son smbolos grficos, diagramas de flujo de datos y el diccionario centralizado de datos

3.2.2.1.1 Diagrama de flujo de datos.

Son una tcnica grfica conforme la informacin se mueve por el sistema, es modificada por una serie de transformaciones. El diagrama de flujo de datos DFD es una tcnica grfica que representa el flujo de la informacin y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.

En la siguiente figura se muestran la notacin bsica para los Diagramas de flujo de datos:

Dicha notacin debe ser ampliada como sea posible con texto descriptivo.

La forma bsica de la implementacin de un DFD se muestra a continuacin:

Podemos tener tantos DFD como nivel de detalle deseemos expresar en nuestro sistema.

3.2.2.1.2 Diccionario de Datos

El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma comprensin de las entradas, de las salidas, de los componentes de los almacenes y tambin de los clculos intermedios.

3.2.3 Mtodo del Prototipo de SistemasEste mtodo hace que el usuario participe de manera ms directa en el anlisis y diseo de sistemas, pero este mtodo solo es til si se emplea en el momento adecuado y en forma adecuada.

3.2.3.1 Qu es un prototipo?

Es un sistema que funciona, no solo una idea en papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema, es en realidad un modelo piloto o de prueba, cuyo diseo evoluciona con el uso

3.2.3.2 Razones para desarrollar prototipos

Los requerimientos de informacin no siempre estn bien definidos, se requiere nueva informacin para ciertos sectores, pero no se tiene claro que informacin se requiere, se tenga un conjunto amplio de requerimientos y tal vez no se satisfaga todos ellos.

Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de disear e implementar sistemas no tienen informacin ni experiencia o existan situaciones de riesgo y costo o sea un sistema novedoso que aun no hubiese sido probado.

3.2.3.3 Pasos para el desarrollo de Prototipos

Los pasos que se siguen en el desarrollo de prototipos son los siguientes: Identificar los requerimientos de informacin que el usuario conoce junto con las caractersticas necesarias del sistema, desarrollar un prototipo que funcione, Probar el prototipo, revisando el mismo con la informacin obtenida y finalmente repetir los pasos anteriores las veces que sea necesario hasta obtener un sistema satisfactorio.

3.3 Bibliografa

1. Senn, J. "Anlisis y Diseo de Sistemas de Informacin. 1999.

2. Kendall & Kendall. Anlisis y Diseo de Sistemas. 1997.

Cuestionario

1. Elabore un ideograma de los tres mtodos clsicos del desarrollo de sistemas profundizando cada uno de ellos.

WORK PAPER # 4



ELABORO: CDIGO:

TITULO WORK PAPER: Mtrica 3

DPTO: UDABOL LA PAZ

DESTINADO A:


OBSERVACIONES:

FECHA DE DIFUSIN:

FECHA DE ENTREGA:

METRICA 3

INTRODUCCIN

La metodologa MTRICA Versin 3 ofrece a las Organizaciones un instrumento til para la sistematizacin de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos:

- Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin mediante la definicin de un marco estratgico para el desarrollo de los mismos.

- Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al anlisis de requisitos.

- Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la reutilizacin en la medida de lo posible.

- Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, as como las necesidades de todos y cada uno de ellos.

- Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.

La nueva versin de MTRICA contempla el desarrollo de Sistemas de Informacin para las distintas tecnologas que actualmente estn conviviendo y los aspectos de gestin que aseguran que un Proyecto cumple sus objetivos en trminos de calidad, coste y plazos.

Su punto de partida es la versin anterior de MTRICA de la cual se han conservado la adaptabilidad, flexibilidad y sencillez, as como la estructura de actividades y tareas, si bien las fases y mdulos de MTRICA versin 2.1 han dado paso a la divisin en Procesos, ms adecuada a la entrada-transformacin-salida que se produce en cada una de las divisiones del ciclo de vida de un proyecto. Para cada tarea se detallan los participantes que intervienen, los productos de entrada y de salida as como las tcnicas y prcticas a emplear para su obtencin.

En la elaboracin de MTRICA Versin 3 se han tenido en cuenta los mtodos de desarrollo ms extendidos, as como los ltimos estndares de ingeniera del software y calidad, adems de referencias especficas en cuanto a seguridad y gestin de proyectos. Tambin se ha tenido en cuenta la experiencia de los usuarios de las versiones anteriores para solventar los problemas o deficiencias detectados.

En una nica estructura la metodologa MTRICA Versin 3 cubre distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a travs de interfaces la realizacin de los procesos de apoyo u organizativos: Gestin de Proyectos, Gestin de Configuracin, Aseguramiento de Calidad y Seguridad.

PROCESOS PRINCIPALES DE MTRICA VERSIN 3

Los procesos de la estructura principal de MTRICA Versin 3 son los siguientes:

- planificacin de sistemas de informacin.

- desarrollo de sistemas de informacin.

- mantenimiento de sistemas de informacin.

En cuanto al Proceso de Desarrollo de Sistemas de Informacin, para facilitar la comprensin y dada su amplitud y complejidad se ha subdividido en cinco procesos:

- estudio de viabilidad del sistema (evs).

- anlisis del sistema de informacin (asi).

- diseo del sistema de informacin (dsi).

- construccin del sistema de informacin (csi).

- implantacin y aceptacin del sistema (ias).

La necesidad de acortar el ciclo de desarrollo de los sistemas de informacin ha orientado a muchas organizaciones a la eleccin de productos software del mercado cuya adaptacin a sus requerimientos supona un esfuerzo bastante inferior al de un desarrollo a medida, por no hablar de los costes de mantenimiento. Esta decisin, que es estratgica en muchas ocasiones para una organizacin, debe tomarse con las debidas precauciones, y es una realidad que est cambiando el escenario del desarrollo del software. Otra consecuencia de lo anterior es la prctica, cada vez ms habitual en las organizaciones, de la contratacin de servicios externos en relacin con los sistemas y tecnologas de la informacin y las comunicaciones, llevando a la necesidad de una buena gestin y control de dichos servicios externos y del riesgo implcito en todo ello, para que sus resultados supongan un beneficio para la organizacin. MTRICA Versin 3 facilita la toma de decisin y la realizacin de todas las tareas que comprende el desarrollo de un sistema de informacin.

Planificacin de Sistemas de Informacin (PSI)

El objetivo de un Plan de Sistemas de Informacin es proporcionar un marco estratgico de referencia para los Sistemas de Informacin de un determinado mbito de la Organizacin.

El resultado del Plan de Sistemas debe, por tanto, orientar las actuaciones en materia de desarrollo de Sistemas de Informacin con el objetivo bsico de apoyar la estrategia corporativa, elaborando una arquitectura de informacin y un plan de proyectos informticos para dar apoyo a los objetivos estratgicos.

Por este motivo es necesario un proceso como el de Planificacin de Sistemas de Informacin, en el que participen, por un lado los responsables de los procesos de la organizacin con una visin estratgica y por otro, los profesionales de SI capaces de enriquecer dicha visin con la aportacin de ventajas competitivas por medio de los sistemas y tecnologas de la informacin y comunicaciones.

Como productos finales de este proceso se obtienen los siguientes, que podrn constituir la entrada para el siguiente proceso de Estudio de Viabilidad del Sistema:

Catlogo de requisitos de PSI que surge del estudio de la situacin actual en el caso de que sea significativo dicho estudio, del diagnstico que se haya llevado a cabo y de las necesidades de informacin de los procesos de la organizacin afectados por el plan de sistemas.

Arquitectura de informacin que se compone a su vez de los siguientes productos:

o Modelo de informacin.

o Modelo de sistemas de informacin.

o Arquitectura tecnolgica.

o Plan de proyectos.

o Plan de mantenimiento del PSI.

Un Plan de Sistemas de Informacin proporcionar un marco de referencia en materia de Sistemas de Informacin. En ocasiones podr servir de palanca de cambio para los procesos de la Organizacin, pero su objetivo estar siempre diferenciado del de un anlisis de dichos procesos por s mismos. Dicho en otras palabras, no se debe confundir el resultado que se persigue con un Plan de Sistemas de Informacin, con el de una mejora o reingeniera de procesos, ya que los objetivos en ambos casos no son los mismos, aunque el medio para conseguirlos tenga puntos en comn (estudio de los procesos y alineamiento con los objetivos estratgicos).

Este nuevo enfoque de alineamiento de los sistemas de informacin con la estrategia de la organizacin, la implicacin directa de la alta direccin y la propuesta de solucin presenta como ventajas:

- La implicacin de la alta direccin facilita que se pueda desarrollar con los recursos necesarios y el calendario establecido.

- La perspectiva horizontal de los procesos dentro de la Organizacin facilita que se atienda a intereses globales y no particulares de unidades organizativas que puedan desvirtuar los objetivos del Plan. Para mantener la visin general que apoye los objetivos estratgicos, el enfoque de un Plan de Sistemas de Informacin debe orientarse al estudio por procesos.

- La prioridad del desarrollo de los sistemas de informacin de la organizacin por objetivos estratgicos.

- La propuesta de Arquitectura de Informacin que se hace en el plan es ms estratgica que tecnolgica. El modelo de sistemas de informacin de la propuesta no es terico y se

contemplan los sistemas de informacin actuales que se mantendrn.

Desarrollo de Sistemas de Informacin

El proceso de Desarrollo de MTRICA Versin 3 contiene todas las actividades y tareas que se deben llevar a cabo para desarrollar un sistema, cubriendo desde el anlisis de requisitos hasta la instalacin del software. Adems de las tareas relativas al anlisis, incluye dos partes en el diseo de sistemas: arquitectnico y detallado. Tambin cubre las pruebas unitarias y de integracin del sistema, aunque siguiendo la norma ISO 12.207 no propone ninguna tcnica especfica y destaca la importancia de la evolucin de los requisitos. Este proceso es, sin duda, el ms importante de los identificados en el ciclo de vida de un sistema y se relaciona con todos los dems.

Las actividades y tareas propuestas por la norma se encuentran ms en la lnea de un desarrollo clsico, separando datos y procesos, que en la de un enfoque orientado a objetos.

En MTRICA Versin 3 se han abordado los dos tipos de desarrollo: estructurado y orientado a objeto, por lo que ha sido necesario establecer actividades especficas a realizar en alguno de los procesos cuando se utiliza la tecnologa de orientacin a objetos. Para este ltimo caso se ha analizado alguna de las propuestas de otras metodologas orientadas a objetos y se han tenido en cuenta la mayora de las tcnicas que contempla UML 1.2 (Unified Modeling Language).

El desarrollo en MTRICA Versin 3 lo constituyen los procesos:

- ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).

- ANLISIS DEL SISTEMA DE INFORMACIN (ASI).

- DISEO DEL SISTEMA DE INFORMACIN (DSI).

- CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI).

- IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS).

Estudio de Viabilidad del Sistema (EVS)

El propsito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solucin a corto plazo. Los criterios con los que se hace esta propuesta no sern estratgicos sino tcticos y relacionados con aspectos econmicos, tcnicos, legales y operativos.

Los resultados del Estudio de Viabilidad del Sistema constituirn la base para tomar la decisin de seguir adelante o abandonar. Si se decide seguir adelante pueden surgir uno o varios proyectos que afecten a uno o varios sistemas de informacin. Dichos sistemas se desarrollarn segn el resultado obtenido en el estudio de viabilidad y teniendo en cuenta la cartera de proyectos para la estrategia de implantacin del sistema global.

Se ha considerado que este proceso es obligatorio, aunque el nivel de profundidad con el que se lleve a cabo depender de cada caso. La conveniencia de la realizacin del estudio de la situacin actual depende del valor aadido previsto para la especificacin de requisitos y para el planteamiento de alternativas de solucin. En las alternativas se considerarn soluciones "a medida", soluciones basadas en la adquisicin de productos software del mercado o soluciones mixtas.

Para valorar las alternativas planteadas y determinar una nica solucin, se estudiar el impacto en la organizacin de cada una de ellas, la inversin y los riesgos asociados.

El resultado final de este proceso son los productos relacionados con la solucin que se propone para cubrir la necesidad concreta que se plante en el proceso, y que depende de si la solucin conlleva desarrollo a medida o no:

Contexto del sistema (con la definicin de las interfaces en funcin de la solucin).

Impacto en la organizacin.

Coste/beneficio de la solucin.

Valoracin de riesgos de la solucin.

Enfoque del plan de trabajo de la solucin.

Planificacin de la solucin.

Solucin propuesta:

o Descripcin de la solucin.

o Modelo de descomposicin en subsistemas.

o Matriz de procesos/localizacin geogrfica.

o Matriz datos/localizacin geogrfica. Entorno tecnolgico y comunicaciones.

o Estrategia de implantacin global del sistema.

o Descripcin de los procesos manuales.

Si la alternativa incluye desarrollo:

o Modelo abstracto de datos/Modelo de procesos.

o Modelo de negocio/Modelo de dominio.

Si la alternativa incluye un producto software estndar de mercado:

o Descripcin del producto.

o Evolucin del producto.

o Costes ocasionados por el producto.

o Estndares del producto.

o Descripcin de adaptacin si es necesaria.

Si en la organizacin se ha realizado con anterioridad un Plan de Sistemas de Informacin que afecte al sistema objeto de este estudio, se dispondr de un conjunto de productos que proporcionarn informacin a tener en cuenta en todo el proceso.

Anlisis del Sistema de Informacin (ASI)

El propsito de este proceso es conseguir la especificacin detallada del sistema de informacin, a travs de un catlogo de requisitos y una serie de modelos que cubran las necesidades de informacin de los usuarios para los que se desarrollar el sistema de informacin y que sern la entrada para el proceso de Diseo del Sistema de Informacin.

Como ya se ha dicho MTRICA Versin 3 cubre tanto desarrollos estructurados como orientados a objetos, y las actividades de ambas aproximaciones estn integradas en una estructura comn aunque presenta alguna actividad exclusiva para cada tipo de desarrollo.

En primer lugar se describe inicialmente el sistema de informacin, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se delimita su alcance, se genera un catlogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel.

Se recogen de forma detallada los requisitos funcionales que el sistema de informacin debe cubrir, catalogndolos, lo que permite hacer la traza a lo largo de los procesos de desarrollo. Adems, se identifican los requisitos no funcionales del sistema, es decir, las facilidades que ha de proporcionar el sistema, y las restricciones a que estar sometido, en cuanto a rendimiento, frecuencia de tratamiento, seguridad, etc.

Para facilitar el anlisis del sistema se identifican los subsistemas de anlisis, y se elaboran los modelos de Casos de Uso y de Clases, en desarrollos orientados a objetos, y de Datos y Procesos en desarrollos estructurados. Se ha incorporado una actividad especfica para la definicin de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y los anteriores modelos. Se especificarn todas las interfaces entre el sistema y el usuario, como formatos de pantallas, dilogos, formatos de informes y formularios de entrada.

Finalizados los modelos, se realiza un anlisis de consistencia, mediante una verificacin y validacin, lo que puede forzar la modificacin de algunos de los modelos obtenidos.

Una vez realizado dicho anlisis de consistencia se elabora el producto Especificacin de Requisitos Software, que constituye un punto de referencia en el desarrollo del software y la lnea base de referencia para las peticiones de cambio sobre los requisitos inicialmente

especificados.

En este proceso se inicia tambin la especificacin del Plan de Pruebas, que se completar en el proceso Diseo del Sistema de Informacin (DSI).

Los productos resultantes del Anlisis del Sistema de Informacin, dependen del tipo de desarrollo de que se trate y se detallan a continuacin especificando los que son distintos, segn los dos tipos de desarrollo a los que da respuesta MTRICA Versin 3:

Descripcin general del entorno tecnolgico.

Glosario de trminos.

Catlogo de normas.

Catlogo de requisitos.

Especificacin de interfaz de usuario.

Adems, en Anlisis Estructurado:

Plan de migracin y carga inicial de datos.

Contexto del sistema.

Matriz de procesos/localizacin geogrfica.

Descripcin de interfaz con otros sistemas.

Modelo de procesos.

Modelo lgico de datos normalizado.

Adems, en Anlisis Orientado a Objetos:

Descripcin de subsistemas de anlisis.

Descripcin de interfaces entre subsistemas.

Modelo de clases de anlisis.

Comportamiento de clases de anlisis.

Anlisis de la realizacin de los casos de uso.

En este proceso es muy importante la participacin de los usuarios, a travs de tcnicas interactivas, como diseo de dilogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construccin y perfeccionamiento del mismo.

Diseo del Sistema de Informacin (DSI)

El propsito del Diseo del Sistema de Informacin (DSI) es obtener la definicin de la arquitectura del sistema y del entorno tecnolgico que le va a dar soporte, junto con la especificacin detallada de los componentes del sistema de informacin. A partir de dicha informacin, se generan todas las especificaciones de construccin relativas al propio sistema, as como la especificacin tcnica del plan de pruebas, la definicin de los requisitos de implantacin y el diseo de los procedimientos de migracin y carga inicial, stos ltimos cuando proceda.

El diseo de la arquitectura del sistema depender en gran medida de las caractersticas de la instalacin, de modo que se ha de tener en cuenta una participacin activa de los responsables de Sistemas y Explotacin de las Organizaciones para las que se desarrolla el sistema de informacin.

Este proceso consta de un primer bloque de actividades, que se realizan en paralelo, y cuyo objetivo es obtener el diseo de detalle del sistema de informacin que comprende la particin fsica del sistema de informacin, independiente de un entorno tecnolgico concreto, la organizacin en subsistemas de diseo, la especificacin del entorno tecnolgico sobre el que se despliegan dichos subsistemas y la definicin de los requisitos de operacin, administracin del sistema, seguridad y control de acceso. En el caso de diseo orientado a objetos, conviene sealar que se ha contemplado que el diseo de la persistencia se lleva a cabo sobre bases de datos relacionales.

De este primer bloque de actividades se obtienen los siguientes productos:

Catlogo de requisitos (se completa).

Catlogo de excepciones.

Catlogo de normas para el diseo y construccin.

Diseo de la arquitectura del sistema.

Entorno tecnolgico del sistema.

Procedimientos de operacin y administracin del sistema.

Procedimientos de seguridad y control de acceso.

Diseo detallado de los subsistemas de soporte.

Modelo fsico de datos optimizado.

Asignacin de esquemas fsicos de datos a nodos.

Adems, en Diseo Estructurado:

Diseo de la arquitectura modular.

Diseo de interfaz de usuario.

Adems, en Diseo Orientado a Objetos:

Diseo de la realizacin de casos de uso.

Modelo de clases de diseo.

Comportamiento de clases de diseo.

Diseo de interfaz de usuario.

Al igual que en el proceso de Anlisis del Sistema de Informacin (ASI), antes de proceder a la especificacin de los componentes, se realiza una verificacin y validacin, con objeto de analizar la consistencia entre los distintos modelos y formalizar la aceptacin del diseo de la arquitectura del sistema por parte de los usuarios de Explotacin y Sistemas.

Un segundo bloque de actividades complementa el diseo del sistema de informacin, en el que se generan todas las especificaciones necesarias para la construccin del sistema de informacin:

Las especificaciones de construccin de los componentes del sistema (mdulos o clases, segn el caso) y de las estructuras de datos.

Los procedimientos de migracin y sus componentes asociados.

La definicin y revisin del plan de pruebas, y el diseo de las verificaciones de los niveles de prueba establecidos.

El catlogo de excepciones que permite establecer un conjunto de verificaciones relacionadas con el propio diseo o con la arquitectura del sistema.

La especificacin de los requisitos de implantacin.

Construccin del Sistema de Informacin (CSI)

La construccin del Sistema de Informacin (CSI) tiene como objetivo final la construccin y prueba de los distintos componentes del sistema de informacin, a partir del conjunto de especificaciones lgicas y fsicas del mismo, obtenido en el Proceso de Diseo del Sistema de Informacin (DSI). Se desarrollan los procedimientos de operacin y seguridad y se elaboran los manuales de usuario final y de explotacin, estos ltimos cuando proceda.

Para conseguir dicho objetivo, se recoge la informacin relativa al producto del diseo

Especificaciones de construccin del sistema de informacin, se prepara el entorno de construccin, se genera el cdigo de cada uno de los componentes del sistema de informacin y se van realizando, a medida que se vaya finalizando la construccin, las pruebas unitarias de cada uno de ellos y las de integracin entre subsistemas.

Si fuera necesario realizar una migracin de datos, es en este proceso donde se lleva a cabo la construccin de los componentes de migracin y procedimientos de migracin y carga inicial de datos.

Como resultado de dicho proceso se obtiene:

Resultado de las pruebas unitarias.

Evaluacin del resultado de las pruebas de integracin.

Evaluacin del resultado de las pruebas del sistema.

Producto software:

Cdigo fuente de los componentes.

Procedimientos de operacin y administracin del sistema.

Procedimientos de seguridad y control de acceso.

Manuales de usuario.

Especificacin de la formacin a usuarios finales.

Cdigo fuente de los componentes de migracin y carga inicial de datos.

Procedimientos de migracin y carga inicial de datos.

Evaluacin del resultado de las pruebas de migracin y carga inicial de datos.

Implantacin y Aceptacin del Sistema (IAS)

Este proceso tiene como objetivo principal, la entrega y aceptacin del sistema en su totalidad, que puede comprender varios sistemas de informacin desarrollados de manera independiente, segn se haya establecido en el proceso de Estudio de Viabilidad del Sistema (EVS), y un segundo objetivo que es llevar a cabo las actividades oportunas para el paso a produccin del sistema.

Se establece el plan de implantacin, una vez revisada la estrategia de implantacin y se detalla el equipo que lo realizar.

Para el inicio de este proceso se toman como punto de partida los componentes del sistema probados de forma unitaria e integrados en el proceso Construccin del Sistema de Informacin (CSI), as como la documentacin asociada. El Sistema se someter a las Pruebas de Implantacin con la participacin del usuario de operacin cuya responsabilidad, entre otros aspectos, es comprobar el comportamiento del sistema bajo las condiciones ms extremas.

Tambin se someter a las Pruebas de Aceptacin cuya ejecucin es responsabilidad del usuario final. En este proceso se elabora el plan de mantenimiento del sistema de forma que el responsable del mantenimiento conozca el sistema antes de que ste pase a produccin.

Tambin se establece el acuerdo de nivel de servicio requerido una vez que se inicie la produccin. El acuerdo de nivel de servicio hace referencia a servicios de gestin de operaciones, de soporte a usuarios y al nivel con el que se prestarn dichos servicios.

Como resultado de este proceso se obtienen los siguientes productos:

Plan de implantacin del sistema en su totalidad.

Equipo de implantacin que realizar la implantacin.

Plan de formacin del equipo de implantacin (esquema, materiales, recursos

necesarios, planificacin y especificacin de la formacin de usuarios finales).

Evaluacin de las pruebas de implantacin del sistema por parte del usuario de

operacin.

Evaluacin de las pruebas de aceptacin del sistema por parte del usuario final.

Plan de mantenimiento previo al paso a produccin.

Acuerdo de nivel de servicio del sistema.

Sistema en produccin.

Mantenimiento de Sistemas de Informacin (MSI)

El objetivo de este proceso es la obtencin de una nueva versin de un sistema de informacin desarrollado con MTRICA, a partir de las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado en el sistema o por la necesidad de una mejora del mismo.

Como consecuencia de esto, slo se considerarn en MTRICA Versin 3 los tipos de Mantenimiento Correctivo y Evolutivo. Se excluyen los tipos de Mantenimiento Adaptativo y Perfectivo, que abarcan actividades tales como la migracin y la retirada de software que precisaran el desarrollo de un tipo de metodologa especfica para resolver su cometido.

Ante una peticin de cambio de un sistema de informacin ya en produccin, se realiza un registro de las peticiones, se diagnostica el tipo de mantenimiento y se decide si se le da respuesta o no, en funcin del plan de mantenimiento asociado al sistema afectado por la peticin, y se establece con qu prioridad

La definicin de la solucin al problema o necesidad planteada por el usuario que realiza el responsable de mantenimiento, incluye un estudio del impacto, la valoracin del esfuerzo y coste, las actividades y tareas del proceso de desarrollo a realizar y el plan de pruebas de regresin.

Los productos que se obtienen en este proceso son los siguientes:

Catlogo de peticiones de cambio.

Resultado del estudio de la peticin.

Propuesta de solucin.

Anlisis de impacto de los cambios.

Plan de accin para la modificacin.

Plan de pruebas de regresin.

Evaluacin del cambio.

Evaluacin del resultado de las pruebas de regresin.

INTERFACES DE MTRICA VERSIN 3

La estructura de MTRICA Versin 3 incluye tambin un conjunto de interfaces que definen una serie de actividades de tipo organizativo o de soporte al proceso de desarrollo y a los productos, que en el caso de existir en la organizacin se debern aplicar para enriquecer o influir en la ejecucin de las actividades de los procesos principales de la metodologa y que si no existen habr que realizar para complementar y garantizar el xito del proyecto desarrollado con MTRICA Versin 3.

La aplicacin de MTRICA Versin 3 proporciona sistemas con calidad y seguridad, no obstante puede ser necesario en funcin de las caractersticas del sistema un refuerzo especial en estos aspectos, refuerzo que se obtendra aplicando la interfaz.

Las interfaces descritas en la metodologa son:

- Gestin de Proyectos (GP)

- Seguridad (SEG)

- Aseguramiento de la Calidad (CAL)

- Gestin de la Configuracin (GC)

Gestin de Proyectos

La Gestin de Proyectos tiene como finalidad principal la planificacin, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Informacin. Como consecuencia de este control es posible conocer en todo momento qu problemas se producen y resolverlos o paliarlos lo ms pronto posible, lo cual evitar desviaciones temporales y econmicas. La Interfaz de Gestin de Proyectos de MTRICA Versin 3 contempla proyectos de desarrollo de Sistemas de Informacin en sentido amplio, acorde con EUROMTODO se consideran proyectos de desarrollo de nuevos Sistemas de Informacin y tambin los proyectos de ampliacin y mejora de los ya existentes.

Las actividades de la Interfaz de Gestin de Proyectos son de tres tipos:

- Actividades de Inicio del Proyecto (GPI), que permiten estimar el esfuerzo y establecer la planificacin del proyecto.

- Actividades de Seguimiento y Control (GPS), supervisando la realizacin de las tareas por parte del equipo de proyecto y gestionando las incidencias y cambios en los requisitos que puedan presentarse y afectar a la planificacin del proyecto.

- Actividades de Finalizacin del Proyecto, cierre y registro de la documentacin de gestin.

Estas actividades pueden requerir, en funcin de la complejidad del proyecto, el soporte de herramientas comerciales de gestin de proyectos.

Seguridad

El anlisis de los riesgos constituye una pieza fundamental en el diseo y desarrollo de sistemas de informacin seguros. Si bien los riesgos que afectan a un sistema de informacin son de distinta ndole: naturales (inundaciones, incendios, etc.) o lgicos (fallos propios, ataques externos, virus, etc.) son estos ltimos los contemplados en la interfaz de Seguridad de MTRICA Versin 3.

El objetivo de la interfaz de seguridad de MTRICA Versin 3 es incorporar en los sistemas de informacin mecanismos de seguridad adicionales a los que se proponen en la propia metodologa, asegurando el desarrollo de cualquier tipo de sistema a lo largo de los procesos que se realicen para su obtencin.

La interfaz de Seguridad hace posible incorporar durante la fase de desarrollo las funciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio proceso de desarrollo, asegurando su consistencia y seguridad, completando el plan de seguridad vigente en la organizacin o desarrollndolo desde el principio, utilizando MAGERIT como metodologa de anlisis y gestin de riesgos en el caso de que la organizacin no disponga de su propia metodologa.

En consecuencia, la interfaz contempla dos tipos de actividades diferenciadas:

- Actividades relacionadas con la seguridad intrnseca del sistema de informacin.

- Actividades que velan por la seguridad del propio proceso de desarrollo del sistema de informacin.

As mismo se hace especial hincapi en la formacin en materia de seguridad.

Las valoraciones sobre la seguridad deben realizarse en funcin de las caractersticas del sistema sin perder de vista adems que, al ser finitos los recursos, no pueden asegurarse todos los aspectos del desarrollo de los sistemas de informacin, por lo que habr que aceptar un determinado nivel de riesgo concentrndose en los aspectos ms comprometidos o amenazados, que sern diferentes segn las circunstancias.

Gestin de la Configuracin

La interfaz de gestin de la configuracin consiste en la aplicacin de procedimientos administrativos y tcnicos durante el desarrollo del sistema de informacin y su posterior mantenimiento. Su finalidad es identificar, definir, proporcionar informacin y controlar los cambios en la configuracin del sistema, as como las modificaciones y versiones de los mismos. Este proceso permitir conocer el estado de cada uno de los productos que se hayan definido como elementos de configuracin, garantizando que no se realizan cambios incontrolados y que todos los participantes en el desarrollo del sistema disponen de la versin adecuada de los productos que manejan.

La interfaz de gestin de configuracin de MTRICA Versin 3 permite definir las necesidades de gestin de configuracin para cada sistema de informacin, recogindolas en un plan de gestin de configuracin, en el que se especifican actividades de identificacin y registro de productos, que se realizan durante todas las actividades de MTRICA Versin 3 asociadas al desarrollo y mantenimiento del sistema de informacin. Asimismo, permite controlar el sistema como producto global a lo largo de su creacin, obtener informes sobre el estado de desarrollo en que se encuentra y reducir el nmero de errores durante el mismo, lo que se traduce en un aumento de calidad del proceso de desarrollo y de mejora de la productividad en la organizacin. La gestin de configuracin facilita adems el mantenimiento del sistema, aportando informacin precisa para valorar el impacto de los cambios solicitados y reduciendo el tiempo de implementacin de un cambio, tanto evolutivo como correctivo.

Aseguramiento de la Calidad

El objetivo de la interfaz de Aseguramiento de la Calidad de MTRICA Versin 3 es proporcionar un marco comn de referencia para la definicin y puesta en marcha de planes especficos de aseguramiento de calidad aplicables a proyectos concretos.

Las actividades propias de la interfaz de Calidad en MTRICA Versin 3 estn orientadas a verificar la calidad de los productos. Son actividades que evalan la calidad y que son realizadas por un grupo de Asesoramiento de la Calidad independiente de los responsables de la obtencin de los productos. Estas actividades de interfaz de MTRICA Versin 3 no entran en contradiccin con el Plan General de Garanta de Calidad (PGGC), siendo lo suficientemente abiertas como para soportar una nueva versin del PGGC en el futuro.

Las actividades contempladas en la interfaz de Aseguramiento de la Calidad permitirn:

- Reducir, eliminar y prevenir las deficiencias de calidad de los productos a obtener.

- Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario queden satisfechas.

Preguntas

1. Qu es metrica3?

2. Cul su opinin en lo que a contratacin de servicios externos para sistemas se refiere?

3. Qu procesos constituyen lo que es mtrica3?

WORK PAPER # 5



ELABORO: CDIGO:

TITULO WORK PAPER: Estudio de Factibilidad

DPTO: UDABOL LA PAZ

DESTINADO A:


OBSERVACIONES:

FECHA DE DIFUSIN:

FECHA DE ENTREGA:

ESTUDIO DE FACTIBILIDAD

INTRODUCCIN

Al hablar de estudio de factibilidad entran en juego una serie de requisitos que se deben estudiar cuidadosamente para lograr el objetivo de este proceso dentro de una organizacin. Con el estudio de factibilidad se busca tratar de resolver los problemas de la organizacin a travs de un sistema de informacin. Este proceso se apoya en tres aspectos bsicos como lo son la factibilidad operativa, tcnico y econmica. Con este estudio se puede determinar si la solucin del problema a estudiar es alcanzable dado los recursos y las limitaciones que presenta la empresa, tambin nos permite estudiar todas las posibles ventajas que este representara si se llegara a implementar en la empresa u organizacin.

ANALISIS DE SISTEMAS

Es el anlisis de un problema de la organizacin que tratar de resolverse a travs de un sistema de informacin. Consiste en definir el problema, identificar las causas, especificar la solucin e identificar los requerimientos de informacin que deben ser cubiertos.

El secreto para la realizacin de un buen sistema de informacin es comprender a fondo la organizacin y el sistema existente. Para lograr esto el analista de sistemas crea un mapa de la institucin y sus sistemas, identificando a los propietarios y usuarios de los datos, ya que estos tienen un inters directo sobre la informacin afectada por el nuevo sistema , tambin describe de manera breve el hardware y software existentes.

Una vez realizado el anlisis organizacional, el analista de sistemas identifica los problemas de los sistemas actuales. Examinado documentos, observando las operaciones de los sistemas y entrevistando a los usuarios, se puede identificar las reas con problemas y los objetivos a ser cubiertos por la nueva solucin. Frecuentemente la solucin implica o el desarrollo de una nueva solucin o el mejoramiento de la ya existente.

Adems de las recomendaciones para la solucin, el anlisis de sistemas implica un estudio de factibilidad.

Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas sealados, la factibilidad se apoya en 3 aspectos bsicos:Operativo, Tcnico,Econmico.

El xito de un proyecto esta determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores.

ESTUDIO DE FACTIBILIDAD.

Un estudio de factibilidad es una manera de determinar si una solucin es alcanzable, dados los recursos y limitaciones de la organizacin.

Sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisin, si procede su estudio, desarrollo o implementacin.

OBJETIVO DE UN ESTUDIO DE FACTIBILIDAD.

1. Auxiliar a una organizacin a lograr sus objetivos.

2. Cubrir la metas con los recursos actuales en las siguientes reas.

Factibilidad Tcnica.

Se refiere a los recursos necesarios como herramientas, conocimientos, habilidades, experiencia, etc., que son necesarios para efectuar las actividades o procesos que requiere el proyecto. Generalmente nos referimos a elementos tangibles (medibles). El proyecto debe considerar si los recursos tcnicos actuales son suficientes, si la solucin propuesta puede ser implantada con el software, el hardware y los recursos tcnicos disponibles o deben complementarse.

En otras palabras, revisa aspectos como:

a. Mejora del sistema actual.

b. Disponibilidad de tecnologa que satisfaga las necesidades.

Factibilidad Econmica.

Se refiere a los recursos econmicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos, adems debe considerarse el costo del tiempo, el costo de la realizacin y el costo de adquirir nuevos recursos.

Generalmente la factibilidad econmica es el elemento mas importante ya que a travs de el se solventan las dems carencias de otros recursos, es lo mas difcil de conseguir y requiere de actividades adicionales cuando no se posee.

Permite ver si los beneficios de una solucin propuesta son mayores que los costos, entre las variables que revisa encontramos:

c. Tiempo del analista.

d. Costo de estudio.

e. Costo del tiempo del personal.

f. Costo del tiempo.

g. Costo del desarrollo / adquisicin.

Factibilidad Operativa.

Se refiere a todos aquellos recursos donde interviene algn tipo de actividad (Procesos), depende de los recursos humanos que participen durante la operacin del proyecto. Durante esta etapa se identifican todas aquellas actividades que son necesarias para lograr el objetivo y se evala y determina todo lo necesario para llevarla a cabo.

Determina si una solucin propuesta es deseable dentro del marco administrativo y organizacional existente, y busca:

h. Operacin garantizada.

i. Uso garantizado.

Por lo general, el proceso de anlisis de sistemas identificar ciertas soluciones distintas que pueden ser adoptadas por la institucin. En este caso se debe evaluar la factibilidad de cada una de ellas.

DEFINICIN DE OBJETIVOSLa investigacin de factibilidad en un proyecto que consiste en descubrir cuales son los objetivos de la organizacin, luego determinar si el proyecto es til para que la empresa logre sus objetivos. La bsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar.

En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos. Estos objetivos son los siguientes:

Reduccin de costos mediante la optimizacin o eliminacin de recursos no necesarios.

Reduccin de errores y mayor precisin en los procesos.

Integracin de todas la reas y subsistemas de la empresa.

Actualizacin y mejoramiento de los servicios a clientes o usuarios.

Aceleracin en la recopilacin de datos.

Reduccin en el tiempo de procesamiento y ejecucin de tareas.

Automatizacin optima de procedimientos manuales.

OBJETIVOS DEL ANLISIS DE FACTIBILIDAD

La investigacin de factibilidad en un proyecto, consiste en descubrir cuales son los objetivos de la organizacin, luego determinar si el proyecto es til para que la empresa logre sus objetivos. La bsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar.

En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos. Estos objetivos son los siguientes:

j. Reduccin de errores y mayor precisin en los procesos.

k. Reduccin de costos mediante la optimizacin o eliminacin de recursos no necesarios.

l. Integracin de todas la reas y subsistemas de la empresa.

m. Actualizacin y mejoramiento de los servicios a clientes o usuarios.

n. Aceleracin en la recopilacin de datos.

o. Reduccin en el tiempo de procesamiento y ejecucin de tareas.

p. Automatizacin optima de procedimientos manuales. PRESENTACIN DE UN ESTUDIO DE FACTIBILIDAD

Un estudio de factibilidad requiere ser presentado con todas la posibles ventajas para la empresa u organizacin, pero sin descuidar ninguno de los elementos necesarios para que el proyecto funcione. Para esto dentro de los estudios de factibilidad se complementan dos pasos en la presentacin del estudio:

q. Requisitos ptimos.

r. Requisitos Mnimos.

El primer paso se refiere a presentar un estudio con los requisitos ptimos que el proyecto requiera, estos elementos debern ser los necesarios para que las actividades y resultados del proyecto sean obtenidos con la mxima eficacia.

El segundo paso consiste en un estudio de requisitos mnimos, el cual cubre los requisitos mnimos necesarios que el proyecto debe ocupar para obtener las metas y objetivos, este paso trata de hacer uso de los recursos disponibles de la empresa para minimizar cualquier gasto o adquisicin adicional.

Un estudio de factibilidad debe representar grficamente los gastos y los beneficios que acarrear la puesta en marcha del sistema, para tal efecto se hace uso de la curva costo-beneficio.

WORK PAPER # 6



ELABORO: CDIGO:

TITULO WORK PAPER: Especificacin y manejo de los requerimientos del Software

DPTO: UDABOL LA PAZ

DESTINADO A:


OBSERVACIONES:

FECHA DE DIFUSIN:

FECHA DE ENTREGA:

Especificacin y manejo de los requerimientos del Software

Introduccin

Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de software, ellos se basan muchos participantes del proyecto para:

Planear el proyecto y los recursos que se usarn en l. Los lideres de proyecto usan los requerimientos como una base para la estimacin del esfuerzo necesario en un proyecto.

Especificar el tipo de verificaciones que se habrn de realizar al sistema. Por ejemplo: cuando se esta tratando de alinearse a cierta norma oficial o estndar.

Planear la estrategia de prueba a la que habr de ser sometido el sistema. Los requerimientos son la base sobre la cual se decide si un caso de prueba fue ejecutado exitosamente por el sistema o no.

Son el fundamento del ciclo de vida del proyecto. Los requerimientos documentados son la base para crear la documentacin del sistema

De ah su importancia y la importancia de que deban de ser definidos y manejados de la forma mas adecuada posible.

Qu son Requerimientos?

Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE .

(1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) 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. (3) Una representacin documentada de una condicin o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.

Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.

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

Los requerimientos deben ser:

Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.

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.

Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Si un requerimiento no se puede comprobar, entonces cmo sabemos si cumplimos con l o no?

Especificados por escrito. Como todo contrato o acuerdo entre dos partes

Lo ms abstracto y conciso posible. Para evitar malas interpretaciones.

Clasificacin de los requerimientosEl clasificar requerimientos es una forma de organizarlos, hay requerimientos que por sus caractersticas no pueden ser tratados iguales. Por ejemplo, los requerimientos de entrenamiento de personal no son tratados de la misma manera que los requerimientos de una conexin a Internet.

La siguiente es una recomendacin de como pueden ser clasificados los requerimientos aunque cada proyecto de software pueda usar sus propias clasificaciones.

Requerimientos del "entorno"

El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el entorno, existen cierto tipo de requerimientos que se clasifican en esta categora por que:

El sistema usa el entorno y lo necesita como una fuente de los servicios necesarios para que funcione. Ejemplos del entorno podemos mencionar: sistemas operativos, sistema de archivos, bases de datos.

El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en el entorno, tales como congestin en los dispositivos y errores de entrada de datos, por lo tanto el entorno se debe de considerar dentro de los requerimientos.

Requerimientos "ergonmicos"

El mas conocido de los requerimientos ergonmicos es la interface con el usuario o GUI (Graphic User Interface). En otras palabras, los requerimientos ergonmicos son la forma en que el ser humano interactua con el ser sistema.

Requerimientos de Interface

La interface es como interactua el sistema con el ser humano o con otros sistemas (el enfoque es prcticamente el opuesto a los requerimientos ergonmicos), La interface es la especificacin formal de los datos que el sistema recibe o manda al exterior. Usualmente se especifica el protocolo, el tipo de informacin, el medio para comunicarse y el formato de los datos que se van a comunicar.

Requerimientos funcionales

Estos son los que describen lo que el sistema debe de hacer. Es importante que se describa el Que? Y no el Como?. Estos requerimientos al tiempo que avanza el proyecto de software se convierten en los algoritmos, la lgica y gran parte del cdigo del sistema.

Requerimientos de desempeo

Estos requerimientos nos informan las caractersticas de desempeo que deben de tener el sistema. Que tan rpido?, Que tan seguido?, Cuantos recursos?, Cuantas transacciones? .

Este tipo de requerimientos es de especial importancia en los sistemas de tiempo real en donde el desempeo de un sistema es tan crtico como su funcionamiento.

Disponibilidad (en un determinado periodo de tiempo)

Este tipo de requerimientos se refiere a la durabilidad, degradacin, potabilidad, flexibilidad, contabilidad y capacidad de actualizacin. Este tipo de requerimientos es tambin muy importante en sistemas de tiempo real puesto que estos sistemas manejan aplicaciones crticas que no deben de estar fuera de servicio por periodos prolongados de tiempo.

Entrenamiento

Este tipo de requerimientos se enfoca a las personas que van usar el sistema. Que tipo de usuarios son?, Que tipo de operadores?, Que manuales se entregarn y en que idioma?

Este tipo de requerimientos, aunque muchas veces no termina en un pedazo de cdigo dentro de el sistema, son muy importantes en el proceso de diseo ya que facilitan la introduccin y aceptacin de el sistema en donde ser implementado.

Restricciones de diseo

Muchas veces las soluciones de un sistema de software son normadas por leyes o estndares, este tipo de normas caen como "restricciones de diseo".

Materiales

Aqu se especifica en que medio se entregara el sistema y como esta empaquetado. Es importante para definir los costos de industrializacin del sistema.

Dificultades para definir los requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes.

Son difciles de expresar en palabras (el lenguaje es ambiguo).

Existen muchos tipos de requerimientos y diferentes niveles de detalle.

La cantidad de requerimientos en un proyecto puede ser difcil de manejar.

Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros.

Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.

Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas.

Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Ingeniera de Requerimientos vs. Administracin de Requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente 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.

WORK PAPER # 7



ELABORO: CDIGO:

TITULO WORK PAPER: Planificacin de un Proyecto de Sistemas

DPTO: UDABOL LA PAZ

DESTINADO A:


OBSERVACIONES:

FECHA DE DIFUSIN:

FECHA DE ENTREGA:

PLANIFICACION DE UN PROYECTO DE SISTEMAS.

Que es un proyecto de Sistema o Software. ?

Es el Proceso de gestin para la creacin de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimacin, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimacin, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costes de tiempo. Y dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificacin. El Tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software.

La disponibilidad de informacin Histrica es otro elemento que determina el riesgo de la estimacin.

Objetivos de la Planificacin del Proyecto.

El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.

El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables.

Actividades asociadas al proyecto de software.

mbito del Software.

Es la primera actividad de llevada a cabo durante la planificacin del proyecto de Software.

En esta etapa se deben evaluar la funcin y el rendimiento que se asignaron al Software durante la Ingeniera del Sistema de Computadora para establecer un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos

Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

El mbito se define como un pre-requisito para la estimacin y existen algunos elementos que se debe tomar en cuenta como es:

La Obtencin de la Informacin necesaria para el software. Para esto el analista y el cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo.

RECURSOS:

La Segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se encuentran los Componentes reutilizables.

Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano).

Cada recurso queda especificado mediante cuatro caractersticas:

Descripcin del Recurso.

Informes de disponibilidad.

Fecha cronolgica en la que se requiere el recurso.

Tiempo durante el que ser aplicado el recurso.

Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar la posicin dentro de la organizacin y la especialidad que desempeara cada profesional.

Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin y la reutilizacin de bloques de construccin de Software.

Tales bloques se deben establecer en catlogos para una consulta ms fcil, estand

Analisis de Sistemas i

Documents

Transcript of Analisis de Sistemas i