TEXTO GUIA DE ANALISIS DE SISTEMAS I

Unidad1
Tópicos Conceptuales sobre análisis y diseño de
sistemas
1.1. Teoría General de sistemas
“En sentido amplio, un sistema es un conjunto de componentes que
interaccionan entre sí para lograr un objetivo común”.

Con esto nos referimos a un grupo de elementos que realizan actividades para
alcanzar un objetivo común, ya sea operando sobre los datos, la energía o la
materia para suministrar información. “Los sistemas proporcionan información
tanto de problemas como de oportunidades”.

La clasificación y el análisis de las características de un sistema es un proceso

que requiere conocer quién lo realiza, el objetivo que se pretende alcanzar y las
condiciones particulares en las que se desarrolla. Sin embargo, antes de
emprender el análisis de un sistema, conviene estar al tanto de la clasificación
general de los sistemas.

Respecto a su relación con el medio ambiente los clasificamos como abiertos o

cerrados:
Sistemas abiertos: este tipo de sistemas se intercambia materia, energía o
información con el ambiente.
Sistemas cerrados: son aquellos sistemas en los cuales el intercambio de
materia, energía o información con ambiente es considerado como nulo.

Ahora definiremos que es un sistema de Información: Un sistema de información

es un conjunto organizado de los elementos necesarios para establecer la
comunicación en una organización. Como vemos en la figura1.

Figura1.
Ejemplos: Sistemas de facturación, planillas de sueldos, cuentas por cobrar,
cuentas por pagar, contabilidad general, etc.

1.2. Que es el análisis de sistemas?

Es la descomposición del sistema en componentes para estudiarlos:
Aisladamente e interactuando con el resto.
Es un proceso cuya:
Entrada: requisitos
Salida: modelo de análisis
Actor: Analista

Los requisitos necesitan una representación más técnica los modelos

Los modelos son representaciones graficas que describen los procesos del
negocio, el problema a resolver y el sistema que ha de ser desarrollado. También
se puede decir que un modelo es una simplificación de la realidad.
Un modelo de software es una descripción de un aspecto del sistema expresado
en un lenguaje bien definido.
Ejemplo de un modelo de software
1.3. Que es el diseño de sistemas?
Esta fase contesta a la pregunta ¿cómo?, no hay que confundir el cómo de la
fase de análisis, donde se investiga cómo se hacen las cosas; éste se refiere a
cómo voy a dar solución a las necesidades y/o problemas. Sus actividades
principales son:
 Diseñar procesos y procedimientos.
 Diseñar algoritmos.
 Diseñar la base de datos.
 Diseñar la distribución de los componentes.
Regularmente los puntos anteriores reciben el nombre de arquitectura de
software o simplemente arquitectura. La arquitectura describe con diferentes
modelos cómo se va a construir la solución. “Una arquitectura de software define
la estructura general de un sistema y varía de acuerdo con el tipo de sistema a
desarrollar.

1.4. Que es la implementación?

1.5. Metodología, Modelo, método, técnica y herramienta

1.6. Método Top Down y Bottom Up

1.7. Roles del analista de sistemas

Los tres roles importantes que el analista debe cubrir son: el de consultor; el de
especialista de apoyo o soporte y el de agente de cambio.

- El analista de sistemas como consultor.-

Un analista puede contratarse solo para canalizar a la empresa ciertos tópicos
de la informática. Esto ofrece una ventaja, en el sentido de que el consultor
externo trae consigo perspectivas frescas, que no poseen otros miembros de la
empresa. Por otra parte para el analista externo implica una desventaja, pues no
tiene fácil acceso a la cultura organizacional auténtica.
Como consultor externo deberá conocer e implementar metodología para el
modelo de sistema y contara con la ayuda de los usuarios para entender la
cultura de la organización desde sus propios puntos de vistas.

- El analista de sistema como especialista de apoyo.-

Otro papel es como especialista de apoyo o de staff. En esta posición, el analista
dispone de una experiencia profesional respecto al hardware y al software y a
sus aplicaciones en la organización. Con frecuencia estas tareas no se asocian
a un proyecto ambicioso de sistemas, sino más bien implican decisiones o
modificaciones menores que se dan en un área individual. Solo será un recurso
humano de apoyo para quienes lo dirigen.

- El analista de sistema como agente de cambio.-

El papel que le confiere un alto grado de responsabilidad, es el de agente de
cambio; sin importar si es o no de la organización. Como analista, será un agente
de cambio cada vez que realice alguna de las actividades del ciclo de desarrollo
del sistema. Un agente de cambio es una persona que sirve de catalizador para
el cambio, que desarrolla un plan para el mismo y que colabora con otros para
llevarlo a cabo y agilizarlo. Debe aceptar el desafío del cambio y tomarlo como
punto de partida de su análisis.
Como analista de sistema, al actuar como agente de cambio, apoya una
corriente particular de cambio, que involucra el uso de los sistemas de
información. Además, transmite a los usuarios el proceso de cambio, ya que esta
convencido de que tales cambios no ocurren de manera independiente en los
sistemas de información, sino más bien, éstos ocasionan cambios a lo largo de
las organizaciones.
Unidad 2
Modelos de ciclo de vida de un sistema
La abstracción es una actividad mental que consiste en resaltar, disminuir y/o
ignorar la importancia de los hechos y/o objetos de la realidad para analizar una
situación dada. Cuando construimos un modelo resalta el concepto de
abstracción, dado que los modelos están orientados a representar la realidad
bajo determinada perspectiva.

Ejemplos:

Modelo1 del ciclo de vida de un sistema

Modelo2 del ciclo de vida de un sistema.

Determinación
Investigación Análisis
de
Preliminar Estructurado
Requerimientos

Pruebas y Diseño
Implemetación
Mantenimiento Estructurado

Los modelos, como resultado de un proceso mental, buscan comunicar una idea-
concepto a otra persona. Esto se presenta porque cada persona cuenta con un
marco referencial (ideas, estudios, experiencias, creencias) distinto respecto a
las otras personas. Eso hace necesario tener una herramienta, en este caso los
modelos, para poder comunicar nuestras ideas.

Dentro del análisis y diseño de sistemas se construyen una diversidad de

modelos, principalmente bajo dos perspectivas: estática y dinámica. La
perspectiva estática se enfoca principalmente en los datos información. Y la
perspectiva dinámica se enfoca principalmente en las funciones procesos.

2.1 Modelo Cascada.-

2.2 Modelo Prototipo.-
2.3 Modelo Espiral.-
2.4 Modelo Caso de estudio.-
UNIDAD 3
ANALISIS DE REQUISITOS y ESTUDIO DE FACTIBILIDAD
Un requerimiento es una capacidad del sistema que solicita de manera implícita o
explícita el usuario, esta capacidad busca solucionar un problema o conseguir un
objetivo.

Estas capacidades del software o sistema, también conocidas como características,

son solicitadas por los usuarios o son detectadas por los analistas para satisfacer
un contrato, una especificación, un estándar u otra documentación impuesta.

La especificación de requerimientos debe ser:

Precisa, concisa, grafica, mantenible.
Se debe Especificar: requisitos, estructura y funcionalidad.

3.1 Identificación de requisitos.-

La identificación de los requerimientos no es una tarea fácil, de hecho es una de
las actividades más complejas de la fase de análisis. En esta actividad interviene
mucho la percepción del analista así como de su conocimiento sobre el negocio
donde se quiere implantar el sistema. También, intervienen los intereses
organizacionales y particulares que tienen el cliente y/o los usuarios.

Además, el entorno es otro factor que aumenta la complejidad debido a que si

no se toma en cuenta el contexto, se podrían estar mal interpretando las ideas
de los participantes.

Los requerimientos no solamente son proporcionados por los usuarios también

tienen otras fuentes como lo son los reglamentos, los manuales, la competencia,
el gobierno, los proveedores, los clientes o cualquier otra fuente que delimite el
comportamiento que debe tener el sistema.

Los analistas estructuran sus investigaciones al buscar respuestas a las

siguientes cuatro importantes preguntas:

 ¿Cuál es el proceso básico de la empresa?

 ¿Qué datos utiliza y produce este proceso?
 ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?
 ¿Qué controles de desempeño utiliza?

Técnicas de recopilación de Información.-

 Entrevistas.- La entrevista es un conjunto de preguntas que están dirigidas
a una persona o un grupo muy pequeño de personas. Las preguntas son
generalmente abiertas, es decir, no hay una respuesta exacta. El objetivo de
la entrevista es obtener datos de carácter cualitativo porque busca conocer
el punto de vista de las personas de acuerdo con la realidad que viven, por
lo que estos datos no se podrán tabular o manipular estadísticamente.
Su uso en la recopilación de requerimientos se enfoca en buscar los motivos
que originan la creación del sistema, las causas que origina el problema, y
especificar los procesos.

Entrevista estructurada contra no estructurada:

 Cuestionarios.-
Al igual que la entrevista, es un conjunto de preguntas pero que están
dirigidas a una cantidad considerable de personas. Las preguntas son
generalmente cerradas: verdadero o falso, opción múltiples, etc.

 Observación.-
Esta es una técnica que siempre se utiliza por los analistas de sistemas. Se
debe prestar atención en las relaciones interpersonales porque nos ayudan
a identificar la forma en que trabajan así como para identificar la organización
informal existente.
Está técnica puede ser un tanto incómoda para las personas que están
siendo observadas, por lo que el analista debe tener tacto en la forma en que
se presenta en el lugar de trabajo de las personas.
3.2 Estudio de factibilidad: Técnica, Operativa , Social, económica –
Financiera.-

Para el análisis de sistemas, el estudio factibilidad consiste en evaluar técnicamente

la posibilidad de llevar a cabo el proyecto de software con los recursos disponibles
y las restricciones. Este estudio, no es un estudio para el analista de sistemas, más
bien es una recopilación de datos relevantes para la alta dirección, quien deberá
tomar la decisión si procede al estudio de sistemas.
Los aspectos que se debe tomar para realizar este estudio son:

Recursos de
Hardware y
Software

Disponibilidad Restricciones
de Personal Técnicas
Factibilidad
del
Sistema?

Impacto en la Alternativas
Organización de Desarrollo

.-

 Factibilidad técnica.-
El analista debe indagar si los recursos técnicos usuales pueden actualizarse
o complementarse, de tal manera que satisfagan la necesidad considerada.
Si no puede ser actualizada, tenemos que considerar la existencia de algún
tipo de tecnología que pueda satisfacer el requisito, se debe verificar si existe
el equipamiento, personal, software para el desarrollo del sistema.

 Factibilidad Económica.-
En este estudio deben considerarse los siguientes recursos básicos: el
tiempo del analista y del equipo de trabajo, el costo de la realización integral
de un estudio de sistemas, el costo del tiempo del empleado para la empresa,
el costo estimado del equipo y el costo estimado del sistema o en su defecto,
el costo total debe ser aceptable.
  Factibilidad Operativa.-
Depende de los recursos humanos que participan durante la operación del
proyecto. Esto se refiere al pronóstico de si, una vez instalado, el sistema
llegará a funcionar o a usarse.

INVESTIGACION 2
a) Costo de desarrollo
Personal
Equipo
Material
b) Costo equipamiento
Equipo software
c) costo de operación anual
Insumos
Mantenimiento equipo y sistema
Costo de implementación a) + b)
Costo operacional c)

Beneficio tangibles
Beneficio intangible

3.3 Determinación de requerimientos Funcionales, no funcionales.-

- Identificación de Requerimientos funcionales.-

Los requerimientos funcionales son declaraciones de los servicios que

proveerá el sistema, de la manera en que éste reaccionará a entradas
particulares. En algunos casos, los requerimientos funcionales de los
sistemas también declaran explícitamente lo que el sistema no debe hacer.

Muchos de los problemas de la ingeniería de software provienen de la

imprecisión en la especificación de requerimientos. Para un desarrollador de
sistemas es natural dar interpretaciones de un requerimiento ambiguo con el
fin de simplificar su implementación. Sin embargo, a menudo no es lo que el
cliente desea. Se tienen que estipular nuevos requerimientos y se deben
hacer cambios al sistema, retrasando la entrega de éste e incrementando el
costo.

En principio, la especificación de requerimientos funcionales de un sistema

debe estar completa y ser consistente. La compleción significa que todos los
servicios solicitados por el usuario están definidos. La consistencia significa
que los requerimientos no tienen definiciones contradictorias.
 - Identificación de Requerimientos no funcionales.-

Son aquellos requerimientos que no se refieren directamente a las funciones

específicas que entrega el sistema, sino a las propiedades emergentes de
éste tales como la fiabilidad, la respuesta en el tiempo y la capacidad de
almacenamiento. De forma alternativa, definen las restricciones del sistema
como la capacidad de los dispositivos de entrada/salida y la representación
de datos que se utiliza en la interface del sistema.

Los requerimientos no funcionales surgen de la necesidad del usuario,

debido a las restricciones en el presupuesto, a las políticas de la
organización, a la necesidad de interoperabilidad con otros sistemas de
software o hardware o a factores externos como los reglamentos de
seguridad, las políticas de privacidad, entre otros.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus

implicaciones.

• Requerimientos del producto. Especifican el comportamiento del producto;

como los requerimientos de desempeño en la rapidez de ejecución del
sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de
fallas para que el sistema sea aceptable; los de portabilidad y los de
usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y

procedimientos existentes en la organización del cliente y en la del
desarrollador: estándares en los procesos que deben utilizarse;
requerimientos de implementación como los lenguajes de programación o el
método de diseño a utilizar, y los requerimientos de entrega que especifican
cuándo se entregará el producto y su documentación.

• Requerimientos externos. Se derivan de los factores externos al sistema y

de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad
que definen la manera en que el sistema interactúa con los otros sistemas de
la organización; los requerimientos legales que deben seguirse para asegurar
que el sistema opere dentro de la ley, y los requerimientos éticos. Estos
últimos son impuestos al sistema para asegurar que será aceptado por el
usuario.

3.4 Especificación de los Requerimientos.-

En esta etapa, luego de realizar la identificación de requerimientos se realiza un

análisis de la información obtenida y se comienza a preparar los documentos de
especificación de requerimientos.
Comenzaremos definiendo los objetivos y alcance preliminar del sistema.
 Tarea1.- Definición de Objetivos y alcance

ObjetivoPermite definir las metas y objetivos del sistema delimitando el

tamaño del mismo.
AlcancePermite definir el alcance del sistema.

Ejemplo: Sistema de Inscripciones en la Umss.

Objetivos Generales del sistema:

- Registrar Estudiantes nuevos.
- Inscribir Estudiantes en nuevo semestre.
- Emitir oferta de materias.
- Emitir Kardex de notas.
- Emitir listados de estudiantes por carreras y por asignaturas.

Alcance:
- El sistema se desarrollara para PC independiente
- La implementación se hará en dirección académica.

3.5 Modelo Conceptual.-

Como ya se indicó anteriormente, los primeros pasos para determinar los requisitos
tiene como finalidad conocer las características generales del sistema que se
analizara y estos se pueden representar mediante diagramas gráficos. A este
diagrama de alto nivel se le denomina DIAGRAMA DE CONTEXTO define el
sistema que va ser estudiado en el sentido de que determinan las fronteras.

El diagrama debe mostrar con que entidades u otras aplicaciones se comunica el

sistema definiendo:
- Que información entra o debe entrar al sistema
- Que información sale o debe salir del sistema
- Define los límites del sistema con su entorno

Elementos Gráficos:

- Entidad

Debe ser la fuente o destino de la información. Representa a persona, sistemas,

departamentos. Interiormente se coloca el nombre del rol o entidad.

- Proceso o sistema
Representa al sistema como un todo y separa de su entorno. Debe contener el
nombre genérico del sistema.

- Flujo

Representa un paquete de datos en movimiento. La dirección de la flecha muestra

la dirección del movimiento y lleva un nombre en sustantivo

Lista de Eventos.- Define los hechos que exigen una repuesta del sistema. Debe
mostrar las cosas que ocurre en el entorno a las cuales el sistema debe responder.
Se debe estar seguro que el evento ocurre fuera de los límites del sistema.
Se clasifican en:
Activados por el flujoSi el evento ocurre cada vez que ocurre un flujo (Una
solicitud)
Activados por el tiempoSi el evento ocurre con una frecuencia determinada.
Ejemplo:
Diagrama de Contexto y Alcance del Sistema de Inscripcion de la Umss

Tarea2: Preparar el Diagrama de contexto y la lista de eventos

4 Análisis Estructurado de Sistemas.-
4.1 Modelo de ciclo de vida
4.2 Modelo Funcional
4.3 Diagrama de flujo de datos
4.4 Modelo de datos
4.5 Diagrama de burbuja
4.6
4.7 Diagrama entidad relación
4.8 Diccionario de datos
5 Diseño estructurado de datos.-
5.1 Diagramas de descomposición funcional
5.2 Diagramas de estructuras
5.3 Técnicas para la toma de decisiones
5.4 Arboles de decisión
5.5 Tablas de decisión
5.6 Técnicas de representación de algoritmos: flujo gramas ,seudocódigo y
diagramas NanssiSheiderman
6 Implementación del Software.-
6.1 Etapas de la codificación
6.2 Pruebas de escritorio
 6.3 Pruebas de unidad
6.4 Cohesión y acoplamiento
6.5 Integración de módulos
7 Pruebas e implantación.-
7.1 Diagramas HIPO
7.2 Diagramas Warnier/Orr
8 Fundamentos del análisis y diseño orientado a objetos.-
8.1 Objetos, atributos, mensajes clases y métodos
8.2 Encapsulamiento, herencia y polimorfismo
8.3 Diagramas de clases y objetos en UML
8.4 Diagramas de estado, secuencia y colaboración en UML
9 Introducción al lenguaje de modelado unificado UML.-
9.1 Que debemos entender como análisis OO?
9.2 El método OO en el diseño de sistemas informáticos
9.3 Componentes del método OO
9.4 Clasificación de herramientas OO
9.5 El lenguaje de modelado unificado
9.6 Elaboración de micro proyectos