INDICE

INTRODUCCIÓN...............................................................................................................2
CAPITULO 1. INGENIERÍA DEL SOFTWARE.......................................................................3
El Software y el Proceso..................................................................................................3
1.1 Características del software...........................................................................................3
1.2 Componentes del software............................................................................................4
1.3 Aplicaciones del software.............................................................................................5
1.4 Ingeniería del Software.................................................................................................6
1.5 Sistemas Basados en Computadora...............................................................................9
1.6 Ingeniería de la información.......................................................................................11
1.7 Ingeniería de productos...............................................................................................11
2. Gestión de proyectos de software.............................................................................11
2.1 Planificación de proyectos..........................................................................................13
2.2 Actividades asociadas a la planificación de proyectos de software............................14
2.3 Estimación del proyecto de software..........................................................................15
2.4 Modelos empíricos de estimación ..............................................................................16
2.5 Herramientas automáticas de estimación....................................................................17
3. Análisis de sistemas..................................................................................................17
3.1 Identificación de las necesidades (análisis de requisitos)...........................................18
3.2 Estudio de la viabilidad...............................................................................................21
3.3 Análisis técnico y económico......................................................................................22
3.4 Modelado de la arquitectura del sistema.....................................................................23
3.5 Especificación del sistema..........................................................................................23
3.6 Creación de prototipos del software...........................................................................24
1.4 Diseño de sistemas.................................................................................................25
1.4.1 Diseño de datos........................................................................................................25
1.4.2 Diseño arquitectónico...............................................................................................26
1.4.3 Diseño de la interfaz.................................................................................................27
4.4 Diseño procedimental..................................................................................................27
1.4.4 Arquitectura del software.........................................................................................28
1.4.6 Criterios para evaluar la calidad del diseño.............................................................28
1.5 Desarrollo de software ..........................................................................................29
1.6 Prueba del software..............................................................................................29
1.6.1 Objetivos de la prueba..............................................................................................30
1.6.2 Verificación y validación.........................................................................................30
1.7 Implantación ..........................................................................................................30
1.7.1 Capacitación de usuarios del sistema.......................................................................30
1.7.2 Evaluación del sistema.............................................................................................31
1.8 Mantenimiento ......................................................................................................31
1.9 Calidad del Software...............................................................................................32
1.9.1 Factores de calidad del software..............................................................................33
1.10.2 Bibliografía............................................................................................................34
5.2 Bibliografía.................................................................................................................34
INTRODUCCIÓN

Las técnicas de modelación de objetos constituyen una nueva forma de pensar acerca de los
problemas, empleando diversos modelos que se organizan a partir del mundo real. Los
modelos orientados a objetos son útiles para comprender los problemas, comunicarse con
los expertos de la aplicación, modelar la empresa, documentar y diseñar programas y bases
de datos.

La esencia del desarrollo orientado a objetos es la identificación y organización de

conceptos del dominio de la aplicación y no de su representación final en un lenguaje de
programación. El desarrollo orientado a objetos es un proceso conceptual, es una forma de
pensar y no una técnica de programación. . Sus beneficios mayores proceden de la ayuda
que ofrecen a quienes construyen las especificaciones, a los desarrolladores y a los clientes
para que expresen conceptos abstractos y se comuniquen unos con otros.

El Lenguaje Unificado de Modelado (UML Unified Modeling Language) es un lenguaje

gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema con
gran cantidad de software. Proporciona una forma estándar de describir los planos del
sistema, cubriendo las cosas conceptuales tales como: procesos de negocio y funciones del
sistema, así como las cosas concretas tales como: clases escritas en un lenguaje de
programación, esquemas de bases de datos y componentes reutilizables.

La metodología de análisis y diseño orientados a objetos OMT es un proceso para la

producción organizada de software orientado a objetos, consta de una serie de etapas o
pasos a seguir que se organizan dentro de un ciclo de vida con varias fases de desarrollo, y
que van desde la formulación inicial del problema, pasando por el análisis, diseño,
implementación y prueba del software, y una fase adicional de mantenimiento si es
necesaria. Está basada en el uso de una notación orientada a objetos para describir clases y
relaciones a lo largo de todo el ciclo vital.

En el presente material se expone en su primera parte un resumen de la Ingeniería del

Software, pasando por las diferentes etapas del ciclo de vida del desarrollo de un software.
En su segunda parte se presenta el lenguaje de representación gráfica UML, de manera que
usted pueda dominar el vocabulario, reglas y especificaciones del lenguaje, así como usarlo
para resolver problemas. En su tercera parte se presenta un resumen de la metodología
OMT de análisis y diseño orientados a objetos, con el objetivo de que se conozcan los
distintos pasos a seguir en la creación de software.
.

2
CAPITULO 1. INGENIERÍA DEL SOFTWARE

El Software y el Proceso.

¿Qué es realmente el software? El software es un producto que permite la utilización de la

potencia del hardware informático en su mayor medida, produciendo y gestionando
información, mostrándola y modificándola. Es la base de control de la computadora
(sistemas operativos), la comunicación de información (redes), y hasta de la creación y
control de otros softwares (herramientas de desarrollo y entornos). Entrega información
(considerada por muchos el producto más importante) y proporciona el medio de adquirirla,
gestiona información comercial en vistas a mejorar la competitividad, permite el acceso a
las redes de comunicación (Internet). Su papel ha cambiado mucho desde las décadas
anteriores a la actualidad, provocado esto por las grandes mejoras en el hardware y los
cambios en las arquitecturas informáticas, como son el aumento de la capacidad de
memoria y de almacenamiento.

Sin embargo, persisten y aumentan un conjunto de problemas relacionados con el software.

Entre ellos tenemos que los avances del hardware dejan atrás la capacidad de producir
software para alcanzar el potencial del mismo, la demanda de nuevos programas es más
grande que la capacidad de producción de software y por tanto no se cubren las necesidades
del mercado y los negocios, la sociedad es cada vez más dependiente de la fiabilidad del
software y sus fallos provocan daños económicos y a veces humanos grandes, por lo cual se
lucha por un software de alta calidad y fiabilidad.

El software puede considerarse como:

1. instrucciones (programas de computadoras) que cuando se ejecutan proporcionan la
función y el rendimiento deseados,
2. estructuras de datos que permiten a los programas manipular adecuadamente la
información, y
3. documentos que describen la operación y el uso de programas.

1.1 Características del software

Para poder comprender lo que es el software (y consecuentemente la ingeniería del

software), es importante examinar las características del software que lo diferencian de
otras cosas que los hombres pueden construir. Cuando se construye hardware, el proceso
creativo humano se traduce finalmente en una forma física. El software es un elemento del
sistema que es lógico, en lugar de físico, por tanto el software tiene características
considerablemente distintas a las del hardware:

♦ El software se desarrolla, no se fabrica en un sentido clásico. Aunque existen

similitudes entre el desarrollo del software y la construcción del hardware, ambas
actividades son diferentes, en ellas la buena calidad se adquiere mediante un buen

3
 diseño, pero la fase de construcción del hardware puede introducir problemas de calidad
que no existen (o son fácilmente corregibles) en el software. Ambas actividades
dependen de las personas y requieren de métodos de construcción del producto final,
pero la relación entre las personas dedicadas y el trabajo realizado es completamente
diferente para el software, así como los métodos utilizados.

♦ El software no se «estropea». Los fallos iniciales en el hardware una vez corregidos

hacen que la tasa de fallos baje a un nivel donde permanece hasta un período de tiempo
en que los componentes de hardware sufren los efectos acumulativos de la suciedad, la
vibración, los malos tratos, las temperaturas extremas y muchos otros males externos.
Sencillamente, el hardware comienza a estropearse. El software no es susceptible a los
males del entorno que hacen que el hardware se estropee. Los defectos no detectados
harán que falle el programa durante las primeras etapas de su vida pero estos se
corrigen.

La implicación es clara, el software no se estropea, pero se deteriora, pues sufre

cambios (mantenimientos) en su vida y conforme se hacen los cambios, es bastante
probable que se introduzcan nuevos defectos, haciendo que se solicite otro cambio.
Lentamente, el nivel mínimo de fallos comienza a crecer; el software se va deteriorando
debido a los cambios. Cada fallo en el software indica un error en el diseño o en el
proceso mediante el que se tradujo el diseño a código máquina ejecutable. Por tanto, el
mantenimiento en el software es más complejo que en el hardware, pues para este
último se cuenta con piezas de repuesto, lo cual no es así en el caso del software.

♦ La mayoría del software se construye a medida, en vez de ensamblar componentes

existentes. Para el diseño y construcción de hardware de control para un producto
basado en un microprocesador el ingeniero construye un esquema de la circuitería
digital, hace algún análisis fundamental para asegurar que se realiza la función adecuada
y va al catálogo de ventas de componentes digitales existentes, donde cada circuito
integrado tiene un número de pieza, una función definida y válida, una interfaz bien
definida y un conjunto estándar de criterios de integración, selecciona cada componente,
y solicita la compra. Para el software no se dispone de esa comodidad que acabamos de
describir. Con pocas excepciones, no existen catálogos de componentes de software.
Se puede comprar software ya desarrollado, pero sólo como una unidad completa, no
como componentes que pueden reensamblarse en nuevos programas, aunque ya se está
comenzando a ver las primeras implementaciones con éxito de este concepto.

1.2 Componentes del software

A medida que la disciplina del software evoluciona, se crea un grupo de componentes de

diseño estándar. Los componentes reutilizables se han creado para que el ingeniero pueda
concentrarse en elementos verdaderamente innovadores de un diseño. En el mundo del
hardware, la reutilización de componentes es una parte natural del proceso de ingeniería.
En el mundo del software, es algo que todavía se tiene que lograr en una escala amplia.

4
La reutilización es una característica importante para un componente de software de alta
calidad. El componente debería diseñarse e implementarse para que pueda volver a ser
reutilizado en muchos programas diferentes. En los años sesenta se construyeron
bibliotecas de subrutinas científicas reutilizables en una amplia serie de aplicaciones
científicas y de ingeniería. Esas bibliotecas de subrutinas reutilizaban de forma efectiva
algoritmos bien definidos, pero tenían un dominio de aplicación limitado. Hoy en día, se ha
extendido la visión de reutilización para abarcar no sólo los algoritmos, sino también
estructuras de datos. Los componentes reutilizables modernos encapsulan tanto datos como
procesos que se aplican a los datos, permitiendo al ingeniero del software crear nuevas
aplicaciones a partir de las partes reutilizables.

1.3 Aplicaciones del software

El software puede aplicarse en cualquier situación en la que se haya definido previamente

un conjunto específico de pasos procedimentales Dos factores importantes a considerar
para determinar la naturaleza de una aplicación de software son: el contenido y
determinismo de la información. El contenido se refiere al significado y a la forma de la
información de entrada y de salida. El determinismo de la información se refiere a la
predecibilidad del orden y del tiempo de llegada de los datos. Un programa de ingeniería
acepta datos que están en un orden predefinido, ejecuta el algoritmo sin interrupción y
produce los datos resultantes en un informe o formato gráfico.

El software, según tipos de aplicaciones, se pueden clasificar como:

 Software de sistemas. Es un conjunto de programas que han sido escritos para servir
a otros programas. Algunos programas de sistemas (por ejemplo, compiladores,
editores y utilidades de gestión de archivos) procesan estructuras de información
complejas, pero determinadas. Otras aplicaciones de sistemas, como ciertos
componentes del sistema operativo, utilidades de manejo de periféricos y procesadores
de telecomunicaciones procesan datos en gran medida indeterminados.

 Software de tiempo real. Mide, analiza y controla sucesos del mundo real
conforme ocurren. Entre sus elementos se incluyen: un componente de adquisición de
datos que recolecta y da formato a la información recibida del entorno externo, un
componente de análisis que transforma la información según lo requiera la aplicación,
un componente de control/salida que responda al entorno externo y un componente de
monitorización que coordina todos los demás componentes, de forma que pueda
mantenerse la respuesta en tiempo real.

 Software de gestión. El procesamiento de información comercial constituye la

mayor de las áreas de aplicación del software. Los «sistemas discretos» (nóminas,
inventarios, etc.) han evolucionado hacia el software de sistemas de información de
gestión (SIG), que accede a una o más bases de datos grandes que contienen
información comercial.

5
  Software de ingeniería y científico. Está caracterizado por los algoritmos de
«manejo de números». Las aplicaciones van desde la astronomía a la vulcanología,
desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas
espaciales y desde la biología molecular a la fabricación automática. Sin embargo, las
nuevas aplicaciones del área de ingeniería y ciencia se han alejado de los algoritmos
convencionales numéricos. El diseño asistido por computadoras (del inglés CAD), la
simulación de sistemas y otras aplicaciones interactivas, han comenzado a coger
características del software de tiempo real e incluso del software de sistemas.

 Software empotrado. Los productos inteligentes se han convertido en algo común

en casi todos los mercados de consumo e industriales. El software empotrado reside en
memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados
industriales y de consumo. El software empotrado puede ejecutar funciones muy
limitadas y curiosas, por ejemplo, el control de las teclas de un horno de microondas.

 Software de computadoras personales. Este mercado ha florecido en la pasada

década. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora,
multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de
negocios y personales, y redes o acceso a bases de datos externas son algunas de los
cientos de aplicaciones.

 Software de Inteligencia Artificial. Este hace uso de algoritmos no numéricos para

resolver problemas complejos para los que no son adecuados el cálculo o el análisis
directo. Actualmente, el área más activa de la IA es la de los sistemas expertos o
basados en el conocimiento. Otras áreas de aplicación para este software son el
reconocimiento de patrones (imágenes y voz), la prueba de teoremas y los juegos. En
los últimos años se ha desarrollado una nueva rama del software de IA llamada redes
neuronales artificiales.

1.4 Ingeniería del Software

La Ingeniería del Software es un área de la informática que ofrece métodos y técnicas para
desarrollar y mantener software de calidad que resuelvan problemas de todo tipo. La
Ingeniería del Software es una nueva ingeniería. Una selección de las definiciones de
“Ingeniería del Software” se muestra a continuación:

Definición de Fritz Bauer, 1972:

Ingeniería del Software trata del establecimiento de principios y métodos de la
ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en
maquinas reales.

La mayoría de los lectores tienden a seguir esta definición. Aunque no dice sobre los
aspectos técnicos de la calidad del software, no se enfrenta directamente con la necesidad
de la satisfacción del cliente, omite la mención de la importancia de mediciones y métricas;

6
tampoco expresa la importancia de un proceso avanzado. Sin embargo, la definición de
Bauer nos proporciona una línea base.
El IEEE [IEEE93] ha desarrollado una definición más completa:

Ingeniería del software: (1) La aplicación de un enfoque sistemático,

disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del
software; es decir, la aplicación de ingeniería al software. (2) El estudio de
enfoques como en (1).

Proceso, métodos y herramientas

La ingeniería del software es una tecnología multicapa. Cualquier enfoque de ingeniería

debe descansar sobre un empeño de organización de calidad. La gestión total de calidad y
las filosofías similares fomentan una cultura continua de mejoras de procesos, la que
conduce últimamente al desarrollo de enfoques cada vez más robustos para la ingeniería del
software.

El fundamento de la ingeniería del software es la capa proceso. El proceso de la ingeniería

del software es la unión que mantiene juntas las capas de tecnología y que permite un
desarrollo racional y oportuno de la ingeniería del software. El proceso define un marco de
trabajo para un conjunto de áreas clave de proceso que se debe establecer para la entrega
efectiva de la tecnología de la ingeniería del software. Las áreas clave del proceso forman
la base del control de gestión de proyectos del software y establece el contexto en el que se
aplican los métodos técnicos, se producen resultados del trabajo (modelos, documentos,
datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se
gestiona adecuadamente.

Los métodos de la ingeniería del software indican cómo construir técnicamente el software.
Abarcan un conjunto de tareas que incluyen análisis de requisitos, diseño, construcción de
programas, pruebas y mantenimiento.

Las herramientas de la ingeniería del software proporcionan un soporte automático o

semiautomático para el proceso y para los métodos. Cuando se integran herramientas para
que la información creada por una herramienta la pueda utilizar otra, se establece un
sistema de soporte para el desarrollo del software llamado ingeniería del software asistida
por computadora (Computer Aided Software Engineering, CASE). CASE combina
software, hardware y una base de datos de ingeniería del software.

La ingeniería es el análisis, diseño, construcción, verificación y gestión de entidades. A la

entidad se le debe realizar y responder las siguientes preguntas:

 ¿Cuál es el problema a resolver?

 ¿Cuáles son las características de la entidad utilizadas para resolver el problema?
 ¿Cómo se realizará la entidad (y la solución)?
 ¿Cómo se construirá la entidad?

7
 ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el
diseño y en la construcción de la entidad?
 ¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones, adaptaciones y
mejoras de la entidad?

En el curso sólo nos vamos a centrar en una sola entidad: el software de computadoras.
Para construir la ingeniería del software adecuadamente, se debe definir un proceso de
desarrollo de software, formado por tres fases:

 Fase de definición se centra sobre el qué.

 Fase de desarrollo se centra en el cómo.
 Fase de mantenimiento se centra en el cambio que va asociado a la corrección.

1.4.2 Modelos de procesos de software.

Para resolver los problemas reales un ingeniero de software o un equipo de ingenieros

deben incorporar una estrategia de desarrollo que acompañe al proceso, métodos,
herramientas y fases genéricas del proceso del software.

Todo el desarrollo del software se puede caracterizar como un bucle de resolución de

problemas donde se encuentran cuatro etapas distintas:

 Status quo: estado actual de sucesos.

 Definición de problemas: identifica el problema específico a resolver.
 Desarrollo técnico: resuelve el problema a través de la aplicación de alguna tecnología.
 Integración de soluciones: ofrece los resultados a los que solicitan la solución en primer
lugar.

Basado en estas cuatro etapas se tienen varios modelos de procesos de software.

Modelo lineal secuencial: llamado también ciclo de vida clásico, sugiere un enfoque
sistemático y secuencial del desarrollo del software, y consta de las actividades siguientes:

 Ingeniería y modelado del sistema/información: el software siempre forma parte de un

sistema más grande, hay que determinar de ese sistema que requisitos forman parte del
software, y su conexión con otros elementos como personas o bases de datos.
 Análisis de los requisitos del software: parte de esto se logra en el paso anterior, en este
paso ese proceso de reunión de requisitos se intensifica y se centra solamente en el
software, el analista debe comprender el dominio del problema para poder construirlo, y
el cliente documenta y repasa los requisitos del sistema.
 Diseño: es un proceso de varios pasos que se centra en cuatro atributos distintos de un
programa: estructura de datos, arquitectura del software, representaciones de interfaz, y
los detalles procedimentales o algoritmos. Este proceso traduce los requisitos en una
representación del software que se pueda evaluar por calidad antes de la generación de
código, y al igual que los requisitos se documenta, lo que forma parte de la
configuración del software.

8
 Generación de código o implementación: Este paso lleva a cabo la tarea de traducción
del diseño a una forma legible por la máquina. Si el diseño es detallado este paso es casi
mecánico.
 Pruebas: Después de la generación comienzan las pruebas del programa, centrada en
los procesos lógicos internos del software, y en los externos funcionales, para detectar
errores y comprobar que la entrada definida produce los resultados deseados.
 Mantenimiento: es casi seguro que el software sufra cambios luego de su entrega al
cliente, provocado por causas como dispositivos nuevos disponibles, o necesidad de
mejoras funcionales o de rendimiento.

Modelo de construcción de prototipos: este modelo comienza con la recolección de

requisitos, donde analista y cliente definen las necesidades, luego aparece un diseño
rápido, que se centra en la representación de los aspectos visibles al usuario, este diseño
lleva a la construcción de un prototipo, que es evaluado por el usuario, y este lo utiliza para
refinar los requisitos que desea del software. Este prototipo se puede utilizar en el
desarrollo del software final o puede descartarse y realizar una ingeniería del software en
vistas a la calidad y la facilidad de mantenimiento.

Modelo DRA: el modelo de desarrollo rápido de aplicaciones es un modelo de desarrollo

lineal secuencial con un ciclo de desarrollo extremadamente corto. Para esto se desarrolla
un enfoque de construcción basado en componentes, lo que permite reducir el ciclo de
entrega del producto final, pero es recomendable solamente en los casos en que la
aplicación se puede modularizar adecuadamente, y enfatiza el desarrollo de componentes
de programas reutilizables, que son la piedra angular de las tecnologías de objetos.

Modelos de procesos evolutivos: estos modelos son iterativos y permiten a los ingenieros
desarrollar versiones cada vez más completas del software.

Modelo incremental: combina el ciclo de vida clásico con la filosofía interactiva de

construcción de prototipos, en cada incremento o secuencia lineal que se realiza se logra
una parte del objetivo, y se van entregando versiones sucesivas del software.

Modelo en espiral: este modelo combina la naturaleza de la construcción de prototipos con

los aspectos controlados del modelo lineal secuencial, se desarrolla el software en cada
etapa o espiral como un prototipo que evalúa el cliente y que es el punto de partida de la
próxima iteración.

Modelo de ensamblaje de componentes: este incorpora muchas características del modelo

en espiral, y configura las aplicaciones a partir de componentes ya existentes que son
reutilizados.

1.5 Sistemas Basados en Computadora

La Ingeniería del Software es una consecuencia de un proceso llamado Ingeniería de

Sistemas de Computadoras.

9
El proceso de ingeniería del software es denominado ingeniería de la información cuando
el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un
producto, el proceso se denomina ingeniería de producto.

Ambas ingenierías de la información y de producto intentan poner orden al desarrollo de

sistemas basados en computadoras, tanto la ingeniería de la información como la de
producto trabajan para asignar un papel al software de computadora y para establecer los
enlaces que unen al software con otros elementos de un sistema basado en computadora.

La palabra «sistema» es uno de los términos más usados del léxico técnico. El diccionario
Webster define «sistema» como «un conjunto o disposición de cosas relacionadas de
manera que forman una unidad o u todo orgánico... un conjunto de hechos, principios,
reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de
unión de las partes... un método o plan de clasificación o disposición... una manera
establecida de hacer algo; método; procedimiento...».

Se define un Sistema Basado en Computadoras como un conjunto o arreglo de elementos

que están organizados para realizar un objetivo predefinido procesando información.

1.5.1 Elementos de un sistema basado en computadoras

 Software. Programas de computadora, estructuras de datos y su documentación que

sirven para hacer efectivo el método lógico, procedimiento o control requerido.

 Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo y

dispositivos electromecánicos (Ej.: sensores, motores, bombas) que proporcionan una
función externa.

 Personas. Son los usuarios y operadores del hardware y software.

 Base de datos. Una gran colección de información organizada a la que se accede

por medio del software.

 Documentación. Manuales, formularios y otra información descriptiva que retrata

el empleo y/o operación del sistema.

 Procedimientos. Los pasos que definen el empleo específico de cada elemento del
sistema o el contexto procedimental en que reside el sistema.

Todos estos elementos se combinan de varias maneras para transformar la información. La

ingeniería de sistemas de computadoras es un proceso de modelado. El ingeniero crea
modelos que:

♦Definan los procesos que satisfagan las necesidades.

♦Representen el comportamiento de los procesos

10
♦Definan explícitamente las entradas de información al modelo
♦Representen todas las uniones (incluyendo las salidas) que permitan al ingeniero entender
mejor la visión.

1.6 Ingeniería de la información

La meta de la ingeniería de la información es definir arquitectura que permitan a las

empresas emplear la información eficazmente. Se deben analizar y diseñar tres
arquitecturas diferentes dentro del contexto de objetivos y metas de negocio:

• Arquitectura de datos
• Arquitectura de aplicaciones
• Infraestructura de la tecnología

La arquitectura de datos proporciona una estructura para las necesidades de información de

un negocio o de una función de negocio. Los objetos de datos fluyen entre las funciones de
negocio, están organizados dentro de una base de datos y son transformados para
proporcionar información que satisfaga las necesidades del negocio.

La arquitectura de aplicación comprende aquellos elementos de un sistema que transforma

objetos dentro de la arquitectura de datos por algún propósito del negocio. Vamos a
considerar que la arquitectura de aplicación es el sistema de programas (software) que
realiza esta transformación. .

La infraestructura de la tecnología proporciona el fundamento de la arquitectura de datos y

de aplicaciones. La infraestructura comprende el hardware y el software empleados para
dar soporte a las aplicaciones y datos. .

1.7 Ingeniería de productos

La meta de la ingeniería de productos es traducir el deseo de un cliente, de un conjunto de

capacidades definidas, en un producto operativo. Para conseguir esta meta, la ingeniería de
producto (como la ingeniería de la información) debe crear una arquitectura y una
infraestructura. La arquitectura comprende cuatro componentes de sistema distintos:
software, hardware, datos (bases de datos) y personas. Se establece una infraestructura de
soporte e incluye la tecnología requerida para unir los componentes y la información (p. ej.:
documentos, CD-ROM, vídeo) que se emplea para dar soporte a los componentes.

2. Gestión de proyectos de software

La gestión eficaz de un proyecto de software se centra en las tres 'p': personal, problema y
proceso. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería

11
del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos.
Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la
evolución del proyecto se arriesga a construir una elegante solución para un problema
equivocado. Finalmente, el administrador que presta poca atención al proceso corre el
riesgo de arrojar métodos técnicos y herramientas eficaces al vacío.

Personal

La necesidad de contar con personal para el desarrollo del software altamente preparado y
motivado se viene discutiendo desde los años 60. El proceso del software y todos los
proyectos de software lo componen participantes que pueden clasificarse en una de cinco
categorías:

1. Gestores superiores, que definen los aspectos de negocios que a menudo tienen una
significativa influencia en el proyecto.
2. Gestiones (técnicos) del proyecto, que deben planificar, motivar, organizar y
controlar a los profesionales que realizan el trabajo de software.
3. Profesionales, que proporcionan las capacidades técnicas necesarias para la
ingeniería de un producto o aplicación.
4. Clientes, que especifican los requisitos para la ingeniería del software.
5. Usuarios finales, que interaccionan con el software una vez que se ha entregado para
la producción,

Problema

Antes de poder planificar un proyecto, se deberían establecer sus objetivos y su ámbito, se

deberían considerar soluciones alternativas e identificar las dificultades técnicas y de
gestión. Sin esta información, es imposible definir unas estimaciones razonables (y
exactas) del costo, una valoración efectiva del riesgo, una subdivisión realista de las tareas
del proyecto o una planificación del proyecto asequible que proporcione una indicación
fiable del progreso.

El desarrollador de software y el cliente deben reunirse para definir los objetivos del
proyecto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de
ingeniería del sistema y continúa como el primer paso en el análisis de los requisitos del
software. Los objetivos identifican las metas generales del proyecto sin considerar cómo se
conseguirán.

El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan el

problema, y más importante, intenta abordar estas características de una manera
cuantitativa.

Una vez que se han entendido los objetivos y el ámbito del proyecto, se consideran las
soluciones alternativas. Aunque se estudia con poco detalle, las alternativas permiten a los
gestores y a los profesionales seleccionar el «Mejor» enfoque, dadas las limitaciones

12
impuestas por las fechas límite de entrega, restricciones del presupuesto, disponibilidad de
personal, interfaces técnicas y otros muchos factores.

Proceso

Un proceso de software proporciona la estructura desde la que se puede establecer un

detallado plan para el desarrollo del software. Un pequeño número de actividades
estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su
tamaño o complejidad. Diferentes conjuntos de tareas, hitos, entregas y garantía de calidad
permite a las actividades estructurales adaptarse a las características del proyecto de
software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras
tales como garantía de calidad del software, gestión y configuración del software y
medición cubren el modelo de proceso y se desarrollan a todo lo largo del mismo.

2.1 Planificación de proyectos

El proceso de gestión de proyecto de software comienza con un conjunto de actividades que

se denominan planificación del proyecto. La primera de estas actividades es la estimación.
Siempre que estimamos, echamos un vistazo al futuro y aceptamos resignados cierto grado
de incertidumbre.

Aunque la estimación es más un arte que una ciencia, es una actividad importante que no
debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de
costes y de tiempos. Y, dado que la estimación es la base de todas las demás actividades de
planificación del proyecto y sirve como guía para una buena ingeniería del software, no es
en absoluto aconsejable embarcarse sin ella.

La estimación de recursos, costes, y planificación temporal de un esfuerzo en desarrollo de

software requiere experiencia, acceder a una buena información histórica y el coraje de
confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos. La
estimación conlleva un riesgo inherente y es este riesgo el que lleva a la incertidumbre.

En la estimación se toman en cuenta además del procedimiento técnico a utilizar en el

proyecto, los recursos, costos y planificación. El tamaño del proyecto constituye un factor
importante que puede afectar la precisión de las estimaciones. En la medida que el tamaño
aumenta, se incrementa más rápido la independencia de los elementos del software.

2.1.1 Objetivos de la planificación del proyecto

El objetivo de la planificación del proyecto de software es brindar un entorno de trabajo

que facilite al gestor hacer estimaciones de recursos, costos y planificación temporal. Las
estimaciones se realizan al comienzo de un proyecto de software, y deben ser actualizadas
en la medida que el proyecto avanza. Las estimaciones deberían definir las escenas del
mejor y peor caso, de forma tal que se puedan definir mejor los limites de los resultados del
proyecto.

13
2.2 Actividades asociadas a la planificación de proyectos de software.

2.2.1 Ámbito del Software.

La primera actividad que se lleva a cabo durante la planificación del proyecto de software
es el ámbito del software. El ámbito se define respondiendo las siguientes cuestiones.

 Contexto. ¿Cómo encaja el software a construir en un sistema, producto o contexto de

negocios mayor y que limitaciones se imponen como resultado del contexto?
 Objetivos de información. ¿Qué objetos de datos visibles al cliente se obtienen del
software? ¿Qué objetos de datos son requeridos de entrada?
 Función y rendimiento. ¿Qué función realiza el software para transformar la
información de entrada en una salida? ¿Hay características de rendimiento especiales
que abordar?

Durante esta etapa, se deben evaluar la función y el rendimiento que se asignaron al

software durante la Ingeniería del Sistema de Computadora, con el propósito de establecer
un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos

El ámbito del software describe la función, el rendimiento, las restricciones, las interfaces y
la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar más
detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los
requisitos de tiempo de respuesta y procesamiento, identifican los límites del software
originados por el hardware externo, por la memoria disponible y por otros sistemas
existentes.

Un prerrequisito para la estimación es el ámbito del software, un elemento importante a

tener en cuenta es la obtención de la información necesaria para el software, donde el
analista y el cliente se reúnen y mediante la realización de preguntas llegan a precisar y
determinar los limites del sistema para su desarrollo, así como a una mejor comprensión
por el analista de sistema.

2.2.2 Recursos

La segunda actividad de la planificación del desarrollo de software es la estimación de los

recursos requeridos para llevar a cabo el desarrollo de software, esto simula a una pirámide
donde las herramientas (hardware y software), son la base y proporciona la infraestructura
de soporte al esfuerzo de desarrollo, en segundo nivel se encuentran los componentes
reutilizables, y en la parte más alta de la pirámide se encuentran los recursos humanos.

Las características de cada recurso están dadas por:

• Descripción del recurso.
• Informes de la disponibilidad.
• Fecha en la que se requiere el recurso.
• Tiempo que será aplicado el recurso.

14
Recursos Humanos

Los recursos humanos son la cantidad de personas necesarias para el desarrollo de un

proyecto de software, sólo puede ser determinado después de hacer una estimación del
esfuerzo de desarrollo (por ejemplo personas mes o personas años), también se selecciona
la posición dentro de la organización y la especialidad que desempeñará cada profesional
durante el desarrollo del software.

Recursos de software reutilizables

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la

reutilización, o sea, la creación y la reutilización de bloques de construcción de software.
Se sugieren cuatro categorías de recursos de software a tener en cuenta durante la
planificación:
1. Componentes ya desarrollados
2. Componentes ya experimentados.
3. Componentes con experiencia parcial
4. Componentes nuevos

Recursos de entorno

El entorno es donde se apoya el proyecto de software, conocido como entorno de ingeniería

del software (EIS), el cual incorpora hardware y software. El hardware proporciona una
plataforma con las herramientas (software) necesarias para desarrollar los productos que
son el resultado de una buena práctica de la ingeniería del software. Como la mayoría de las
organizaciones de software tienen aspectos que requieren acceso a EIS, un planificador de
proyecto debe determinar la ventana temporal requerida para el hardware y el software, y
verificar que estos recursos estarán disponibles.
Cuando se le aplica la ingeniería a un sistema basado en computadora, el equipo de
software puede requerir acceso a los elementos en desarrollo por otros equipos de
ingeniería.

2.3 Estimación del proyecto de software.

El coste del software constituía un pequeño porcentaje del coste total de los sistemas
basados en computadora. En la actualidad, el software constituye el elemento más caro de
la mayoría de los sistemas informáticos. Un gran error en la estimación del coste puede ser
lo que marque la diferencia entre beneficios y pérdidas, y sobrepasarse en el coste puede ser
catastrófico en el equipo de desarrollo.
La estimación del coste y del esfuerzo del software nunca será una ciencia exacta. Son
demasiadas las variables humanas, técnicas, de entorno, políticas que pueden afectar al
coste final del software y al esfuerzo aplicado para desarrollarlo.

15
Las siguientes opciones son útiles para realizar estimaciones seguras de costes y esfuerzos:

1. Deje la estimación para más adelante (lógico que podemos realizar una estimación
al cien por cien fiable luego de haber terminado el proyecto).
2. Guiar las estimaciones en proyectos similares ya concluidos.
3. Usar técnicas de descomposición relativamente sencillas para generar las
estimaciones de coste y de esfuerzo del proyecto.
4. Realice un modelo empírico para el cálculo de costes y esfuerzos del software.

Lamentablemente, la primera opción, aunque atractiva, no es práctica, debido a que las

estimaciones de costes se han de realizar a priori. No obstante, hay que reconocer que
cuanto más tiempo transcurra, más elementos conocemos, y cuanto más sepamos, menor
será la probabilidad de cometer graves errores en las estimaciones.

La segunda opción funciona si el proyecto actual es bastante similar a los esfuerzos

anteriores y si otras influencias del proyecto son similares.

Las opciones restantes son métodos viables para la estimación del proyecto de software.
Las técnicas de descomposición utilizan un enfoque de «divide y vencerás» para la
estimación del proyecto de software. Se pueden utilizar los modelos empíricos de
estimación como complemento de las técnicas de descomposición, ofreciendo un enfoque
de estimación potencialmente valioso por derecho propio

2.3.1 Técnicas de estimación. Estimación basada en el proceso.

La estimación basada en el proceso es la técnica más común para estimar un proyecto, es

decir, el proceso se descompone en un conjunto relativamente pequeño de tareas, y en el
esfuerzo necesario para estimar cada tarea. Esta estimación se inicia con una delineación
de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las
funciones del problema y las actividades del proceso. Por último, se calculan los costos y el
esfuerzo de cada función y en general la del proceso de software.

2.4 Modelos empíricos de estimación

Los datos empíricos que soportan la mayoría de los modelos de estimación se obtienen de
una muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado
para todas las clases de software y en todos los entornos de desarrollo. Por tanto, los
resultados obtenidos de dichos modelos se deben utilizar con prudencia

2.4.1 Modelo COCOMO

Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce
una jerarquía de modelos de estimación de Software con el nombre de COCOMO
(Constructive Cost Model) o modelo constructivo de costos. La jerarquía de modelos de
Boehm esta formada por:

16
Modelo I. Es el modelo COCOMO básico que calcula el esfuerzo y el costo del desarrollo
de software en función del tamaño del programa, expresado en las líneas estimadas.

Modelo II. Es el modelo intermedio que calcula el esfuerzo del desarrollo de software en
función del tamaño del programa y de un conjunto de conductores de costos que
intervienen en la evaluación subjetiva del producto, del hardware, del personal y de los
atributos del proyecto.

Modelo III. Es el modelo avanzado que incorpora las características de la versión

intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada
caso (análisis, diseño, etc.) del proceso de ingeniería de Software.

2.5 Herramientas automáticas de estimación

Las técnicas de descomposición y los modelos empíricos de estimación se pueden

implementar con software, las herramientas automáticas de estimación permiten al
planificador estimar costes y esfuerzos, y llevar a cabo un análisis del tipo «qué pasa si»
con importantes variables del proyecto, como es la fecha de entrega y la selección de
personal.

Las herramientas automáticas de estimación requieren una o más clases de datos como:

 Una estimación cuantitativa del tamaño del proyecto o de la funcionalidad.

 Características cualitativas del proyecto: complejidad, la fiabilidad requerida y el grado
de criticidad del negocio.
 Descripción del personal de desarrollo y/o del entorno de desarrollo.

Con estos datos, el modelo implementado por la herramienta automática de estimación

brinda estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costes, la
carga de personal, la duración y en algunos casos, la planificación temporal de desarrollo y
el riesgo asociado.

3. Análisis de sistemas

El análisis de sistemas se lleva a cabo con los siguientes objetivos:

• Identificar la necesidad del cliente.

• Evaluar el concepto del sistema para establecer la viabilidad.
• Realizar el análisis técnico y económico.
• Asignar funciones al hardware, software, personal, bases de datos y otros elementos del
sistema.
• Establecer restricciones de presupuesto y planificación temporal.

17
• Crear una definición del sistema que forme el fundamento de todo el trabajo de
ingeniería.

Para alcanzar los objetivos de la etapa del análisis se requiere de un amplio conocimiento
del área de hardware, software, administración de bases de datos y de la ingeniería humana
para interactuar con el personal que solicita la realización del sistema.

Los métodos de análisis se relacionan por un conjunto de principios operativos:

l. Debe representarse y entenderse el dominio de información de un problema.

2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software (como consecuencia de
acontecimientos externos).
4. Deben dividirse los modelos que representan información, función y comportamiento
de manera que se descubran los detalles por capas (o jerárquicamente).
5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la
implementación.

Además de los principios operativos de análisis mencionados anteriormente, se sugiere un

conjunto de principios directrices para la «ingeniería de requisitos»:

 Entender el problema antes de empezar a crear el modelo de análisis. Hay tendencia a

precipitarse en busca de una solución, incluso antes de entender el problema.
 Desarrollar prototipos que permitan al usuario entender como será la interacción
hombre-máquina. Como el concepto de calidad del software se basa a menudo en la
opinión sobre la «amigabilidad» de la interfaz, el desarrollo de prototipos (y la
iteración que se produce) es altamente recomendable.
 Registrar el origen y la razón de cada requisito. Este es el primer paso para establecer
un seguimiento hasta el cliente
 Use múltiples planteamientos de requisitos. La construcción de modelos de datos,
funcionales y de comportamiento le proporcionan al ingeniero del software tres puntos
de vista diferentes. Esto reduce la probabilidad de que se olvide algo y aumenta la
probabilidad de reconocer la falta de consistencia.
 Dar prioridad a los requisitos. Las fechas ajustadas de entrega pueden impedir la
implementación de todos los requisitos del software. Si se aplica un modelo de
proceso incremental, se deben identificar los requisitos que se van a entregar en la
primera entrega.
 Trabajar para eliminar la ambigüedad. Como la mayoría de los requisitos están
descritos en un lenguaje natural, abunda la oportunidad de ambigüedades. El empleo
de revisiones técnicas formales es una manera de descubrir y eliminar la ambigüedad.

3.1 Identificación de las necesidades (análisis de requisitos)

18
Lo primero en el análisis del sistema es la identificación de la necesidad del usuario, donde
el analista se reúne con el cliente y usuarios finales para entender los objetivos del
producto y definir las metas necesarias para alcanzarlos.

Una vez que se han identificado las metas globales, el analista pasa a la evaluación de la
información suplementaria:

♦Tecnología para construir el sistema.

♦Recursos especiales de desarrollo y fabricación necesarios.
♦Límites de presupuesto y de planificación temporal.
♦Si el nuevo sistema es un producto a desarrollar para venderlo a muchos clientes, se debe
analizar: ¿Cuál es el mercado potencial del producto? ¿Cómo es comparativamente este
producto con los de la competencia? ¿Qué posición ocupa este producto en la línea
general de producción de la compañía?

El análisis de requisitos permite al ingeniero del software (analista) la definición del

software y construir los modelos de los dominios de datos, funcional y de comportamiento
que van a ser tratados por el software. El análisis de requisitos proporciona modelos al
diseñador del software que pueden traducirse en el diseño de datos, arquitectónico, de
interfaz y procedimental.

El análisis de requisitos del software puede dividirse en cinco áreas:

 Reconocimiento del problema
 Evaluación y síntesis
 Modelado
 Especificación
 Revisión.

El analista estudia la especificación del sistema. Es importante entender el software en el

contexto de un sistema y revisar el ámbito del software que se empleó para generar las
estimaciones de la planificación. Se debe establecer la comunicación para el análisis de
manera que nos garantice el reconocimiento del problema. El objetivo del analista es el
reconocimiento de los elementos básicos del problema tal y como los percibe el usuario o el
cliente.

En la evaluación del problema y la síntesis de la solución el analista debe definir todos los
objetos de datos observables externamente, evaluar el flujo y contenido de la información,
definir y elaborar todas las funciones del software, entender el comportamiento del
software en el contexto de sistema. Estas tareas sirven para describir el problema de manera
que se pueda sintetizar un enfoque o solución global.
Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del
sistema para entender el flujo de datos y de control, el tratamiento funcional.

En esta etapa no es posible una especificación detallada del sistema, el cliente puede no
estar seguro de lo que quiere, el desarrollador puede no estar seguro de que un enfoque
específico consiga apropiadamente el funcionamiento y rendimiento adecuados.

19
Una vez que se han identificado las metas globales, el analista pasa a la evaluación de la
información suplementaria: ¿Existe la tecnología para construir el sistema? ¿Qué recursos
especiales de desarrollo y fabricación serán necesarios? ¿Qué límites se han puesto al
presupuesto y a la planificación temporal? Si el nuevo sistema es un producto a desarrollar
para venderlo a muchos clientes, se plantean además las siguientes cuestiones: ¿Cuál es el
mercado potencial del producto? ¿Cómo es comparativamente este producto con los de la
competencia? ¿Qué posición ocupa este producto en la línea general de producción de la
compañía?

La información reunida durante el paso de identificación de necesidades es especificada en

un documento conceptual del sistema. El documento conceptual original es preparado a
veces por el cliente antes de las reuniones con el analista. Invariablemente, la
comunicación cliente-analista origina modificaciones en el documento.

La técnica de análisis más usada para cubrir el hueco de comunicación entre el cliente y el
desarrollador y para empezar el proceso de comunicación es llevar a cabo una reunión o
entrevista preliminar. El primer conjunto de cuestiones de contexto libre se enfoca sobre el
cliente, los objetivos generales y los beneficios esperados. Por ejemplo, el analista podría
preguntar:

 ¿Quién está detrás de la solicitud de este trabajo?

 ¿Quién utilizará la solución?
 ¿Cuál será el beneficio económico del éxito de una solución?
 ¿Hay alguna otra alternativa para la solución que necesita?

El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del

problema y al cliente comentar sus opiniones sobre la solución:

 ¿Cómo caracterizaría una «buena» salida (resultado) generada para una buena
solución?
 ¿A qué tipo de problema(s) va dirigida esta solución?
 ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución?
 ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de
enfocar la solución?

El último conjunto de preguntas se concentra en la eficacia de la reunión. Gauge y

Weinberg las denominan «Meta-preguntas» y proponen la siguiente lista (abreviada):

 ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas
son «oficiales»?
 ¿Son adecuadas mis preguntas para el problema que tiene usted'?
 ¿Estoy preguntando demasiado?
 ¿Hay alguien más que pueda proporcionar información adicional'?
 ¿Hay algo más que debería preguntarle?

20
Estas preguntas (y otras) ayudarán a «romper el hielo» e iniciar la comunicación tan
esencial para el éxito del análisis. Pero el formato de reunión tipo «pregunta y respuesta»
no es un enfoque que haya tenido mucho éxito. De hecho, esta sesión de preguntas y
respuestas debería emplearse solamente en el primer encuentro y sustituirse después por
una modalidad que combine elementos de resolución del problema, negociación y
especificación.

3.2 Estudio de la viabilidad

Todos los proyectos son posibles en caso de tener infinitos recursos y tiempo.
Desafortunadamente el desarrollo de un sistema basado en computadoras es muy probable
que exista escasez de recursos y de fechas de entrega. Por lo que es necesario evaluar la
viabilidad de un proyecto cuanto antes.

La viabilidad y el análisis de riesgo están relacionados de muchas maneras. Si el riesgo del

proyecto es alto, la viabilidad de producir software de calidad se reduce. Analizaremos lo
siguiente:

 Viabilidad económica. Es la evaluación de los costos de desarrollo, con relación a

los ingresos netos o beneficios obtenidos del sistema desarrollado.
 Viabilidad técnica. Es el análisis y estudio de funciones, rendimiento y
restricciones que puedan afectar la realización de un sistema aceptable.
 Viabilidad legal. Es la determinación de 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
sistema.

No es necesario un estudio de viabilidad para sistemas en que la justificación económica es

obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe ninguna
alternativa razonable.

La justificación económica es generalmente la consideración fundamental para la mayoría

de los sistemas. Incluye una amplia gama de aspectos a tener en cuenta como son el análisis
de costes/beneficios, las estrategias de ingresos de la empresa a largo plazo, el impacto en
otros productos o centros de beneficios, costo de recursos necesarios para el desarrollo y
crecimiento potencial del mercado.

La viabilidad tecnológica es frecuentemente el área más difícil de valorar en esta etapa del
proceso de ingeniería del producto. Como los objetivos, funciones y rendimiento son poco
claros, cualquier cosa parece posible si se hacen las suposiciones correctas. Es esencial que
el proceso de análisis y definición se realice en paralelo con una valoración de la viabilidad
técnica. De esta manera se pueden juzgar especificaciones concretas a medida que se
establecen.

21
Las consideraciones que están asociadas normalmente con la viabilidad técnica son:

Riesgo de desarrollo. ¿Puede diseñarse el elemento del sistema de manera que se

consigan la función y rendimiento necesarios dentro de las restricciones descubiertas
durante el análisis?

Disponibilidad de recursos. ¿Tenemos disponible una plantilla cualificada para

desarrollar el elemento del sistema en cuestión? ¿Tenemos disponibles otros recursos
necesarios (hardware y software) para construir el sistema?

Tecnología. ¿Ha progresado la tecnología respectiva hasta un punto que sea capaz de
soportar el sistema?

La viabilidad legal comprende una gama muy amplia de aspectos que incluyen contratos,
responsabilidades legales, infracciones y un montón de trampas frecuentemente
desconocidas para el personal técnico.

El grado con que se consideran las alternativas está a menudo limitado por restricciones de
tiempo y costes; sin embargo, no debería despreciarse una variación legítima por no estar
«subvencionada».

El estudio de viabilidad es revisado primero por el jefe del proyecto (para valorar la
fiabilidad del contenido) y por la dirección (para valorar el estado del proyecto). El estudio
debería concluir en una decisión «adelante / abandonamos».

3.3 Análisis técnico y económico.

Una información importante contenida en un estudio de viabilidad es el análisis de costo/

beneficio: una valoración de la justificación económica para un proyecto de sistema basado
en computadora.

El análisis costes beneficios determina los costes para el desarrollo del proyecto y los
pondera con los beneficios tangibles (medibles directamente en dinero) y beneficios
intangibles del sistema. El análisis costo/beneficio es complicado por criterios que varían
con las características del sistema a desarrollar, el tamaño relativo del proyecto y los
beneficios esperados de la inversión como parte del plan estratégico de la compañía.
Además, muchos beneficios obtenidos de los sistemas basados en computadora son
intangibles (por ejemplo, mejor calidad de diseño gracias a una optimización frecuente,
mayor satisfacción del cliente gracias al control programable y mejores decisiones de
negocio gracias a los datos de ventas preanalizados y reformateados). Las comparaciones
cuantitativas directas pueden ser difíciles de conseguir.

Durante el análisis técnico, el analista evalúa los principios técnicos del sistema al mismo
tiempo que se recoge información adicional sobre el rendimiento, fiabilidad, características
de mantenimiento y productividad.

22
  El análisis técnico empieza con una valoración de la viabilidad técnica del
sistema propuesto. ¿Qué tecnologías se requieren para lograr el funcionamiento
y rendimiento del sistema?
 ¿Qué nuevos materiales, métodos, algoritmos o procesos se necesitan y cuál es
su riesgo de desarrollo?
 ¿Cómo afectarán estos aspectos tecnológicos a los costes?

3.4 Modelado de la arquitectura del sistema.

Los sistemas basados en computadora pueden moderarse como la transformación de la

información empleando una arquitectura del tipo entrada-proceso-salida.

Para desarrollar el modelo de sistema, se emplea un esquema de arquitectura, donde el

ingeniero de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del
esquema: (1) Interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema, (4)
salida y (5) mantenimiento y autocomprobación.

Como casi todas las técnicas de modelado usadas en la ingeniería del software y de
sistemas, el esquema de arquitectura permite al analista crear una jerarquía en detalle. En
la parte alta de la jerarquía reside el diagrama de contexto de la arquitectura (DCA).

El diagrama de contexto «establece el límite de información entre el sistema que se está

implementando y el entorno en que va a operar». Es decir, el DCA define todos los
suministradores externos de información que emplea el sistema, todos los consumidores
externos de información creados por el sistema y todas las entidades que se comunican a
través de la interfaz o realizan mantenimiento y autocomprobación.

El ingeniero de sistemas refina el diagrama de contexto de arquitectura con más detalle, y

se identifican los subsistemas principales que permiten funcionar al sistema.

3.5 Especificación del sistema.

Las especificaciones del sistema se registran en un documento que sirve de base para
ingeniería hardware, software, base de datos, e ingeniería Humana. En este documento se
describen las funciones y rendimiento de un sistema basado en computadoras y las
dificultades que se pueden presentar durante su desarrollo. Al concluir la etapa del análisis
se realizan las especificaciones de los requisitos del software.

Puede decirse que un proyecto de desarrollo de un sistema de información comprende

varios pasos durante la etapa del análisis, el cual facilita traducir las necesidades del cliente
en un modelo de sistema que hace uso de varios componentes: software, hardware,
personas, base de datos, documentación y procedimientos

23
3.6 Creación de prototipos del software.

El análisis hay que hacerlo independientemente del paradigma de ingeniería del software
que se aplique, sin embargo, la forma que toma este análisis varía. En algunos casos es
posible aplicar los principios operativos del análisis y obtener un modelo de software del
que se pueda desarrollar un diseño. En otras situaciones, se realizan recopilaciones de
requisitos, se aplican los principios del análisis y se construye un modelo del software a
fabricar denominado prototipo para que lo valore el cliente y el desarrollador. Finalmente,
hay circunstancias que requieren la construcción de un prototipo al comienzo del análisis,
ya que el modelo es el único medio a través del cual se pueden obtener eficazmente los
requisitos. El modelo evoluciona después hacia la producción del software.

El paradigma de creación de prototipos puede ser cerrado o abierto. El enfoque cerrado se

denomina a menudo prototipo desechable. Este prototipo sirve únicamente como una basta
demostración de los requisitos. Después se desecha, y se hace una ingeniería del software
con un paradigma diferente. Un enfoque abierto, denominado prototipo evolutivo, emplea
el prototipo como primera parte de una actividad de análisis a la que seguirá el diseño y la
construcción. El prototipo del software es la primera evolución del sistema terminado.

Antes de poder elegir un enfoque abierto o cerrado, es necesario determinar si se puede

crear un prototipo del sistema a construir.

En general, cualquier aplicación que cree pantallas visuales dinámicas, interactúe

intensamente con el ser humano, o demande algoritmos de procesamiento de
combinaciones que deban crearse de manera progresiva, es un buen candidato para la
creación de un prototipo. Sin embargo, estas áreas de aplicación deben ponderarse con la
complejidad de la aplicación. Si una aplicación candidato (una con las características
reseñadas anteriormente) va a requerir el desarrollo de decenas de miles de líneas de código
antes de poder realizar cualquier función demostrable, es muy probable que sea demasiado
compleja para crear un prototipo. Si se puede hacer una partición a su complejidad, puede
ser posible crear prototipos de porciones del software.

Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que (1) se
destinen recursos del cliente a la evaluación y refinamiento del prototipo, y (2) el cliente
sea capaz de tomar decisiones inmediatas sobre los requisitos.

Existe un conjunto de seis cuestiones que ayudarán en la selección del enfoque de creación
de prototipos:

1. ¿Entiende el cliente y el desarrollador el dominio de la aplicación para la que se va a

construir el software?
2. ¿Se puede modelar el problema?
3. ¿Está el cliente suficientemente seguro de los requisitos básicos del sistema?
4. ¿Están suficientemente establecidos los requisitos y tienen posibilidad de ser
razonablemente estables?
5. ¿Hay requisitos ambiguos?

24
 6. ¿Hay contradicciones en los requisitos?

1.4 Diseño de sistemas

El diseño se ha descrito como un proceso multifase en el que se sintetizan representaciones

de la estructura de datos, estructura del programa, características de la interfaz y detalles
procedimentales desde los requisitos de la información.

El diseño del software es el núcleo técnico del proceso de ingeniería del software y se
aplica independientemente del paradigma de desarrollo utilizado.

Cada uno de los elementos del modelo de análisis proporciona información necesaria para
crear un modelo de diseño. Los requisitos del software, manifestados por los datos y los
modelos funcionales y de comportamiento, componen la fase de diseño. Mediante el
empleo de uno de los métodos de diseño la fase de diseño produce:

• Diseño de datos
• Diseño arquitectónico
• Diseño de interfaz
• Diseño procedimental.

1.4.1 Diseño de datos.

El diseño de datos es la primera (y alguien diría que la más importante) de las cuatro
actividades de diseño que se llevan a cabo durante la ingeniería del software.

El impacto de la estructura de datos en la estructura del programa y la complejidad

procedimental hace que el diseño de los datos tenga una profunda influencia en la calidad
del software. Los conceptos de ocultación de información y abstracción de datos
proporcionan el fundamento para un enfoque del diseño de datos.

El proceso de diseño de datos lo resume Wasserman [WAS80]:

La actividad principal del diseño de datos es seleccionar representaciones lógicas de

objetos de datos (estructuras de datos) identificadas durante la fase de definición y
especificación de requisitos. El proceso de selección puede incluir el análisis de
estructuras alternativas para determinar el diseño más eficaz o puede incluir
simplemente el empleo de un conjunto de módulos (un «paquete») que proporcione
las operaciones deseadas sobre alguna representación de un objeto.

Una actividad relacionada importante durante el diseño es identificar aquellos

módulos del programa que deben operar directamente sobre las estructuras de datos
lógicas. De esta manera se puede restringir el alcance de efecto de las decisiones
individuales sobre el diseño de datos.

25
Independientemente de las técnicas de diseño que se emplean, datos bien diseñados pueden
conducir a una mejor estructura y modularidad del programa, y a una menor complejidad
procedimental.

Wasserman ha propuesto un conjunto de principios que pueden emplearse para especificar

y diseñar datos. En realidad, el diseño de datos empieza durante la creación del modelo de
análisis. Recordando que el análisis de requisitos y el diseño a menudo se solapan,
consideramos el siguiente conjunto de principios [WAS80] para la especificación de datos:

1. Los principios del análisis sistemático aplicados 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.
2. Se debería establecer un diccionario de datos y usarlo para definir el diseño de los
datos y del programa.
3. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del
proceso de diseño.
4. La representación de las estructuras de datos deberían conocerla sólo aquellos
módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.
5. Debería desarrollarse una biblioteca de estructuras de datos útiles y de las
operaciones que se les pueden aplicar. Las estructuras de datos y las operaciones
deberían considerarse como recursos para el diseño del software.
6. Un diseño del software y un lenguaje de programación deberían soportar la
especificación y realización de los tipos abstractos de datos.

El 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 entidad-relación y el contenido detallado de
datos del diccionario de datos proporciona la base para la actividad de diseño de datos.

1.4.2 Diseño arquitectónico

El objetivo del diseño arquitectónico es desarrollar una estructura de programa modular y

representar las relaciones de control entre los módulos. Además, el diseño arquitectónico
combina la estructura del programa y las estructuras de datos, definiendo interfaces que
permiten el flujo de datos a través del programa.

El diseño orientado al flujo de datos es un método de diseño arquitectónico que permite una
cómoda transición desde el modelo de análisis a una descripción del diseño de la estructura
del programa.

La transición desde el flujo de información (representado como un diagrama de flujo de

datos) a una estructura se realiza en un proceso de cinco pasos: (1) se establece el tipo de
flujo de información; (2) se indican los límites del flujo; (3) se convierte el DFD en la
estructura del programa; (4) se define la jerarquía de control descomponiéndola mediante

26
particionamiento; y (5) se refina la estructura resultante usando medidas y heurísticas de
diseño. El tipo de flujo de información es lo que determina el método de conversión
requerido en el paso 3.

1.4.3 Diseño de la interfaz

El diseño arquitectónico proporciona al ingeniero del software una imagen de la estructura

del programa. Como el plano para una casa, el diseño general no está completo sin la
representación de las puertas, ventanas y conexiones a servicios para agua, electricidad y
teléfono (sin mencionar la televisión por cable). Las «puertas, ventanas y conexiones a
servicios» para el software de computadora componen el diseño de la interfaz del sistema.

El diseño de la interfaz se concentra en tres áreas importantes:

(1) el diseño de interfaces entre los módulos software;

(2) el diseño de interfaces entre el software y otros productores y consumidores no
humanos de información (por ejemplo, otras entidades externas); y
(3) el diseño de la interfaz entre el hombre (Ej. el usuario) y la computadora.

El diseño de la interfaz de usuario tiene tanto que ver con el estudio de las personas como
con los aspectos de la tecnología. ¿Quién es el usuario? ¿Cómo aprende el usuario a
interactuar con el nuevo sistema basado en computadora?¿Cómo interpreta el usuario la
información producida por el sistema? ¿Qué es lo que espera el usuario del sistema? Éstas
son unas pocas de las cuestiones que deben hacerse y contestarse como parte del diseño de
la interfaz de usuario.

El proceso general para diseñar la interfaz de usuario empieza con la creación de diferentes
modelos de función del sistema (tal y como se percibe desde fuera). Se definen las tareas
orientadas al hombre y a la máquina, requeridas para conseguir la función del sistema; se
consideran los aspectos de diseño aplicables a todos los diseños de interfaz; se usan
herramientas para crear el prototipo e implementar el modelo de diseño y se evalúa la
calidad del resultado.

El diseño de interfaz describe cómo se comunica el software consigo mismo, con los
sistemas que operan con él y con los operadores que lo emplean. Una interfaz implica un
flujo de información. Por tanto, los diagramas de flujo de datos y control proporcionan la
información necesaria para el diseño de la interfaz.

4.4 Diseño procedimental

El diseño procedimental se realiza después de los diseños de datos, arquitectónico y de

interfaz. En un mundo ideal, la especificación procedimental necesaria para definir los
detalles de los algoritmos se expresaría en un lenguaje natural. Después de todo, todos los
miembros de una organización de desarrollo de software hablan un lenguaje natural (en

27
teoría, al menos), las personas fuera del mundo del software podrían entender mejor la
especificación, y no sería necesario un nuevo aprendizaje.

Desgraciadamente, hay un pequeño problema. El diseño procedimental debe especificar

los detalles procedimentales sin ambigüedades, y la falta de ambigüedad en el lenguaje
natural no es natural. Con un lenguaje natural podemos escribir un conjunto de pasos
procedimentales de demasiadas formas diferentes.

La importancia del diseño del software se puede decir con una sola palabra: calidad. El
diseño es el lugar donde se fomenta la calidad en el desarrollo del software. El diseño nos
proporciona representaciones del software en las que se pueden valorar la calidad. El
diseño es la única manera de traducir con precisión los requisitos del cliente en un sistema o
producto software

El diseño del software es un proceso y un modelo a la vez. El modelo del diseño es el

equivalente a los planos de una casa para un arquitecto. Empieza representando la totalidad
de lo que se va a construir (ejemplo, una representación tridimensional de la casa) y
lentamente lo va refinando para proporcionar una directriz para construir cada detalle

1.4.4 Arquitectura del software

La arquitectura del software contribuye a «la estructura global del software del sistema».
En su forma más simple, la arquitectura es la estructura jerárquica de los componentes del
programa (módulos), la manera de interactuar de estos componentes, y la estructura de los
datos usados por estos componentes. La relación de control entre los módulos se expresa
de la siguiente manera: un módulo que controla otro módulo se dice que es superior a él;
inversamente, un módulo controlado por otro se dice que es inferior.

La jerarquía de control también representa dos características sutilmente diferentes de la

arquitectura del software: visibilidad y conectividad. La visibilidad indica el conjunto de
componentes de programa que pueden invocarse o usarse sus datos por un componente
dado, incluso cuando esto se realiza indirectamente. La conectividad indica el conjunto de
componentes que son invocados directamente o usados sus datos por un componente
determinado.

La modularidad juega un papel importante en el diseño, se ha convertido en un enfoque

admitido en todas las disciplinas de la ingeniería. Un diseño modular reduce la
complejidad, facilita los cambios y hace más fácil la implementación al fomentar el
desarrollo en paralelo de diferentes partes de un sistema.

1.4.6 Criterios para evaluar la calidad del diseño.

• Debe tener una estructura jerárquica que haga un uso inteligente del control entre los
componentes del software.

28
• Debe ser modular, o sea hacer una partición lógica del software en elementos que
realicen funciones y subfunciones especificas.
• Debe contener abstracciones de datos y procedimientos.
• Los módulos deben presentar características de funcionamiento independiente.
• Las interfaces no deben ser complejas para las conexiones entre los módulos y el
entorno exterior.
• Debe hacerse usando un método según la información obtenida durante el análisis de
requisitos de Software.

1.5 Desarrollo de software

La fase de desarrollo se centra en el cómo, durante el desarrollo un ingeniero del software

intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la
función como una arquitectura del software, cómo han de implementarse detalles
procedimentales, cómo han de caracterizarse las interfaces, cómo ha de traducirse el diseño
en un lenguaje de programación y cómo ha de realizarse la prueba.

Los encargados de desarrollar software pueden instalar software comprado a terceros o

escribir programas diseñados a la medida del solicitante. La elección depende del costo de
cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de
los programadores.

Los programadores son responsables de la documentación de los programas y de explicar

su codificación, esta documentación es esencial para probar el programa y hacer el
mantenimiento.

1.6 Prueba del software

Luego de generar el código se comienzan las pruebas del programa, este paso se centra en
los procesos lógicos internos del software, asegurando que todas las sentencias y procesos
externos funcionales se han comprobado, se realizan las pruebas para la detección de
errores y el sentirse seguro de que las entradas produzcan resultados reales de acuerdo con
los resultados requeridos.

La prueba abarca un conjunto de actividades que se pueden planificar por adelantado y

llevar a cabo sistemática. Se debe definir en el proceso de la ingeniería del software una
plantilla para la prueba del software: es decir, un conjunto de pasos en los que podamos
situar los métodos específicos de diseño de casos de prueba.

Existen varias estrategias de prueba del software, todas proporcionan al desarrollador de

software una plantilla para la prueba y tienen las características generales siguientes:

• La prueba comienza en el nivel de módulo y trabaja «hacia fuera», hacia la

integración de todo el sistema basado en computadora.

29
 • Según el momento son apropiadas diferentes técnicas de prueba.
• La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes
proyectos) un grupo independiente de pruebas.

Una estrategia de prueba del software debe incluir pruebas de bajo nivel que verifiquen que
todos los pequeños segmentos de código fuente se han implementado correctamente, así
como pruebas de alto nivel que validen las principales funciones del sistema frente a los
requisitos del cliente. Una estrategia debe proporcionar una guía al profesional y
proporcionar un conjunto de hitos para el jefe de proyecto.

1.6.1 Objetivos de la prueba.

• La prueba es un proceso de ejecución de un programa con la intención de descubrir

un error.
• Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error
no descubierto hasta entonces.
• Una prueba tiene éxito si descubre un error no detectado hasta entonces.

1.6.2 Verificación y validación

La prueba del software es un elemento de un tema más amplio que, a menudo, se le conoce
como verificación y validación. La verificación se refiere al conjunto de actividades que
aseguran que el software implementa correctamente una función específica. La validación
se refiere a un conjunto diferente de actividades que aseguran que el software construido se
ajusta a los requisitos del cliente.

1.7 Implantación

La implantación es la última etapa del desarrollo de sistemas. Es el resultado de instalar el

software y equipamiento nuevo, y llevar a cabo el proceso automatizado.

Para implantar el sistema de información hay que estar bien seguro que el sistema sea
operacional, o sea, que funcione de acuerdo a los requerimientos del análisis.

A pesar de que el sistema esté bien diseñado y cuente con interfaces adecuadas, es
importante para la implantación realizar una buena capacitación a todos los usuarios para su
puesta en explotación y garantizar el mantenimiento.

1.7.1 Capacitación de usuarios del sistema

Durante la fase de implementación es responsabilidad del analista la capacitación de los

usuarios del sistema comenzando desde las personas que capturan los datos hasta aquellos

30
que toman las decisiones sin usar una computadora. Es recomendable no incluir durante el
entrenamiento a grupos de personas de habilidad e intereses de trabajo diferentes; ya que
ambos grupos quedarían perdidos.

A pesar de que una empresa puede contratar los servicios de instructores externos, el
analista es la persona que puede ofrecer la mejor capacitación debido a que conoce al
usuario del sistema y al sistema mejor que cualquier otro.

No obstante la organización puede contratar otros servicios de capacitación como son:

 Vendedores: Son aquellos que proporcionan capacitación gratuita fuera de la

empresa de uno o dos días.
 Instructor pagado externamente: Son aquellos que pueden enseñar todo acerca de
las computadoras, en caso necesario para algunos usuarios.
 Instructores en casa: Están familiarizados con el personal y pueden adecuar los
materiales a sus necesidades, pero le faltaría experiencia en Sistemas de
Información que es realmente la necesidad del usuario.

1.7.2 Evaluación del sistema.

La evaluación del sistema se lleva a cabo para identificar puntos débiles y fuertes del
mismo. Esta evaluación se lleva en cualquiera de las siguientes dimensiones:

♦ Evaluación operacional:

Se evalúa la manera en que funciona el sistema, facilidad de uso, tiempo de respuesta ante
una petición, formatos en que se muestra la información de entradas y salidas, y el nivel de
utilidad.

♦ Impacto organizacional:

Se miden los beneficios operacionales para la empresa en áreas tales como las finanzas,
eficiencia en el desempeño laboral e impacto competitivo. Se evalúa el impacto, rapidez y
organización en el flujo de información interna y externa.

♦ Desempeño del desarrollo:

Se evalúa el proceso de desarrollo adecuado considerando criterios como, tiempo y

esfuerzo en el desarrollo de acuerdo al presupuesto y estándares y otros criterios de
administración de proyectos. Se realiza la valoración de los métodos y herramientas usados
en el desarrollo del sistema.

1.8 Mantenimiento

31
Es lógico que el software sufra cambios después de ser entregado al cliente. Se producirán
cambios porque se han encontrado errores, porque el software debe adaptarse para ajustarse
a los cambios de su entorno externo o porque el cliente requiere mejoras funcionales o de
rendimiento.

La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores,

a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios
debidos a las mejoras producidas por los requisitos cambiantes del cliente.

Esta fase vuelve a aplicar los pasos de las fases de definición y de desarrollo, pero en el
contexto del software ya existente. Durante la fase de mantenimiento se encuentran cuatro
tipos de cambios:

Corrección. A pesar de llevar a cabo las mejores actividades de garantía de calidad, es

muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo
modifica el software para corregir los defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (ejemplo:
CPU, el sistema operativo, las reglas de empresa, las características externas de productos)
para el que se desarrolló el software. El mantenimiento adaptativo produce modificación
en el software para acomodarlo a los cambios de su entorno externo.

Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones

adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software
más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto el

mantenimiento preventivo también llamado reingeniería del software, se debe conducir
para permitir que el software sirva para las necesidades de los usuarios finales. En esencia,
el mantenimiento preventivo hace cambios en programas de computadora a fin de que se
puedan corregir, adaptar y mejorar más fácilmente.

El mantenimiento aunque en tiempo fue despreciada su importancia, es considerado en la

actualidad uno de los problemas más riguroso en el desarrollo del software. Muchos
investigadores sugieren que el costo de mantenimiento más de la mitad de los costos y
recursos globales del desarrollo total del software.

1.9 Calidad del Software

Todas las metodologías y herramientas tienen un único fin que es producir software de
gran calidad.

Podemos considerar la calidad del software como:

“La concordancia entre los requisitos funcionales y de rendimiento explícitamente

establecidos con los estándares de desarrollo explícitamente documentados y con las

32
 características implícitas que se espera de todo software desarrollado
profesionalmente”.

Los requisitos del software son la base de las medidas de calidad. La falta de concordancia
con los requisitos es una falta de calidad. Los estándares o metodologías definen un
conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del
software. Si no se sigue ninguna metodología siempre habrá falta de calidad. Existen
algunos requisitos implícitos o expectativas que a menudo no se mencionan, o se
mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que
también pueden implicar una falta de calidad.

Aseguramiento de calidad del software (Software Quality Assurance)

El aseguramiento de calidad del software es el conjunto de actividades planificadas y

sistemáticas necesarias para aportar la confianza en que el producto (software)
satisfacerá los requisitos dados de calidad. El aseguramiento de calidad del software se
diseña para cada aplicación antes de comenzar a desarrollarla y no después.

El aseguramiento de calidad del software está presente en:

• Métodos y herramientas de análisis, diseño, programación y prueba.

• Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del
software.
• Estrategias de prueba multiescala.
• Control de la documentación del software y de los cambios realizados.
• Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de
ellos).
• Mecanismos de medida (métricas).
• Registro de auditorias y realización de informes.

1.9.1 Factores de calidad del software

La construcción de software de calidad requiere el cumplimiento de numerosas

características. Entre ellas se destacan:

• Eficiencia: La eficiencia del software está dada por la capacidad de hacer un buen
uso de los recursos que manipula.

• Transportabilidad (Portabilidad): La portabilidad es la facilidad con que un

software puede ser transportado sobre diferentes sistemas físicos y lógicos.

• Verificabilidad: La verificabilidad es la facilidad de verificación de un software, es

la capacidad de soportar los procedimientos de validación y facilitar juegos de
pruebas ó ensayos de programas.

33
 • Integridad: La integridad es la capacidad de un software de proteger sus propios
componentes contra los procesos que no tengan derecho de acceso.

• Fácil de utilizar: Un software es fácil de utilizar si se puede comunicar con él de

manera cómoda.

• Corrección: Capacidad de los productos de software de realizar exactamente las

tareas definidas en su especificación.

• Robustez: Capacidad de los productos de software de funcionar incluso en

condiciones anormales.

• Extensibilidad: Facilidad que tienen los productos de adaptarse a cambios en su

especificación. Para esto es bueno seguir principios de diseño simple y
descentralizado.

• Reutilización: Capacidad de los productos para ser reutilizados en parte o en su

totalidad en nuevas aplicaciones.

• Compatibilidad: Facilidad de los productos de ser combinados con otros.

1.10.2 Bibliografía.

Para profundizar los conocimientos adquiridos en este capítulo, puede consultar la

siguiente literatura:
 Pressman R.: Ingeniería del Software. Un enfoque práctico. Cuarta Edición. Mc
Graw Hill. 1997.
 Meyer B.: Reusable Software: The Base Object Oriented Component Libraríes,
Prentice-Hall, 1995.
 [IEEE93] IEEE Estándar Collection: Software Engineering, IEEE Standard 610.12-
90, IEEE 1993.
 [WAS80] Wasserman A: Principles of Systematics Data Design and
Implementation, en Software Design Thecniques (Pressman and Waserman ed.)
tercera edicion, IEEE Computer Society Press, 1980, 287-293.

5.2 Bibliografía.

Para profundizar los conocimientos adquiridos en este capítulo, puede consultar la

siguiente literatura:

34
• Modelado y diseño orientados a objetos. Metodología OMT . Prentice Hall. 1995
Rumbaugh, Jim y otros.

• Object-Oriented Modeling and Design. Prentice Hall. 1991.

Rumbaugh, Blaha, et. al.

• Análisis y Diseño orientado a objetos con aplicaciones. Benjaming Cummings 1994

Booch, Grady.

• Ingeniería del Software. Un enfoque práctico. Mc Graw Hill. 1997 Cuarta Edición
Roger Pressman.

• www.rational.com

35