INDICE

INTRODUCCIN............................................................................................................... 2
CAPITULO 1. INGENIERA DEL SOFTWARE........................................................................3
1. El Software y el Proceso...........................................................................................3
1.1 Caractersticas del software..........................................................................................3
1.2 Componentes del software............................................................................................4
1.3 Aplicaciones del software.............................................................................................5
1.4 Ingeniera del Software.................................................................................................6
1.5 Sistemas Basados en Computadora...............................................................................9
1.6 Ingeniera de la informacin.......................................................................................11
1.7 Ingeniera de productos...............................................................................................11
2. Gestin de proyectos de software.............................................................................11
2.1 Planificacin de proyectos..........................................................................................13
2.2 Actividades asociadas a la planificacin de proyectos de software............................14
2.3 Estimacin del proyecto de software..........................................................................15
2.4 Modelos empricos de estimacin...............................................................................16
2.5 Herramientas automticas de estimacin....................................................................17
3. Anlisis de sistemas.................................................................................................. 17
3.1 Identificacin de las necesidades (anlisis de requisitos)...........................................18
3.2 Estudio de la viabilidad...............................................................................................21
3.3 Anlisis tcnico y econmico......................................................................................22
3.4 Modelado de la arquitectura del sistema.....................................................................23
3.5 Especificacin del sistema..........................................................................................23
3.6 Creacin de prototipos del software...........................................................................24
1.4 Diseo de sistemas................................................................................................. 25
1.4.1 Diseo de datos........................................................................................................25
1.4.2 Diseo arquitectnico..............................................................................................26
1.4.3 Diseo de la interfaz................................................................................................27
4.4 Diseo procedimental.................................................................................................27
1.4.4 Arquitectura del software.........................................................................................28
1.4.6 Criterios para evaluar la calidad del diseo.............................................................28
1.5 Desarrollo de software........................................................................................... 29
1.6 Prueba del software.............................................................................................. 29
1.6.1 Objetivos de la prueba..............................................................................................30
1.6.2 Verificacin y validacin..........................................................................................30
1.7 Implantacin........................................................................................................... 30
1.7.1 Capacitacin de usuarios del sistema.......................................................................30
1.7.2 Evaluacin 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 Bibliografa............................................................................................................34
5.2 Bibliografa.................................................................................................................34
INTRODUCCIN

Las tcnicas de modelacin 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 aplicacin, modelar la empresa, documentar y disear programas y bases
de datos.

La esencia del desarrollo orientado a objetos es la identificacin y organizacin de

conceptos del dominio de la aplicacin y no de su representacin final en un lenguaje de
programacin. El desarrollo orientado a objetos es un proceso conceptual, es una forma de
pensar y no una tcnica de programacin. . 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

grfico para visualizar, especificar, construir y documentar los artefactos de un sistema con
gran cantidad de software. Proporciona una forma estndar 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
programacin, esquemas de bases de datos y componentes reutilizables.

La metodologa de anlisis y diseo orientados a objetos OMT es un proceso para la

produccin 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 formulacin inicial del problema, pasando por el anlisis, diseo,
implementacin y prueba del software, y una fase adicional de mantenimiento si es
necesaria. Est basada en el uso de una notacin 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 Ingeniera 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 representacin grfica 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 metodologa
OMT de anlisis y diseo orientados a objetos, con el objetivo de que se conozcan los
distintos pasos a seguir en la creacin de software.
.

2
CAPITULO 1. INGENIERA DEL SOFTWARE

1. El Software y el Proceso.

Qu es realmente el software? El software es un producto que permite la utilizacin de la

potencia del hardware informtico en su mayor medida, produciendo y gestionando
informacin, mostrndola y modificndola. Es la base de control de la computadora
(sistemas operativos), la comunicacin de informacin (redes), y hasta de la creacin y
control de otros softwares (herramientas de desarrollo y entornos). Entrega informacin
(considerada por muchos el producto ms importante) y proporciona el medio de adquirirla,
gestiona informacin comercial en vistas a mejorar la competitividad, permite el acceso a
las redes de comunicacin (Internet). Su papel ha cambiado mucho desde las dcadas
anteriores a la actualidad, provocado esto por las grandes mejoras en el hardware y los
cambios en las arquitecturas informticas, 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 atrs la capacidad de producir
software para alcanzar el potencial del mismo, la demanda de nuevos programas es ms
grande que la capacidad de produccin de software y por tanto no se cubren las necesidades
del mercado y los negocios, la sociedad es cada vez ms dependiente de la fiabilidad del
software y sus fallos provocan daos econmicos 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
funcin y el rendimiento deseados,
2. estructuras de datos que permiten a los programas manipular adecuadamente la
informacin, y
3. documentos que describen la operacin y el uso de programas.

1.1 Caractersticas del software

Para poder comprender lo que es el software (y consecuentemente la ingeniera del

software), es importante examinar las caractersticas 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 fsica. El software es un elemento del
sistema que es lgico, en lugar de fsico, por tanto el software tiene caractersticas
considerablemente distintas a las del hardware:

El software se desarrolla, no se fabrica en un sentido clsico. Aunque existen

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

3
 diseo, pero la fase de construccin del hardware puede introducir problemas de calidad
que no existen (o son fcilmente corregibles) en el software. Ambas actividades
dependen de las personas y requieren de mtodos de construccin del producto final,
pero la relacin entre las personas dedicadas y el trabajo realizado es completamente
diferente para el software, as como los mtodos 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 perodo de tiempo
en que los componentes de hardware sufren los efectos acumulativos de la suciedad, la
vibracin, 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
harn que falle el programa durante las primeras etapas de su vida pero estos se
corrigen.

La implicacin 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 mnimo de fallos comienza a crecer; el software se va deteriorando
debido a los cambios. Cada fallo en el software indica un error en el diseo o en el
proceso mediante el que se tradujo el diseo a cdigo mquina ejecutable. Por tanto, el
mantenimiento en el software es ms 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 mayora del software se construye a medida, en vez de ensamblar componentes

existentes. Para el diseo y construccin de hardware de control para un producto
basado en un microprocesador el ingeniero construye un esquema de la circuitera
digital, hace algn anlisis fundamental para asegurar que se realiza la funcin adecuada
y va al catlogo de ventas de componentes digitales existentes, donde cada circuito
integrado tiene un nmero de pieza, una funcin definida y vlida, una interfaz bien
definida y un conjunto estndar de criterios de integracin, 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 catlogos de componentes de software.
Se puede comprar software ya desarrollado, pero slo 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

diseo estndar. Los componentes reutilizables se han creado para que el ingeniero pueda
concentrarse en elementos verdaderamente innovadores de un diseo. En el mundo del
hardware, la reutilizacin de componentes es una parte natural del proceso de ingeniera.
En el mundo del software, es algo que todava se tiene que lograr en una escala amplia.

4
La reutilizacin es una caracterstica importante para un componente de software de alta
calidad. El componente debera disearse e implementarse para que pueda volver a ser
reutilizado en muchos programas diferentes. En los aos sesenta se construyeron
bibliotecas de subrutinas cientficas reutilizables en una amplia serie de aplicaciones
cientficas y de ingeniera. Esas bibliotecas de subrutinas reutilizaban de forma efectiva
algoritmos bien definidos, pero tenan un dominio de aplicacin limitado. Hoy en da, se ha
extendido la visin de reutilizacin para abarcar no slo los algoritmos, sino tambin
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 situacin en la que se haya definido previamente

un conjunto especfico de pasos procedimentales Dos factores importantes a considerar
para determinar la naturaleza de una aplicacin de software son: el contenido y
determinismo de la informacin. El contenido se refiere al significado y a la forma de la
informacin de entrada y de salida. El determinismo de la informacin se refiere a la
predecibilidad del orden y del tiempo de llegada de los datos. Un programa de ingeniera
acepta datos que estn en un orden predefinido, ejecuta el algoritmo sin interrupcin y
produce los datos resultantes en un informe o formato grfico.

El software, segn 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 gestin de archivos) procesan estructuras de informacin complejas,
pero determinadas. Otras aplicaciones de sistemas, como ciertos componentes del
sistema operativo, utilidades de manejo de perifricos 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 adquisicin de datos que
recolecta y da formato a la informacin recibida del entorno externo, un componente de
anlisis que transforma la informacin segn lo requiera la aplicacin, un componente
de control/salida que responda al entorno externo y un componente de monitorizacin
que coordina todos los dems componentes, de forma que pueda mantenerse la
respuesta en tiempo real.

Software de gestin. El procesamiento de informacin comercial constituye la mayor

de las reas de aplicacin del software. Los sistemas discretos (nminas,
inventarios, etc.) han evolucionado hacia el software de sistemas de informacin de
gestin (SIG), que accede a una o ms bases de datos grandes que contienen
informacin comercial.

5
 Software de ingeniera y cientfico. Est caracterizado por los algoritmos de manejo
de nmeros. Las aplicaciones van desde la astronoma a la vulcanologa, desde el
anlisis de la presin de los automotores a la dinmica orbital de las lanzaderas
espaciales y desde la biologa molecular a la fabricacin automtica. Sin embargo, las
nuevas aplicaciones del rea de ingeniera y ciencia se han alejado de los algoritmos
convencionales numricos. El diseo asistido por computadoras (del ingls CAD), la
simulacin de sistemas y otras aplicaciones interactivas, han comenzado a coger
caractersticas del software de tiempo real e incluso del software de sistemas.

Software empotrado. Los productos inteligentes se han convertido en algo comn en

casi todos los mercados de consumo e industriales. El software empotrado reside en
memoria de slo 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 dcada.

El procesamiento de textos, las hojas de clculo, los grficos por computadora,
multimedia, entretenimientos, gestin 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 numricos para

resolver problemas complejos para los que no son adecuados el clculo o el anlisis
directo. Actualmente, el rea ms activa de la IA es la de los sistemas expertos o
basados en el conocimiento. Otras reas de aplicacin para este software son el
reconocimiento de patrones (imgenes y voz), la prueba de teoremas y los juegos. En
los ltimos aos se ha desarrollado una nueva rama del software de IA llamada redes
neuronales artificiales.

1.4 Ingeniera del Software

La Ingeniera del Software es un rea de la informtica que ofrece mtodos y tcnicas para
desarrollar y mantener software de calidad que resuelvan problemas de todo tipo. La
Ingeniera del Software es una nueva ingeniera. Una seleccin de las definiciones de
Ingeniera del Software se muestra a continuacin:

Definicin de Fritz Bauer, 1972:

Ingeniera del Software trata del establecimiento de principios y mtodos de la
ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje en
maquinas reales.

La mayora de los lectores tienden a seguir esta definicin. Aunque no dice sobre los
aspectos tcnicos de la calidad del software, no se enfrenta directamente con la necesidad
de la satisfaccin del cliente, omite la mencin de la importancia de mediciones y mtricas;
tampoco expresa la importancia de un proceso avanzado. Sin embargo, la definicin de
Bauer nos proporciona una lnea base.

6
El IEEE [IEEE93] ha desarrollado una definicin ms completa:

Ingeniera del software: (1) La aplicacin de un enfoque sistemtico,

disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del
software; es decir, la aplicacin de ingeniera al software. (2) El estudio de
enfoques como en (1).

1.4.1 Proceso, mtodos y herramientas

La ingeniera del software es una tecnologa multicapa. Cualquier enfoque de ingeniera

debe descansar sobre un empeo de organizacin de calidad. La gestin total de calidad y
las filosofas similares fomentan una cultura continua de mejoras de procesos, la que
conduce ltimamente al desarrollo de enfoques cada vez ms robustos para la ingeniera del
software.

El fundamento de la ingeniera del software es la capa proceso. El proceso de la ingeniera

del software es la unin que mantiene juntas las capas de tecnologa y que permite un
desarrollo racional y oportuno de la ingeniera 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 tecnologa de la ingeniera del software. Las reas clave del proceso forman
la base del control de gestin de proyectos del software y establece el contexto en el que se
aplican los mtodos tcnicos, 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 mtodos de la ingeniera del software indican cmo construir tcnicamente el software.
Abarcan un conjunto de tareas que incluyen anlisis de requisitos, diseo, construccin de
programas, pruebas y mantenimiento.

Las herramientas de la ingeniera del software proporcionan un soporte automtico o

semiautomtico para el proceso y para los mtodos. Cuando se integran herramientas para
que la informacin creada por una herramienta la pueda utilizar otra, se establece un
sistema de soporte para el desarrollo del software llamado ingeniera del software asistida
por computadora (Computer Aided Software Engineering, CASE). CASE combina
software, hardware y una base de datos de ingeniera del software.

La ingeniera es el anlisis, diseo, construccin, verificacin y gestin de entidades. A la

entidad se le debe realizar y responder las siguientes preguntas:

Cul es el problema a resolver?

Cules son las caractersticas de la entidad utilizadas para resolver el problema?
Cmo se realizar la entidad (y la solucin)?
Cmo se construir la entidad?
Qu enfoque se va a utilizar para no contemplar los errores que se cometieron en el
diseo y en la construccin de la entidad?

7
 Cmo se apoyar la entidad cuando usuarios soliciten correcciones, adaptaciones y
mejoras de la entidad?

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

Fase de definicin se centra sobre el qu.

Fase de desarrollo se centra en el cmo.
Fase de mantenimiento se centra en el cambio que va asociado a la correccin.

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 acompae al proceso, mtodos,
herramientas y fases genricas del proceso del software.

Todo el desarrollo del software se puede caracterizar como un bucle de resolucin de

problemas donde se encuentran cuatro etapas distintas:

Status quo: estado actual de sucesos.

Definicin de problemas: identifica el problema especfico a resolver.
Desarrollo tcnico: resuelve el problema a travs de la aplicacin de alguna tecnologa.
Integracin de soluciones: ofrece los resultados a los que solicitan la solucin en primer
lugar.

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

Modelo lineal secuencial: llamado tambin ciclo de vida clsico, sugiere un enfoque
sistemtico y secuencial del desarrollo del software, y consta de las actividades siguientes:

Ingeniera y modelado del sistema/informacin: el software siempre forma parte de un

sistema ms grande, hay que determinar de ese sistema que requisitos forman parte del
software, y su conexin con otros elementos como personas o bases de datos.
Anlisis de los requisitos del software: parte de esto se logra en el paso anterior, en este
paso ese proceso de reunin 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.
Diseo: 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
representacin del software que se pueda evaluar por calidad antes de la generacin de
cdigo, y al igual que los requisitos se documenta, lo que forma parte de la
configuracin del software.
Generacin de cdigo o implementacin: Este paso lleva a cabo la tarea de traduccin
del diseo a una forma legible por la mquina. Si el diseo es detallado este paso es casi
mecnico.

8
 Pruebas: Despus de la generacin comienzan las pruebas del programa, centrada en
los procesos lgicos 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 construccin de prototipos: este modelo comienza con la recoleccin de

requisitos, donde analista y cliente definen las necesidades, luego aparece un diseo
rpido, que se centra en la representacin de los aspectos visibles al usuario, este diseo
lleva a la construccin 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 ingeniera del software en
vistas a la calidad y la facilidad de mantenimiento.

Modelo DRA: el modelo de desarrollo rpido de aplicaciones es un modelo de desarrollo

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

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

Modelo incremental: combina el ciclo de vida clsico con la filosofa interactiva de

construccin 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 construccin de prototipos con

los aspectos controlados del modelo lineal secuencial, se desarrolla el software en cada
etapa o espiral como un prototipo que evala el cliente y que es el punto de partida de la
prxima iteracin.

Modelo de ensamblaje de componentes: este incorpora muchas caractersticas del modelo

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

1.5 Sistemas Basados en Computadora

La Ingeniera del Software es una consecuencia de un proceso llamado Ingeniera de

Sistemas de Computadoras.

El proceso de ingeniera del software es denominado ingeniera de la informacin cuando

el contexto del trabajo de ingeniera se enfoca a una empresa. Cuando hay que construir un
producto, el proceso se denomina ingeniera de producto.

9
Ambas ingenieras de la informacin y de producto intentan poner orden al desarrollo de
sistemas basados en computadoras, tanto la ingeniera de la informacin 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 trminos ms usados del lxico tcnico. El diccionario
Webster define sistema como un conjunto o disposicin de cosas relacionadas de
manera que forman una unidad o u todo orgnico... un conjunto de hechos, principios,
reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lgico de
unin de las partes... un mtodo o plan de clasificacin o disposicin... una manera
establecida de hacer algo; mtodo; procedimiento....

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

que estn organizados para realizar un objetivo predefinido procesando informacin.

1.5.1 Elementos de un sistema basado en computadoras

Software. Programas de computadora, estructuras de datos y su documentacin que

sirven para hacer efectivo el mtodo lgico, procedimiento o control requerido.

Hardware. Dispositivos electrnicos que proporcionan capacidad de clculo y

dispositivos electromecnicos (Ej.: sensores, motores, bombas) que proporcionan una
funcin externa.

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

Base de datos. Una gran coleccin de informacin organizada a la que se accede por
medio del software.

Documentacin. Manuales, formularios y otra informacin descriptiva que retrata el

empleo y/o operacin del sistema.

Procedimientos. Los pasos que definen el empleo especfico 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 informacin. La

ingeniera 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
Definan explcitamente las entradas de informacin al modelo
Representen todas las uniones (incluyendo las salidas) que permitan al ingeniero
entender mejor la visin.

10
1.6 Ingeniera de la informacin

La meta de la ingeniera de la informacin es definir arquitectura que permitan a las

empresas emplear la informacin eficazmente. Se deben analizar y disear tres
arquitecturas diferentes dentro del contexto de objetivos y metas de negocio:

Arquitectura de datos
Arquitectura de aplicaciones
Infraestructura de la tecnologa

La arquitectura de datos proporciona una estructura para las necesidades de informacin de

un negocio o de una funcin de negocio. Los objetos de datos fluyen entre las funciones de
negocio, estn organizados dentro de una base de datos y son transformados para
proporcionar informacin que satisfaga las necesidades del negocio.

La arquitectura de aplicacin comprende aquellos elementos de un sistema que transforma

objetos dentro de la arquitectura de datos por algn propsito del negocio. Vamos a
considerar que la arquitectura de aplicacin es el sistema de programas (software) que
realiza esta transformacin. .

La infraestructura de la tecnologa 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 Ingeniera de productos

La meta de la ingeniera de productos es traducir el deseo de un cliente, de un conjunto de

capacidades definidas, en un producto operativo. Para conseguir esta meta, la ingeniera de
producto (como la ingeniera de la informacin) 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 tecnologa requerida para unir los componentes y la informacin (p. ej.:
documentos, CD-ROM, vdeo) que se emplea para dar soporte a los componentes.

2. Gestin de proyectos de software

La gestin 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 ingeniera
del software es un esfuerzo humano intenso nunca tendr xito en la gestin de proyectos.
Un gestor que no fomenta una minuciosa comunicacin con el cliente al principio de la
evolucin del proyecto se arriesga a construir una elegante solucin para un problema
equivocado. Finalmente, el administrador que presta poca atencin al proceso corre el
riesgo de arrojar mtodos tcnicos y herramientas eficaces al vaco.

11
Personal

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

1. Gestores superiores, que definen los aspectos de negocios que a menudo tienen una
significativa influencia en el proyecto.
2. Gestiones (tcnicos) del proyecto, que deben planificar, motivar, organizar y
controlar a los profesionales que realizan el trabajo de software.
3. Profesionales, que proporcionan las capacidades tcnicas necesarias para la
ingeniera de un producto o aplicacin.
4. Clientes, que especifican los requisitos para la ingeniera del software.
5. Usuarios finales, que interaccionan con el software una vez que se ha entregado para
la produccin,

Problema

Antes de poder planificar un proyecto, se deberan establecer sus objetivos y su mbito, se

deberan considerar soluciones alternativas e identificar las dificultades tcnicas y de
gestin. Sin esta informacin, es imposible definir unas estimaciones razonables (y
exactas) del costo, una valoracin efectiva del riesgo, una subdivisin realista de las tareas
del proyecto o una planificacin del proyecto asequible que proporcione una indicacin
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
ingeniera del sistema y contina como el primer paso en el anlisis de los requisitos del
software. Los objetivos identifican las metas generales del proyecto sin considerar cmo se
conseguirn.

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

problema, y ms importante, intenta abordar estas caractersticas 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
impuestas por las fechas lmite de entrega, restricciones del presupuesto, disponibilidad de
personal, interfaces tcnicas y otros muchos factores.

Proceso

12
Un proceso de software proporciona la estructura desde la que se puede establecer un
detallado plan para el desarrollo del software. Un pequeo nmero de actividades
estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su
tamao o complejidad. Diferentes conjuntos de tareas, hitos, entregas y garanta de calidad
permite a las actividades estructurales adaptarse a las caractersticas del proyecto de
software y a los requisitos del equipo del proyecto. Finalmente, las actividades protectoras
tales como garanta de calidad del software, gestin y configuracin del software y
medicin cubren el modelo de proceso y se desarrollan a todo lo largo del mismo.

2.1 Planificacin de proyectos

El proceso de gestin de proyecto de software comienza con un conjunto de actividades que

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

Aunque la estimacin es ms un arte que una ciencia, es una actividad importante que no
debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de
costes y de tiempos. Y, dado que la estimacin es la base de todas las dems actividades de
planificacin del proyecto y sirve como gua para una buena ingeniera del software, no es
en absoluto aconsejable embarcarse sin ella.

La estimacin de recursos, costes, y planificacin temporal de un esfuerzo en desarrollo de

software requiere experiencia, acceder a una buena informacin histrica y el coraje de
confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos. La
estimacin conlleva un riesgo inherente y es este riesgo el que lleva a la incertidumbre.

En la estimacin se toman en cuenta adems del procedimiento tcnico a utilizar en el

proyecto, los recursos, costos y planificacin. El tamao del proyecto constituye un factor
importante que puede afectar la precisin de las estimaciones. En la medida que el tamao
aumenta, se incrementa ms rpido la independencia de los elementos del software.

2.1.1 Objetivos de la planificacin del proyecto

El objetivo de la planificacin del proyecto de software es brindar un entorno de trabajo

que facilite al gestor hacer estimaciones de recursos, costos y planificacin 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 deberan 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 planificacin de proyectos de software.

2.2.1 mbito del Software.

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

Contexto. Cmo 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 informacin. Qu objetos de datos visibles al cliente se obtienen del
software? Qu objetos de datos son requeridos de entrada?
Funcin y rendimiento. Qu funcin realiza el software para transformar la
informacin de entrada en una salida? Hay caractersticas de rendimiento especiales
que abordar?

Durante esta etapa, se deben evaluar la funcin y el rendimiento que se asignaron al

software durante la Ingeniera del Sistema de Computadora, con el propsito de establecer
un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos

El mbito del software describe la funcin, el rendimiento, las restricciones, las interfaces y
la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar ms
detalles antes del comienzo de la estimacin. Las restricciones de rendimiento abarcan los
requisitos de tiempo de respuesta y procesamiento, identifican los lmites del software
originados por el hardware externo, por la memoria disponible y por otros sistemas
existentes.

Un prerrequisito para la estimacin es el mbito del software, un elemento importante a

tener en cuenta es la obtencin de la informacin necesaria para el software, donde el
analista y el cliente se renen y mediante la realizacin de preguntas llegan a precisar y
determinar los limites del sistema para su desarrollo, as como a una mejor comprensin
por el analista de sistema.

2.2.2 Recursos

La segunda actividad de la planificacin del desarrollo de software es la estimacin de los

recursos requeridos para llevar a cabo el desarrollo de software, esto simula a una pirmide
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 ms alta de la pirmide se encuentran los recursos humanos.

Las caractersticas de cada recurso estn dadas por:

Descripcin 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, slo puede ser determinado despus de hacer una estimacin del
esfuerzo de desarrollo (por ejemplo personas mes o personas aos), tambin se selecciona
la posicin dentro de la organizacin y la especialidad que desempear cada profesional
durante el desarrollo del software.

Recursos de software reutilizables

Cualquier estudio sobre recursos de software estara incompleto sin estudiar la

reutilizacin, o sea, la creacin y la reutilizacin de bloques de construccin de software.
Se sugieren cuatro categoras de recursos de software a tener en cuenta durante la
planificacin:
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 ingeniera

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 prctica de la ingeniera del software. Como la mayora 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 estarn disponibles.
Cuando se le aplica la ingeniera a un sistema basado en computadora, el equipo de
software puede requerir acceso a los elementos en desarrollo por otros equipos de
ingeniera.

2.3 Estimacin del proyecto de software.

El coste del software constitua un pequeo porcentaje del coste total de los sistemas
basados en computadora. En la actualidad, el software constituye el elemento ms caro de
la mayora de los sistemas informticos. Un gran error en la estimacin del coste puede ser
lo que marque la diferencia entre beneficios y prdidas, y sobrepasarse en el coste puede ser
catastrfico en el equipo de desarrollo.
La estimacin del coste y del esfuerzo del software nunca ser una ciencia exacta. Son
demasiadas las variables humanas, tcnicas, de entorno, polticas 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 estimacin para ms adelante (lgico que podemos realizar una estimacin
al cien por cien fiable luego de haber terminado el proyecto).
2. Guiar las estimaciones en proyectos similares ya concluidos.
3. Usar tcnicas de descomposicin relativamente sencillas para generar las
estimaciones de coste y de esfuerzo del proyecto.
4. Realice un modelo emprico para el clculo de costes y esfuerzos del software.

Lamentablemente, la primera opcin, aunque atractiva, no es prctica, debido a que las

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

La segunda opcin funciona si el proyecto actual es bastante similar a los esfuerzos

anteriores y si otras influencias del proyecto son similares.

Las opciones restantes son mtodos viables para la estimacin del proyecto de software.
Las tcnicas de descomposicin utilizan un enfoque de divide y vencers para la
estimacin del proyecto de software. Se pueden utilizar los modelos empricos de
estimacin como complemento de las tcnicas de descomposicin, ofreciendo un enfoque
de estimacin potencialmente valioso por derecho propio

2.3.1 Tcnicas de estimacin. Estimacin basada en el proceso.

La estimacin basada en el proceso es la tcnica ms comn para estimar un proyecto, es

decir, el proceso se descompone en un conjunto relativamente pequeo de tareas, y en el
esfuerzo necesario para estimar cada tarea. Esta estimacin se inicia con una delineacin
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 funcin y en general la del proceso de software.

2.4 Modelos empricos de estimacin

Los datos empricos que soportan la mayora de los modelos de estimacin se obtienen de
una muestra limitada de proyectos. Por esta razn, el modelo de estimacin 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 clsico sobre economa de la Ingeniera del Software, introduce
una jerarqua de modelos de estimacin de Software con el nombre de COCOMO
(Constructive Cost Model) o modelo constructivo de costos. La jerarqua de modelos de
Boehm esta formada por:

16
Modelo I. Es el modelo COCOMO bsico que calcula el esfuerzo y el costo del desarrollo
de software en funcin del tamao del programa, expresado en las lneas estimadas.

Modelo II. Es el modelo intermedio que calcula el esfuerzo del desarrollo de software en
funcin del tamao del programa y de un conjunto de conductores de costos que
intervienen en la evaluacin subjetiva del producto, del hardware, del personal y de los
atributos del proyecto.

Modelo III. Es el modelo avanzado que incorpora las caractersticas de la versin

intermedia y lleva a cabo una evaluacin del impacto de los conductores de costos en cada
caso (anlisis, diseo, etc.) del proceso de ingeniera de Software.

2.5 Herramientas automticas de estimacin

Las tcnicas de descomposicin y los modelos empricos de estimacin se pueden

implementar con software, las herramientas automticas de estimacin permiten al
planificador estimar costes y esfuerzos, y llevar a cabo un anlisis del tipo qu pasa si
con importantes variables del proyecto, como es la fecha de entrega y la seleccin de
personal.

Las herramientas automticas de estimacin requieren una o ms clases de datos como:

Una estimacin cuantitativa del tamao del proyecto o de la funcionalidad.

Caractersticas cualitativas del proyecto: complejidad, la fiabilidad requerida y el grado
de criticidad del negocio.
Descripcin del personal de desarrollo y/o del entorno de desarrollo.

Con estos datos, el modelo implementado por la herramienta automtica de estimacin

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

3. Anlisis de sistemas

El anlisis 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 anlisis tcnico y econmico.
Asignar funciones al hardware, software, personal, bases de datos y otros elementos del
sistema.
Establecer restricciones de presupuesto y planificacin temporal.

17
 Crear una definicin del sistema que forme el fundamento de todo el trabajo de
ingeniera.

Para alcanzar los objetivos de la etapa del anlisis se requiere de un amplio conocimiento
del rea de hardware, software, administracin de bases de datos y de la ingeniera humana
para interactuar con el personal que solicita la realizacin del sistema.

Los mtodos de anlisis se relacionan por un conjunto de principios operativos:

l. Debe representarse y entenderse el dominio de informacin 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 informacin, funcin y comportamiento
de manera que se descubran los detalles por capas (o jerrquicamente).
5. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la
implementacin.

Adems de los principios operativos de anlisis mencionados anteriormente, se sugiere un

conjunto de principios directrices para la ingeniera de requisitos:

Entender el problema antes de empezar a crear el modelo de anlisis. Hay tendencia a

precipitarse en busca de una solucin, incluso antes de entender el problema.
Desarrollar prototipos que permitan al usuario entender como ser la interaccin
hombre-mquina. Como el concepto de calidad del software se basa a menudo en la
opinin sobre la amigabilidad de la interfaz, el desarrollo de prototipos (y la
iteracin que se produce) es altamente recomendable.
Registrar el origen y la razn de cada requisito. Este es el primer paso para establecer
un seguimiento hasta el cliente
Use mltiples planteamientos de requisitos. La construccin 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
implementacin 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 ambigedad. Como la mayora de los requisitos estn
descritos en un lenguaje natural, abunda la oportunidad de ambigedades. El empleo
de revisiones tcnicas formales es una manera de descubrir y eliminar la ambigedad.

3.1 Identificacin de las necesidades (anlisis de requisitos)

18
Lo primero en el anlisis del sistema es la identificacin de la necesidad del usuario, donde
el analista se rene 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 evaluacin de la
informacin suplementaria:

Tecnologa para construir el sistema.

Recursos especiales de desarrollo y fabricacin necesarios.
Lmites de presupuesto y de planificacin temporal.
Si el nuevo sistema es un producto a desarrollar para venderlo a muchos clientes, se
debe analizar: Cul es el mercado potencial del producto? Cmo es
comparativamente este producto con los de la competencia? Qu posicin ocupa este
producto en la lnea general de produccin de la compaa?

El anlisis de requisitos permite al ingeniero del software (analista) la definicin del

software y construir los modelos de los dominios de datos, funcional y de comportamiento
que van a ser tratados por el software. El anlisis de requisitos proporciona modelos al
diseador del software que pueden traducirse en el diseo de datos, arquitectnico, de
interfaz y procedimental.

El anlisis de requisitos del software puede dividirse en cinco reas:

Reconocimiento del problema
Evaluacin y sntesis
Modelado
Especificacin
Revisin.

El analista estudia la especificacin 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 planificacin. Se debe establecer la comunicacin para el anlisis de
manera que nos garantice el reconocimiento del problema. El objetivo del analista es el
reconocimiento de los elementos bsicos del problema tal y como los percibe el usuario o el
cliente.

En la evaluacin del problema y la sntesis de la solucin el analista debe definir todos los
objetos de datos observables externamente, evaluar el flujo y contenido de la informacin,
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 solucin global.
Durante la actividad de evaluacin y sntesis de la solucin, 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 especificacin detallada del sistema, el cliente puede no
estar seguro de lo que quiere, el desarrollador puede no estar seguro de que un enfoque
especfico consiga apropiadamente el funcionamiento y rendimiento adecuados.

19
Una vez que se han identificado las metas globales, el analista pasa a la evaluacin de la
informacin suplementaria: Existe la tecnologa para construir el sistema? Qu recursos
especiales de desarrollo y fabricacin sern necesarios? Qu lmites se han puesto al
presupuesto y a la planificacin temporal? Si el nuevo sistema es un producto a desarrollar
para venderlo a muchos clientes, se plantean adems las siguientes cuestiones: Cul es el
mercado potencial del producto? Cmo es comparativamente este producto con los de la
competencia? Qu posicin ocupa este producto en la lnea general de produccin de la
compaa?

La informacin reunida durante el paso de identificacin 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
comunicacin cliente-analista origina modificaciones en el documento.

La tcnica de anlisis ms usada para cubrir el hueco de comunicacin entre el cliente y el

desarrollador y para empezar el proceso de comunicacin es llevar a cabo una reunin 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 podra
preguntar:

Quin est detrs de la solicitud de este trabajo?

Quin utilizar la solucin?
Cul ser el beneficio econmico del xito de una solucin?
Hay alguna otra alternativa para la solucin que necesita?

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

problema y al cliente comentar sus opiniones sobre la solucin:

Cmo caracterizara una buena salida (resultado) generada para una buena
solucin?
A qu tipo de problema(s) va dirigida esta solucin?
Puede mostrarme (o describirme) el entorno en que se utilizar la solucin?
Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de
enfocar la solucin?

El ltimo conjunto de preguntas se concentra en la eficacia de la reunin. 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 ms que pueda proporcionar informacin adicional'?
Hay algo ms que debera preguntarle?

20
Estas preguntas (y otras) ayudarn a romper el hielo e iniciar la comunicacin tan
esencial para el xito del anlisis. Pero el formato de reunin tipo pregunta y respuesta
no es un enfoque que haya tenido mucho xito. De hecho, esta sesin de preguntas y
respuestas debera emplearse solamente en el primer encuentro y sustituirse despus por
una modalidad que combine elementos de resolucin del problema, negociacin y
especificacin.

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 anlisis de riesgo estn relacionados de muchas maneras. Si el riesgo del

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

Viabilidad econmica. Es la evaluacin de los costos de desarrollo, con relacin a

los ingresos netos o beneficios obtenidos del sistema desarrollado.
Viabilidad tcnica. Es el anlisis y estudio de funciones, rendimiento y
restricciones que puedan afectar la realizacin de un sistema aceptable.
Viabilidad legal. Es la determinacin de cualquier posibilidad de infraccin,
violacin o responsabilidad legal en que se podra incurrir al desarrollar el sistema.
Alternativas. Una evaluacin de los enfoques alternativos del desarrollo del
sistema.

No es necesario un estudio de viabilidad para sistemas en que la justificacin econmica es

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

La justificacin econmica es generalmente la consideracin fundamental para la mayora

de los sistemas. Incluye una amplia gama de aspectos a tener en cuenta como son el anlisis
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 tecnolgica es frecuentemente el rea ms difcil de valorar en esta etapa del

proceso de ingeniera 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 anlisis y definicin se realice en paralelo con una valoracin de la viabilidad
tcnica. De esta manera se pueden juzgar especificaciones concretas a medida que se
establecen.

Las consideraciones que estn asociadas normalmente con la viabilidad tcnica son:

21
 Riesgo de desarrollo. Puede disearse el elemento del sistema de manera que se
consigan la funcin y rendimiento necesarios dentro de las restricciones descubiertas
durante el anlisis?

Disponibilidad de recursos. Tenemos disponible una plantilla cualificada para

desarrollar el elemento del sistema en cuestin? Tenemos disponibles otros recursos
necesarios (hardware y software) para construir el sistema?

Tecnologa. Ha progresado la tecnologa 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 montn de trampas frecuentemente
desconocidas para el personal tcnico.

El grado con que se consideran las alternativas est a menudo limitado por restricciones de
tiempo y costes; sin embargo, no debera despreciarse una variacin legtima 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 direccin (para valorar el estado del proyecto). El estudio
debera concluir en una decisin adelante / abandonamos.

3.3 Anlisis tcnico y econmico.

Una informacin importante contenida en un estudio de viabilidad es el anlisis de costo/

beneficio: una valoracin de la justificacin econmica para un proyecto de sistema basado
en computadora.

El anlisis 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 anlisis costo/beneficio es complicado por criterios que varan
con las caractersticas del sistema a desarrollar, el tamao relativo del proyecto y los
beneficios esperados de la inversin como parte del plan estratgico de la compaa.
Adems, muchos beneficios obtenidos de los sistemas basados en computadora son
intangibles (por ejemplo, mejor calidad de diseo gracias a una optimizacin frecuente,
mayor satisfaccin 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 difciles de conseguir.

Durante el anlisis tcnico, el analista evala los principios tcnicos del sistema al mismo
tiempo que se recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas
de mantenimiento y productividad.

22
 El anlisis tcnico empieza con una valoracin de la viabilidad tcnica del
sistema propuesto. Qu tecnologas se requieren para lograr el funcionamiento
y rendimiento del sistema?
Qu nuevos materiales, mtodos, algoritmos o procesos se necesitan y cul es
su riesgo de desarrollo?
Cmo afectarn estos aspectos tecnolgicos a los costes?

3.4 Modelado de la arquitectura del sistema.

Los sistemas basados en computadora pueden moderarse como la transformacin de la

informacin 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 autocomprobacin.

Como casi todas las tcnicas de modelado usadas en la ingeniera del software y de
sistemas, el esquema de arquitectura permite al analista crear una jerarqua en detalle. En
la parte alta de la jerarqua reside el diagrama de contexto de la arquitectura (DCA).

El diagrama de contexto establece el lmite de informacin 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 informacin que emplea el sistema, todos los consumidores
externos de informacin creados por el sistema y todas las entidades que se comunican a
travs de la interfaz o realizan mantenimiento y autocomprobacin.

El ingeniero de sistemas refina el diagrama de contexto de arquitectura con ms detalle, y

se identifican los subsistemas principales que permiten funcionar al sistema.

3.5 Especificacin del sistema.

Las especificaciones del sistema se registran en un documento que sirve de base para
ingeniera hardware, software, base de datos, e ingeniera 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 anlisis
se realizan las especificaciones de los requisitos del software.

Puede decirse que un proyecto de desarrollo de un sistema de informacin comprende

varios pasos durante la etapa del anlisis, 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, documentacin y procedimientos

23
3.6 Creacin de prototipos del software.

El anlisis hay que hacerlo independientemente del paradigma de ingeniera del software
que se aplique, sin embargo, la forma que toma este anlisis vara. En algunos casos es
posible aplicar los principios operativos del anlisis y obtener un modelo de software del
que se pueda desarrollar un diseo. En otras situaciones, se realizan recopilaciones de
requisitos, se aplican los principios del anlisis 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 construccin de un prototipo al comienzo del anlisis,
ya que el modelo es el nico medio a travs del cual se pueden obtener eficazmente los
requisitos. El modelo evoluciona despus hacia la produccin del software.

El paradigma de creacin de prototipos puede ser cerrado o abierto. El enfoque cerrado se

denomina a menudo prototipo desechable. Este prototipo sirve nicamente como una basta
demostracin de los requisitos. Despus se desecha, y se hace una ingeniera del software
con un paradigma diferente. Un enfoque abierto, denominado prototipo evolutivo, emplea
el prototipo como primera parte de una actividad de anlisis a la que seguir el diseo y la
construccin. El prototipo del software es la primera evolucin 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 aplicacin que cree pantallas visuales dinmicas, interacte

intensamente con el ser humano, o demande algoritmos de procesamiento de
combinaciones que deban crearse de manera progresiva, es un buen candidato para la
creacin de un prototipo. Sin embargo, estas reas de aplicacin deben ponderarse con la
complejidad de la aplicacin. Si una aplicacin candidato (una con las caractersticas
reseadas anteriormente) va a requerir el desarrollo de decenas de miles de lneas de cdigo
antes de poder realizar cualquier funcin demostrable, es muy probable que sea demasiado
compleja para crear un prototipo. Si se puede hacer una particin 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 evaluacin y refinamiento del prototipo, y (2) el cliente
sea capaz de tomar decisiones inmediatas sobre los requisitos.

Existe un conjunto de seis cuestiones que ayudarn en la seleccin del enfoque de creacin
de prototipos:

1. Entiende el cliente y el desarrollador el dominio de la aplicacin para la que se va a

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

24
 6. Hay contradicciones en los requisitos?

1.4 Diseo de sistemas

El diseo se ha descrito como un proceso multifase en el que se sintetizan representaciones

de la estructura de datos, estructura del programa, caractersticas de la interfaz y detalles
procedimentales desde los requisitos de la informacin.

El diseo del software es el ncleo tcnico del proceso de ingeniera del software y se
aplica independientemente del paradigma de desarrollo utilizado.

Cada uno de los elementos del modelo de anlisis proporciona informacin necesaria para
crear un modelo de diseo. Los requisitos del software, manifestados por los datos y los
modelos funcionales y de comportamiento, componen la fase de diseo. Mediante el
empleo de uno de los mtodos de diseo la fase de diseo produce:

Diseo de datos
Diseo arquitectnico
Diseo de interfaz
Diseo procedimental.

1.4.1 Diseo de datos.

El diseo de datos es la primera (y alguien dira que la ms importante) de las cuatro

actividades de diseo que se llevan a cabo durante la ingeniera del software.

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

procedimental hace que el diseo de los datos tenga una profunda influencia en la calidad
del software. Los conceptos de ocultacin de informacin y abstraccin de datos
proporcionan el fundamento para un enfoque del diseo de datos.

El proceso de diseo de datos lo resume Wasserman [WAS80]:

La actividad principal del diseo de datos es seleccionar representaciones lgicas de

objetos de datos (estructuras de datos) identificadas durante la fase de definicin y
especificacin de requisitos. El proceso de seleccin puede incluir el anlisis de
estructuras alternativas para determinar el diseo ms eficaz o puede incluir
simplemente el empleo de un conjunto de mdulos (un paquete) que proporcione
las operaciones deseadas sobre alguna representacin de un objeto.

Una actividad relacionada importante durante el diseo es identificar aquellos

mdulos del programa que deben operar directamente sobre las estructuras de datos
lgicas. De esta manera se puede restringir el alcance de efecto de las decisiones
individuales sobre el diseo de datos.

25
Independientemente de las tcnicas de diseo que se emplean, datos bien diseados 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 disear datos. En realidad, el diseo de datos empieza durante la creacin del modelo de
anlisis. Recordando que el anlisis de requisitos y el diseo a menudo se solapan,
consideramos el siguiente conjunto de principios [WAS80] para la especificacin de datos:

1. Los principios del anlisis sistemtico aplicados a la funcin y al comportamiento

deberan aplicarse tambin a los datos. Todas las estructuras de datos y las
operaciones a llevar a cabo en cada una de ellas deberan estar claramente
identificadas.
2. Se debera establecer un diccionario de datos y usarlo para definir el diseo de los
datos y del programa.
3. Las decisiones de diseo de datos de bajo nivel deberan dejarse para el final del
proceso de diseo.
4. La representacin de las estructuras de datos deberan conocerla slo aquellos
mdulos que deban hacer uso directo de los datos contenidos dentro de la estructura.
5. Debera desarrollarse una biblioteca de estructuras de datos tiles y de las
operaciones que se les pueden aplicar. Las estructuras de datos y las operaciones
deberan considerarse como recursos para el diseo del software.
6. Un diseo del software y un lenguaje de programacin deberan soportar la
especificacin y realizacin de los tipos abstractos de datos.

El diseo de datos transforma el modelo de dominio de la informacin, creado durante el

anlisis, en las estructuras de datos necesarias para implementar el software. Los objetos de
datos y las relaciones definidas en el diagrama entidad-relacin y el contenido detallado de
datos del diccionario de datos proporciona la base para la actividad de diseo de datos.

1.4.2 Diseo arquitectnico

El objetivo del diseo arquitectnico es desarrollar una estructura de programa modular y

representar las relaciones de control entre los mdulos. Adems, el diseo arquitectnico
combina la estructura del programa y las estructuras de datos, definiendo interfaces que
permiten el flujo de datos a travs del programa.

El diseo orientado al flujo de datos es un mtodo de diseo arquitectnico que permite una
cmoda transicin desde el modelo de anlisis a una descripcin del diseo de la estructura
del programa.

La transicin desde el flujo de informacin (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 informacin; (2) se indican los lmites del flujo; (3) se convierte el DFD en la
estructura del programa; (4) se define la jerarqua de control descomponindola mediante

26
particionamiento; y (5) se refina la estructura resultante usando medidas y heursticas de
diseo. El tipo de flujo de informacin es lo que determina el mtodo de conversin
requerido en el paso 3.

1.4.3 Diseo de la interfaz

El diseo arquitectnico proporciona al ingeniero del software una imagen de la estructura

del programa. Como el plano para una casa, el diseo general no est completo sin la
representacin de las puertas, ventanas y conexiones a servicios para agua, electricidad y
telfono (sin mencionar la televisin por cable). Las puertas, ventanas y conexiones a
servicios para el software de computadora componen el diseo de la interfaz del sistema.

El diseo de la interfaz se concentra en tres reas importantes:

(1) el diseo de interfaces entre los mdulos software;

(2) el diseo de interfaces entre el software y otros productores y consumidores no
humanos de informacin (por ejemplo, otras entidades externas); y
(3) el diseo de la interfaz entre el hombre (Ej. el usuario) y la computadora.

El diseo de la interfaz de usuario tiene tanto que ver con el estudio de las personas como
con los aspectos de la tecnologa. Quin es el usuario? Cmo aprende el usuario a
interactuar con el nuevo sistema basado en computadora?Cmo interpreta el usuario la
informacin 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 diseo de
la interfaz de usuario.

El proceso general para disear la interfaz de usuario empieza con la creacin de diferentes
modelos de funcin del sistema (tal y como se percibe desde fuera). Se definen las tareas
orientadas al hombre y a la mquina, requeridas para conseguir la funcin del sistema; se
consideran los aspectos de diseo aplicables a todos los diseos de interfaz; se usan
herramientas para crear el prototipo e implementar el modelo de diseo y se evala la
calidad del resultado.

El diseo de interfaz describe cmo 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 informacin. Por tanto, los diagramas de flujo de datos y control proporcionan la
informacin necesaria para el diseo de la interfaz.

4.4 Diseo procedimental

El diseo procedimental se realiza despus de los diseos de datos, arquitectnico y de

interfaz. En un mundo ideal, la especificacin procedimental necesaria para definir los
detalles de los algoritmos se expresara en un lenguaje natural. Despus de todo, todos los
miembros de una organizacin de desarrollo de software hablan un lenguaje natural (en

27
teora, al menos), las personas fuera del mundo del software podran entender mejor la
especificacin, y no sera necesario un nuevo aprendizaje.

Desgraciadamente, hay un pequeo problema. El diseo procedimental debe especificar

los detalles procedimentales sin ambigedades, y la falta de ambigedad 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 diseo del software se puede decir con una sola palabra: calidad. El
diseo es el lugar donde se fomenta la calidad en el desarrollo del software. El diseo nos
proporciona representaciones del software en las que se pueden valorar la calidad. El
diseo es la nica manera de traducir con precisin los requisitos del cliente en un sistema o
producto software

El diseo del software es un proceso y un modelo a la vez. El modelo del diseo 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 representacin 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 ms simple, la arquitectura es la estructura jerrquica de los componentes del
programa (mdulos), la manera de interactuar de estos componentes, y la estructura de los
datos usados por estos componentes. La relacin de control entre los mdulos se expresa
de la siguiente manera: un mdulo que controla otro mdulo se dice que es superior a l;
inversamente, un mdulo controlado por otro se dice que es inferior.

La jerarqua de control tambin representa dos caractersticas 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 diseo, se ha convertido en un enfoque

admitido en todas las disciplinas de la ingeniera. Un diseo modular reduce la
complejidad, facilita los cambios y hace ms fcil la implementacin al fomentar el
desarrollo en paralelo de diferentes partes de un sistema.

1.4.6 Criterios para evaluar la calidad del diseo.

Debe tener una estructura jerrquica que haga un uso inteligente del control entre los
componentes del software.

28
 Debe ser modular, o sea hacer una particin lgica del software en elementos que
realicen funciones y subfunciones especificas.
Debe contener abstracciones de datos y procedimientos.
Los mdulos deben presentar caractersticas de funcionamiento independiente.
Las interfaces no deben ser complejas para las conexiones entre los mdulos y el
entorno exterior.
Debe hacerse usando un mtodo segn la informacin obtenida durante el anlisis de
requisitos de Software.

1.5 Desarrollo de software

La fase de desarrollo se centra en el cmo, durante el desarrollo un ingeniero del software

intenta definir cmo han de disearse las estructuras de datos, cmo ha de implementarse la
funcin como una arquitectura del software, cmo han de implementarse detalles
procedimentales, cmo han de caracterizarse las interfaces, cmo ha de traducirse el diseo
en un lenguaje de programacin y cmo ha de realizarse la prueba.

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

escribir programas diseados a la medida del solicitante. La eleccin 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 documentacin de los programas y de explicar

su codificacin, esta documentacin es esencial para probar el programa y hacer el
mantenimiento.

1.6 Prueba del software

Luego de generar el cdigo se comienzan las pruebas del programa, este paso se centra en
los procesos lgicos internos del software, asegurando que todas las sentencias y procesos
externos funcionales se han comprobado, se realizan las pruebas para la deteccin 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 sistemtica. Se debe definir en el proceso de la ingeniera del software una
plantilla para la prueba del software: es decir, un conjunto de pasos en los que podamos
situar los mtodos especficos de diseo 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 caractersticas generales siguientes:

La prueba comienza en el nivel de mdulo y trabaja hacia fuera, hacia la

integracin de todo el sistema basado en computadora.

29
 Segn el momento son apropiadas diferentes tcnicas 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 pequeos segmentos de cdigo 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 gua 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 ejecucin de un programa con la intencin 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 Verificacin y validacin

La prueba del software es un elemento de un tema ms amplio que, a menudo, se le conoce

como verificacin y validacin. La verificacin se refiere al conjunto de actividades que
aseguran que el software implementa correctamente una funcin especfica. La validacin
se refiere a un conjunto diferente de actividades que aseguran que el software construido se
ajusta a los requisitos del cliente.

1.7 Implantacin

La implantacin 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 informacin hay que estar bien seguro que el sistema sea
operacional, o sea, que funcione de acuerdo a los requerimientos del anlisis.

A pesar de que el sistema est bien diseado y cuente con interfaces adecuadas, es
importante para la implantacin realizar una buena capacitacin a todos los usuarios para su
puesta en explotacin y garantizar el mantenimiento.

1.7.1 Capacitacin de usuarios del sistema

Durante la fase de implementacin es responsabilidad del analista la capacitacin 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 quedaran perdidos.

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

No obstante la organizacin puede contratar otros servicios de capacitacin como son:

Vendedores: Son aquellos que proporcionan capacitacin gratuita fuera de la

empresa de uno o dos das.
Instructor pagado externamente: Son aquellos que pueden ensear todo acerca de
las computadoras, en caso necesario para algunos usuarios.
Instructores en casa: Estn familiarizados con el personal y pueden adecuar los
materiales a sus necesidades, pero le faltara experiencia en Sistemas de
Informacin que es realmente la necesidad del usuario.

1.7.2 Evaluacin del sistema.

La evaluacin del sistema se lleva a cabo para identificar puntos dbiles y fuertes del
mismo. Esta evaluacin se lleva en cualquiera de las siguientes dimensiones:

Evaluacin operacional:

Se evala la manera en que funciona el sistema, facilidad de uso, tiempo de respuesta ante
una peticin, formatos en que se muestra la informacin 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 desempeo laboral e impacto competitivo. Se evala el impacto, rapidez y
organizacin en el flujo de informacin interna y externa.

Desempeo del desarrollo:

Se evala el proceso de desarrollo adecuado considerando criterios como, tiempo y

esfuerzo en el desarrollo de acuerdo al presupuesto y estndares y otros criterios de
administracin de proyectos. Se realiza la valoracin de los mtodos y herramientas usados
en el desarrollo del sistema.

1.8 Mantenimiento

31
Es lgico que el software sufra cambios despus de ser entregado al cliente. Se producirn
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 correccin 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 definicin y de desarrollo, pero en el
contexto del software ya existente. Durante la fase de mantenimiento se encuentran cuatro
tipos de cambios:

Correccin. A pesar de llevar a cabo las mejores actividades de garanta de calidad, es

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

Adaptacin. Con el paso del tiempo, es probable que cambie el entorno original (ejemplo:
CPU, el sistema operativo, las reglas de empresa, las caractersticas externas de productos)
para el que se desarroll el software. El mantenimiento adaptativo produce modificacin
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
ms all de sus requisitos funcionales originales.

Prevencin. El software de computadora se deteriora debido al cambio, y por esto el

mantenimiento preventivo tambin llamado reingeniera 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 ms fcilmente.

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

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

1.9 Calidad del Software

Todas las metodologas 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 explcitamente

establecidos con los estndares de desarrollo explcitamente documentados y con las

32
 caractersticas implcitas 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 estndares o metodologas definen un
conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del
software. Si no se sigue ninguna metodologa siempre habr falta de calidad. Existen
algunos requisitos implcitos o expectativas que a menudo no se mencionan, o se
mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que
tambin 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

sistemticas necesarias para aportar la confianza en que el producto (software) satisfacer
los requisitos dados de calidad. El aseguramiento de calidad del software se disea para
cada aplicacin antes de comenzar a desarrollarla y no despus.

El aseguramiento de calidad del software est presente en:

Mtodos y herramientas de anlisis, diseo, programacin y prueba.

Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo del
software.
Estrategias de prueba multiescala.
Control de la documentacin del software y de los cambios realizados.
Procedimientos para ajustarse a los estndares (y dejar claro cuando se est fuera de
ellos).
Mecanismos de medida (mtricas).
Registro de auditorias y realizacin de informes.

1.9.1 Factores de calidad del software

La construccin de software de calidad requiere el cumplimiento de numerosas

caractersticas. 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 fsicos y lgicos.

Verificabilidad: La verificabilidad es la facilidad de verificacin de un software, es

la capacidad de soportar los procedimientos de validacin 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.

Fcil de utilizar: Un software es fcil de utilizar si se puede comunicar con l de

manera cmoda.

Correccin: Capacidad de los productos de software de realizar exactamente las

tareas definidas en su especificacin.

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

especificacin. Para esto es bueno seguir principios de diseo simple y
descentralizado.

Reutilizacin: 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 Bibliografa.

Para profundizar los conocimientos adquiridos en este captulo, puede consultar la

siguiente literatura:
Pressman R.: Ingeniera del Software. Un enfoque prctico. Cuarta Edicin. Mc
Graw Hill. 1997.
Meyer B.: Reusable Software: The Base Object Oriented Component Librares,
Prentice-Hall, 1995.
[IEEE93] IEEE Estndar 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 Bibliografa.

Para profundizar los conocimientos adquiridos en este captulo, puede consultar la

siguiente literatura:

Modelado y diseo orientados a objetos. Metodologa OMT . Prentice Hall. 1995

34
 Rumbaugh, Jim y otros.

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

Rumbaugh, Blaha, et. al.

Anlisis y Diseo orientado a objetos con aplicaciones. Benjaming Cummings 1994

Booch, Grady.

Ingeniera del Software. Un enfoque prctico. Mc Graw Hill. 1997 Cuarta Edicin
Roger Pressman.

www.rational.com

35