Ingeniería del Software

Índice
1 Fundamentos del diseño.
1.1 Panorama general del diseño físico y lógico.
1.2 Conceptos del diseño de sistemas.
1.2.1 Acoplamiento y coherencia.
1.2.2 Arquitectura del software.
1.3 Heurísticas de diseño.

2 Diseño de sistemas.
2.1 Modelo estructurado.
2.2 Modelo orientado a objetos.
2.3 Modelo basado en componentes.
2.4 Diseño de la Arquitectura del software.
2.5 Diseño de Interfaz de usuario.
2.6 Diseño de bases de datos.
2.7 Diseño de controles y procesos.
2.8 Aplicación de métricas para la evaluación del diseño.

3 Construcción.
3.1 Selección del ambiente operativo y lenguaje de desarrollo.
3.2 Elaboración de programas.
3.2.1 Implementación.
3.3 Métricas para evaluar el software.
3.4 Prueba de programas y del sistema.
3.5 Implementación.
3.6 Documentación.
3.6.1 Elaboración del manual de usuario.
3.6.2 Elaboración del manual de administración.
3.6.3 Elaboración del manual técnico.

4 Estudio de casos prácticos para mantenimiento.
4.1 Tipos de mantenimiento.
4.2 Técnicas de mantenimiento.
4.3 Análisis de casos.
4.4 Viabilidad del mantenimiento.
4.5 Administración del Mantenimiento.

Fundamentos del Diseño
1.1 Panorama general del diseño físico y lógico.

Diseño Físico
El diseño físico es el proceso de traducción del modelo lógico abstracto a un
diseño técnico específico para el nuevo sistema. Produce las especificaciones
reales para el hardware, software y bases de datos físicas, medios de
entrada/salida, procedimientos manuales y controles específicos. Proporciona las
especificaciones que transforman el diseño lógico abstracto en un sistema de
funciones de personas y máquinas.
También el diseño físico de sistemas es la forma en que se lograrán las
tareas del sistema, lo que incluye la manera de conjuntar sus componentes y las
funciones que realizará cada uno de éstos.
En el diseño físico se especifican las características de los componentes del
sistema requeridos para poner en práctica el diseño lógico. En esta fase deben
delinearse las características de cada uno de los componentes que se enumeran a
continuación.
Diseño de hardware: Debe especificarse todo el equipo de cómputo, lo que
incluye dispositivos de entrada, procesamiento y salida, con sus características de
rendimiento.
Diseño de software: De todo el Software Por ejemplo, si en el diseño lógico se
indica la necesidad de que de que los usuarios actualicen al mismo tiempo la base
de datos, en el diseño físico deben especificarse un sistema de administración 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, también se toman en cuenta
durante el diseño físico del software.

Diseño 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 diseño lógico deben reflejarse también en el diseño físico.
Diseño

de

telecomunicaciones: Deben especificarse las características

necesarias del software, medios y dispositivos de telecomunicaciones.
Diseño de personal: Este paso incluye especificar los antecedentes y experiencia
de los individuos que más probablemente satisfagan las descripciones de empleos
que se incluyen en el diseño lógico.
Diseño de procedimientos y controles: Comprende detallar la forma en que se
ejecuta cada aplicación y las medidas para minimizar las probabilidades de delitos
y fraudes. Tales especificaciones incluyen métodos de auditoría, soporte y
distribución de salidas.
Diseño Lógico
Es aquel que representa los componentes del sistema y sus relaciones
mutuas, como se mostraría ante el usuario. Muestra lo que la solución sistemática
hará en contraposición con el modo como lo es en la actualidad impactada
físicamente. También describe las entradas y salidas, las funciones de
procesamiento a realizar, los procedimientos de negocios, los modelos de datos y
los controles.
El diseño lógico de sistemas se refiere a lo que hará el nuevo sistema, el diseño
lógico es una descripción de los requisitos funcionales de un sistema.
El diseño lógico incluye planear el propósito de cada elemento del sistema, sin
relación con consideraciones de hardware y software.
Especificaciones del diseño lógico
Diseño de salida: Es una descripción de todas las salidas del sistema e incluye
sus tipos, formato, contenido y frecuencia.

Diseño de entrada: Una vez que se completa el diseño de salidas, puede
iniciarse el de entradas. En éste se especifican los tipos, formato, contenido
sistema capture los números telefónicos de los clientes cuando éstos llaman a la
organización y use tal dato para buscar de manera automática la información de
su cuenta, es una especificación de diseño lógico.
Diseño

de

procesamiento:

Los

tipos

de

cálculos,

comparaciones

y

manipulaciones de datos en general que requiere el sistema se determinan
durante esta fase.
Diseño de archivos y bases de datos: En muchos sistemas de información se
requieren subsistemas de archivos y bases de datos. Las características de estos
subsistemas se especifican también en la fase de diseño lógico.
Diseño de telecomunicaciones: Durante el diseño lógico es necesario
especificar los sistemas de redes y telecomunicaciones.
A partir de estos requisitos, podría optarse por una topología híbrida. Los
programas de gráficos y las herramientas de CASE son útiles para facilitar el
diseño de redes lógicas.
Diseño

de

procedimientos:

Lo

dos

sistema

de

información

requiere

procedimientos para la ejecución de aplicaciones y la solución de los problemas
que surjan. Estos requisitos importantes se capturan durante el diseño de
procedimientos. Una vez diseñados, los procedimientos se pueden describir con
programas de procesamiento de texto.
Diseño de controles y seguridad: Otra parte importante del diseño lógico es
determinar la frecuencia y características necesarias de los sistemas de respaldo.
En general, debe tenerse apoyo de todo, lo que incluye el hardware, software,
datos, personal, insumos e instalaciones.
Diseño de personal y empleos: Algunos sistemas requieren contratar empleados
adicionales, mientras que con otros es necesario modificar las tareas relacionadas
con uno o más empleos de SI existentes. Los nombres y descripciones de los

puestos se especifican durante el diseño de personal y empleos. Los
organigramas son útiles en el diseño de personal para diagramar los empleos y
sus nombres.
1.2 Conceptos del diseño de sistemas.
El diseño del sistema es la estrategia de alto nivel para resolver problemas
y construir una solución. El Diseño de Sistemas se define el proceso de aplicar
ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o
un Sistema, con suficientes detalles como para permitir su interpretación y
realización física.
La etapa del diseño del Sistema encierra cuatro etapas:
El diseño de los datos
Trasforma el modelo de dominio de la información, creado durante el
análisis, en las estructuras de datos necesarios para implementar el Software.
El diseño Arquitectónico
Define la relación entre cada uno de los elementos estructurales del programa.
El diseño 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 diseño de procedimientos
Transforma elementos estructurales de la arquitectura del programa. La
importancia del Diseño del Software se puede definir en una sola palabra Calidad,
dentro del diseño es donde se fomenta la calidad del Proyecto. El Diseño es la
única manera de materializar con precisión los requerimientos del cliente.

El diseño del Software
Es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de
pasos repetitivos que permiten al diseñador describir todos los aspectos del
Sistema a construir.
El diseño debe implementar todos los requisitos explícitos contenidos en el
modelo de análisis y debe acumular todos los requisitos implícitos que desea el
cliente.
Debe ser una guía que puedan leer y entender los que construyan el código y los
que prueban y mantienen el Software.
El Diseño 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 Implementación.
Para evaluar la calidad de una presentación del diseño, se deben
establecer criterios técnicos para un buen diseño como son:
Un diseño debe presentar una organización jerárquica que haga un uso
inteligente del control entre los componentes del software.

El diseño debe ser modular, es decir, se debe hacer una partición lógica del
Software en elementos que realicen funciones y subfunciones especificas.
Un diseño debe contener abstracciones de datos y procedimientos.
Debe producir módulos que presenten características de funcionamiento
independiente.
Debe conducir a interfaces que reduzcan la complejidad de las conexiones
entre los módulos y el entorno exterior.

Debe producir un diseño usando un método que pudiera repetirse según la
información obtenida durante el análisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseño del
Software exige buena calidad a través de la aplicación de principios
fundamentales de Diseño, Metodología sistemática y una revisión exhaustiva.
Cuando se va a diseñar un Sistema de Computadoras se debe tener
presente que el proceso de un diseño incluye, concebir y planear algo en la mente,
así como hacer un dibujo o modelo o croquis.
1.2.1 Acoplamiento y coherencia.
Cohesión
Grado de relación entre los elementos de un modulo. Si evaluamos el
acoplamiento y la cohesión nos puede dar la calidad de un buen sistema de
información.
Tipos de Cohesión:
Cohesión funcional: Los elementos de la unidad de software están relacionados
en el desarrollo de una única función, es el criterio de agrupación más deseable.
Probablemente haya entre las unidades un acoplamiento relativamente alto, por lo
tanto es conveniente que estén juntas.
Cohesión 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 próxima continúe trabajando.
Cohesión comunicacional o de datos: La unidad de software realiza actividades
paralelas usando los mismos datos de entrada y salida.
Cohesión procedimental: La unidad de software tiene una serie de funciones
relacionadas por un procedimiento efectuado por el código.

Cohesión lógica: Cuando las unidades de software agrupadas realizan un trabajo
en una misma categoría lógica, pero no necesariamente tienen relación entre sí.
Cohesión temporal: Los elementos de la unidad de software están implicados en
actividades relacionadas con el tiempo.
Cohesión casual o coincidente: Los elementos de la unidad de software
contribuyen a las actividades relacionándose mutuamente de una manera poco
significativa.
¿Qué ocurre en el caso de la cohesión?
La cohesión de un componente mide la identidad de su comportamiento.
La cohesión 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
definición funcional es una y clara.
Acoplamiento
Grado de interdependencia entre las unidades de software (módulos, funciones,
subrutinas, bibliotecas, etc.) de un sistema informático. 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 reutilización de las unidades de software.
Evitar el efecto onda, ya que un defecto en una unidad puede propagarse a otras,
haciendo incluso más difícil de detectar dónde está el problema.
Minimiza el riesgo de tener que cambiar múltiples unidades de software cuando se
debe alterar una.

El acoplamiento, junto con la modularidad, la cohesión y otros factores, permiten
mejorar la programación y el diseño de sistemas informáticos y aplicaciones, y son
cruciales en el incremento de la reutilización de los códigos.
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 están ligadas a componentes
externos, como por ejemplo dispositivos de entrada/salida, protocolos de
comunicaciones,etc.
Acoplamiento común: dos unidades de software acceden a un mismo recurso
común, 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?
Básicamente, lo más importante es saber definir las responsabilidades de cada
componente para garantizar que la dependencia sea funcional o arquitectónica, no
de implementación.
En el caso de acoplamiento funcional, está bien que un componente de cálculo de
probabilidades dependa de un componente de cálculo matemático básico, en el
caso de acoplamiento arquitectónico, se puede ver un ejemplo en el esquema
MVC (modelo-vista-controlador). La capa del modelo realizará cambios de
acuerdo con los parámetros 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 conexión entre los módulos y la comunicación es a
través de estructuras de datos simples (variables).
• Se envían datos simples y se devuelven simples.
Estampado: Están conectados y la comunicación es a través de estructuras de
datos compuestas (registros).
• Se envían datos compuestos y devuelve simples.
Como el segundo modulo retorna datos simples la relación es de datos y
estampado. En estos casos se toma el de mayor acoplamiento. En ese caso sería
estampado.
De control: Están conectados y la comunicación es a través de un indicador, flag
o señal a partir de la cual se pueden tomar decisiones en el modulo subordinado o
superior.
La desventaja es que hay mucha relación entre los módulos, depende mucho uno
de otro.
• El modulo subordinado, debe saber que opción le manda el superior. El modulo
subordinado no le puede informar al superior que datos debe enviarle.
El objetivo final del diseño de software (o soluciones informáticas) en materia de
estos dos conceptos es: Reducir al máximo el acoplamiento entre componentes y
aumentar la cohesión interna de cada componente.

1.2.2 Arquitectura del software.
Una Arquitectura de Software, también denominada Arquitectura lógica,
consiste en un conjunto de patrones y abstracciones coherentes que proporcionan
el marco de referencia necesario para guiar la construcción del software para un
sistema de información.
La Arquitectura de Software establece los fundamentos para que analistas,
diseñadores, programadores, etc. trabajen en una línea común que permita
alcanzar los objetivos del sistema de información, cubriendo todas las
necesidades.
Una arquitectura de software se selecciona y diseña con base en objetivos y
restricciones. Los objetivos son aquellos prefijados para el sistema de información,
pero no solamente los de tipo funcional, también otros objetivos como la
mantenibilidad, adaptabilidad, flexibilidad e interacción con otros sistemas de
información.
Las restricciones son aquellas limitaciones derivadas de las tecnologías
disponibles para implementar sistemas de información. Unas arquitecturas son
más recomendables de implementar con ciertas tecnologías mientras que otras
tecnologías no son aptas para determinadas arquitecturas.
La arquitectura de software define, de manera abstracta, los componentes
que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación
ente ellos. Toda arquitectura debe ser implementable en una arquitectura física,
que consiste simplemente en determinar qué computadora tendrá asignada cada
tarea.
La Arquitectura del Software es el diseño de más alto nivel de la estructura de un
sistema.

1.3 Heurísticas de diseño.
Heurística de diseño: Las heurísticas de diseño son un conjunto de datos que
ayudan a mejorar la estructura del sistema, optimizando la secuencia.
Tamaño de módulo: El tamaño del módulo está relacionado con la modularidad,
más no solo de manera simple de "cortar en programa en más piezas". Esto es, la
modularidad técnica no se incrementa simplemente cuando el tamaño de módulo
decrece, mientras otros aspectos permanecen igual.
Normalmente, módulos menores a cinco a nueve líneas, deben considerarse para
un replanteo. Esto es especialmente relevante cuando existen muchos de estos
módulos muy pequeños en el sistema.
No siempre módulos muy grandes o muy pequeños son necesariamente malos. La
cuestión importante es que los módulos reflejen la estructura del problema lo más
fielmente posible.
Descomponer un módulo simplemente para llevarlo a un tamaño óptimo, aún
perdiendo su significado con respecto a la estructura del problema, no es una
buena estrategia.
Un módulo demasiado grande a menudo puede deberse a dos razones
principales:
Una factorización incompleta en módulos subordinados apropiados.
Dos o más funciones han sido combinadas (frecuentemente con cohesión
lógica) en un mismo módulo.

En el primer caso, se puede realizar una reducción a través de la identificación y
extracción de subfunciones.

En el segundo caso, podemos descomponer el módulo 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 módulos muy pequeños, debemos distinguir dos casos:
El módulo atómico (nivel más bajo) y modulo atómico.

En el caso de módulos atómicos, las cuestiones a considerar son: la cantidad de
llamadas desde módulos superiores que recibe el módulo (fan-in), y la sobrecarga
(overhead) producido por el proceso de llamada a subrutina.

Un módulo muy pequeño puede ser comprimido en sus módulos superiores.
Pero si el módulo tiene usos múltiples (alto fan-in) puede ser muy peligroso
absorberlo en sus módulos superiores, porque se duplicará el esfuerzo de
implementación y mantenimiento del mismo.
En el caso de que la sobrecarga producida por el mecanismo de llamada a
subrutina

sea

intolerable,

se

puede

testear

y

depurar

el

módulo

independientemente
Cuando el módulo es no atómico, el análisis es más complicado. Las opciones son
comprimir el módulo hacia arriba en su superior, o hacia abajo en un subordinado.
Ambas opciones deben ser consideradas.
Un caso especial es el llamado módulo fantasma, un módulo que lo único que
contiene son llamadas a otros módulos subordinados.
Amplitud del Control (Fan-out)

La amplitud del control o ancho de salida (fan-out), es el número de subordinados
inmediatos de un módulo. Al igual que en con el tamaño de módulo, amplitudes de
control muy altas o muy bajas, son indicadores de un posible diseño pobre.
Una amplitud de control demasiado baja puede incrementarse en la mayoría de
los casos descomponiendo el módulo en subfunciones subordinadas adicionales,
o comprimiendo el módulo en sus superiores.
Una amplitud de control demasiado alta puede ser un indicativo de una reticencia
por parte del diseñador a delegar responsabilidades en módulos subordinados. Sin
embargo en la mayoría de los casos, esto proviene de estructuras "panqueque" o
fallas en la definición de niveles intermedios. Para solucionar este problema, debe

considerarse la posibilidad de agruparse varios subordinados en una función
combinada.
Ancho de Entrada (Fan-In)

Siempre que sea posible, desearemos maximizar el ancho de entrada de un
módulo (fan-in) durante el proceso de diseño. Cada instancia de múltiples
entradas de un módulo, representa que ha podido evitarse duplicidad de código.
Sin embargo, un gran ancho de entrada no es algo que deba buscarse a cualquier
costo. Por ejemplo, es ridículo combinar muchas funciones "no relacionadas" en
un módulo bajamente cohesivo, con el propósito de incrementar el fan-in.
Un gran ancho de entrada es alcanzado a través de un proceso analítico que
acompaña los pasos del proceso de diseño estructurado. Cada vez que vamos a
dibujar un nuevo módulo en el diagrama de estructura, primero debemos verificar
si no existe ya algún otro módulo que realice la función requerida.
Es importante notar que la especificación del fan-in es una tarea del diseñador, no
del implementador (codificador).
La clave está en comprender cual es la parte común de ambos módulos, y aislarlo
en un nuevo módulo. Por ejemplo, supongamos que tenemos una función Q1 que
parece ser similar a Q2. Si Q es la parte común de ambas funciones, podemos
reestructurar

nuestro

diseño

de

la

siguiente

manera:

Alcance de Efecto / Alcance de Control

Cada decisión o sentencia condicional (if-then-else) en un sistema tiene algunas
consecuencias: ciertos procesos se realizarán o no como resultado de una
decisión. Equivalentemente podemos decir que cierto procesamiento es
condicional en base a la salida o resultado de una decisión.
El alcance de efecto de una decisión es la colección de todos los módulos que
contienen algún procesamiento que está condicionado por dicha decisión.
Aunque solo una pequeña parte del procesamiento de un módulo se vea afectada
por la decisión. Si la activación de un módulo completo está condicionada por la
decisión, el módulo superior (invocador) también se incluye dentro del alcance de
efecto.
El alcance de control de un módulo es el módulo mismo y todos sus subordinados.
El alcance de control es un parámetro puramente estructural independiente de las
funciones del módulo.
Todos los módulos que son afectados o influenciados por una determinada
decisión deben estar subordinados finalmente al módulo que toma la decisión.
La toma de decisiones y la estructura modular se interrelacionan mejor cuando las
decisiones se toman a un nivel no más alto que lo necesario dentro de estructura
jerárquica, con el objetivo de ubicar el alcance de efecto dentro del alcance de
control.

2 Diseño de sistemas.
2.1 Modelo estructurado.
El Análisis Estructurado, fue seleccionado como técnica de investigación de
requerimientos, ya que permite al analista conocer el sistema o proceso en una
forma lógica y manejable, al mismo tiempo que proporciona la base para asegurar
que no se omite ningún detalle.
Este es un método para el análisis 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 través de un sistema, la representación
gráfica de los procesos del sistema estará a cargo de los Diagramas de Flujos de
Datos (DFD).
Que se relacionan con el Análisis Estructurado
Símbolos gráficos: 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 técnicas y lenguajes que permiten a los analistas describir actividades
importantes que forman parte del sistema.
• Reglas; estándares para describir y documentar el sistema en forma correcta y
completa.

Fase de diseño:
En esta fase, el diseño estructurado produce el modelo de diseño con los
siguientes elementos:
Diseño de datos: Transforma el modelo de dominio de la información creado
durante el análisis, en las estructuras de datos necesarias para implementar el
software. Los objetos de datos y las relaciones definidas en el diagrama entidadrelación y el contenido detallado de datos del diccionario de datos constituyen la
base para el diseño de datos.
Diseño arquitectónico: Define la relación entre los principales elementos
estructurales del programa. Se obtiene a partir del modelo de análisis y de la
interacción de subsistemas definidos dentro del modelo de análisis.
Diseño 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 información necesaria para
el diseño de la interfaz.
Diseño procedimental: Transforma elementos estructurales de la arquitectura del
programa en una descripción procedimental de los componentes del software. Se
obtiene a partir de la especificación del proceso, la especificación del control y el
diagrama de transición de estados.
Componentes:
Símbolos gráficos: 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: descripción técnica 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 características de los campos y/o descripción
detallada de los diferentes objetos que componen el sistema
Diagrama de estructuras de datos: describe la relación entre las entidades y los
objetos (conjunta de información que contienen las entidades)
Diseño del sistema
El uso de los Diagramas de Flujos de Datos (DFDs), es una herramienta que
permite mostrar gráficamente y de manera general, el funcionamiento del sistema
y los procesos necesarios para su desarrollo.
Los DFDs se pueden dibujar con sólo cuatro notaciones sencillas, en este caso, la
notación 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 están 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 diseño forman parte de las entidades los Justiciables, la cual incluye a
todas aquellas personas que tienen relación directa con el proceso. Las entidades
Secretaria, Juez y Asistente, quienes conforman al órgano jurídico 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 aplicación:

Solicitar Copias Certificadas: en el cual se supervisa que las solicitudes a
procesar estén conforme a los requisitos establecidos por el Código 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 relación 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 emisión directa de las Copias Certificadas solicitadas.
Registro automático 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. Están representados por una flecha para
mostrar su origen y su destino.
Almacén: Representa una colección de paquetes de datos que permanecen en
estado de reposo.
2.2 Modelo orientado a objetos.
Las técnicas 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 Diseño 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 básica es el objeto que combina las estructuras de datos con los
comportamientos en una entidad única.
La fase de análisis determina lo que debe hacer la implementación y la fase de
diseño del sistema determina el plan de ataque.
La fase de diseño de objetos determina las definiciones completas de las clases y
asociaciones que se utilizarán en la implementación, así como las interfaces y
algoritmos de los métodos utilizados para implementar las operaciones. La fase de
diseño de objetos añadirá objetos internos para la implementación
Aspectos generales del diseño de objetos
Durante el diseño de objetos, se ejecuta la estrategia seleccionada durante el
diseño del sistema y se rellenan los detalles.
Se produce un desplazamiento del énfasis pasando de los conceptos del dominio
de la aplicación a los propios de las computadoras.
. Las clases, atributos y asociaciones del análisis deben de implementarse en
forma de estructuras de datos específicas.
Es necesario introducir nuevas clases de objetos para almacenar resultados
intermedios durante la ejecución del programa y para evitar la necesidad de
recalcularlos.
La optimización del diseño no debería llevarse a extremos exagerados porque la
facilidad de implementación y mantenimiento y la extensibilidad son también
objetivos importantes.
La Metodología OMT se extiende desde el análisis hasta la implementación
pasando por el diseño.
En este modelo se toman decisiones importantes que después se completan para
optimizar la implementación en segundo lugar. Los objetos del dominio de la

aplicación constituyen el marco de trabajo del modelo de diseño, pero se
implementan en términos de objetos del dominio de la computadora.
Por último, el modelo de diseño se implementa en algún lenguaje de
programación, base de datos o hardware.
Tipos de modelos
Modelo de Objetos
Describe la estructura estática (de datos), de los objetos del sistema (identidad,
atributos y operaciones) y también 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 jerarquías que comparten
una estructura y comportamiento comunes y que están asociadas a otras clases.
Estas clases definen los atributos que lleva cada instancia de objeto y las
operaciones que efectúa o sufre cada uno.
Modelo dinámico
Describe los aspectos de comportamiento (de control) de un sistema que cambian
con el tiempo. El modelo dinámico se utiliza para especificar e implementar los
aspectos del control del sistema.
Los modelos dinámicos 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 temporización y secuencia de operaciones
(sucesos que marcan los cambios, secuencias de sucesos, estados que definen el
contexto para los sucesos), y la organización de sucesos y de estados.

El modelo dinámico 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 estén
implementadas.
Modelo funcional
Describe las transformaciones (de función), 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 cálculo 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 dinámico 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 código pre elaborado que encapsula alguna
funcionalidad expuesta a través de interfaces estándar.
El paradigma de ensamblar componentes y escribir código 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
características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque
interactivo para la creación 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 reutilización del
software, y la reutilización proporciona beneficios a los ingenieros de software.
Según estudios de reutilización, QSM Associates, Inc. Informa que el ensamblaje
de componentes lleva a una reducción 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 más efectivos para la construcción de grandes
sistemas y aplicaciones de software.
Beneficios del desarrollo de Software basado en componentes
El uso de este paradigma posee algunas ventajas:
• Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización 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 débil acoplamiento
entre componentes, el desabollador es libre de actualizar y/o agregar
componentes según 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 organización, la calidad de una aplicación basada
en componentes mejorará con el paso del tiempo.
La notación 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 relación entre componentes de software,
sus dependencias, su comunicación su ubicación y otras condiciones.
Interfaces
Los componentes también 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 físico del sistema en un
ambiente de producción (o de prueba). Muestra dónde se ubican los
componentes, en qué servidores, máquinas 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 función; las post-condiciones indican lo que

debe ser verdadero después de que un componente haya realizado algún trabajo
y los invariantes especifican lo que debe permanecer verdadero durante la vida del
componente.
Análisis 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, evaluándolo, y con ello decidimos si
continuamos con las fases siguientes y planificamos la próxima actividad.
Ventajas:
El análisis del riesgo se hace de forma explícita 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 identificación 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 difícil).

2.4 Diseño de la Arquitectura del software.
Para poder entender el diseño, es necesario comprender que es la arquitectura de
software.
Diseño de software:
El diseño se ha descrito como un proceso multifase en el que se sintetizan
representaciones de la estructura de los datos, la estructura del programa, las
características de la interfaz y los detalles procedimentales desde los requisitos de
la información.
El diseño:
Una actividad en la que se toman decisiones importantes, frecuentemente de
naturaleza estructural. Comparte con la programación un interés por la
abstracción de la representación de la información y de las secuencias de
procesamiento, pero el nivel de detalle es muy diferente en ambos casos.
Se considera que:
El diseño está dirigido por la información. Los métodos de diseño del software se
obtienen del estudio de cada uno de los tres dominios del modelo de análisis:
La arquitectura de software de un sistema de programa o computación 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, Más bien, es la representación que
capacita al ingeniero del software para:
Analizar la efectividad del diseño para la consecución de los requisitos fijados,

Considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios
en el diseño es relativamente fácil, y
Reducir los riesgos asociados a la construcción del software.

¿Por qué es

importante la arquitectura?

Facilitan la comunicación entre todas las partes interesadas en el desarrollo de un
sistema basado en computadora.
Destaca decisiones tempranas de diseño que tendrán un profundo impacto en
todo el trabajo de ingeniería del software.
Constituye un modelo relativamente pequeño e intelectualmente comprensible de
cómo está estructurado el sistema y de cómo trabajan juntos sus componentes.
El diseño de la arquitectura del software tiene en cuenta 2 niveles de la pirámide,
el diseño de datos y el diseño arquitectónico.
El diseño de datos nos facilita la representación de los componentes de datos de
la arquitectura.
El diseño arquitectónico se centra en la representación de la estructura de los
componentes del software, sus propiedades e interacciones.
En el contexto del diseño arquitectónico:
Un componente del software puede ser tan simple como un módulo de programa,
pero también puede ser algo tan complicado como incluir bases de datos y
software intermedio «middleware») que permiten la configuración de una red de
clientes y servidores
El diseño arquitectónico se centra en la representación de la estructura de los
componentes del software, sus propiedades e interacciones.

Ejemplo de un diseño arquitectónico:

¿Por qué es importante la arquitectura?
Las representaciones de la arquitectura de software facilitan la comunicación entre
todas las partes (partícipes) interesadas en el desarrollo de un sistema basado en
computadora.
El modelo de diseño arquitectónico y los patrones arquitectónicos contenidos
dentro son transferibles.
Estilos arquitectónicos
Cada estilo describe una categoría del sistema que contiene: un conjunto de
componentes, que realiza una función requerida por el sistema, un conjunto de
conectores que posibilitan la comunicación, la coordinación y la cooperación 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 almacén al que otros
componentes acceden con frecuencia para actualizar, añadir, borrar o modificar
los datos del almacén. El software del cliente accede a l almacén 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 programación descompone las
funciones en una jerarquía de control donde un programa principal llama a un

número de componentes del programa, los cuales pueden también llamar a otros
componentes.
Arquitectura de llamada de procedimiento remoto: Los componentes de una
arquitectura de programa principal/subprograma, están 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 comunicación y la coordinación entre componentes se consiguen a
través 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 máquina. 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 arquitectónica: Para evaluar la complejidad total de una
arquitectura dada una técnica 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 transformación
La información debe introducirse y obtenerse del software en forma de mundo
exterior, la información 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 información entrante se pasa a través de un centro de transformación
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 transacción
El flujo de transacción se caracteriza por datos que se mueven a lo largo de un
camino de entrada que convierte la información del mundo exterior en una
transacción. La transacción se evalúa y, basándose en ese valor, se inicia el flujo
a lo largo de uno de muchos caminos de acción. El centro de flujo de información
del que parten muchos de los caminos de acción se denomina centro de
transacción.
Diseño de datos
El diseño de datos (a veces llamado arquitectura de datos) crea un modelo de
datos y/o información que se representa con un alto nivel de Abstracción (la visión
de datos del cliente/usuario).
Este modelo de datos, es refinado en progresivas representaciones específicas de
la implementación, que pueden ser procesadas por un sistema basado en
computadora.
Al nivel de los componentes del programa, el diseño de las estructuras de datos y
de los algoritmos asociados requeridos para su manipulación, son la parte

esencial en la creación de aplicaciones de alta calidad. Al nivel de aplicación, la
traducción 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
información almacenada en las diferentes bases de datos y reorganiza en el
almacén de datos facilita la minería de datos o el descubrimiento de conocimiento
que puede influir en el próximo éxito del negocio
Un almacén de datos es un entorno de datos separado, que no está directamente
integrado con las aplicaciones del día a día, pero que abarca todos los datos
utilizados por una empresa.
Características de un almacén de base de datos:
Orientación por materia: Esto nos lleva a una exclusión de datos que podrían ser
necesarios para una función particular del negocio.
Integración: Sin tener en cuenta la fuente de datos, da consistencia nombrar
convenciones, unidades y medidas, estructuras de codificación y atributos físicos.
Restricción de tiempo: Para un entorno aplicación orientado a transacción, los
datos son precisos en el momento del acceso y por un período de tiempo pequeño
(60 a 90 días) antes del acceso. En un almacén de datos se accede a los datos en
un momento específico de tiempo.
No volatilidad: En el almacén de datos, los datos se cargan, pero después de la
primera transferencia, los datos no cambian.
Modelo de datos
Este modelo de datos, es entonces refinado en progresivas representaciones
específicas de la implementación, 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.
Diseño de datos a nivel de componentes
Se centra en la representación de estructuras de datos a las que se accede
directamente a través de uno o más componentes del software.
Principios para la especificación de los datos:
• Los principios del análisis sistemático aplicado a la función y al comportamiento
deberían aplicarse también a los datos.
• Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de
ellas deberían estar claramente identificadas.
• Se debería establecer un diccionario de datos y usarlo para definir el diseño de
los datos y del programa
• Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del
proceso de diseño.
• La representación de las estructuras de los datos deberían conocerla solo
aquellos módulos que deban hacer uso directo de los datos contenidos dentro de
la estructura.
• Deberían desarrollarse una biblioteca de estructuras de los datos útiles y de las
operaciones que se les pueden aplicar.
• Un diseño del software y un lenguaje de programación debería soportar la
especificación y realización de los tipos abstractos de datos.

2.5 Diseño de Interfaz de usuario.
El diseño 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 información al
usuario y le permiten interactuar con la información y con el computadora.
También se puede considerar parte de la IU la documentación (manuales, ayuda,
referencia, tutoriales) que acompaña al hardware y al software. Si la IU está bien
diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así
puede ser frustrante su operación, 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 presentación es lo que primero capta la
atención del usuario
La presentación no es lo más 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 técnicas de interacción del usuario, a
través de diversos dispositivos. La tercera es la más importante, y es donde el
diseñador determina la metáfora adecuada que encaja con el modelo mental del
usuario. El modelo debe comenzar por esta parte e ir hacia arriba.
Una vez definida la metáfora y los objetos del interfaz, los aspectos visuales
saldrán de una manera lógica y fácil.

Producción de prototipos preliminares y diálogos

El propósito de la interfaz es muy simple: recoger de los usuarios la información
del sistema y ponerla a disposición de otros usuarios. La información recogida se
llama entrada del sistema y se almacena en la base de datos para ponerla a
disposición de los demás usuarios. La información suministrada se llama salida del
sistema. Es decir, el diseño 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 reúnen en formularios en el punto de recepción y después se
introducen en el ordenador al mismo tiempo.
Estas transacciones se procesan y un tiempo después se producen las salidas, las
cuales se pasan al usuario
El diseño de interfaz interactivo provoca un diálogo hombre-máquina que permite
un intercambio rápido de información entre los ordenadores y sus usuarios
humanos, mientras que la interfaz no interactiva utiliza un soporte de papel para
contener la información en el que las entradas normalmente se realizan en

formularios especialmente diseñados 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 función, teclas de ayuda y líneas
de visualización de los mensajes de ayuda.

Ergonomía del diseño de la interfaz
El viaje al mundo del diseño de pantallas comienza con una discusión con el
usuario, la parte más importante de cualquier sistema informatizado
Para realizar un buen trabajo, la interfaz con el ordenador debe ser, entre otras
cosas, lo más fácil, amigable y agradable posible, y se debe usar un diálogo que
se acerque al lenguaje natural en vez de la jerga informática.
Entre las consideraciones a tener cuenta a la hora de diseñar pantallas se
encuentran las siguientes:
Características deseadas: simplicidad, claridad y fácil de comprender. Será
necesario tener claridad visual, de forma que los elementos estén agrupados de
forma comprensible y con significado en vez de al azar y de forma confusa.

Saber dónde situar la información en la pantalla: Será necesario indicar un punto de
partida obvio en la esquina superior izquierda de la pantalla, reservar áreas
específicas de pantalla para diferentes tipos de información (como, por ejemplo,
mandatos, mensajes de error, títulos y campos de datos, de forma que esta consistencia
se mantenga en todas las pantallas) y proporcionar una composición que guste
visualmente (es decir, que esté balanceada, sea simétrica, sea predecible, secuencial,
simple, con agrupamientos, etc.).

Saber qué información situar en la pantalla: Para ello, hay que poner sólo la
información que es esencial para la toma de una decisión o para la ejecución de
una acción (¡No inundar al usuario con información!) 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 cómo situar la información en la pantalla: Así, en cuanto a las fuentes de
letras, se recomienda utilizar minúsculas para el texto con la letra inicial de la frase
en mayúsculas; para las etiquetas, encabezamientos o subtítulos utilizar
mayúsculas.
La interfaz de entrada debe recoger todos los datos necesarios, sin introducir errores,
para el sistema

Las entradas deben estar bien estructuradas y ser fáciles de comprender y utilizar.
Se deben usar nombres precisos y permitir abreviaturas cuando se necesiten
introducciones rápidas de datos. Se deben evitar las entradas repetitivas.
Igualmente, el diseño de la salida asegura que se extraen todos los datos
suministrados por el sistema y que esas salidas están estructuradas de forma que
sean fáciles de leer.
El color añade una nueva dimensión a la facilidad de uso de la pantalla, ya que
atrae la atención del usuario.
Para finalizar, diremos que el diseño de pantallas es un proceso ordenado que
empieza en los requisitos y finaliza con la implementación.
Pruebas del software
Una de las características típicas del desarrollo de software basado en el ciclo de
vida es la realización de controles periódicos, normalmente coincidiendo con los
hitos del proyecto o la terminación de documentos. Estos controles pretenden una
evaluación de la calidad de los productos generados (especificación de requisitos,
documentos de diseño, etc.) para poder detectar posibles defectos cuanto antes.

Las pruebas constituyen un método más para poder verificar y validar el software.
Se puede definir la verificación como
“el proceso de evaluación 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 validación es “el proceso de evaluación de un sistema o de uno
de sus componentes durante o al final del proceso de desarrollo para determinar si
satisface los requisitos especificados”.
Verificación: ¿estamos construyendo correctamente el producto?
Validación: ¿estamos construyendo el producto correcto?
Definiciones
Las siguientes definiciones son algunas de las recogidas en el diccionario IEEE en
relación a las pruebas [IEEE, 1990], que complementamos con otras más
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 evaluación de algún aspecto”.
El nombre “prueba”, además 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 ejecución
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 definición 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 teóricamente correcto. Por ejemplo, una diferencia de dos
centímetros entre el valor calculado y el real.

Un defecto: Por ejemplo, una instrucción incorrecta en un programa.
Un resultado incorrecto: Por ejemplo, un programa ofrece como resultado de la
raíz cuadrada de 36 el valor 7 en vez de 6.
Una acción humana que conduce a un resultado incorrecto (una metedura de
pata).
El proceso de prueba
El proceso de prueba comienza con la generación de un plan de pruebas en base
a la documentación sobre el proyecto y la documentación sobre el software a
probar.

Técnicas de diseño de casos de prueba

El diseño de casos de prueba está totalmente mediatizado por la imposibilidad de
probar exhaustivamente el software. Pensemos en un programa muy sencillo que
sólo suma dos números enteros de dos cifras (del 0 al 99). Si quisiéramos probar,
simplemente, todos los valores válidos que se pueden sumar, deberíamos probar
10.000 combinaciones distintas de cien posibles números 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 diseño de casos de prueba consiste en elegir
algunas de ellas que, por sus características, se consideren representativas del
resto.
Existen tres enfoques principales para el diseño de casos:
El enfoque estructural o de caja blanca. Consiste en centrarse en la estructura
interna (implementación) del programa para elegir los casos de prueba. En este
caso, la prueba ideal (exhaustiva) del software consistiría en probar todos los
posibles caminos de ejecución, a través de las instrucciones del código, que
puedan trazarse.
Pruebas estructurales. (Prueba de la caja negra)
El enfoque funcional o de caja negra, consiste en estudiar la especificación de las
funciones, la entrada y la salida para derivar los casos. Aquí, la prueba ideal del
software consistiría en probar todas las posibles entradas y salidas del programa.
El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones
estadísticos) que representen las posibles entradas al programa para crear a partir
de ellos los casos de prueba. La prueba exhaustiva consistiría en probar todas las
posibles entradas al programa.

Pruebas estructurales. (Prueba de la caja blanca)
El diseño de casos tiene que basarse en la elección de caminos importantes que ofrezcan
una seguridad aceptable en descubrir defecto, y para ello se utilizan los llamados criterios
de cobertura lógica.

2.5 Diseño de bases de datos.
Uno de los pasos cruciales en la construcción de una aplicación que maneje una
base de datos, es sin duda, el diseño de la base de datos.
No importa si nuestra base de datos tiene sólo 20 registros, o algunos cuantos
miles, es importante asegurarnos que nuestra base de datos está correctamente
diseñada para que tenga eficiencia y que se pueda seguir utilizando por largo del
tiempo.

Diseño de bases de datos
Son muchas las consideraciones a tomar en cuenta al momento de hacer el
diseño de la base de datos, quizá las más fuertes sean:

La velocidad de acceso,

El tamaño de la información,

El tipo de la información,

Facilidad de acceso a la información,

Facilidad para extraer la información requerida,

El comportamiento del manejador de bases de datos con cada tipo de
información.

No obstante que pueden desarrollarse sistemas de procesamiento de archivo e
incluso manejadores de bases de datos basándose en la experiencia del equipo
de desarrollo de software logrando resultados altamente aceptables
Objetivos del diseño de bases de datos
Diseño de bases de datos
En este apartado se describen con más detalle los objetivos de cada una de las
etapas del diseño de bases de datos: diseño conceptual, diseño lógico y diseño
físico. La metodología a seguir en cada una de estas etapas se describe en los
tres capítulos que siguen a éste.
Diseño conceptual: En esta etapa se debe construir un esquema de la
información que se usa en la empresa, independientemente de cualquier
consideración física. A este esquema se le denomina esquema conceptual. Al
construir el esquema, los diseñadores descubren la semántica (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 representación física.
•El uso de los datos a través de las áreas de aplicación.
El esquema conceptual se puede utilizar para que el diseñador transmita a la
empresa lo que ha entendido sobre la información que ésta maneja
El diseño conceptual es completamente independiente de los aspectos de
implementación, como puede ser el SGBD que se vaya a usar, los programas de
aplicación, los lenguajes de programación, el hardware disponible o cualquier otra
consideración física
Diseño lógico: El diseño lógico es el proceso de construir un esquema de la
información que utiliza la empresa, basándose en un modelo de base de datos

específico, independiente del SGBD concreto que se vaya a utilizar y de cualquier
otra consideración física.
En esta etapa, se transforma el esquema conceptual en un esquema lógico 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 jerárquico o el modelo orientado a objetos. Conforme se va
desarrollando el esquema lógico, éste se va probando y validando con los
requisitos de usuario.
El esquema lógico es una fuente de información para el diseño físico.
Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen
un punto de inicio y se van refinando continuamente.
El diseño conceptual y el diseño lógico son etapas clave para conseguir un
sistema que funcione correctamente. Si el esquema no es una representación fiel
de la empresa, será difícil, sino imposible, definir todas las vistas de usuario
(esquemas externos), o mantener la integridad de la base de datos.
Diseño físico: El diseño físico es el proceso de producir la descripción de la
implementación de la base de datos en memoria secundaria: estructuras de
almacenamiento y métodos de acceso que garanticen un acceso eficiente a los
datos.
Para llevar a cabo esta etapa, se debe haber decidido cuál es el SGBD que se va
a utilizar, ya que el esquema físico se adapta a él
En general, el propósito del diseño físico es describir cómo se va a implementar
físicamente el esquema lógico 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 métodos de acceso que se
van a utilizar para conseguir unas prestaciones óptimas.
2.6 Diseño de controles y procesos.
Definición de control
El control es una etapa primordial en la administración, pues, aunque una empresa
cuente con magníficos planes, una estructura organizacional adecuada y una
dirección eficiente, el ejecutivo no podrá verificar cuál es la situación real de la
organización 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.
• Reducción de tiempo.
De manufactura
• Reducción de inventario en proceso
• Certificación (mercados internacionales)
• Protección del medio ambiente (desarrollo sustentable)
El proceso de diseño del sistema de control

Para poder diseñar un sistema de control automático, se requiere conocer el
proceso que se desea controlar, es decir, conocer la ecuación diferencial que
describe su comportamiento, utilizando las leyes físicas, químicas y/o eléctricas,
computacionales etc.
Definición de diseño de sistemas
El diseño de sistemas es la evaluación de las distintas soluciones alternativas y la
especificación de una solución detallada a un problema de información.

Controles internos
El diseño de sistemas se encarga de:
1. Analizar y distribuir datos
2. Analizar y distribuir los procesos
3. Dividir en unidades de diseño
4. Diseñar bases de datos y o archivos
5. Diseñar entradas y salidas informáticas
6. Diseñar interfaces interactivas de usuario
7. Presentar y revisar el diseño
Actividades que se desarrollan en el diseño de control y proceso:
• Actividad de Definición de la Arquitectura del Sistema.

• Definición de la arquitectura del sistema.
• Definición de Niveles de Arquitectura.
• Identificación de Requisitos de Diseño y Construcción.
• Especificación de Estándares y Normas de Diseño y Construcción.
• Identificación de Subsistemas de Diseño.
• Especificación de Requisitos de Operación y Seguridad.
• Generación del código de los componentes y procedimientos.
• Generación del Código de Componentes.
• Generación del Código de los Procedimientos de Operación y Seguridad
Actividad de definición de la arquitectura del sistema en esta actividad se
establece:
• El particionamiento físico del sistema de información.
• La organización en subsistemas de diseño.
• La especificación del entorno tecnológico.
• Los requisitos de operación, administración, seguridad y control de acceso.
• Se completan los catálogos de requisitos y normas.
• Se crea un catálogo de excepciones del sistema, en el que se registran las
situaciones de funcionamiento secundario o anómalo que se estime oportuno
considerar y, por lo tanto, diseñar y probar.

Definición de la arquitectura del sistema en esta actividad se define la:
• Arquitectura general del sistema de información, especificando las distintas
particiones físicas del mismo.
• La descomposición lógica en subsistemas de diseño y la ubicación de cada
subsistema en cada partición.
• Se especifica detalladamente la infraestructura tecnológica necesaria para dar
soporte al sistema de información.
• El entorno Tecnológico del Sistema, comprende la especificación del entorno
tecnológico, las restricciones técnicas y la planificación de capacidades.
• Se definen los procedimientos de Operación y Administración del Sistema. •
Procedimientos de Seguridad y Control de Acceso.
• Se definen los requisitos de operación, seguridad y control, especificando los
procedimientos necesarios para su cumplimiento.
Definición de niveles de arquitectura
En esta tarea se describen los niveles de la arquitectura software, mediante la
definición de las principales particiones físicas del sistema de información,
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 impresión.
• Monitores de teleproceso.

• Servidores.
• Comunicaciones.
Identificación de requisitos de diseño y construcción
En esta tarea se realiza la especificación de los requisitos que están directamente
relacionados con el diseño o la construcción del sistema de información.

Estos requisitos son:
• Lenguajes.
• Rendimiento de los distintos elementos de la arquitectura.
• Criterios de ubicación de módulos y datos en los distintos nodos.
•Especificación de Estándares y Normas de Diseño y Construcción.
•En esta tarea se definen:
• Los estándares técnicos o normas.
• Recomendaciones que están relacionados con la adopción o diseño de una
arquitectura o infraestructura tecnológica concreta, y que condicionan el diseño o
la construcción del sistema de información.
Identificación de subsistemas de diseño.
En esta tarea se divide de forma lógica el sistema de información en subsistemas
de diseño, con el fin de reducir la complejidad y facilitar el mantenimiento.

Especificación de requisitos de operación y seguridad.
El objetivo de esta tarea es definir los procedimientos de seguridad y operación
necesarios para el adecuado funcionamiento del sistema y garantizar el
cumplimiento de los niveles de servicios que exigirá el sistema en cuanto a la
gestión de operaciones

Para ello, se diseñan los procedimientos relacionados con:
• Acceso al sistema y a sus recursos (datos, transacciones, librerías, etc.).
• Mantenimiento de la integridad y confidencialidad de los datos.
• Control y registro de accesos al sistema (logs, certificación, etc.).
• Copias de seguridad y recuperación de datos y su periodicidad.
• Recuperación ante catástrofes.
• Se definen los requisitos de operación para los distintos elementos del sistema
(módulos, clases, estructuras físicas de datos, sistemas de ficheros)
• Control y planificación de trabajos.
• Recuperación y reanudación de trabajos.
• Distribución de información generada por el sistema.
• Control y seguimiento del correcto funcionamiento de los procedimientos de
backup y recuperación utilizados habitualmente.

Generación del código de los componentes y procedimientos.
El objetivo de esta actividad es la codificación de los componentes del sistema de
información
Generación del Código de Componentes
En esta tarea se genera el código correspondiente a cada uno de los
componentes del sistema de información, identificados en la tarea Definición de
Componentes y Subsistemas de Construcción.
Generación del Código de los procedimientos de operación y seguridad
• El objetivo de esta tarea es generar los procedimientos de operación y
administración del sistema de información, así como los procedimientos de
seguridad y control de acceso, necesarios para ejecutar el sistema una vez que se
haya implantado y esté en producción.
• Para la generación de dichos procedimientos se tienen en cuenta, también, los
estándares y normas de la instalación recogidos en el catálogo de normas.

2.7 Aplicación de métricas para la evaluación del diseño.
Una métrica es un instrumento que cuantifica un criterio.
El concepto de métrica es el término que describe muchos y muy variados casos
de medición. Siendo una métrica una medida estadística (no cuantitativa como en
otras disciplinas ejemplo física) que se aplica a todos los aspectos de calidad de
software, los cuales deben ser medidos desde diferentes puntos de vista como el
análisis, construcción, funcional, documentación, métodos, proceso, usuario, entre
otros.

Las métricas
En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto
el proceso técnico 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 medición es muy común en el mundo de la ingeniería
Desgraciadamente la medición se aleja de lo común en el mundo de la ingeniería
del software.
Las mediciones del mundo físico pueden englobarse en dos categorías: medidas
directas y medidas indirectas.

Medidas directas: En el proceso de ingeniería se encuentran el costo, y el
esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el
tamaño 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.
Métricas del software: Son las que están relacionadas con el desarrollo del
software como funcionalidad, complejidad, eficiencia.
Métricas técnicas: Se centran en las características de software por ejemplo: la
complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el
cómo está hecho.
Métricas de calidad: proporcionan una indicación de cómo se ajusta el software a
los requisitos implícitos y explícitos del cliente. Es decir cómo voy a medir para
que mi sistema se adapte a los requisitos que me pide el cliente.

Métricas de productividad: Se centran en el rendimiento del proceso de la
ingeniería del software. Es decir que tan productivo va a ser el software que voy a
diseñar.
Métricas orientadas a la persona: Proporcionan medidas e información 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 métodos.
Métricas orientadas al tamaño: 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 organización de software mantiene
registros sencillos.
Métricas orientadas a la función: Son medidas indirectas del software y del
proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas
orientadas a la función se centran en la funcionalidad o utilidad del programa.
Las métricas orientadas a la función fueron
Los puntos de función que obtienen utilizando una función empírica basando en
medidas cuantitativas del dominio de información 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 más alto de la organización.
Definición y Organización: Detalla y concreta la descripción del PSI asignando
un calendario y recursos humanos al mismo.
Estudio información relevante: Se analiza información de interés para el
correcto desarrollo del plan de sistemas
Identificación requisitos: Obtiene la especificación de requisitos que deben
tener los sistemas de información analizados por el plan de sistemas.
Estudio S.I. actuales: Obtiene una valoración de la situación actual.

Diseño modelo: Identifica y define los S.I. Que van a dar soporte a los procesos
afectados por el Plan de Sistemas de Información.
Arquitectura tecnológica: Se propone la arquitectura tecnológica que dé soporte
al modelo de información y sistemas de información.
Definición plan: Se elabora y detalla el plan de sistemas de información:
definición de proyectos, actividades, calendario y recursos para implementar los
sistemas de información e infraestructura tecnológica
Revisión y aprobación: Se somete el plan a la revisión última y aprobación de la
dirección.

Métricas como planeación de sistemas
Los objetivos principales de las métricas
•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 métricas
Uno de los problemas que tienen las métricas es que no existe un esquema de
criterios generalmente aceptado (un estándar). Como no hay acuerdo en los
criterios involucrados, abundan las propuestas de métricas que abordan la calidad
con criterios propios.

Características de las métricas
Localización: La localización es una característica del software que indica la
forma que se concentra la información dentro de un programa.
Encapsulamiento: define el encapsulamiento como “el empaquetamiento (o
enlazado) de una colección de elementos.
Ocultamiento de información: El ocultamiento de información 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 jerarquía de clases
Abstracción: La abstracción es un mecanismo que permite al diseñador centrarse
en los detalles esenciales de algún componente de un programa (tanto si es un
dato como si es un proceso) sin preocuparse por los detalles de nivel inferior.

3

Construcción.

3.1 Selección del ambiente operativo y lenguaje de desarrollo.
Para seleccionar la plataforma para el desarrollo de la aplicación 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 aplicación vaya a
interactuar con otros sistemas), tomar en cuenta las bondades que ofrece el
lenguaje de programación,
En cuanto a lenguajes de programación para aplicaciones web hay también varios
lenguajes, algunos muy conocidos como PERL, PHP, VBScript, C#, Java, que nos

ayudan a estas tareas, son flexibles e interactúan 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
información por lo que nos brindan grandes ventajas para este tipo de aplicaciones
Después de configurar y tener todo listo, procedemos al desarrollo de la
aplicación, la cual se realizará de acuerdo a los procedimientos y condiciones
establecidas en la etapa de diseño
Al realizar esta fase también debemos someter a una evaluación el desarrollo para
ver si requieren ajustes o bien van quedando correctos los programas.
3.2 Elaboración de programas.
Partiendo del concepto que se tiene sobre planeación y programación que para
algunas personas son equivalentes, algunos estudios de estos asuntos define al
primer término como el aspecto global de un proceso de desarrollo y al segundo
con un grado de mayor concreción, indicando las partes y condiciones de un
periodo de tiempo dado.

Desarrollo de los aspectos de un programa
Justificación: Se refiere a la exposición de los motivos que fundamentan la
aplicación del programa
Objetivos: Son las metas o fines que se desean alcanzar con la realización del
programa, los objetivos que se establezcan deben ser determinados como
resultado de la adecuada estimación de problemas y recursos, y deben ser
precisos
Limitación del programa
Espacio: Es el área donde se desarrollara la acción.

Determinación y precisión de actividades: Comprende la especificación de las
actividades que necesitan efectuarse para alcanzar los objetivos
Tiempo y calendario de actividades: Se refiere a los días meses o años durante
los cuales se llevará a cabo el programa.
Universo de Trabajo: Es la determinación del número y tipo de personas que se
beneficiaran al ejercer la acción del programa.
Dentro de Organización:
Procedimientos
Métodos de las actividades: Se refiere a la manera de cómo 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á coordinación y la forma
como colaborará cada uno en el programa.
Material y equipo: Se refiere al equipo que se necesitará para la realización del
programa.
Locales: Se refiere a los lugares cerrados o abiertos donde se ejecutara el
programa.
Instructivos y reglamentos: Las instrucciones de las técnicas que se vayan ha
emplear. Los reglamentos son las normas que

regirán

el desarrollo de las

actividades o de las labores.
Personal: Se refiere a las personas que participarán en la aplicación del
programa.
Tipo y número: Como su nombre lo indica es el número de personas que
intervendrán en la ejecución del programa

Determinación de funciones: Estas pueden ser la línea desde el punto de vista
jerárquico, de actividades según los integrantes del personal y supervisión que
determinan por quienes y como desarrollará esta labor.
Reclutamiento: Se refiere a la descripción de cómo y dónde se seleccionará el
personal necesario.
Adiestramiento: Se relaciona con la preparación especial que se impartirá al
personal seleccionado.
Financiamiento
Elaboración del presupuesto: Se trata de especificar el presupuesto que se
requerirá para la ejecución del programa y se deben desglosar las diversas
partidas que lo integran.
Plan de obtención de fondos: Se refiere a la manera como se piensa obtener los
fondos que se necesitan para cubrir el presupuesto.
Evaluación: Es la estimación de las realizaciones del programa con relación a los
objetivos y procedimientos señalados

La evaluación puede ser:
• Simultánea y al final del programa.
• Cuantitativa y Cualitativa.
• Interna y externa. Se denomina simultánea, cuando se efectúa durante el
desarrollo del programa y al final si se realiza al término de él.

3.2.1 Implementación.
Fases de implementación
1ra. Fase: seleccionar el sector productivo o empresa, en el cual se desarrollara el
trabajo.
Se toma en cuenta las políticas de Formación 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: sensibilización del sector productivo, campaña de información y
divulgación para involucrar a los diferentes actores sociales (empleadores,
trabajadores, gobierno, etc.).
4ta Fase: Constitución de las comisiones técnicas, el comité estará integrado por
representantes del sector productivo y del sistema de formación profesional,
contemplándose la participación de otros profesionales independientes del sector
5ta Fase: Capacitación del comité de normalización, la capacitación se basa en
talleres y jornadas de trabajo sobre competencia laboral y explicación de la
metodología para elaborar las NCL.
6ta Fase: Determinación de las competencias laborales, Se determinan aplicando
el Análisis Funcional, lo que producirá una serie de competencias laborales, las
cuales conformarán un Mapa Funcional
Propósito principal del sector productivo o empresa
Consiste en la identificación 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 Métricas para evaluar el software.
Métricas para la evaluación de software
Las métricas 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 métodos y herramientas de ingeniería del software.
• Establecer una línea base para la estimación.
• Justificar el uso de nuevas herramientas o de formación adicional.
Pero es necesario utilizar las métricas más 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 código 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
específicos.

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
Después de que los programas han sido verificados, probados e implantados, se
les debe seguir dando mantenimiento
3.5 Implementación.
Es la última fase del desarrollo de Sistemas. Es el proceso instalar equipos o
Software nuevo, como resultado de un análisis y diseño previo como resultado de
la sustitución o mejoramiento de la forma de llevar a cavo un proceso
automatizado.
Existen varios enfoques de implementación:
•Uso de diferentes estrategias para el entrenamiento de los usuarios.

•El Analista de Sistemas necesita ponderar la situación y proponer un plan de
conversión que sea adecuado para la organización.
•El Analista necesita formular medidas de desempeño con las cuales evaluar a los
Usuarios.

3.6 Documentación.
La documentación consiste en material que explica las características técnicas y la
operación de un sistema
Documentación:
Bajo este término genérico se agrupan todos los manuales, guías 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 documentación.
La de programas: que explica la lógica 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 cómo usarlo

3.6.1 Elaboración del manual de usuario.
Manual de Usuario: Esta parte se divide en dos manuales distintos, uno por cada
aplicación 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. Introducción: Describe el uso del documento (¿para qué sirve?) y ¿de qué
habla?
3. Análisis y requerimientos del sistema (¿que se ocupa para poder instalarlo y
usarlo?)
4. Explicación del funcionamiento: Debes de poner paso a paso y con pantallas
bien explicadas cómo 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 más mínimo 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.

Instalación del sistema

Iniciación al uso del sistema

Manual de referencia

Caducidad de documento fuente y destino final

3.6.2 Elaboración del manual de administración.
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 técnica

Programa de trabajo

Participantes

Responsable de su autorización

Captación de la información

Levantamiento de la información

Investigación documental

Consulta a sistemas de información

Encuesta

Observación directa

Análisis de la información: En esta etapa se debe realizar un estudio o examen
crítico de cada uno de los elementos de información o grupos de datos que se
integraron con el propósito de conocer su naturaleza, características y
comportamiento
Técnicas de apoyo para el análisis: En esta fase comprende los recursos
técnicos que se emplean para estudiar la información obtenida con el fin de
conocerla en forma detallada t determinar alternativas de acción específicas que
permitan derivar soluciones óptimas para lograr los resultados deseados
Organizacionales
Preparación del proyecto del manual: Una vez que se cuenta con toda la
información del manual se procederá a integrarlo; para tal actividad se requiere

convocar a todos los participes de la presentación del manual, para revisión del
contenido y presentación de cada apartado
3.6.3 Elaboración del manual técnico.
Este documento contiene toda la información sobre los recursos utilizados por el
proyecto, llevan una descripción muy bien detallada sobre las características
físicas y técnicas de cada elemento.
Este documento debe incorporar la siguiente información:
• Portada
Logotipo de la organización.
• Nombre oficial de la organización
• Denominación y extensión. De corresponder a una unidad en particular debe
anotarse el nombre de la misma.
• Lugar y fecha de elaboración.
• Número de revisión (en su caso).
• Unidades responsables de su elaboración, revisión y/o autorización.
• Clave de la forma. En primer término, las siglas de la organización, en segundo
lugar las siglas de la unidad administrativa donde se utiliza la forma y, por último,
el número de la forma. Entre las siglas y el número debe colocarse un guión o
diagonal. (En su caso).
Estructura del documento manual técnico
• Índice
Relación de los capítulos y páginas correspondientes que forman parte del
documento
• Introducción.

Se debe presentar una breve descripción del sistema desarrollado, que contemple
el ámbito abarcado, cual es su función principal y un detalle de las funciones
macros o partes que lo componen. Puede incluir un mensaje de la máxima
autoridad de las áreas comprendidas en el manual.
•Objetivo general del sistema
Se debe de describir el objetivo general del sistema.
•Objetivos específicos
Se deben describir brevemente los objetivos específicos que se cumplieron con el
desarrollo del sistema.
•Contenido técnico.
•Definición 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.
•Descripción de campos requeridos por pantalla con presentación de pantallas.
•Diagrama de navegación del sistema.
• Requerimientos de interfaz con otros sistemas.
• Modelo lógico de datos, diagrama entidad-relación.
•Modelo de datos físico, junto con su respectivo diccionario de datos.
• Matriz de procesos versus organización.
•Matriz de programas versus entidades.

4

Estudio de casos prácticos para mantenimiento.

4.1 Tipos de mantenimiento.
Existen cuatro tipos reconocidos de operaciones de mantenimiento, los cuales
están en función del momento en el tiempo en que se realizan, el objetivo
particular para el cual son puestos en marcha, y en función a los recursos
utilizados
Existen varios tipos de mantenimiento que a continuación mencionaremos:
Mantenimiento correctivo:
Este mantenimiento también es denominado “mantenimiento reactivo”, tiene lugar
luego que ocurre una falla o avería, 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 día 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, documentación, 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, análisis, limpieza,
lubricación, calibración, que deben llevarse a cabo en forma periódica 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 débiles en la instalación entre una larga lista de
ventajas.

El mantenimiento preventivo consiste en la revisión periódica 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 también es denominado “mantenimiento planificado”, tiene
lugar antes de que ocurra una falla o avería, se efectúa bajo condiciones
controladas sin la existencia de algún error en el sistema.
Mantenimiento predictivo:
Consiste en determinar en todo instante la condición técnica (mecánica y eléctrica)
real de la máquina examinada, mientras esta se encuentre en pleno
funcionamiento, para ello se hace uso de un programa sistemático de mediciones
de los parámetros más importantes del equipo.
Tiene como objetivo disminuir las paradas por mantenimientos preventivos, y de
esta manera minimizar los costos por mantenimiento y por no producción
El mantenimiento predictivo es una técnica para pronosticar el punto futuro de falla
de un componente de una máquina, 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,
colaboración, iniciativa propia, sensibilización, trabajo en equipo, de moto tal que
todos los involucrados directa o indirectamente en la gestión del mantenimiento
deben conocer la problemática del mantenimiento
El Mantenimiento Proactivo, es una filosofía de mantenimiento, dirigida
fundamentalmente a la detección y corrección de las causas que generan el
desgaste y que conducen a la falla de la maquinaria.

El Mantenimiento Proactivo, establece una técnica de detección temprana,
monitoreando el cambio en la tendencia de los parámetros considerados como
causa de falla, para tomar acciones que permitan al equipo regresar a las
condiciones establecidas que le permitan desempeñarse adecuadamente por más
tiempo
4.2 Técnicas de mantenimiento.
Dentro de la ingeniería del software se proporcionan soluciones técnicas que
permiten abordar el mantenimiento de manera que su impacto en coste dentro del
ciclo de vida sea menor. Las soluciones técnicas pueden ser de tres tipos:
Ingeniería inversa: Análisis de un sistema para identificar sus componentes y las
relaciones entre ellos
Reingeniería: Modificación de un producto software, o de ciertos componentes,
usando para el análisis del sistema existente técnicas de ingeniería inversa y, para
la etapa de reconstrucción, herramientas de ingeniería directa
Reestructuración del software: Cambio de representación de un producto
software, pero dentro del mismo nivel de abstracción
También existen otras tecnologías, como por ejemplo:
La remodularización: consiste en cambiar la estructura modular de un sistema de
forma que se obtenga una nueva estructura siguiendo los principios del diseño
estructurado.
Visualización: el proceso más antiguo para la comprensión del software.
Análisis y mediciones: son importantes tecnologías que estudian ciertas
propiedades de los programas.
4.3 Análisis 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.
•Insatisfacción del cliente cuando no se puede atender en un tiempo aceptable una
petición de reparación 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.
•Insatisfacción del cliente cuando no se puede atender en un tiempo aceptable una
petición de reparación 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 económica:
Un estudio de funciones, rendimiento y restricciones que puedan afectar la
realización de un sistema aceptable.

Viabilidad Legal:
Es determinar cualquier posibilidad de infracción, violación o responsabilidad legal
en que se podría incurrir al desarrollar el Sistema.

Alternativas: Una evaluación 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 Administración del Mantenimiento.
El principal objetivo del mantenimiento es optimizar la disponibilidad de los
equipos al mínimo costo.
El mantenimiento tiene que ver con preservar los activos físicos.
La mayoría de los equipos tiende a fallar más 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 información de fallas antes de desarrollar
estrategias de mantenimiento exitosas.
El mantenimiento afecta todos los aspectos del negocio y no solo disponibilidad y
costos, afecta también a la seguridad, la integridad ambiental, la eficiencia
energética y calidad de productos.
El mantenimiento afecta todos los aspectos del negocio y no solo disponibilidad y
costos, afecta también a la seguridad, la integridad ambiental, la eficiencia
energética 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.