TEMARIO

UNIDAD I

FUNDAMENTOS DEL DISEO

1.1 Panorama general de diseo fisico y logico.

El diseo de sistemas se refiere a la formulacin de especificaciones para el
nuevo sistema o subsistema propuesto, de manera que satisfaga los
requisitos determinados durante la fase de anlisis. Finalmente el diseo de
sistemas vendr a ser una presentacin detallada del informe de
terminacin del anlisis de sistemas.
El diseo de un sistema de informacin puede descomponerse en
especificaciones fsicas y lgicas.
El diseo lgico representa los componentes del sistema y sus relaciones
mutuas, como apareceran ante los usuarios.
Muestra lo que la solucin sistemtica har en contraposicin con el modo
como lo es en la actualidad implantada fsicamente. Describe las entradas
y salidas, las funciones de procesamiento a realizar, los procedimientos de
negocios, los modelos de datos y los controles.
El diseo fsico es el proceso de traduccin del modelo lgico abstracto a
un diseo tcnico especfico para el nuevo sistema. Produce las
especificaciones reales para el hardware, especfico para el nuevo sistema.
Produce las especificaciones reales para el hardware, software y bases de
datos fsicas, medios de entrada/salida, procedimientos manuales y
controles especficos. Proporciona las especificaciones que transforman el
diseo lgico abstracto en un sistema de funciones de personas y
mquinas.
Cuando el analista est listo para comenzar a disear el nuevo sistema, ya
deben estar establecidos ciertos elementos. Debe hacer una definicin del
problema, informacin general de antecedentes sobre el rea bajo estudio,
una idea aproximada de las interacciones dentro del rea de estudio y con
otras reas, un buen entendimiento del sistema actual, y un conjunto de
requerimientos para el nuevo sistema.
http://www.tutoriales.itsa.edu.mx/sistemasinformacion2/#
1.2 Conceptos del diseo de sistemas.

El diseo puede definirse como el acto de delinear, planear, bosquejar y

disponer muchos elementos separados, reunindolos en un conjunto viable
y unificado. Mientras que en la fase de anlisis de sistemas se responde a
preguntas tales como qu est haciendo el sistema? Y qu debera hacer
para satisfacer las necesidades de los usuarios?, La fase de diseo se ocupa
de cmo debe desarrollarse el sistema para que pueda satisfacer esas
necesidades? Durante el proceso de diseo, el analista plantea soluciones
alternativas y finalmente determina cul es la mejor. La fase de diseo es
de naturaleza tcnica, hasta el punto de que el analista debe responder
esta pregunta "Cmo vamos a hacerlo?".
Por otra parte, el diseo tambin es un arte creativo, hasta el punto de que
el analista se pregunta continuamente: qu ocurrir si...? y por qu no?
El diseo es una solucin: la conversin de los requerimientos en formas
que los satisfagan.
El diseo determina el xito del sistema. A travs del diseo, los analistas
de sistemas pueden tener gran influencia sobre la efectividad del usuario,
ya sea para el manejo de transacciones o par la administracin de la
organizacin. Algunos diseos son ms efectivos que otros.
Mientras que anlisis de sistemas describe lo que un sistema debe hacer
para satisfacer los requerimientos de informacin, el diseo de sistemas
muestra cmo el sistema debe de satisfacer este objetivo. El diseo de
sistemas de informacin es el plan general o modelo para ese sistema.
Como el plano de un edificio o una casa, tiene todas las especificaciones
que dan al sistema su forma y estructura, el diseo de los sistemas de
informacin es una tarea creativa que requiere de imaginacin, sensibilidad
al detalle y habilidades.
Para disear un sistema, el analista debe conocer ciertos elementos
relacionados con los siguientes aspectos.
1.
Los recursos de la organizacin.
2.
Las necesidades de informacin de los usuarios.
3.
Las necesidades de otros sistemas.
4.
Los mtodos de procesamiento de datos,
5.
Las operaciones con los datos.
6.
Las herramientas del diseo.
Para producir el diseo, el analista tiene que aplicar el razonamiento
y la creatividad a los elementos mencionados.

http://www.tutoriales.itsa.edu.mx/sistemasinformacion2/#

1.2.1 Acomplamiento y coherencia.

Acoplamiento y coherencia. Un sistema est acoplado a otro sistema
cuando existe una dependencia entre ambos. En otra perspectiva, el
acoplamiento mide el efecto de un cambio en un mdulo, como se refleja
en los mdulos relacionados.
Acoplamiento fuerte, es cuando un cambio en un modulo implica un
esfuerzo grande en los mdulos relacionados.
Acoplamiento dbil, es cuando un cambio en un modulo implica un esfuerzo
mnimo en los mdulos relacionados.
Lo recomendable es tener un conjunto de mdulos dbilmente acoplados.
Cuando los desarrolladores se "atan" al cmo de los mdulos de software,
el acoplamiento se fortalece.
Para debilitar el acoplamiento, se debe recurrir a tcnicas de
encapsulamiento, herencia, polimorfismo y diseo por interfaces.
Coherencia. En una estructura de mdulos, la coherencia es el grado de
comunicacin que hay entre elementos del mdulo. Esto se debe procurar
relacionar todos los objetos de un mismo mdulo o paquete.
Una coherencia baja, es cuando los objetos de un paquete o mdulo no
tienen nada que ver entre s.
Una coherencia alta, es cuando los objetos de un paquete o mdulo estn
completamente relacionados. En resumen, para poder lograr un sistema
bien diseado, la coherencia debe ser alta y el acoplamiento debe ser dbil.
Con una coherencia alta se lograr independizar un mdulo de software de
otro, y con un acoplamiento dbil, los mdulos no se ven afectados ante
cambios en otros mdulos relacionado.
http://www.tutoriales.itsa.edu.mx/sistemasinformacion2/#
1.2.2 Arquitectura del software.
La Arquitectura del Software es el diseo de ms alto nivel de la estructura
de un sistema.
Una Arquitectura de Software, tambin denominada Arquitectura lgica,
consiste en un conjunto de patrones y abstracciones coherentes que
proporcionan el marco de referencia necesario para guiar la construccin
del software para un sistema de informacin.
La Arquitectura de Software establece los fundamentos para que analistas,
diseadores, programadores, etc. trabajen en una lnea comn que permita
alcanzar los objetivos del sistema de informacin, cubriendo todas las
necesidades.

Una arquitectura de software se selecciona y disea con base en objetivos y

restricciones. Los objetivos son aquellos prefijados para el sistema de
informacin, pero no solamente los de tipo funcional, tambin otros
objetivos como la mantenibilidad, adaptabilidad, flexibilidad e interaccin
con otros sistemas de informacin. Las restricciones son aquellas
limitaciones derivadas de las tecnologas disponibles para implementar
sistemas de informacin. Unas arquitecturas son ms recomendables de
implementar con ciertas tecnologas mientras que otras tecnologas no son
aptas para determinadas arquitecturas.
http://www.tutoriales.itsa.edu.mx/sistemasinformacion2/#

UNIDAD II DISEO DE SISTEMAS

2.1 Modelo estructurado.
En el modelo estructurado se examinan brevemente las nueve actividades
y los tres terminadores que lo componen, como se muestra en la figura
2.3.1. Los terminadores son los usuarios, los administradores, y el personal
de operaciones. Los cuales se tratan de individuos o grupos que
proporcionan la entrada al equipo del proyecto, y son los beneficiados
finales del sistema.

http://sistemas.itlp.edu.mx/tutoriales/analisis/23.htm

2.2 Modelo estructurado a objetos.

Es evidente que el concepto bsico de la orientacin a objetos es el

objeto, pero para ello debemos precisar primero porque orientado a
objetos. Un objeto puede ser algo tan trivial como una silla o una mesa,
pero en el mundo hay infinidad de objetos de ese tipo y las
declaraciones de atributos y operaciones para cada uno sera muy difcil
y desgastante. La verdadera esencia de la orientacin a objetos est en
la estructuracin de una jerarqua de clases y esto trae consigo otros
conceptos que siguen. Por otra parte los objetos deben comunicarse
unos con otros. Es por ello que Coad y Yourdon definieron la orientacin
a objetos as:
Orientado a objetos = Objetos + Clasificacin + Herencia + Comunicacin.

Clases y objetos.
Un modelo orientado a objetos de SW debe exhibir abstracciones de
datos y procedimientos que conduzcan a una modularidad eficaz. Una
clase es un concepto orientado a objetos que encapsula las
abstracciones de datos y procedimientos que se requieren para describir
el contenido y el comportamiento de alguna entidad del mundo real.
Una clase es una descripcin generalizada que describe una coleccin de
objetos similares. Por definicin, todos los objetos que existen dentro de
una clase heredan sus atributos y operaciones. De este concepto se
derivan cosas como:
Una superclase es una coleccin de clases.
Una subclase es una instancia de una clase.
Es interesante sin embargo la notacin de Taylor sobre una clase, donde
queda destacado de forma relevante que la clase encapsula las
abstracciones de datos (atributos) dentro de una muralla de
abstracciones procedimentales (operaciones), a travs de la cual hay
que pasar para poder acceder a los datos. De esta forma queda
representado de alguna manera el concepto de ocultacin de la
informacin. Tambin favorece el concepto de alta cohesin entre los
mtodos y los pocos datos que estos manipulan, mientras que se
presupone tambin, el acople de la clase con otros elementos del
sistema a travs de la comunicacin va mtodos.
Para todas las cosas orientadas a objetos, el marco de referencia
conceptual es el modelo de objetos que incluye cuatro elementos
fundamentales: abstraccin, encapsulamiento, modularidad y jerarqua;
as como tres elementos secundarios: tipos, concurrencia y persistencia.
Una abstraccin denota las caractersticas esenciales de un objeto que lo
distinguen de todos los dems tipos de objetos y proporciona as

fronteras conceptuales ntidamente definidas respecto a la perspectiva

del observador.
El encapsulamiento es el proceso de almacenar en un mismo
compartimento los elementos de una abstraccin que constituyen su
estructura y su comportamiento; sirve para separar la interfaz
contractual de una abstraccin y su implantacin.
La modularidad es la propiedad que tiene un sistema que ha sido
descompuesto en un conjunto de mdulos cohesivos y dbilmente
acoplados.
La jerarqua es una clasificacin u ordenacin de abstracciones.
Los tipos son la puesta en vigor de una clase de los objetos, de modo
que los objetos de tipos distintos no pueden intercambiarse o, como
mucho, pueden intercambiarse slo de formas muy restringidas.
La concurrencia es la propiedad que distingue un objeto activo de uno
que no est activo.
La persistencia es la propiedad de un objeto por la que su existencia
trasciende el tiempo, el espacio, o ambos.

Atributos.
Los atributos son las caractersticas estables que identifican claramente
a los objetos y clases de objetos de la vida real. Se puede decir que una
caracterstica puede verse como una relacin binaria entre una clase y
cierto dominio donde quedan definidos los posibles valores que puede
tomar esa caracterstica.
http://148.202.148.5/cursos/cc321/fundamentos/unidad3/tema3_4_1.h
tml
2.3 Modelo basados en componentes.
El modelo de desarrollo basado en componentes incorpora muchas de las
caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un
enfoque interactivo para la creacin del software. Sin embargo, el modelo
de desarrollo basado en componentes configura aplicaciones desde
componentes preparados de software (clases).
El modelo de desarrollo basado en componentes conduce ala reutilizacin
del software, y la reutilizacin proporciona beneficios a los ingenieros de
software. Segn estudios de reutilizacin, QSM Associates, Inc. Informa
que el ensamblaje de componentes lleva a una reduccin del 70 % del ciclo
de desarrollo un 84% del coste del proyecto y un ndice de productividad
del 26.2. No hay duda que el ensamblaje de componentes proporciona
ventajas significativas para los ingenieros del software.
El proceso unificado de desarrollo de software representa un nmero de
modelos de desarrollo basado en componentes que han sido propuestos en
la industria. El lenguaje de modelado unificado define los componentes.
Utilizando una combinacin del desarrollo ncremental e interactivo, el

proceso unificado define la funcin del sistema aplicando un enfoque

basado en escenarios.
El desarrollo de software basado en componentes se ha convertido
actualmente en uno de los mecanismos ms efectivos para la construccin
de grandes sistemas y aplicaciones de software.
Una vez que la mayor parte de los aspectos funcionales de esta disciplina
comienzan a estar bien definidos, la atencin de la comunidad cientfica
comienza a centrarse en los aspectos extrafuncionales y de calidad, como
un paso hacia una verdadera ingeniera. En este artculo se discuten
precisamente los aspectos de calidad relativos a los componentes software
y a las aplicaciones que con ellos se construyen, con especial nfasis en los
estndares internacionales que los definen y regulan, y en los problemas
que se plantean en este tipo de entornos.
Beneficios del Desarrollo de Software Basado en Componentes
El uso de este paradigma posee algunas ventajas:
1. Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de
reutilizacin de software.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas
probando cada uno de los componentes antes de probar el conjunto
completo de componentes ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un dbil
acoplamiento entre componentes, el desabollador es libre de actualizar y/o
agregar componentes segn sea necesario, sin afectar otras partes del
sistema.
4. Mayor calidad. Dado que un componente puede ser construido y luego
mejorado continuamente por un experto u organizacin, la calidad de una
aplicacin basada en componentes mejorar con el paso del tiempo
La Notacin de Componentes
Un componente puede ser algo como un control Actives; tanto un
componente de la Interfaz de usuario como un servidor de reglas de
negocio.
El Diagrama de Componentes
El diagrama de componentes muestra la relacin entre componentes de
software, sus dependencias, su comunicacin su ubicacin y otras
condiciones.
Interfaces
Los componentes tambin pueden exponer las interfaces. Estas son los
puntos visibles de entrada o los servicios que un componente est
ofreciendo y dejando disponibles a otros componentes de software y clases.
Tpicamente, un componente est compuesto por numerosas clases y
paquetes de clases internos. Tambin se puede crear a partir de una
coleccin de componentes ms pequeos.
Los componentes y los Nodos
Un diagrama de despliegue muestra el despliegue fsico del sistema en un
ambiente de produccin (o de prueba). Muestra dnde se ubican los

componentes, en qu servidores, mquinas o hardware. Puede representar

los enlaces de redes.
Restricciones
Los componentes pueden restricciones asignadas que indican el entorno en
el que operan.
Las pre-condiciones especifican lo que debe ser verdadero antes de que un
componente pueda realizar alguna funcin; las post-condiciones indican lo
que debe ser verdadero despus de que un componente haya realizado
algn trabajo y los invariantes especifican lo que debe permanecer
verdadero durante la vida del componente.
Conclusin
Tenemos la fortuna de presenciar el nacimiento de una nueva forma de
hacer software, que traer beneficios inmensos para todos. El desarrollo de
software basado en componentes desde siempre fue la idea revolucionaria
que nos llev a pensar que s era posible el construir software de calidad en
corto tiempo y con la misma calidad que la mayora de las industrias de
nuestro tiempo. Al mirar hacia atrs, vemos los increbles avances que
hemos logrado en la comprensin de la forma correcta de reutilizar el
software y el conocimiento existente, y nos asombramos cada vez ms al
darnos cuenta de que este solo es el inicio.
El desarrollo de software basado de componentes se convirti en el pilar de
la Revolucin Industrial del Software y se proyecta hoy en da en diversas
nuevas formas de hacer software de calidad con los costos ms bajos del
mercado y en tiempos que antes eran impensables. Empresas como
Microsoft entendieron el potencial de esta metodologa hace aos y hoy nos
ofrecen nuevas iniciativas y herramientas que buscan llevar al proceso de
construccin de software hacia el sitial privilegiado en el que debi
colocarse desde un principio.
Anlisis del riesgo
Se estudian todos los riesgos potenciales y se seleccionan una o varias
alternativas propuestas para reducir o eliminar los riesgos.
Planificar Revisamos todo lo hecho, evalundolo, y con ello decidimos si
continuamos con las fases siguientes y planificamos la prxima actividad.
2.4 Diseo de la arquitectura del software.

La Arquitectura del Software es el diseo de ms alto nivel de la

estructura de un sistema.
Una Arquitectura de Software, tambin denominadaArquitectura
lgica, consiste en un conjunto de patrones y abstracciones coherentes que
proporcionan el marco de referencia necesario para guiar la construccin
del software para un sistema de informacin.
La Arquitectura de Software establece los fundamentos para que
analistas, diseadores, programadores, etc. trabajen en una lnea comn
que permita alcanzar los objetivos del sistema de informacin, cubriendo
todas las necesidades.

Una arquitectura de software se selecciona y disea con base en

objetivos y restricciones. Los objetivos son aquellos prefijados para el
sistema de informacin, pero no solamente los de tipo funcional, tambin
otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e
interaccin con otros sistemas de informacin. Las restricciones son
aquellas limitaciones derivadas de las tecnologas disponibles para
implementar sistemas de informacin. Unas arquitecturas son ms
recomendables de implementar con ciertas tecnologas mientras que otras
tecnologas no son aptas para determinadas arquitecturas. Por ejemplo, no
es viable emplear una arquitectura de software de tres capas para
implementar sistemas en tiempo real.
La arquitectura de software define, de manera abstracta, los
componentes que llevan a cabo alguna tarea de computacin, sus
interfaces y la comunicacin entre ellos. Toda arquitectura debe ser
implementable en una arquitectura fsica, que consiste simplemente en
determinar qu computadora tendr asignada cada tarea.
http://es.wikipedia.org/wiki/Arquitectura_de_software#Arquitectura
2.5 Diseo de la interfaz de usuario.
El diseo de interfaz de usuario o ingeniera de la interfaz es el
diseo de computadoras, aplicaciones, mquinas, dispositivos de
comunicacin mvil, aplicaciones de software, y sitios web enfocado en la
experiencia de usuario y la interaccin.
Normalmente es una actividad multidisciplinar que involucra a varias ramas
del diseo y el conocimiento como el diseo grfico, industrial, web, de
software y la ergonoma; y est implicado en un amplio rango de
proyectos, desde sistemas para computadoras, vehculos hasta aviones
comerciales.
Su objetivo es que las aplicaciones o los objetos sean ms atractivos y
adems, hacer que la interaccin con el usuario sea lo ms intuitiva posible,
conocido como el diseo centrado en el usuario. En este sentido las
disciplinas del diseo industrial y grfico se encargan de que la actividad a
desarrollar se comunique y aprenda lo ms rpidamente, a travs de
recursos como la grfica, los pictogramas, los estereotipos y la simbologa,
todo sin afectar el funcionamiento tcnico eficiente
http://es.wikipedia.org/wiki/Dise%C3%B1o_de_interfaz_de_usuario

2.6 Diseo de la base de datos.

Son muchas las consideraciones a tomar en cuenta al momento dehacer el
diseo de la base de datos, quiz las ms fuertes sean:
La velocidad de acceso,

El tamao de la informacin,

El tipo de la informacin,

Facilidad de acceso a la informacin,

Facilidad para extraer la informacin requerida,

El comportamiento del manejador de bases de datos con cada tipo de

informacin.
No obstante que pueden desarrollarse sistemas de procesamiento de
archivo e incluso manejadores de bases de datos basndose en la
experiencia del equipo de desarrollo de software
lograndoresultados altamente aceptables, siempre es recomendable la
utilizacin de determinados estndares de diseo que garantizan el nivel de
eficiencia mas alto en lo que se refiere a almacenamiento y recuperacin de
la informacin.
De igual manera se obtiene modelos que optimizan el aprovechamiento
secundario y la sencillez y flexibilidad en las consultas que pueden
proporcionarse al usuario.
UNIDAD III CONSTRUCCION
3.1 Seleccion de ambiente operativo y lenguaje de desarrollo.
3.2 Elaboracion de programas.
3.2.1 Implementacion.
3.3 Metricas para evaluar el software.
3.4 Prueba de programas y del sistema.
3.5 Implementacion.
3.6 Documentacion.
3.6.1 Elaboracion de manual de usuario.
3.6.2 Elaboracion del manual de administracin.
3.6.3 Elaboracion del manual tecnico.
UNIDAD IV
4.1
4.2
4.3
4.4
4.5

ESTUDIOS DE CASOS PRACTICOS PARA EL MANTENIMIENTO

Tipos de mantenimiento.
Tecnicos de mantenimiento.
Analisis de casos.
Viabilidad del mantenimiento.
Administracion del mantenimiento.