INFORMATICA III:

(Anlisis y diseo de sistemas

estructurados)

TEMA II.- ANLISIS DE SISTEMAS.

LA FASE DE ANLSIS DEL SISTEMA ES LA PRIMERA
QUE DEBEMOS CONSIDERAR Y ES PARTE DEL CICLO
DE VIDA DE LOS SISTEMAS
 Criterios para el anlisis.

principios para desarrollar correctamente un sistema de informacin:

1. Involucrar al usuario.
El usuario es una parte imprescindible para el adecuado desarrollo de un sistema. Implicando al
usuario se lograr mejor sus necesidades y reducir su potencial resistencia a los nuevos sistemas de
informacin.

2. Utilizar mtodos de solucin de problemas como es el ciclo de vida de sistemas.

Cualquier actividad compleja necesita aplicar lgicas contrastadas. El ciclo de vida es en s un
mtodo de resolucin de un problema especfico.

3. Abordar adecuadamente cada una de las fases.

El ciclo de vida moderno incorpora una serie de fases: planificacin, anlisis, diseo, implantacin y
soporte de sistemas. En trminos generales se puede decir que se desarrollan secuencialmente, y
cada una de ellas incorpora mayor grado de detalle que la anterior. Las fases planificacin y
anlisis han de abordarse correctamente, puesto que por muy inteligentes que sean las soluciones
tcnicas, sin un anlisis correcto ser muy difcil que el sistema sea todo lo til que potencialmente
podra ser.
4. Normalizar y documentar.
Es fundamental que se fijen normas sobre las actividades, sobre las responsabilidades,
requisitos documentales y controles de calidad para asegurar en el tiempo la supervivencia del
sistema. Los analistas y programadores responsables de un sistema pueden dejar su puesto y si no
existe la documentacin apropiada, todo puede resultar catico. La necesidad de documentar aumenta
en la medida que el sistema que se desarrolle sea ms complejo.

5. Justificar adecuadamente el sistema.

Desarrollar sistemas de informacin supone invertir en el futuro de la empresa. No se puede
considerar un gasto, sino una inversin y como tal ha de plantearse.

6. Cancelar o revisar el proyecto si es necesario.

Si es necesario, durante el desarrollo se ha de ser lo suficientemente flexible como para cancelar
un proyecto. Durante el ciclo de vida existen distintos momentos en los que se efecta un control
progresivo que es un control de la viabilidad del proyecto.

7. Descomponer y simplificar.
Un sistema complejo se ha de abordar dividindolo en subsistemas ms simples. De esta manera
disminuye la complejidad y es ms abordable por el ser humano.

8. Disear sistemas flexibles.

Si los sistemas no se disean previendo futuras modificaciones, slo servirn para momentos
concretos en el tiempo. Si se hace necesario cambiar un sistema que no es flexible, consumir muchos
recursos y talento de las unidades involucradas en el soporte o mantenimiento del sistema.
Elaboracin del proyecto de desarrollo de
un sistema.
Se puede decir que el ciclo de vida es una
herramienta de gestin de proyectos-
empleada para planificar, elaborar y
controlar el proyecto de desarrollo de un
sistema- y que involucra tanto a analistas
como a ingenieros de software,
programadores, propietarios y usuarios.
 Modelos del ciclo de vida de los
sistemas de informacin

Modelo clsico o en cascada.

Modelo incremental.
Modelo de desarrollo evolutivo.
Modelo de prototipado de requerimientos.
Modelo de espiral.
Modelo de construccin de prototipos.
Modelo de sntesis automtica de software.
Modelo de sistemas suaves (soft)
 Modelo clsico o en cascada.
Ingeniera y Anlisis del
Sistema

Anlisis de los
Requisitos

Diseo

Codificacin

Prueba

Mantenimiento

Ingeniera y Anlisis del Sistema: Debido a que el software es siempre parte de un

sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos
del sistema y luego asignando algn subconjunto de estos requisitos al software.

Anlisis de los requisitos del software: el proceso de recopilacin de los requisitos se

centra e intensifica especialmente en el software. El ingeniero de software (Analistas)
debe comprender el mbito de la informacin del software, as como la funcin, el
rendimiento y las interfaces requeridas.
 Modelo clsico o en cascada.
Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa:
la estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una
representacin del software con la calidad requerida antes de que comience la
codificacin.

Codificacin: el diseo debe traducirse en una forma legible para la maquina. El paso
de codificacin realiza esta tarea. Si el diseo se realiza de una manera detallada la
codificacin puede realizarse mecnicamente.

Prueba: una vez que se ha generado el cdigo comienza la prueba del programa. La
prueba se centra en la lgica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados que
realmente se requieren.

Mantenimiento: el software sufrir cambios despus de que se entrega al cliente.

Los cambios ocurrirn debido a que hayan encontrado errores, a que el software
deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos
perifricos), o debido a que el cliente requiera ampliaciones funcionales o del
rendimiento.
 Modelo incremental.
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes.
Una forma de reducir los riesgos es construir slo una parte del sistema, reservando
otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de
construccin siempre incrementando subconjuntos de requerimientos del sistema.

El modelo de desarrollo incremental provee algunos beneficios significativos para los

proyectos:

Construir un sistema pequeo tiene siempre menos riesgo que construir un sistema
grande.

Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los

requerimientos planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, slo la ltima iteracin necesita ser descartada.

Reduciendo el tiempo de desarrollo de un sistema decrecen las probabilidades que

esos requerimientos de usuarios puedan cambiar durante el desarrollo.

Si un error importante es realizado, el incremento previo puede ser usado.

Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes

del comienzo del prximo incremento.
 Modelo de desarrollo evolutivo
(desarrollo por requerimientos).
Construye una serie de grandes versiones sucesivas de un producto. El modelo
evolutivo asume que los requerimientos no son completamente conocidos al inicio del
proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos

que son bien comprendidos son seleccionados para el primer incremento. Los
desarrolladores construyen una implementacin parcial del sistema que recibe slo
estos requerimientos.

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin

a los desarrolladores. Basada en esta retroalimentacin, la especificacin de
requerimientos es actualizada, y una segunda versin del producto es desarrollada y
desplegada. El proceso se repite indefinidamente.

Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos

conocidos y comprender al principio que muchos nuevos requerimientos es probable que
aparezcan cuando el sistema sea desplegado o desarrollado.
Modelo de prototipado de requerimientos.
El prototipado de requerimientos es la creacin de una
implementacin parcial de un sistema, para el propsito explcito de
aprender sobre los requerimientos del sistema.

Un prototipo es construido de una manera rpida tal como sea

posible. Esto es dado a los usuarios, clientes o representantes de
ellos, posibilitando que ellos experimenten con el prototipo. Estos
individuos luego proveen la retroalimentacin sobre lo que a ellos les
gust y no les gust acerca del prototipo proporcionado, quienes
capturan en la documentacin actual de la especificacin de
requerimientos la informacin entregada por los usuarios para el
desarrollo del sistema real.
 Modelo en espiral
Es un modelo evolutivo que combina el modelo clsico con el diseo de prototipos.
Incluye la etapa de anlisis de riesgos.
Es ideal para crear productos con diferentes versiones mejoradas.
Este es el enfoque ms realista actualmente. El modelo en espiral se divide en un
numero de actividades estructurales, tambin llamadas regiones de tareas.

Generalmente, existen entre tres y seis regiones de tareas:

Comunicacin con el cliente: las tareas requeridas para establecer comunicacin
entre el desarrollador y el cliente.

Planificacin: las tareas requeridas para definir recursos, el tiempo y otras

informaciones relacionadas con el proyecto. Son todos los requerimientos.

Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y otras
informaciones relacionadas con el proyecto.

Ingeniera: las tareas requeridas para construir una o ms representaciones de la

aplicacin.

Construccin y adaptacin: las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario.

Evaluacin del cliente: las tareas requeridas para obtener la reaccin del cliente
segn la evaluacin de las representaciones del software creadas durante la etapa de
ingeniera e implementacin durante la etapa de instalacin.
 El modelo en espiral
Planificacin Anlisis de riesgos

Comunicacin
con el cliente

Ingeniera

Evaluacin del
cliente Construccin y adaptacin
Modelo de construccin de prototipos

Este modelo arranca con el establecimiento de los requerimientos

del sistema, se definen los objetivos del sistema y los requisitos
conocidos con base en las reas de mayor prioridad e importancia
para el sistema.

Luego se hace un diseo preliminar , sobre el cual se construye un

prototipo o modelo del sistema, compuesto a menudo de ventanas,
tablas de la Base de Datos, formatos de entrada y de salida bsicos.

Un prototipo es una representacin o modelo del producto de

programacin que incorpora componentes del producto real. Por lo
regular, un prototipo tiene un funcionamiento limitado en cuanto a
capacidades, confiabilidad o eficiencia.
Modelo de construccin de
prototipos

Recoleccin
refinamiento
requisitos

Producto de Diseo
ingeniera rpido

Refinamiento Construccin
del prototipo del prototipo

Evaluacin
del prototipo
por el cliente
 Modelo de sntesis automtica de
software

Se define el sistema utilizando un lenguaje formal.

La implementacin es automtica, asistida por el Ordenador.

La documentacin se genera de forma automtica.

El mantenimiento se realiza por sustitucin no mediante parches.

Dificultad en la participacin del usuario.

Diseos poco optimizados.

 Anlisis de sistemas
El anlisis de sistemas es el estudio de una aplicacin
del sistema de informacin y de empresa actual y la
definicin de las necesidades y las prioridades de
usuario para conseguir una aplicacin nueva o
mejorada.

Trata bsicamente de determinar los objetivos y

lmites del sistema objeto de anlisis, caracterizar su
estructura y funcionamiento, marcar las directrices
que permitan alcanzar los objetivos propuestos y
evaluar sus consecuencia.

Conlleva el estudio del sistema actual y la definicin

de las necesidades reales de los usuarios.
 Fases de Anlisis de sistemas
Incluye las siguientes fases:

Identificacin del problema

Anlisis de requerimientos

Anlisis de la Viabilidad del Proyecto (o fase de inspeccin).

Anlisis del sistema actual ( o fase de estudio).

Definicin y establecimiento de prioridades entre las necesidades de

usuarios( o fase de definicin).

Planeacin del Sistema

Fase del: Identificacin del problema.
Tener claro que problema se deber resolver
el Sistema de Informacin.

Es un proceso que deber recabar la

informacin necesaria para emprender una
accin que solucione el problema.
Fase de anlisis de Requerimientos

Es establecer lo que el
cliente o el usuario requiere
de un Sistema de Software.
Fase de anlisis de Requerimientos

-Tiene la funcin de fortalecer el proceso de desarrollo

de software, tanto en su definicin como en lo que se
desea que haga.
- Permiten administrar las necesidades del proyecto en
forma estructurada
- Mejora la capacidad de predecir resultados
- Disminuyen los costos y retrasos del proyecto
- Mejora la calidad del software
- Mejora la comunicacin entre los equipos
- Evita rechazos de usuarios finales
 Que son los requerimientos

Es la condicin o necesidad de un
usuario para resolver un problema del
negocio o alcanzar un objetivo.
 Qu es un Requerimiento

Es la condicin o necesidad de un usuario para resolver un

problema del negocio o alcanzar un objetivo.
Puede ser la base para una declaracin de un contrato,
por lo tanto, deber estar abierto a interpretacin.
Puede ser la base para el contrato en s, por lo tanto,
debe ser definido en detalle.
 Tipos de Requerimientos
El proceso de establecer los servicios que el cliente
requiere de un sistema y los limites bajo los cuales
opera y se desarrolla.

Los Requerimientos pueden ser Funcionales o No-

Funcionales

Los Requerimientos funcionales describen

servicios o funciones
Los Requerimientos No-funcionales son aspectos
secundarios que no tienen que ver con la
funcionalidad de un sistema. Por ejem. Logos,
colores, etc.
Caractersticas de un requerimiento

-Debe ser especificado por escrito como un contrato o

acuerdo de ambas partes
- Se debe de probar o verificar para detectar su
cumplimiento
- Debe ser conciso fcil de leer y entender
- Debe ser completo
- Debe ser consistente y sin contradicciones
- No debe ser ambiguo no debe causar ninguna confusin
 Dificultades para definir los requerimientos

- Los requerimientos vienen de muchas fuentes y no son obvios

- Son difciles de expresar en palabras
- La gran cantidad de requerimientos puede ser difcil de manejar y
clasificar
- Pueden cambiar a lo largo del ciclo de desarrollo del software
- Al usuario se le dificulta explicar lo que hace
- Generalmente se habla de lo que no funciona
- Los usuarios tienen vocabulario distinto al de los desarrolladores
Requerimientos Definicin/Especificacin

Definicin de Requerimientos
Una declaracin en un Lenguaje Natural incluye los
diagramas de los servicios del sistema y sus lmites
operacionales. Escrito para clientes.
Especificacin de Requerimientos
Un documento estructurado con descripcin o detalle de
los servicios del sistema. Escrito como un contrato entre el
cliente y el contratista.
Especificacin de Software
Descripcin detallada de software, la cual, puede servir
como una base para diseo o implementacin. Escrito para
desarrolladores.
 Documento de Requerimientos
Es la declaracin oficial de lo que es requerido
para que el sistema sea desarrollado.
Incluye la definicin y especificacin de
requerimientos.
No es un documento de diseo. Tanto como
sea posible, es un conjunto de lo que es el
sistema y como lo har.
Requerimientos del Documento de Requerimientos

Especificacin de la conducta externa del sistema.

Especificar los lmites de la implementacin.
Fcil de cambiar.
Sirve como una herramienta de referencia para
mantenimiento.
Recuerda el ciclo de vida del sistema, esto es, predice
cambios.
Proporciona respuestas caractersticas a un evento
no esperado.
 Estructura del Documento de Requerimientos

Introduccin.
Describe la necesidad de crear el sistema y cuales son sus
objetivos.
Glosario.
Define los trminos tcnicos usados.
Modelos del Sistema.
Define los modelos que muestran los componentes del
sistema y las relaciones entre ellos.
Definicin de Requerimientos Funcionales.
Define los servicios que sern proporcionados.
 Estructura del Documento de Requerimientos
Definicin de Requerimientos No-funcionales.
Definir las limitantes del sistema y el proceso de
desarrollo.
Evolucin del Sistema.
Definir las suposiciones fundamentales en las cuales el
sistema se basa y se anticipan los cambios.
Especificacin de Requerimientos.
Especificacin detallada de los requerimientos
funcionales del sistema.
Apndices.
Descripcin de la plataforma de Hardware del Sistema.
Requerimientos de la base de Datos (quiz como un
modelo ER)
Indice.
 Anlisis de la Viabilidad del Proyecto.

Establecer Objetivos de inspeccin.

Identificar los problemas, las oportunidades y las normas que dieron lugar
a la solicitud del proyecto.

EJEMPLO:
Objetivo de inspeccin.- Conocer las causas de la baja en las Ventas

Problema.- Agilizar las ventas en un SuperMercado

Oportunidades.- Manejo del crdito
Normas.- El pago deber ser por medio de tarjeta de crdito
Identificacin del problema y oportunidades.

El analista se involucra en la identificacin de los

problemas y puntos de oportunidad (oportunidades de
mejoras) y cumplimiento de objetivos.

Esta fase es recomendable elaborar un diagrama de

procesos que muestre el flujo de las actividades del
sistema actual, los problemas detectados y sealar
claramente los puntos de oportunidad y mejoras.
Anlisis de la Viabilidad del Proyecto.
Es determinar si resolver los problemas, aprovechar las oportunidades y
cumplir las normas reportar beneficios a la empresa.

Qu tcnicas se utilizarn en el Estudio de Viabilidad del Sistema (EVS)

Anlisis coste/beneficio.
Diagrama entidad/relacin extendido.
Sesiones de trabajo.
Catalogacin
Impacto en la organizacin.
Planificacin
Diagramas de actividades
Matrices
Presentaciones
 Anlisis de la Viabilidad del Proyecto.

Dnde interviene cada uno de los siguientes participantes y cules su misin?

Comit de direccin: participa al principio y al final del EVS. Su misin es indicar

cul debe ser el alcance del sistema y aprobar la solucin final.

Usuarios expertos: participan en el estudio de la situacin actual, la definicin de

requisitos y el estudio de alternativas. Su objetivo es ayudar a conocer los sistemas
existentes, exponer sus requisitos y dar su opinin en las alternativas de solucin.

Especialistas en comunicaciones: participan en el estudio de alternativas de

solucin. Su objetivo es definir los requisitos de comunicacin de las distintas
soluciones.
 Anlisis del sistema actual
Consiste en estudiar y analizar el sistema actual, siempre y
cuando se cuente con un sistema actual, hago uso o no de la
informtica, dota al analista de una comprensin mas profunda
del sistema.

Los objetivos:

Conocer el entorno de empresa del sistema.

Conocer las causas y los efectos subyacentes del sistema.
Conocer las ventajas de aprovechar las oportunidades.
Conocer las implicaciones de no cumplir con las normas.
 Establecer las prioridades de los usuarios

Es definir qu necesita el sistema y que quiere el usuario que haga.

Objetivos:
Definir las necesidades de la empresa sobre los problemas y establecer
prioridades.
Definir las necesidades de empresa sobre oportunidades y establecer
prioridades
Definir las necesidades sobre normas y establecer prioridades.

Actividades:
Identificar las necesidades.
Modelizar las necesidades de sistemas.
Elaborar prototipos de descubrimiento.
Definir prioridades entre las necesidades de empresa.
Modificar el mbito y el plan de proyecto.
Revisar las especificaciones de las necesidades.
 La planeacin de sistemas.

La funcin de planificacin pretende sealar y establecer

prioridades sobre aquellas tecnologas y aplicaciones que
producirn un mximo beneficio para la organizacin.

El objetivo de esta fase consiste en decidir junto con el

equipo humano de la empresa donde se va a implementar
el sistema, los objetivos generales, especficos de la
misma y elaborar los esquemas generales de la manera
ms clara y precisa.
 Planeacin de sistemas
Como sabemos, la planificacin de los sistemas de informacin es la primera etapa
de un moderno ciclo de desarrollo y se puede considerar compuesta a su vez de tres
subetapas:
Estudio de la misin y de los objetivos de la empresa.
Establecer una arquitectura de la informacin.
Analizar las reas de empresa.

Estudio de la misin y de los objetivos de la empresa.

Para que los S.I sean verdaderamente tiles, han de contribuir a la misin de
la empresa. Para aumentar el impacto positivo de las inversiones en sistemas de
informacin, han de dirigirse a los objetivos, reas y actividades que contribuyan en
mayor medida al cumplimiento de la misin.
Anlisis de los factores fundamentales para el xito.
Anlisis contextual. Especial referencia a la competencia.
Anlisis de las actividades sobre la base de la cadena de valor.
Anlisis del sistema de las actividades.
 Planeacin de sistemas
Definicin de una arquitectura de informacin .
La arquitectura de informacin se encarga del estudio, anlisis, organizacin,
disposicin y estructuracin de la informacin en la organizacin, y de la
seleccin y presentacin de los datos en los sistemas de informacin interactivos.
Su principal objetivo es facilitar al mximo los procesos de comprensin y asimilacin
de la informacin, as como las tareas que ejecutan los usuarios en un espacio de
informacin definido.
Durante esta etapa de definicin se han de realizar una serie de actividades que
siguen una determinada secuencia, que se muestra a continuacin junto con el
diccionario de planificacin en el que se archivan todos los documentos que se van
generando.
Definicin de un modelo de empresa

Valorar las estrategias actuales de empresa

Valorar los servicios actuales de infamacin

Diccionario
de
Determinar las reas de empresa y prioridades
planificacin

Completar la nueva arquitectura de la informacin

Identificar futuros proyectos, revisar las conclusiones y aprobar el

plan.
 Planeacin de sistemas
Examen de las reas de empresa.
Es un examen general en un doble sentido, abarca todo un rea de empresa y el nivel
de detalle no debe ser muy elevado.

Las tcnicas de estudio y anlisis buscan conjuntamente el rediseo de los

procesos para hacerlos ms eficaces y eficientes. En los ltimos aos se ha
hablado de la reingeniera de procesos o rediseo radical de los sistemas de
informacin para mejorarlos y simplificarlos de forma intensa.

Para desarrollar esta fase de reingeniera de procesos ser necesario:

Constituir un equipo de anlisis multifuncional.

Identificar las medidas de rendimiento del rea de empresa.
Ampliar y desarrollar los modelos de reas de empresa.
Valoracin del rendimiento del rea de empresa y de los sistemas.
Establecer proyectos y prioridades.
Planificar proyectos de desarrollo reales.
Revisar las conclusiones y aprobar el plan.