Ingeniera del Software

ndice
1 Fundamentos del diseo.
1.1 Panorama general del diseo fsico y lgico.
1.2 Conceptos del diseo de sistemas.
1.2.1 Acoplamiento y coherencia.
1.2.2 Arquitectura del software.
1.3 Heursticas de diseo.

2 Diseo de sistemas.
2.1 Modelo estructurado.
2.2 Modelo orientado a objetos.
2.3 Modelo basado en componentes.
2.4 Diseo de la Arquitectura del software.
2.5 Diseo de Interfaz de usuario.
2.6 Diseo de bases de datos.
2.7 Diseo de controles y procesos.
2.8 Aplicacin de mtricas para la evaluacin del diseo.

3 Construccin.
3.1 Seleccin del ambiente operativo y lenguaje de desarrollo.
3.2 Elaboracin de programas.
3.2.1 Implementacin.
3.3 Mtricas para evaluar el software.
3.4 Prueba de programas y del sistema.
3.5 Implementacin.
3.6 Documentacin.
3.6.1 Elaboracin del manual de usuario.
3.6.2 Elaboracin del manual de administracin.
3.6.3 Elaboracin del manual tcnico.

4 Estudio de casos prcticos para mantenimiento.

4.1 Tipos de mantenimiento.
4.2 Tcnicas de mantenimiento.
4.3 Anlisis de casos.
4.4 Viabilidad del mantenimiento.
4.5 Administracin del Mantenimiento.

Fundamentos del Diseo

1.1 Panorama general del diseo fsico y lgico.

Diseo Fsico
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, 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.
Tambin el diseo fsico de sistemas es la forma en que se lograrn las
tareas del sistema, lo que incluye la manera de conjuntar sus componentes y las
funciones que realizar cada uno de stos.
En el diseo fsico se especifican las caractersticas de los componentes del
sistema requeridos para poner en prctica el diseo lgico. En esta fase deben
delinearse las caractersticas de cada uno de los componentes que se enumeran a
continuacin.
Diseo de hardware: Debe especificarse todo el equipo de cmputo, lo que
incluye dispositivos de entrada, procesamiento y salida, con sus caractersticas de
rendimiento.
Diseo de software: De todo el Software Por ejemplo, si en el diseo lgico se
indica la necesidad de que de que los usuarios actualicen al mismo tiempo la base
de datos, en el diseo fsico deben especificarse un sistema de administracin de
base de datos que lo permita algunos casos se puede adquirir el software,
mientras que en otros se desarrollan internamente en cuanto a requisitos de
salidas, entradas y procesamiento de los programas, tambin se toman en cuenta
durante el diseo fsico del software.

Diseo de bases de datos: Es necesario detallar el tipo, estructura y funciones

de las bases de datos. Las relaciones entre los elementos de datos establecidos
en el diseo lgico deben reflejarse tambin en el diseo fsico.
Diseo

de

telecomunicaciones: Deben especificarse las caractersticas

necesarias del software, medios y dispositivos de telecomunicaciones.

Diseo de personal: Este paso incluye especificar los antecedentes y experiencia
de los individuos que ms probablemente satisfagan las descripciones de empleos
que se incluyen en el diseo lgico.
Diseo de procedimientos y controles: Comprende detallar la forma en que se
ejecuta cada aplicacin y las medidas para minimizar las probabilidades de delitos
y fraudes. Tales especificaciones incluyen mtodos de auditora, soporte y
distribucin de salidas.
Diseo Lgico
Es aquel que representa los componentes del sistema y sus relaciones
mutuas, como se mostrara ante el usuario. Muestra lo que la solucin sistemtica
har en contraposicin con el modo como lo es en la actualidad impactada
fsicamente. Tambin describe las entradas y salidas, las funciones de
procesamiento a realizar, los procedimientos de negocios, los modelos de datos y
los controles.
El diseo lgico de sistemas se refiere a lo que har el nuevo sistema, el diseo
lgico es una descripcin de los requisitos funcionales de un sistema.
El diseo lgico incluye planear el propsito de cada elemento del sistema, sin
relacin con consideraciones de hardware y software.
Especificaciones del diseo lgico
Diseo de salida: Es una descripcin de todas las salidas del sistema e incluye
sus tipos, formato, contenido y frecuencia.

Diseo de entrada: Una vez que se completa el diseo de salidas, puede

iniciarse el de entradas. En ste se especifican los tipos, formato, contenido
sistema capture los nmeros telefnicos de los clientes cuando stos llaman a la
organizacin y use tal dato para buscar de manera automtica la informacin de
su cuenta, es una especificacin de diseo lgico.
Diseo

de

procesamiento:

Los

tipos

de

clculos,

comparaciones

manipulaciones de datos en general que requiere el sistema se determinan

durante esta fase.
Diseo de archivos y bases de datos: En muchos sistemas de informacin se
requieren subsistemas de archivos y bases de datos. Las caractersticas de estos
subsistemas se especifican tambin en la fase de diseo lgico.
Diseo de telecomunicaciones: Durante el diseo lgico es necesario
especificar los sistemas de redes y telecomunicaciones.
A partir de estos requisitos, podra optarse por una topologa hbrida. Los
programas de grficos y las herramientas de CASE son tiles para facilitar el
diseo de redes lgicas.
Diseo

de

procedimientos:

Lo

dos

sistema

de

informacin

requiere

procedimientos para la ejecucin de aplicaciones y la solucin de los problemas

que surjan. Estos requisitos importantes se capturan durante el diseo de
procedimientos. Una vez diseados, los procedimientos se pueden describir con
programas de procesamiento de texto.
Diseo de controles y seguridad: Otra parte importante del diseo lgico es
determinar la frecuencia y caractersticas necesarias de los sistemas de respaldo.
En general, debe tenerse apoyo de todo, lo que incluye el hardware, software,
datos, personal, insumos e instalaciones.
Diseo de personal y empleos: Algunos sistemas requieren contratar empleados
adicionales, mientras que con otros es necesario modificar las tareas relacionadas
con uno o ms empleos de SI existentes. Los nombres y descripciones de los

puestos se especifican durante el diseo de personal y empleos. Los

organigramas son tiles en el diseo de personal para diagramar los empleos y
sus nombres.
1.2 Conceptos del diseo de sistemas.
El diseo del sistema es la estrategia de alto nivel para resolver problemas
y construir una solucin. El Diseo de Sistemas se define el proceso de aplicar
ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o
un Sistema, con suficientes detalles como para permitir su interpretacin y
realizacin fsica.
La etapa del diseo del Sistema encierra cuatro etapas:
El diseo de los datos
Trasforma el modelo de dominio de la informacin, creado durante el
anlisis, en las estructuras de datos necesarios para implementar el Software.
El diseo Arquitectnico
Define la relacin entre cada uno de los elementos estructurales del programa.
El diseo de la Interfaz
Describe como se comunica el Software consigo mismo, con los sistemas
que operan junto con el y con los operadores y usuarios que lo emplean.
El diseo de procedimientos
Transforma elementos estructurales de la arquitectura del programa. La
importancia del Diseo del Software se puede definir en una sola palabra Calidad,
dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la
nica manera de materializar con precisin los requerimientos del cliente.

El diseo del Software

Es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de
pasos repetitivos que permiten al diseador describir todos los aspectos del
Sistema a construir.
El diseo debe implementar todos los requisitos explcitos contenidos en el
modelo de anlisis y debe acumular todos los requisitos implcitos que desea el
cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y los
que prueban y mantienen el Software.
El Diseo debe proporcionar una completa idea de lo que es el Software,
enfocando los dominios de datos, funcional y comportamiento desde el punto de
vista de la Implementacin.
Para evaluar la calidad de una presentacin del diseo, se deben
establecer criterios tcnicos para un buen diseo como son:
Un diseo debe presentar una organizacin jerrquica que haga un uso
inteligente del control entre los componentes del software.

El diseo debe ser modular, es decir, se debe hacer una particin lgica del
Software en elementos que realicen funciones y subfunciones especificas.
Un diseo debe contener abstracciones de datos y procedimientos.
Debe producir mdulos que presenten caractersticas de funcionamiento
independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones
entre los mdulos y el entorno exterior.

Debe producir un diseo usando un mtodo que pudiera repetirse segn la

informacin obtenida durante el anlisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseo del
Software exige buena calidad a travs de la aplicacin de principios
fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva.
Cuando se va a disear un Sistema de Computadoras se debe tener
presente que el proceso de un diseo incluye, concebir y planear algo en la mente,
as como hacer un dibujo o modelo o croquis.
1.2.1 Acoplamiento y coherencia.
Cohesin
Grado de relacin entre los elementos de un modulo. Si evaluamos el
acoplamiento y la cohesin nos puede dar la calidad de un buen sistema de
informacin.
Tipos de Cohesin:
Cohesin funcional: Los elementos de la unidad de software estn relacionados
en el desarrollo de una nica funcin, es el criterio de agrupacin ms deseable.
Probablemente haya entre las unidades un acoplamiento relativamente alto, por lo
tanto es conveniente que estn juntas.
Cohesin secuencial: Una unidad de software realiza distintas tareas en
secuencia, de forma que las entradas de cada tarea son las salidas de la tarea
anterior, se agrupan las unidades que cumplen que los resultados o salidas que
produce una sirven como entrada para que la prxima contine trabajando.
Cohesin comunicacional o de datos: La unidad de software realiza actividades
paralelas usando los mismos datos de entrada y salida.
Cohesin procedimental: La unidad de software tiene una serie de funciones
relacionadas por un procedimiento efectuado por el cdigo.

Cohesin lgica: Cuando las unidades de software agrupadas realizan un trabajo

en una misma categora lgica, pero no necesariamente tienen relacin entre s.
Cohesin temporal: Los elementos de la unidad de software estn implicados en
actividades relacionadas con el tiempo.
Cohesin casual o coincidente: Los elementos de la unidad de software
contribuyen a las actividades relacionndose mutuamente de una manera poco
significativa.
Qu ocurre en el caso de la cohesin?
La cohesin de un componente mide la identidad de su comportamiento.
La cohesin no es buena cuando nos encontramos con que hay operaciones con
un objetivo junto a otras con otro objetivo dentro de un mismo componente, cuya
definicin funcional es una y clara.
Acoplamiento
Grado de interdependencia entre las unidades de software (mdulos, funciones,
subrutinas, bibliotecas, etc.) de un sistema informtico. El acoplamiento da la idea
de lo dependiente que son las unidades de software entre s, es decir, el grado en
que una unidad puede funcionar sin recurrir a otras.
El bajo acoplamiento permite:
Mejorar la mantenibilidad de las unidades de software.
Aumentar la reutilizacin de las unidades de software.
Evitar el efecto onda, ya que un defecto en una unidad puede propagarse a otras,
haciendo incluso ms difcil de detectar dnde est el problema.
Minimiza el riesgo de tener que cambiar mltiples unidades de software cuando se
debe alterar una.

El acoplamiento, junto con la modularidad, la cohesin y otros factores, permiten

mejorar la programacin y el diseo de sistemas informticos y aplicaciones, y son
cruciales en el incremento de la reutilizacin de los cdigos.
Tipos de acoplamiento
Acoplamiento normal: una unidad de software llama a otra de un nivel inferior y
tan solo intercambian datos. Dentro de este tipo de acoplamiento podemos
encontrarnos 3 subtipos, dependiendo de los datos que intercambien las unidades
de.software.
Acoplamiento externo: las unidades de software estn ligadas a componentes
externos, como por ejemplo dispositivos de entrada/salida, protocolos de
comunicaciones,etc.
Acoplamiento comn: dos unidades de software acceden a un mismo recurso
comn, generalmente memoria compartida, una variable global o un fichero.
Acoplamiento de contenido: ocurre cuando una unidad de software necesita
acceder a una parte de otra unidad de software.
Qu quiere decir reducir el acoplamiento?
Bsicamente, lo ms importante es saber definir las responsabilidades de cada
componente para garantizar que la dependencia sea funcional o arquitectnica, no
de implementacin.
En el caso de acoplamiento funcional, est bien que un componente de clculo de
probabilidades dependa de un componente de clculo matemtico bsico, en el
caso de acoplamiento arquitectnico, se puede ver un ejemplo en el esquema
MVC (modelo-vista-controlador). La capa del modelo realizar cambios de
acuerdo con los parmetros que recibe del controlador

Dentro del acoplamiento podemos encontrarnos tres subtipos, dependiendo de los

datos que intercambien las unidades de software:
De datos: Cuando existe conexin entre los mdulos y la comunicacin es a
travs de estructuras de datos simples (variables).
Se envan datos simples y se devuelven simples.
Estampado: Estn conectados y la comunicacin es a travs de estructuras de
datos compuestas (registros).
Se envan datos compuestos y devuelve simples.
Como el segundo modulo retorna datos simples la relacin es de datos y
estampado. En estos casos se toma el de mayor acoplamiento. En ese caso sera
estampado.
De control: Estn conectados y la comunicacin es a travs de un indicador, flag
o seal a partir de la cual se pueden tomar decisiones en el modulo subordinado o
superior.
La desventaja es que hay mucha relacin entre los mdulos, depende mucho uno
de otro.
El modulo subordinado, debe saber que opcin le manda el superior. El modulo
subordinado no le puede informar al superior que datos debe enviarle.
El objetivo final del diseo de software (o soluciones informticas) en materia de
estos dos conceptos es: Reducir al mximo el acoplamiento entre componentes y
aumentar la cohesin interna de cada componente.

1.2.2 Arquitectura del software.

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.
La arquitectura de software define, de manera abstracta, los componentes
que llevan a cabo alguna tarea de computacin, sus interfaces y la comunicacin
ente ellos. Toda arquitectura debe ser implementable en una arquitectura fsica,
que consiste simplemente en determinar qu computadora tendr asignada cada
tarea.
La Arquitectura del Software es el diseo de ms alto nivel de la estructura de un
sistema.

1.3 Heursticas de diseo.

Heurstica de diseo: Las heursticas de diseo son un conjunto de datos que
ayudan a mejorar la estructura del sistema, optimizando la secuencia.
Tamao de mdulo: El tamao del mdulo est relacionado con la modularidad,
ms no solo de manera simple de "cortar en programa en ms piezas". Esto es, la
modularidad tcnica no se incrementa simplemente cuando el tamao de mdulo
decrece, mientras otros aspectos permanecen igual.
Normalmente, mdulos menores a cinco a nueve lneas, deben considerarse para
un replanteo. Esto es especialmente relevante cuando existen muchos de estos
mdulos muy pequeos en el sistema.
No siempre mdulos muy grandes o muy pequeos son necesariamente malos. La
cuestin importante es que los mdulos reflejen la estructura del problema lo ms
fielmente posible.
Descomponer un mdulo simplemente para llevarlo a un tamao ptimo, an
perdiendo su significado con respecto a la estructura del problema, no es una
buena estrategia.
Un mdulo demasiado grande a menudo puede deberse a dos razones
principales:
Una factorizacin incompleta en mdulos subordinados apropiados.
Dos o ms funciones han sido combinadas (frecuentemente con cohesin
lgica) en un mismo mdulo.

En el primer caso, se puede realizar una reduccin a travs de la identificacin y

extraccin de subfunciones.

En el segundo caso, podemos descomponer el mdulo en sus funciones

constitutivas.

En cualquier caso, los diagramas de estructura pueden usarse como

herramienta, y las modificaciones estructurales deben probarse sobre papel.
Cuando tratamos con mdulos muy pequeos, debemos distinguir dos casos:
El mdulo atmico (nivel ms bajo) y modulo atmico.

En el caso de mdulos atmicos, las cuestiones a considerar son: la cantidad de

llamadas desde mdulos superiores que recibe el mdulo (fan-in), y la sobrecarga
(overhead) producido por el proceso de llamada a subrutina.

Un mdulo muy pequeo puede ser comprimido en sus mdulos superiores.

Pero si el mdulo tiene usos mltiples (alto fan-in) puede ser muy peligroso
absorberlo en sus mdulos superiores, porque se duplicar el esfuerzo de
implementacin y mantenimiento del mismo.
En el caso de que la sobrecarga producida por el mecanismo de llamada a
subrutina

sea

intolerable,

se

puede

testear

depurar

el

mdulo

independientemente
Cuando el mdulo es no atmico, el anlisis es ms complicado. Las opciones son
comprimir el mdulo hacia arriba en su superior, o hacia abajo en un subordinado.
Ambas opciones deben ser consideradas.
Un caso especial es el llamado mdulo fantasma, un mdulo que lo nico que
contiene son llamadas a otros mdulos subordinados.
Amplitud del Control (Fan-out)

La amplitud del control o ancho de salida (fan-out), es el nmero de subordinados

inmediatos de un mdulo. Al igual que en con el tamao de mdulo, amplitudes de
control muy altas o muy bajas, son indicadores de un posible diseo pobre.
Una amplitud de control demasiado baja puede incrementarse en la mayora de
los casos descomponiendo el mdulo en subfunciones subordinadas adicionales,
o comprimiendo el mdulo en sus superiores.
Una amplitud de control demasiado alta puede ser un indicativo de una reticencia
por parte del diseador a delegar responsabilidades en mdulos subordinados. Sin
embargo en la mayora de los casos, esto proviene de estructuras "panqueque" o
fallas en la definicin de niveles intermedios. Para solucionar este problema, debe

considerarse la posibilidad de agruparse varios subordinados en una funcin

combinada.
Ancho de Entrada (Fan-In)

Siempre que sea posible, desearemos maximizar el ancho de entrada de un

mdulo (fan-in) durante el proceso de diseo. Cada instancia de mltiples
entradas de un mdulo, representa que ha podido evitarse duplicidad de cdigo.
Sin embargo, un gran ancho de entrada no es algo que deba buscarse a cualquier
costo. Por ejemplo, es ridculo combinar muchas funciones "no relacionadas" en
un mdulo bajamente cohesivo, con el propsito de incrementar el fan-in.
Un gran ancho de entrada es alcanzado a travs de un proceso analtico que
acompaa los pasos del proceso de diseo estructurado. Cada vez que vamos a
dibujar un nuevo mdulo en el diagrama de estructura, primero debemos verificar
si no existe ya algn otro mdulo que realice la funcin requerida.
Es importante notar que la especificacin del fan-in es una tarea del diseador, no
del implementador (codificador).
La clave est en comprender cual es la parte comn de ambos mdulos, y aislarlo
en un nuevo mdulo. Por ejemplo, supongamos que tenemos una funcin Q1 que
parece ser similar a Q2. Si Q es la parte comn de ambas funciones, podemos
reestructurar

nuestro

diseo

de

la

siguiente

manera:

Alcance de Efecto / Alcance de Control

Cada decisin o sentencia condicional (if-then-else) en un sistema tiene algunas

consecuencias: ciertos procesos se realizarn o no como resultado de una
decisin. Equivalentemente podemos decir que cierto procesamiento es
condicional en base a la salida o resultado de una decisin.
El alcance de efecto de una decisin es la coleccin de todos los mdulos que
contienen algn procesamiento que est condicionado por dicha decisin.
Aunque solo una pequea parte del procesamiento de un mdulo se vea afectada
por la decisin. Si la activacin de un mdulo completo est condicionada por la
decisin, el mdulo superior (invocador) tambin se incluye dentro del alcance de
efecto.
El alcance de control de un mdulo es el mdulo mismo y todos sus subordinados.
El alcance de control es un parmetro puramente estructural independiente de las
funciones del mdulo.
Todos los mdulos que son afectados o influenciados por una determinada
decisin deben estar subordinados finalmente al mdulo que toma la decisin.
La toma de decisiones y la estructura modular se interrelacionan mejor cuando las
decisiones se toman a un nivel no ms alto que lo necesario dentro de estructura
jerrquica, con el objetivo de ubicar el alcance de efecto dentro del alcance de
control.

2 Diseo de sistemas.
2.1 Modelo estructurado.
El Anlisis Estructurado, fue seleccionado como tcnica de investigacin de
requerimientos, ya que permite al analista conocer el sistema o proceso en una
forma lgica y manejable, al mismo tiempo que proporciona la base para asegurar
que no se omite ningn detalle.
Este es un mtodo para el anlisis de sistemas manuales o automatizados, que
conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar
modificaciones a los ya existentes.
Aunado a ello y por ser considerados como una herramienta capaz de describir y
analizar el movimiento de los datos a travs de un sistema, la representacin
grfica de los procesos del sistema estar a cargo de los Diagramas de Flujos de
Datos (DFD).
Que se relacionan con el Anlisis Estructurado
Smbolos grficos: iconos y convenciones para identificar y describir los
componentes de un sistema junto con las relaciones entre estos componentes.
Diccionario de datos; descripciones de todos los datos utilizados en el sistema.
Descripciones de procesos y procedimientos; declaraciones formales que
emplean tcnicas y lenguajes que permiten a los analistas describir actividades
importantes que forman parte del sistema.
Reglas; estndares para describir y documentar el sistema en forma correcta y
completa.

Fase de diseo:
En esta fase, el diseo estructurado produce el modelo de diseo con los
siguientes elementos:
Diseo de datos: Transforma el modelo de dominio de la informacin creado
durante el anlisis, en las estructuras de datos necesarias para implementar el
software. Los objetos de datos y las relaciones definidas en el diagrama entidadrelacin y el contenido detallado de datos del diccionario de datos constituyen la
base para el diseo de datos.
Diseo arquitectnico: Define la relacin entre los principales elementos
estructurales del programa. Se obtiene a partir del modelo de anlisis y de la
interaccin de subsistemas definidos dentro del modelo de anlisis.
Diseo de interfaz: Describe como se comunica el software consigo mismo, con
los sistemas que operan con l y con los operadores que lo emplean. Los
diagramas de flujo de datos y control proporcionan la informacin necesaria para
el diseo de la interfaz.
Diseo procedimental: Transforma elementos estructurales de la arquitectura del
programa en una descripcin procedimental de los componentes del software. Se
obtiene a partir de la especificacin del proceso, la especificacin del control y el
diagrama de transicin de estados.
Componentes:
Smbolos grficos: Identifica y describe los componentes de un sistema y las
relaciones entre estos.
Diccionarios de datos: Describe todos los datos utilizados en el sistema pueden
ser manual o automatizado.
Descripciones de procesos y procedimientos: descripcin tcnica para
describir las actividades que se realizan los procesos.

Reglas: Pasos a seguir para describir y documentar el ven forma correcta y

completa.
Herramientas:
Diagrama de flujo de datos: Es la base para otros componentes y describe como
navegan los datos entre procesos y elementos relacionados.
Diccionario de datos: Contiene las caractersticas de los campos y/o descripcin
detallada de los diferentes objetos que componen el sistema
Diagrama de estructuras de datos: describe la relacin entre las entidades y los
objetos (conjunta de informacin que contienen las entidades)
Diseo del sistema
El uso de los Diagramas de Flujos de Datos (DFDs), es una herramienta que
permite mostrar grficamente y de manera general, el funcionamiento del sistema
y los procesos necesarios para su desarrollo.
Los DFDs se pueden dibujar con slo cuatro notaciones sencillas, en este caso, la
notacin utilizada est basada en el enfoque de Gane y Sarson.
Origen/Destino de Datos: Representan entidades externas al sistema que se
comunican con l y que estn fuera de su control. Las relaciones existentes entre
las entidades no se representan en el DFD, ya que no son parte del sistema bajo
estudio.
Para este diseo forman parte de las entidades los Justiciables, la cual incluye a
todas aquellas personas que tienen relacin directa con el proceso. Las entidades
Secretaria, Juez y Asistente, quienes conforman al rgano jurdico y son los
garantes de llevar a cabo el proceso judicial.
Procesos: Muestran la parte del sistema que transforma las entradas de datos en
salida; en tal sentido, el diagrama (DFD Propuesto) muestra cinco (5) procesos
considerados vitales para el funcionamiento y operatividad de la aplicacin:

Solicitar Copias Certificadas: en el cual se supervisa que las solicitudes a

procesar estn conforme a los requisitos establecidos por el Cdigo de
Procedimiento Civil, o alguna otra Ley que condicione la puesta en marcha de
stas.
Verificar existencia de actas en el sistema: en el se constata que el acta que
tiene relacin con la copia certificada solicitada est o no en los archivos del
circuito y de ese modo se tenga acceso directo a l.
Generar copias certificadas: encargado de procesar los reportes generados por
el sistema, en este caso la emisin directa de las Copias Certificadas solicitadas.
Registro automtico de libros: en l se almacena una serie de datos
proveniente del procesamiento de las solicitudes.
Firmar y sellar actas: Proceso manual que se limita a autenticar las Copias
Certificadas previa su entrega al solicitante.
Flujo de datos: El flujo describe el movimiento de paquetes de datos que viajan
desde una parte del sistema a otra. Estn representados por una flecha para
mostrar su origen y su destino.
Almacn: Representa una coleccin de paquetes de datos que permanecen en
estado de reposo.
2.2 Modelo orientado a objetos.
Las tcnicas orientadas a objetos pretenden satisfacer tanto las necesidades de
los usuarios finales como las de los desarrolladores de software mediante una
cierta capacidad de modelar el mundo real.
El Modelado y Diseo Orientado a Objetos se funda en pensar acerca de
problemas a resolver empleando modelos que se han organizado tomando como
base conceptos del mundo real.

La unidad bsica es el objeto que combina las estructuras de datos con los
comportamientos en una entidad nica.
La fase de anlisis determina lo que debe hacer la implementacin y la fase de
diseo del sistema determina el plan de ataque.
La fase de diseo de objetos determina las definiciones completas de las clases y
asociaciones que se utilizarn en la implementacin, as como las interfaces y
algoritmos de los mtodos utilizados para implementar las operaciones. La fase de
diseo de objetos aadir objetos internos para la implementacin
Aspectos generales del diseo de objetos
Durante el diseo de objetos, se ejecuta la estrategia seleccionada durante el
diseo del sistema y se rellenan los detalles.
Se produce un desplazamiento del nfasis pasando de los conceptos del dominio
de la aplicacin a los propios de las computadoras.
. Las clases, atributos y asociaciones del anlisis deben de implementarse en
forma de estructuras de datos especficas.
Es necesario introducir nuevas clases de objetos para almacenar resultados
intermedios durante la ejecucin del programa y para evitar la necesidad de
recalcularlos.
La optimizacin del diseo no debera llevarse a extremos exagerados porque la
facilidad de implementacin y mantenimiento y la extensibilidad son tambin
objetivos importantes.
La Metodologa OMT se extiende desde el anlisis hasta la implementacin
pasando por el diseo.
En este modelo se toman decisiones importantes que despus se completan para
optimizar la implementacin en segundo lugar. Los objetos del dominio de la

aplicacin constituyen el marco de trabajo del modelo de diseo, pero se

implementan en trminos de objetos del dominio de la computadora.
Por ltimo, el modelo de diseo se implementa en algn lenguaje de
programacin, base de datos o hardware.
Tipos de modelos
Modelo de Objetos
Describe la estructura esttica (de datos), de los objetos del sistema (identidad,
atributos y operaciones) y tambin sus relaciones. El modelo de objetos contiene
diagramas de objetos.
Un diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos
arcos son relaciones entre las clases.
El diagrama contiene clases de objetos organizados en jerarquas que comparten
una estructura y comportamiento comunes y que estn asociadas a otras clases.
Estas clases definen los atributos que lleva cada instancia de objeto y las
operaciones que efecta o sufre cada uno.
Modelo dinmico
Describe los aspectos de comportamiento (de control) de un sistema que cambian
con el tiempo. El modelo dinmico se utiliza para especificar e implementar los
aspectos del control del sistema.
Los modelos dinmicos contienen diagramas de estados. Un diagrama de estados
es un grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados
causadas por sucesos o eventos.
Se especifican en este modelo la temporizacin y secuencia de operaciones
(sucesos que marcan los cambios, secuencias de sucesos, estados que definen el
contexto para los sucesos), y la organizacin de sucesos y de estados.

El modelo dinmico captura el control, aquel aspecto de un sistema que describe

las secuencias de operaciones que se producen sin tener en cuenta lo que hagan
las operaciones, aquello a lo que afecten o la forma en la que estn
implementadas.
Modelo funcional
Describe las transformaciones (de funcin), de valores de datos que ocurren
dentro del sistema, captura lo que hace el sistema, independientemente de
cuando se haga o de la forma en que se haga.

El modelo funcional contiene diagramas de flujo de datos. Un diagrama de flujo de

datos es un grafo cuyos nodos son procesos y cuyos arcos son flujos de datos, se
muestra las dependencias entre los valores y el clculo de valores de salida a
partir de los de entrada y de funciones, sin considerar cuando se ejecutan las
funciones, ni siquiera si llegan a ejecutarse.

Las funciones se invocan como acciones en el modelo dinmico y se muestran

como operaciones que afectan a objetos en el modelo de objetos.
2.3 Modelo basado en componentes.
Un componente es una pieza de cdigo pre elaborado que encapsula alguna
funcionalidad expuesta a travs de interfaces estndar.
El paradigma de ensamblar componentes y escribir cdigo para hacer que estos
componentes funcionen se conoce como Desarrollo de Software Basado en
Componentes.
Desarrollo basado 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 a la 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 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.
Beneficios del desarrollo de Software basado en componentes
El uso de este paradigma posee algunas ventajas:
Reutilizacin del software. Nos lleva a alcanzar un mayor nivel de reutilizacin de
software.
Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada
uno de los componentes antes de probar el conjunto completo de componentes
ensamblados.
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.

 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.
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.
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.
Ventajas:
El anlisis del riesgo se hace de forma explcita y clara. Une los mejores
elementos de los restantes modelos. - Reduce riesgos del proyecto - Incorpora
objetivos de calidad - Integra el desarrollo con el mantenimiento

Desventajas:
Genera mucho tiempo en el desarrollo del sistema - Modelo costoso Requiere
experiencia en la identificacin de riesgos.
Inconvenientes:
Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y
coste dentro de la empresa. Exige una cierta habilidad en los analistas (es
bastante difcil).

2.4 Diseo de la Arquitectura del software.

Para poder entender el diseo, es necesario comprender que es la arquitectura de
software.
Diseo de software:
El diseo se ha descrito como un proceso multifase en el que se sintetizan
representaciones de la estructura de los datos, la estructura del programa, las
caractersticas de la interfaz y los detalles procedimentales desde los requisitos de
la informacin.
El diseo:
Una actividad en la que se toman decisiones importantes, frecuentemente de
naturaleza estructural. Comparte con la programacin un inters por la
abstraccin de la representacin de la informacin y de las secuencias de
procesamiento, pero el nivel de detalle es muy diferente en ambos casos.
Se considera que:
El diseo est dirigido por la informacin. Los mtodos de diseo del software se
obtienen del estudio de cada uno de los tres dominios del modelo de anlisis:
La arquitectura de software de un sistema de programa o computacin es la
estructura de las estructuras del sistema, la cual comprende los componentes del
software, las propiedades de esos componentes visibles externamente, y las
relaciones entre ellos.
La arquitectura no es el software operacional, Ms bien, es la representacin que
capacita al ingeniero del software para:
Analizar la efectividad del diseo para la consecucin de los requisitos fijados,

Considerar las alternativas arquitectnicas en una etapa en la cual hacer cambios

en el diseo es relativamente fcil, y
Reducir los riesgos asociados a la construccin del software.

Por qu es

importante la arquitectura?

Facilitan la comunicacin entre todas las partes interesadas en el desarrollo de un

sistema basado en computadora.
Destaca decisiones tempranas de diseo que tendrn un profundo impacto en
todo el trabajo de ingeniera del software.
Constituye un modelo relativamente pequeo e intelectualmente comprensible de
cmo est estructurado el sistema y de cmo trabajan juntos sus componentes.
El diseo de la arquitectura del software tiene en cuenta 2 niveles de la pirmide,
el diseo de datos y el diseo arquitectnico.
El diseo de datos nos facilita la representacin de los componentes de datos de
la arquitectura.
El diseo arquitectnico se centra en la representacin de la estructura de los
componentes del software, sus propiedades e interacciones.
En el contexto del diseo arquitectnico:
Un componente del software puede ser tan simple como un mdulo de programa,
pero tambin puede ser algo tan complicado como incluir bases de datos y
software intermedio middleware) que permiten la configuracin de una red de
clientes y servidores
El diseo arquitectnico se centra en la representacin de la estructura de los
componentes del software, sus propiedades e interacciones.

Ejemplo de un diseo arquitectnico:

Por qu es importante la arquitectura?

Las representaciones de la arquitectura de software facilitan la comunicacin entre
todas las partes (partcipes) interesadas en el desarrollo de un sistema basado en
computadora.
El modelo de diseo arquitectnico y los patrones arquitectnicos contenidos
dentro son transferibles.
Estilos arquitectnicos
Cada estilo describe una categora del sistema que contiene: un conjunto de
componentes, que realiza una funcin requerida por el sistema, un conjunto de
conectores que posibilitan la comunicacin, la coordinacin y la cooperacin entre
los componentes; restricciones que definen como se puede integrar los
componentes que forman el sistema
Arquitecturas centradas a datos
En el centro de esta arquitectura se encuentra un almacn al que otros
componentes acceden con frecuencia para actualizar, aadir, borrar o modificar
los datos del almacn. El software del cliente accede a l almacn central, es decir
accede a lo datos independientes de cualquier cambio en los datos o de las
acciones de de cliente.
Arquitectura de programa principal: Clasifica de programacin descompone las
funciones en una jerarqua de control donde un programa principal llama a un

nmero de componentes del programa, los cuales pueden tambin llamar a otros
componentes.
Arquitectura de llamada de procedimiento remoto: Los componentes de una
arquitectura de programa principal/subprograma, estn distribuidos entre varias
computadoras en una red.
Arquitecturas orientadas a objetos: Los componentes de un sistema
encapsulan los datos y las operaciones que se deben realizar para manipular los
datos. La comunicacin y la coordinacin entre componentes se consiguen a
travs del paso de mensaje.
Arquitecturas Estratificadas: Se crean diferentes capas y cada una realiza
operaciones que progresivamente se aproximan mas al cuadro de instrucciones
de la mquina. En la capa externa, los componentes sirven a las operaciones de
interfaz de usuario. En la capa interna, los componentes realizan operaciones de
interfaz del sistema. Las capas intermedias proporcionan servicios de utilidad y
funciones de software de aplicaciones.
Complejidad arquitectnica: Para evaluar la complejidad total de una
arquitectura dada una tcnica consiste en consideran las relaciones de
dependencias entre los componentes de la arquitectura.
Existen tres tipos de dependencias:
Dependencias de compartimiento: Representan las relaciones de dependencia
entre los consumidores que utilizan los mismos recursos o los productores que
producen para los mismos consumidores.
Dependencias de flujo: Representan las relaciones de dependencias entre los
productores y los consumidores de recursos.

Dependencias restrictivas: Representan las restricciones de un relativo flujo de

control entre un cuadro de actividades.
Flujo de transformacin
La informacin debe introducirse y obtenerse del software en forma de mundo
exterior, la informacin entra en el sistema a lo largo de caminos que transforman
los datos externos a un formato interno. Estos caminos se identifican como flujo de
entrada. La informacin entrante se pasa a travs de un centro de transformacin
y empieza a moverse a lo largo de caminos que ahora conducen hacia fuera, los
datos que se mueven a lo largo de este camino se denominan flujo de salida.
Flujo de transaccin
El flujo de transaccin se caracteriza por datos que se mueven a lo largo de un
camino de entrada que convierte la informacin del mundo exterior en una
transaccin. La transaccin se evala y, basndose en ese valor, se inicia el flujo
a lo largo de uno de muchos caminos de accin. El centro de flujo de informacin
del que parten muchos de los caminos de accin se denomina centro de
transaccin.
Diseo de datos
El diseo de datos (a veces llamado arquitectura de datos) crea un modelo de
datos y/o informacin que se representa con un alto nivel de Abstraccin (la visin
de datos del cliente/usuario).
Este modelo de datos, es refinado en progresivas representaciones especficas de
la implementacin, que pueden ser procesadas por un sistema basado en
computadora.
Al nivel de los componentes del programa, el diseo de las estructuras de datos y
de los algoritmos asociados requeridos para su manipulacin, son la parte

esencial en la creacin de aplicaciones de alta calidad. Al nivel de aplicacin, la

traduccin de un modelo de datos en una base de datos es el punto clave para
alcanzar los objetivos de negocio del sistema. Al nivel de negocios, el conjunto de
informacin almacenada en las diferentes bases de datos y reorganiza en el
almacn de datos facilita la minera de datos o el descubrimiento de conocimiento
que puede influir en el prximo xito del negocio
Un almacn de datos es un entorno de datos separado, que no est directamente
integrado con las aplicaciones del da a da, pero que abarca todos los datos
utilizados por una empresa.
Caractersticas de un almacn de base de datos:
Orientacin por materia: Esto nos lleva a una exclusin de datos que podran ser
necesarios para una funcin particular del negocio.
Integracin: Sin tener en cuenta la fuente de datos, da consistencia nombrar
convenciones, unidades y medidas, estructuras de codificacin y atributos fsicos.
Restriccin de tiempo: Para un entorno aplicacin orientado a transaccin, los
datos son precisos en el momento del acceso y por un perodo de tiempo pequeo
(60 a 90 das) antes del acceso. En un almacn de datos se accede a los datos en
un momento especfico de tiempo.
No volatilidad: En el almacn de datos, los datos se cargan, pero despus de la
primera transferencia, los datos no cambian.
Modelo de datos
Este modelo de datos, es entonces refinado en progresivas representaciones
especficas de la implementacin, que pueden ser procesadas por un sistema
basado en computadora.

En muchas aplicaciones de software, la arquitectura de datos tendr una gran

influencia sobre la arquitectura del software que debe procesarlo.
Diseo de datos a nivel de componentes
Se centra en la representacin de estructuras de datos a las que se accede
directamente a travs de uno o ms componentes del software.
Principios para la especificacin de los datos:
Los principios del anlisis sistemtico aplicado a la funcin y al comportamiento
deberan aplicarse tambin a los datos.
Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de
ellas deberan estar claramente identificadas.
Se debera establecer un diccionario de datos y usarlo para definir el diseo de
los datos y del programa
Las decisiones de diseo de datos de bajo nivel deberan dejarse para el final del
proceso de diseo.
La representacin de las estructuras de los datos deberan conocerla solo
aquellos mdulos que deban hacer uso directo de los datos contenidos dentro de
la estructura.
Deberan desarrollarse una biblioteca de estructuras de los datos tiles y de las
operaciones que se les pueden aplicar.
Un diseo del software y un lenguaje de programacin debera soportar la
especificacin y realizacin de los tipos abstractos de datos.

2.5 Diseo de Interfaz de usuario.

El diseo de interfaces de usuario es una tarea que ha adquirido relevancia en el
desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los
motivos que conduzca a un sistema al xito o al fracaso.
La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de
elementos hardware y software de una computadora que presentan informacin al
usuario y le permiten interactuar con la informacin y con el computadora.
Tambin se puede considerar parte de la IU la documentacin (manuales, ayuda,
referencia, tutoriales) que acompaa al hardware y al software. Si la IU est bien
diseada, el usuario encontrar la respuesta que espera a su accin. Si no es as
puede ser frustrante su operacin, ya que el usuario habitualmente tiende a
culparse a s mismo por no saber usar el objeto.
Los programas son usados por usuarios con distintos niveles de conocimientos,
desde principiantes hasta expertos. La presentacin es lo que primero capta la
atencin del usuario
La presentacin no es lo ms relevante y un abuso en la misma (por ejemplo, en
el color) puede ser contraproducente, distrayendo al usuario.
La segunda parte del modelo define las tcnicas de interaccin del usuario, a
travs de diversos dispositivos. La tercera es la ms importante, y es donde el
diseador determina la metfora adecuada que encaja con el modelo mental del
usuario. El modelo debe comenzar por esta parte e ir hacia arriba.
Una vez definida la metfora y los objetos del interfaz, los aspectos visuales
saldrn de una manera lgica y fcil.

Produccin de prototipos preliminares y dilogos

El propsito de la interfaz es muy simple: recoger de los usuarios la informacin

del sistema y ponerla a disposicin de otros usuarios. La informacin recogida se
llama entrada del sistema y se almacena en la base de datos para ponerla a
disposicin de los dems usuarios. La informacin suministrada se llama salida del
sistema. Es decir, el diseo de interfaces cubre tanto las entradas como las
salidas. Las entradas y salidas pueden ser interactivas o por lotes.
En el caso de entradas o salidas no interactivas, es decir, por lotes, las
transacciones se renen en formularios en el punto de recepcin y despus se
introducen en el ordenador al mismo tiempo.
Estas transacciones se procesan y un tiempo despus se producen las salidas, las
cuales se pasan al usuario
El diseo de interfaz interactivo provoca un dilogo hombre-mquina que permite
un intercambio rpido de informacin entre los ordenadores y sus usuarios
humanos, mientras que la interfaz no interactiva utiliza un soporte de papel para
contener la informacin en el que las entradas normalmente se realizan en

formularios especialmente diseados y las salidas se producen en un listado

impreso.
Entre los aspectos a considerar en los formatos de pantalla se destacan:
encabezamiento, cuerpo principal, pie, teclas de funcin, teclas de ayuda y lneas
de visualizacin de los mensajes de ayuda.

Ergonoma del diseo de la interfaz

El viaje al mundo del diseo de pantallas comienza con una discusin con el
usuario, la parte ms importante de cualquier sistema informatizado
Para realizar un buen trabajo, la interfaz con el ordenador debe ser, entre otras
cosas, lo ms fcil, amigable y agradable posible, y se debe usar un dilogo que
se acerque al lenguaje natural en vez de la jerga informtica.
Entre las consideraciones a tener cuenta a la hora de disear pantallas se
encuentran las siguientes:
Caractersticas deseadas: simplicidad, claridad y fcil de comprender. Ser
necesario tener claridad visual, de forma que los elementos estn agrupados de
forma comprensible y con significado en vez de al azar y de forma confusa.

Saber dnde situar la informacin en la pantalla: Ser necesario indicar un punto de

partida obvio en la esquina superior izquierda de la pantalla, reservar reas
especficas de pantalla para diferentes tipos de informacin (como, por ejemplo,
mandatos, mensajes de error, ttulos y campos de datos, de forma que esta consistencia
se mantenga en todas las pantallas) y proporcionar una composicin que guste
visualmente (es decir, que est balanceada, sea simtrica, sea predecible, secuencial,
simple, con agrupamientos, etc.).

Saber qu informacin situar en la pantalla: Para ello, hay que poner slo la
informacin que es esencial para la toma de una decisin o para la ejecucin de
una accin (No inundar al usuario con informacin!) y poner todos los datos
relacionados con una tarea en una nica pantalla (as el usuario no tiene que
recordar datos de una pantalla a otra).
Saber cmo situar la informacin en la pantalla: As, en cuanto a las fuentes de
letras, se recomienda utilizar minsculas para el texto con la letra inicial de la frase
en maysculas; para las etiquetas, encabezamientos o subttulos utilizar
maysculas.
La interfaz de entrada debe recoger todos los datos necesarios, sin introducir errores,
para el sistema

Las entradas deben estar bien estructuradas y ser fciles de comprender y utilizar.
Se deben usar nombres precisos y permitir abreviaturas cuando se necesiten
introducciones rpidas de datos. Se deben evitar las entradas repetitivas.
Igualmente, el diseo de la salida asegura que se extraen todos los datos
suministrados por el sistema y que esas salidas estn estructuradas de forma que
sean fciles de leer.
El color aade una nueva dimensin a la facilidad de uso de la pantalla, ya que
atrae la atencin del usuario.
Para finalizar, diremos que el diseo de pantallas es un proceso ordenado que
empieza en los requisitos y finaliza con la implementacin.
Pruebas del software
Una de las caractersticas tpicas del desarrollo de software basado en el ciclo de
vida es la realizacin de controles peridicos, normalmente coincidiendo con los
hitos del proyecto o la terminacin de documentos. Estos controles pretenden una
evaluacin de la calidad de los productos generados (especificacin de requisitos,
documentos de diseo, etc.) para poder detectar posibles defectos cuanto antes.

Las pruebas constituyen un mtodo ms para poder verificar y validar el software.

Se puede definir la verificacin como
el proceso de evaluacin de un sistema o de uno de sus componentes para
determinar si los productos de una fase dada satisfacen las condiciones impuestas
al comienzo de dicha fase.
Por otra parte, la validacin es el proceso de evaluacin de un sistema o de uno
de sus componentes durante o al final del proceso de desarrollo para determinar si
satisface los requisitos especificados.
Verificacin: estamos construyendo correctamente el producto?
Validacin: estamos construyendo el producto correcto?
Definiciones
Las siguientes definiciones son algunas de las recogidas en el diccionario IEEE en
relacin a las pruebas [IEEE, 1990], que complementamos con otras ms
informales:
Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se
ejecuta 2 en circunstancias previamente especificadas, los resultados se observan
y registran y se realiza una evaluacin de algn aspecto.
El nombre prueba, adems de la actividad de probar, se puede utilizar para
designar un conjunto de casos y procedimientos de prueba [IEEE, 1990].
Caso de prueba (test case): un conjunto de entradas, condiciones de ejecucin
y resultados esperados desarrollados para un objetivo particular como, por
ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento
de un determinado requisito.

Defecto (defect, fault, bug): un defecto en el software como, por ejemplo, un

proceso, una definicin de datos o un paso de procesamiento incorrectos en un
programa.
Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes
para realizar las funciones requeridas dentro de los requisitos de rendimiento
especificados.
Error (error): tiene varias acepciones:
La diferencia entre un valor calculado, observado o medido y el valor verdadero,
especificado o tericamente correcto. Por ejemplo, una diferencia de dos
centmetros entre el valor calculado y el real.

Un defecto: Por ejemplo, una instruccin incorrecta en un programa.

Un resultado incorrecto: Por ejemplo, un programa ofrece como resultado de la
raz cuadrada de 36 el valor 7 en vez de 6.
Una accin humana que conduce a un resultado incorrecto (una metedura de
pata).
El proceso de prueba
El proceso de prueba comienza con la generacin de un plan de pruebas en base
a la documentacin sobre el proyecto y la documentacin sobre el software a
probar.

Tcnicas de diseo de casos de prueba

El diseo de casos de prueba est totalmente mediatizado por la imposibilidad de

probar exhaustivamente el software. Pensemos en un programa muy sencillo que
slo suma dos nmeros enteros de dos cifras (del 0 al 99). Si quisiramos probar,
simplemente, todos los valores vlidos que se pueden sumar, deberamos probar
10.000 combinaciones distintas de cien posibles nmeros del primer sumando y
cien del segundo.
Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la
disponibilidad de recursos y la confianza que aportan los casos para descubrir los
defectos existentes

Ya que no se pueden probar todas las posibilidades de funcionamiento del

software, la idea fundamental para el diseo de casos de prueba consiste en elegir
algunas de ellas que, por sus caractersticas, se consideren representativas del
resto.
Existen tres enfoques principales para el diseo de casos:
El enfoque estructural o de caja blanca. Consiste en centrarse en la estructura
interna (implementacin) del programa para elegir los casos de prueba. En este
caso, la prueba ideal (exhaustiva) del software consistira en probar todos los
posibles caminos de ejecucin, a travs de las instrucciones del cdigo, que
puedan trazarse.
Pruebas estructurales. (Prueba de la caja negra)
El enfoque funcional o de caja negra, consiste en estudiar la especificacin de las
funciones, la entrada y la salida para derivar los casos. Aqu, la prueba ideal del
software consistira en probar todas las posibles entradas y salidas del programa.
El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones
estadsticos) que representen las posibles entradas al programa para crear a partir
de ellos los casos de prueba. La prueba exhaustiva consistira en probar todas las
posibles entradas al programa.

Pruebas estructurales. (Prueba de la caja blanca)

El diseo de casos tiene que basarse en la eleccin de caminos importantes que ofrezcan
una seguridad aceptable en descubrir defecto, y para ello se utilizan los llamados criterios
de cobertura lgica.

2.5 Diseo de bases de datos.

Uno de los pasos cruciales en la construccin de una aplicacin que maneje una
base de datos, es sin duda, el diseo de la base de datos.
No importa si nuestra base de datos tiene slo 20 registros, o algunos cuantos
miles, es importante asegurarnos que nuestra base de datos est correctamente
diseada para que tenga eficiencia y que se pueda seguir utilizando por largo del
tiempo.

Diseo de bases de datos

Son muchas las consideraciones a tomar en cuenta al momento de hacer 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 logrando resultados altamente aceptables
Objetivos del diseo de bases de datos
Diseo de bases de datos
En este apartado se describen con ms detalle los objetivos de cada una de las
etapas del diseo de bases de datos: diseo conceptual, diseo lgico y diseo
fsico. La metodologa a seguir en cada una de estas etapas se describe en los
tres captulos que siguen a ste.
Diseo conceptual: En esta etapa se debe construir un esquema de la
informacin que se usa en la empresa, independientemente de cualquier
consideracin fsica. A este esquema se le denomina esquema conceptual. Al
construir el esquema, los diseadores descubren la semntica (significado) de los
datos de la empresa: encuentran entidades, atributos y relaciones. El objetivo es
comprender:
La perspectiva que cada usuario tiene de los datos.
La naturaleza de los datos, independientemente de su representacin fsica.
El uso de los datos a travs de las reas de aplicacin.
El esquema conceptual se puede utilizar para que el diseador transmita a la
empresa lo que ha entendido sobre la informacin que sta maneja
El diseo conceptual es completamente independiente de los aspectos de
implementacin, como puede ser el SGBD que se vaya a usar, los programas de
aplicacin, los lenguajes de programacin, el hardware disponible o cualquier otra
consideracin fsica
Diseo lgico: El diseo lgico es el proceso de construir un esquema de la
informacin que utiliza la empresa, basndose en un modelo de base de datos

especfico, independiente del SGBD concreto que se vaya a utilizar y de cualquier

otra consideracin fsica.
En esta etapa, se transforma el esquema conceptual en un esquema lgico que
utilizar las estructuras de datos del modelo de base de datos en el que se basa el
SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de
red, el modelo jerrquico o el modelo orientado a objetos. Conforme se va
desarrollando el esquema lgico, ste se va probando y validando con los
requisitos de usuario.
El esquema lgico es una fuente de informacin para el diseo fsico.
Tanto el diseo conceptual, como el diseo lgico, son procesos iterativos, tienen
un punto de inicio y se van refinando continuamente.
El diseo conceptual y el diseo lgico son etapas clave para conseguir un
sistema que funcione correctamente. Si el esquema no es una representacin fiel
de la empresa, ser difcil, sino imposible, definir todas las vistas de usuario
(esquemas externos), o mantener la integridad de la base de datos.
Diseo fsico: El diseo fsico es el proceso de producir la descripcin de la
implementacin de la base de datos en memoria secundaria: estructuras de
almacenamiento y mtodos de acceso que garanticen un acceso eficiente a los
datos.
Para llevar a cabo esta etapa, se debe haber decidido cul es el SGBD que se va
a utilizar, ya que el esquema fsico se adapta a l
En general, el propsito del diseo fsico es describir cmo se va a implementar
fsicamente el esquema lgico obtenido en la fase anterior. Concretamente, en el
modelo relacional, esto consiste en:
Obtener un conjunto de relaciones (tablas) y las restricciones que se deben
cumplir sobre ellas.

Determinar las estructuras de almacenamiento y los mtodos de acceso que se

van a utilizar para conseguir unas prestaciones ptimas.
2.6 Diseo de controles y procesos.
Definicin de control
El control es una etapa primordial en la administracin, pues, aunque una empresa
cuente con magnficos planes, una estructura organizacional adecuada y una
direccin eficiente, el ejecutivo no podr verificar cul es la situacin real de la
organizacin i no existe un mecanismo que se cerciore e informe si los hechos van
de acuerdo con los objetivos.

Por qu es necesario controlar un proceso?

Incremento de la productividad.
Alto costo de mano de obra
Seguridad.
Alto costo de materiales.
Mejorar la calidad.
Reduccin de tiempo.
De manufactura
Reduccin de inventario en proceso
Certificacin (mercados internacionales)
Proteccin del medio ambiente (desarrollo sustentable)
El proceso de diseo del sistema de control

Para poder disear un sistema de control automtico, se requiere conocer el

proceso que se desea controlar, es decir, conocer la ecuacin diferencial que
describe su comportamiento, utilizando las leyes fsicas, qumicas y/o elctricas,
computacionales etc.
Definicin de diseo de sistemas
El diseo de sistemas es la evaluacin de las distintas soluciones alternativas y la
especificacin de una solucin detallada a un problema de informacin.

Controles internos
El diseo de sistemas se encarga de:
1. Analizar y distribuir datos
2. Analizar y distribuir los procesos
3. Dividir en unidades de diseo
4. Disear bases de datos y o archivos
5. Disear entradas y salidas informticas
6. Disear interfaces interactivas de usuario
7. Presentar y revisar el diseo
Actividades que se desarrollan en el diseo de control y proceso:
Actividad de Definicin de la Arquitectura del Sistema.

 Definicin de la arquitectura del sistema.

Definicin de Niveles de Arquitectura.
Identificacin de Requisitos de Diseo y Construccin.
Especificacin de Estndares y Normas de Diseo y Construccin.
Identificacin de Subsistemas de Diseo.
Especificacin de Requisitos de Operacin y Seguridad.
Generacin del cdigo de los componentes y procedimientos.
Generacin del Cdigo de Componentes.
Generacin del Cdigo de los Procedimientos de Operacin y Seguridad
Actividad de definicin de la arquitectura del sistema en esta actividad se
establece:
El particionamiento fsico del sistema de informacin.
La organizacin en subsistemas de diseo.
La especificacin del entorno tecnolgico.
Los requisitos de operacin, administracin, seguridad y control de acceso.
Se completan los catlogos de requisitos y normas.
Se crea un catlogo de excepciones del sistema, en el que se registran las
situaciones de funcionamiento secundario o anmalo que se estime oportuno
considerar y, por lo tanto, disear y probar.

Definicin de la arquitectura del sistema en esta actividad se define la:

Arquitectura general del sistema de informacin, especificando las distintas
particiones fsicas del mismo.
La descomposicin lgica en subsistemas de diseo y la ubicacin de cada
subsistema en cada particin.
Se especifica detalladamente la infraestructura tecnolgica necesaria para dar
soporte al sistema de informacin.
El entorno Tecnolgico del Sistema, comprende la especificacin del entorno
tecnolgico, las restricciones tcnicas y la planificacin de capacidades.
Se definen los procedimientos de Operacin y Administracin del Sistema.
Procedimientos de Seguridad y Control de Acceso.
Se definen los requisitos de operacin, seguridad y control, especificando los
procedimientos necesarios para su cumplimiento.
Definicin de niveles de arquitectura
En esta tarea se describen los niveles de la arquitectura software, mediante la
definicin de las principales particiones fsicas del sistema de informacin,
representadas como nodos y comunicaciones entre nodos. Los elementos que se
deben de especificar son:
Gestores de datos.
Tipos de puesto cliente.
Tipos de dispositivos de impresin.
Monitores de teleproceso.

 Servidores.
Comunicaciones.
Identificacin de requisitos de diseo y construccin
En esta tarea se realiza la especificacin de los requisitos que estn directamente
relacionados con el diseo o la construccin del sistema de informacin.

Estos requisitos son:

Lenguajes.
Rendimiento de los distintos elementos de la arquitectura.
Criterios de ubicacin de mdulos y datos en los distintos nodos.
Especificacin de Estndares y Normas de Diseo y Construccin.
En esta tarea se definen:
Los estndares tcnicos o normas.
Recomendaciones que estn relacionados con la adopcin o diseo de una
arquitectura o infraestructura tecnolgica concreta, y que condicionan el diseo o
la construccin del sistema de informacin.
Identificacin de subsistemas de diseo.
En esta tarea se divide de forma lgica el sistema de informacin en subsistemas
de diseo, con el fin de reducir la complejidad y facilitar el mantenimiento.

Especificacin de requisitos de operacin y seguridad.

El objetivo de esta tarea es definir los procedimientos de seguridad y operacin
necesarios para el adecuado funcionamiento del sistema y garantizar el
cumplimiento de los niveles de servicios que exigir el sistema en cuanto a la
gestin de operaciones

Para ello, se disean los procedimientos relacionados con:

Acceso al sistema y a sus recursos (datos, transacciones, libreras, etc.).
Mantenimiento de la integridad y confidencialidad de los datos.
Control y registro de accesos al sistema (logs, certificacin, etc.).
Copias de seguridad y recuperacin de datos y su periodicidad.
Recuperacin ante catstrofes.
Se definen los requisitos de operacin para los distintos elementos del sistema
(mdulos, clases, estructuras fsicas de datos, sistemas de ficheros)
Control y planificacin de trabajos.
Recuperacin y reanudacin de trabajos.
Distribucin de informacin generada por el sistema.
Control y seguimiento del correcto funcionamiento de los procedimientos de
backup y recuperacin utilizados habitualmente.

Generacin del cdigo de los componentes y procedimientos.

El objetivo de esta actividad es la codificacin de los componentes del sistema de
informacin
Generacin del Cdigo de Componentes
En esta tarea se genera el cdigo correspondiente a cada uno de los
componentes del sistema de informacin, identificados en la tarea Definicin de
Componentes y Subsistemas de Construccin.
Generacin del Cdigo de los procedimientos de operacin y seguridad
El objetivo de esta tarea es generar los procedimientos de operacin y
administracin del sistema de informacin, as como los procedimientos de
seguridad y control de acceso, necesarios para ejecutar el sistema una vez que se
haya implantado y est en produccin.
Para la generacin de dichos procedimientos se tienen en cuenta, tambin, los
estndares y normas de la instalacin recogidos en el catlogo de normas.

2.7 Aplicacin de mtricas para la evaluacin del diseo.

Una mtrica es un instrumento que cuantifica un criterio.
El concepto de mtrica es el trmino que describe muchos y muy variados casos
de medicin. Siendo una mtrica una medida estadstica (no cuantitativa como en
otras disciplinas ejemplo fsica) que se aplica a todos los aspectos de calidad de
software, los cuales deben ser medidos desde diferentes puntos de vista como el
anlisis, construccin, funcional, documentacin, mtodos, proceso, usuario, entre
otros.

Las mtricas
En la mayora de los desafos tcnicos, las mtricas nos ayudan a entender tanto
el proceso tcnico que se utiliza para desarrollar un producto, como el propio
producto. El proceso para intentar mejorarlo, el producto se mide para intentar
aumentar su calidad. La medicin es muy comn en el mundo de la ingeniera
Desgraciadamente la medicin se aleja de lo comn en el mundo de la ingeniera
del software.
Las mediciones del mundo fsico pueden englobarse en dos categoras: medidas
directas y medidas indirectas.

Medidas directas: En el proceso de ingeniera se encuentran el costo, y el

esfuerzo aplicado, las lneas de cdigo producidas, velocidad de ejecucin, el
tamao de memoria y los defectos observados en un determinado periodo de
tiempo.
Medidas Indirectas: Se encuentra la funcionalidad, calidad, complejidad,
eficiencia, fiabilidad, facilidad de mantenimiento, etc.
Mtricas del software: Son las que estn relacionadas con el desarrollo del
software como funcionalidad, complejidad, eficiencia.
Mtricas tcnicas: Se centran en las caractersticas de software por ejemplo: la
complejidad lgica, el grado de modularidad. Mide la estructura del sistema, el
cmo est hecho.
Mtricas de calidad: proporcionan una indicacin de cmo se ajusta el software a
los requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para
que mi sistema se adapte a los requisitos que me pide el cliente.

Mtricas de productividad: Se centran en el rendimiento del proceso de la

ingeniera del software. Es decir que tan productivo va a ser el software que voy a
disear.
Mtricas orientadas a la persona: Proporcionan medidas e informacin sobre la
forma que la gente desarrolla el software de computadoras y sobre todo el punto
de vista humano de la efectividad de las herramientas y mtodos.
Mtricas orientadas al tamao: Es para saber en qu tiempo voy a terminar el
software y cuantas personas voy a necesitar. Son medidas directas al software y
el proceso por el cual se desarrolla, si una organizacin de software mantiene
registros sencillos.
Mtricas orientadas a la funcin: Son medidas indirectas del software y del
proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las mtricas
orientadas a la funcin se centran en la funcionalidad o utilidad del programa.
Las mtricas orientadas a la funcin fueron
Los puntos de funcin que obtienen utilizando una funcin emprica basando en
medidas cuantitativas del dominio de informacin del software y valoraciones
subjetivos de la complejidad del software
Inicio del Plan: Determina el arranque formal del plan de sistemas, con el apoyo
del nivel ms alto de la organizacin.
Definicin y Organizacin: Detalla y concreta la descripcin del PSI asignando
un calendario y recursos humanos al mismo.
Estudio informacin relevante: Se analiza informacin de inters para el
correcto desarrollo del plan de sistemas
Identificacin requisitos: Obtiene la especificacin de requisitos que deben
tener los sistemas de informacin analizados por el plan de sistemas.
Estudio S.I. actuales: Obtiene una valoracin de la situacin actual.

Diseo modelo: Identifica y define los S.I. Que van a dar soporte a los procesos
afectados por el Plan de Sistemas de Informacin.
Arquitectura tecnolgica: Se propone la arquitectura tecnolgica que d soporte
al modelo de informacin y sistemas de informacin.
Definicin plan: Se elabora y detalla el plan de sistemas de informacin:
definicin de proyectos, actividades, calendario y recursos para implementar los
sistemas de informacin e infraestructura tecnolgica
Revisin y aprobacin: Se somete el plan a la revisin ltima y aprobacin de la
direccin.

Mtricas como planeacin de sistemas

Los objetivos principales de las mtricas
Comprender mejor la calidad del producto.
Estimar la efectividad del proceso.
Mejorar la calidad del trabajo realizado en el nivel del proyecto.
Desventajas de las mtricas
Uno de los problemas que tienen las mtricas es que no existe un esquema de
criterios generalmente aceptado (un estndar). Como no hay acuerdo en los
criterios involucrados, abundan las propuestas de mtricas que abordan la calidad
con criterios propios.

Caractersticas de las mtricas

Localizacin: La localizacin es una caracterstica del software que indica la
forma que se concentra la informacin dentro de un programa.
Encapsulamiento: define el encapsulamiento como el empaquetamiento (o
enlazado) de una coleccin de elementos.
Ocultamiento de informacin: El ocultamiento de informacin suprime los
detalles operativos de un componente de un programa.
Herencia: La herencia es un mecanismo que hace posible que los compromisos
de un objeto se difundan a otros objetos. La herencia se produce a lo largo de
todos los niveles de la jerarqua de clases
Abstraccin: La abstraccin es un mecanismo que permite al diseador centrarse
en los detalles esenciales de algn componente de un programa (tanto si es un
dato como si es un proceso) sin preocuparse por los detalles de nivel inferior.

Construccin.

3.1 Seleccin del ambiente operativo y lenguaje de desarrollo.

Para seleccionar la plataforma para el desarrollo de la aplicacin debemos tomar
en cuenta las funciones que se van a realizar, equipo con el que contamos,
sistema operativo, conectividad con la que se cuenta, plataformas de datos con las
que cuentan los sistemas actuales (en el dado caso que la aplicacin vaya a
interactuar con otros sistemas), tomar en cuenta las bondades que ofrece el
lenguaje de programacin,
En cuanto a lenguajes de programacin para aplicaciones web hay tambin varios
lenguajes, algunos muy conocidos como PERL, PHP, VBScript, C#, Java, que nos

ayudan a estas tareas, son flexibles e interactan con lenguajes como HTML para
generar salida de datos y darle el formato deseado y pueda ser visible al usuario,
tienen la gran ventaja que son lenguajes muy ligeros al ejecutarse procesar
informacin por lo que nos brindan grandes ventajas para este tipo de aplicaciones
Despus de configurar y tener todo listo, procedemos al desarrollo de la
aplicacin, la cual se realizar de acuerdo a los procedimientos y condiciones
establecidas en la etapa de diseo
Al realizar esta fase tambin debemos someter a una evaluacin el desarrollo para
ver si requieren ajustes o bien van quedando correctos los programas.
3.2 Elaboracin de programas.
Partiendo del concepto que se tiene sobre planeacin y programacin que para
algunas personas son equivalentes, algunos estudios de estos asuntos define al
primer trmino como el aspecto global de un proceso de desarrollo y al segundo
con un grado de mayor concrecin, indicando las partes y condiciones de un
periodo de tiempo dado.

Desarrollo de los aspectos de un programa

Justificacin: Se refiere a la exposicin de los motivos que fundamentan la
aplicacin del programa
Objetivos: Son las metas o fines que se desean alcanzar con la realizacin del
programa, los objetivos que se establezcan deben ser determinados como
resultado de la adecuada estimacin de problemas y recursos, y deben ser
precisos
Limitacin del programa
Espacio: Es el rea donde se desarrollara la accin.

Determinacin y precisin de actividades: Comprende la especificacin de las

actividades que necesitan efectuarse para alcanzar los objetivos
Tiempo y calendario de actividades: Se refiere a los das meses o aos durante
los cuales se llevar a cabo el programa.
Universo de Trabajo: Es la determinacin del nmero y tipo de personas que se
beneficiaran al ejercer la accin del programa.
Dentro de Organizacin:
Procedimientos
Mtodos de las actividades: Se refiere a la manera de cmo se har cada una
de las actividades que se hayan considerado.
Organismos que colaboran en el programa: Aqu se mencionar los
organismos o dependencias con los que se establecer coordinacin y la forma
como colaborar cada uno en el programa.
Material y equipo: Se refiere al equipo que se necesitar para la realizacin del
programa.
Locales: Se refiere a los lugares cerrados o abiertos donde se ejecutara el
programa.
Instructivos y reglamentos: Las instrucciones de las tcnicas que se vayan ha
emplear. Los reglamentos son las normas que

regirn

el desarrollo de las

actividades o de las labores.

Personal: Se refiere a las personas que participarn en la aplicacin del
programa.
Tipo y nmero: Como su nombre lo indica es el nmero de personas que
intervendrn en la ejecucin del programa

Determinacin de funciones: Estas pueden ser la lnea desde el punto de vista

jerrquico, de actividades segn los integrantes del personal y supervisin que
determinan por quienes y como desarrollar esta labor.
Reclutamiento: Se refiere a la descripcin de cmo y dnde se seleccionar el
personal necesario.
Adiestramiento: Se relaciona con la preparacin especial que se impartir al
personal seleccionado.
Financiamiento
Elaboracin del presupuesto: Se trata de especificar el presupuesto que se
requerir para la ejecucin del programa y se deben desglosar las diversas
partidas que lo integran.
Plan de obtencin de fondos: Se refiere a la manera como se piensa obtener los
fondos que se necesitan para cubrir el presupuesto.
Evaluacin: Es la estimacin de las realizaciones del programa con relacin a los
objetivos y procedimientos sealados

La evaluacin puede ser:

Simultnea y al final del programa.
Cuantitativa y Cualitativa.
Interna y externa. Se denomina simultnea, cuando se efecta durante el
desarrollo del programa y al final si se realiza al trmino de l.

3.2.1 Implementacin.
Fases de implementacin
1ra. Fase: seleccionar el sector productivo o empresa, en el cual se desarrollara el
trabajo.
Se toma en cuenta las polticas de Formacin Profesional y las necesidades del
mercado de trabajo.
2da Fase: identificar las reas funcionales por sector productivo o por empresa,
Su objetivo es determinar los productos o servicios que en cada una de ellas se
genera.
3ra Fase: sensibilizacin del sector productivo, campaa de informacin y
divulgacin para involucrar a los diferentes actores sociales (empleadores,
trabajadores, gobierno, etc.).
4ta Fase: Constitucin de las comisiones tcnicas, el comit estar integrado por
representantes del sector productivo y del sistema de formacin profesional,
contemplndose la participacin de otros profesionales independientes del sector
5ta Fase: Capacitacin del comit de normalizacin, la capacitacin se basa en
talleres y jornadas de trabajo sobre competencia laboral y explicacin de la
metodologa para elaborar las NCL.
6ta Fase: Determinacin de las competencias laborales, Se determinan aplicando
el Anlisis Funcional, lo que producir una serie de competencias laborales, las
cuales conformarn un Mapa Funcional
Propsito principal del sector productivo o empresa
Consiste en la identificacin de los principales objetivos del sector o empresa, de
modo que refleje la estrategia y condiciones de competitividad que le permite
destacarse en el mercado.

3.3 Mtricas para evaluar el software.

Mtricas para la evaluacin de software
Las mtricas se utilizan para evaluar y controlar el proceso de desarrollo del
software, de forma que permitan:
Indicar la calidad del producto.
Evaluar la productividad de los desarrolladores.
Evaluar los beneficios (en cuanto a calidad y productividad).
derivados del uso de nuevos mtodos y herramientas de ingeniera del software.
Establecer una lnea base para la estimacin.
Justificar el uso de nuevas herramientas o de formacin adicional.
Pero es necesario utilizar las mtricas ms adecuadas para conseguir el control,
seguimiento y mejora de la calidad

Necesidades de medida
Las necesidades de medida pueden ser diversas, desde medir el rendimiento de
los proyectos de una empresa, evaluar las inspecciones de cdigo hasta evaluar
las actividades de mejora del proceso software
3.4 Prueba de programas y del sistema.
Prueba de los programas
Una vez que los programas han sido verificados, requieren ser rigurosamente
probados para asegurar que cada componente opere como es debido y que el

sistema funcione exactamente de acuerdo con los requerimientos locales

especficos.

Entre las medidas de prueba se pueden considerar las siguientes:

Desarrollar un conjunto de criterios para la prueba.
Aplicar pruebas funcionales para determinar si se han satisfecho los criterios de
prueba.
Aplicar evaluaciones de calidad para determinar si se han satisfecho los criterios
de prueba.
Conducir pruebas en condiciones de laboratorio y en una variedad de
condiciones reales.
Conducir pruebas durante un periodo prolongado, para cerciorarse que los
sistemas pueden funcionar de manera consistente.
Mantenimiento de los programas
Despus de que los programas han sido verificados, probados e implantados, se
les debe seguir dando mantenimiento
3.5 Implementacin.
Es la ltima fase del desarrollo de Sistemas. Es el proceso instalar equipos o
Software nuevo, como resultado de un anlisis y diseo previo como resultado de
la sustitucin o mejoramiento de la forma de llevar a cavo un proceso
automatizado.
Existen varios enfoques de implementacin:
Uso de diferentes estrategias para el entrenamiento de los usuarios.

El Analista de Sistemas necesita ponderar la situacin y proponer un plan de

conversin que sea adecuado para la organizacin.
El Analista necesita formular medidas de desempeo con las cuales evaluar a los
Usuarios.

3.6 Documentacin.
La documentacin consiste en material que explica las caractersticas tcnicas y la
operacin de un sistema
Documentacin:
Bajo este trmino genrico se agrupan todos los manuales, guas de referencia,
libros de ayuda, etc., que suelen entregarse con cada programa, de manera que el
usuario pueda aprender su manejo y consultar cualquier duda ante un problema
desconocido.
Existen varios tipos de documentacin.
La de programas: que explica la lgica de un programa e incluye descripciones,
diagramas de flujo, listados de programas y otros documentos; la del usuario en
forma general la naturaleza y capacidades del sistema y cmo usarlo

3.6.1 Elaboracin del manual de usuario.

Manual de Usuario: Esta parte se divide en dos manuales distintos, uno por cada
aplicacin cliente. Se explicar todas las posibles opciones que puede realizar el
usuario con estas aplicaciones de manera detallada, y mediante el uso de
capturas de pantalla.
Pasos del manual del usuario:
1. Portada: De qu se trata el documento y quien lo elaboro?

2. Introduccin: Describe el uso del documento (para qu sirve?) y de qu

habla?
3. Anlisis y requerimientos del sistema (que se ocupa para poder instalarlo y
usarlo?)
4. Explicacin del funcionamiento: Debes de poner paso a paso y con pantallas
bien explicadas cmo funciona el programa
5. Glosario:
Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la
menor dificultad posible.
Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar
el programa.
Especificar los alcances y las limitaciones que tiene el programa.
Un buen punto de partida para un manual de usuario, es hacer de cuenta que las
personas que lo van a leer no tienen el ms mnimo conocimiento sobre
computadores.
Importancia del manual de usuario
El manual de usuario facilita el conocimiento de:
Los documentos a los que se puede dar entrada por computadora.
Los formatos de los documentos.
Las operaciones que utiliza de entrada y salida de los datos.
Contenido

Diagrama general del sistema

Diagrama particular detallado.

Instalacin del sistema

Iniciacin al uso del sistema

Manual de referencia

Caducidad de documento fuente y destino final

3.6.2 Elaboracin del manual de administracin.

Recabados los elementos preliminares para llevar a cabo el manual, se
debe preparar el documento de partida para concretarlo, el cual debe quedar
integrado por:

Propuesta tcnica

Programa de trabajo

Participantes

Responsable de su autorizacin

Captacin de la informacin

Levantamiento de la informacin

Investigacin documental

Consulta a sistemas de informacin

Encuesta

Observacin directa

Anlisis de la informacin: En esta etapa se debe realizar un estudio o examen

crtico de cada uno de los elementos de informacin o grupos de datos que se
integraron con el propsito de conocer su naturaleza, caractersticas y
comportamiento
Tcnicas de apoyo para el anlisis: En esta fase comprende los recursos
tcnicos que se emplean para estudiar la informacin obtenida con el fin de
conocerla en forma detallada t determinar alternativas de accin especficas que
permitan derivar soluciones ptimas para lograr los resultados deseados
Organizacionales
Preparacin del proyecto del manual: Una vez que se cuenta con toda la
informacin del manual se proceder a integrarlo; para tal actividad se requiere

convocar a todos los participes de la presentacin del manual, para revisin del
contenido y presentacin de cada apartado
3.6.3 Elaboracin del manual tcnico.
Este documento contiene toda la informacin sobre los recursos utilizados por el
proyecto, llevan una descripcin muy bien detallada sobre las caractersticas
fsicas y tcnicas de cada elemento.
Este documento debe incorporar la siguiente informacin:
Portada
Logotipo de la organizacin.
Nombre oficial de la organizacin
Denominacin y extensin. De corresponder a una unidad en particular debe
anotarse el nombre de la misma.
Lugar y fecha de elaboracin.
Nmero de revisin (en su caso).
Unidades responsables de su elaboracin, revisin y/o autorizacin.
Clave de la forma. En primer trmino, las siglas de la organizacin, en segundo
lugar las siglas de la unidad administrativa donde se utiliza la forma y, por ltimo,
el nmero de la forma. Entre las siglas y el nmero debe colocarse un guin o
diagonal. (En su caso).
Estructura del documento manual tcnico
ndice
Relacin de los captulos y pginas correspondientes que forman parte del
documento
Introduccin.

Se debe presentar una breve descripcin del sistema desarrollado, que contemple
el mbito abarcado, cual es su funcin principal y un detalle de las funciones
macros o partes que lo componen. Puede incluir un mensaje de la mxima
autoridad de las reas comprendidas en el manual.
Objetivo general del sistema
Se debe de describir el objetivo general del sistema.
Objetivos especficos
Se deben describir brevemente los objetivos especficos que se cumplieron con el
desarrollo del sistema.
Contenido tcnico.
Definicin de reglas del negocio implementadas en el sistema desarrollado.
Diagramas de flujo de datos, junto con su respectivo diccionario de datos.
Controles de auditoria implementados en el sistema.
Descripcin de campos requeridos por pantalla con presentacin de pantallas.
Diagrama de navegacin del sistema.
Requerimientos de interfaz con otros sistemas.
Modelo lgico de datos, diagrama entidad-relacin.
Modelo de datos fsico, junto con su respectivo diccionario de datos.
Matriz de procesos versus organizacin.
Matriz de programas versus entidades.

Estudio de casos prcticos para mantenimiento.

4.1 Tipos de mantenimiento.

Existen cuatro tipos reconocidos de operaciones de mantenimiento, los cuales
estn en funcin del momento en el tiempo en que se realizan, el objetivo
particular para el cual son puestos en marcha, y en funcin a los recursos
utilizados
Existen varios tipos de mantenimiento que a continuacin mencionaremos:
Mantenimiento correctivo:
Este mantenimiento tambin es denominado mantenimiento reactivo, tiene lugar
luego que ocurre una falla o avera, es decir, solo actuar cuando se presenta un
error en el sistema
El mantenimiento correctivo o mantenimiento por rotura fue el esbozo de lo que
hoy da es el mantenimiento. Esta etapa del mantenimiento va precedida del
mantenimiento planificado.
Este mantenimiento agrupa las acciones a realizar en el software (programas,
bases de datos, documentacin, etc.) ante un funcionamiento incorrecto, deficiente
o incompleto que por su naturaleza no pueden planificarse en el tiempo
Mantenimiento preventivo:
El mantenimiento preventivo es una actividad programada de inspecciones, tanto
de funcionamiento como de seguridad, ajustes, reparaciones, anlisis, limpieza,
lubricacin, calibracin, que deben llevarse a cabo en forma peridica en base a
un plan establecido
El mantenimiento preventivo permite detectar fallos repetitivos, disminuir los
puntos muertos por paradas, aumentar la vida til de equipos, disminuir costes de
reparaciones, detectar puntos dbiles en la instalacin entre una larga lista de
ventajas.

El mantenimiento preventivo consiste en la revisin peridica de ciertos aspectos,

tanto de hardware como de software en un pc.
Aunque

el

mantenimiento

preventivo

es

considerado

valioso

para

las

organizaciones, existen una serie de riesgos como fallos de la maquinaria o

errores humanos a la hora de realizar estos procesos de mantenimiento.
Este mantenimiento tambin es denominado mantenimiento planificado, tiene
lugar antes de que ocurra una falla o avera, se efecta bajo condiciones
controladas sin la existencia de algn error en el sistema.
Mantenimiento predictivo:
Consiste en determinar en todo instante la condicin tcnica (mecnica y elctrica)
real de la mquina examinada, mientras esta se encuentre en pleno
funcionamiento, para ello se hace uso de un programa sistemtico de mediciones
de los parmetros ms importantes del equipo.
Tiene como objetivo disminuir las paradas por mantenimientos preventivos, y de
esta manera minimizar los costos por mantenimiento y por no produccin
El mantenimiento predictivo es una tcnica para pronosticar el punto futuro de falla
de un componente de una mquina, de tal forma que dicho componente pueda
reemplazarse, con base en un plan, justo antes de que falle.
Mantenimiento proactivo:
Este mantenimiento tiene como fundamento los principios de solidaridad,
colaboracin, iniciativa propia, sensibilizacin, trabajo en equipo, de moto tal que
todos los involucrados directa o indirectamente en la gestin del mantenimiento
deben conocer la problemtica del mantenimiento
El Mantenimiento Proactivo, es una filosofa de mantenimiento, dirigida
fundamentalmente a la deteccin y correccin de las causas que generan el
desgaste y que conducen a la falla de la maquinaria.

El Mantenimiento Proactivo, establece una tcnica de deteccin temprana,

monitoreando el cambio en la tendencia de los parmetros considerados como
causa de falla, para tomar acciones que permitan al equipo regresar a las
condiciones establecidas que le permitan desempearse adecuadamente por ms
tiempo
4.2 Tcnicas de mantenimiento.
Dentro de la ingeniera del software se proporcionan soluciones tcnicas que
permiten abordar el mantenimiento de manera que su impacto en coste dentro del
ciclo de vida sea menor. Las soluciones tcnicas pueden ser de tres tipos:
Ingeniera inversa: Anlisis de un sistema para identificar sus componentes y las
relaciones entre ellos
Reingeniera: Modificacin de un producto software, o de ciertos componentes,
usando para el anlisis del sistema existente tcnicas de ingeniera inversa y, para
la etapa de reconstruccin, herramientas de ingeniera directa
Reestructuracin del software: Cambio de representacin de un producto
software, pero dentro del mismo nivel de abstraccin
Tambin existen otras tecnologas, como por ejemplo:
La remodularizacin: consiste en cambiar la estructura modular de un sistema de
forma que se obtenga una nueva estructura siguiendo los principios del diseo
estructurado.
Visualizacin: el proceso ms antiguo para la comprensin del software.
Anlisis y mediciones: son importantes tecnologas que estudian ciertas
propiedades de los programas.
4.3 Anlisis de casos.
Para realizar alguno de los tipos de mantenimientos se debe tomar en cuenta lo
siguiente:

Costes del mantenimiento

Oportunidades de desarrollo que se pierden.
Insatisfaccin del cliente cuando no se puede atender en un tiempo aceptable una
peticin de reparacin que parece razonable.
Los errores ocultos que se introducen al cambiar el sw. durante el mantenimiento
reducen la calidad global del producto.
Perjuicio en otros proyectos de desarrollo cuando la plantilla tiene que dejarlos,
total o parcialmente, para atender peticiones de mantenimiento. Coste de las
actividades de mantenimiento.
Dificultades del mantenimiento.
Oportunidades de desarrollo que se pierden.
Insatisfaccin del cliente cuando no se puede atender en un tiempo aceptable una
peticin de reparacin que parece razonable.
Los errores ocultos que se introducen al cambiar el sw. durante el mantenimiento
reducen la calidad global del producto.
4.4 Viabilidad del mantenimiento.
Viabilidad econmica:
Un estudio de funciones, rendimiento y restricciones que puedan afectar la
realizacin de un sistema aceptable.

Viabilidad Legal:
Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal
en que se podra incurrir al desarrollar el Sistema.

Alternativas: Una evaluacin de los enfoques alternativos del desarrollo del

producto o Sistema.
El estudio de la viabilidad puede documentarse como un informe aparte para la
alta gerencia.

4.5 Administracin del Mantenimiento.

El principal objetivo del mantenimiento es optimizar la disponibilidad de los
equipos al mnimo costo.
El mantenimiento tiene que ver con preservar los activos fsicos.
La mayora de los equipos tiende a fallar ms en la medida que se ponen viejos.
El mantenimiento proactivo tiene que ver con prevenir fallas.
El mantenimiento proactivo tiene que ver con prevenir fallas.
Se debe tener disponibilidad de informacin de fallas antes de desarrollar
estrategias de mantenimiento exitosas.
El mantenimiento afecta todos los aspectos del negocio y no solo disponibilidad y
costos, afecta tambin a la seguridad, la integridad ambiental, la eficiencia
energtica y calidad de productos.
El mantenimiento afecta todos los aspectos del negocio y no solo disponibilidad y
costos, afecta tambin a la seguridad, la integridad ambiental, la eficiencia
energtica y calidad de productos.
Solamente los mantenedores, en forma conjunta con los operadores de los
activos, pueden desarrollar un plan de mantenimiento exitoso y duradero.