Академический Документы
Профессиональный Документы
Культура Документы
Doc!aster
El principal objetivo del 5ocmaster es lograr calidad # completitud en los
documentos del desarrollo. 1us responsabilidades son4
6antener actuali$ado # de calidad el sitio web de la empresa(
Aacerle el seguimiento a la elaboracin # fechas de entregas de los
documentos generados por el equipo(
Lleva el registro de las reuniones generales )asistentes, decisiones,
justificaciones, acciones a tomar # sus responsables-, as como elaborar
# publicar oportunamente sus minutas(
Elaborar # mantener los manuales asociados al desarrollo.
5efinir # velar por los estndares que deben cumplir los documentos, en
cuanto a organi$acin, redaccin, ortografa # consistencia de
presentacin.
.oordinar la elaboracin del material de apo#o a las presentaciones del
equipo # velar por su calidad.
6anejar no ms de cinco riesgos asociados con la documentacin.
En el pasado se ha encontrado conveniente separar este rol en dos4 Editor
!"cnico # 8ebmaster. %ara ello se prev" el rol de ;sistente al 5ocmaster. El
5ocmaster eplicitar qu" responsabilidades quiere delegar en su asistente.
2"
Coordinador de Interfaces con el Usuario
El principal objetivo del .oordinador de 9nterfaces es lograr un producto cu#a
capa de presentacin )interfa$ con el usuario- sea de calidad # en la ma#or
medida posible independiente de la capa del dominio de la aplicacin. 1us
principales responsabilidades son4
.oordinar la elaboracinImantenimiento de los requerimientos, dise,o e
implementacin de la capa de presentacin.
.ustudiar # respaldar los artefactos asociadas a la capa de
presentacin.
Eplicitar las decisiones de dise,o para la capa # sus justificaciones.
;provechar plenamente las habilidades # potencialidades de los dems
miembros del equipo.
6anejar no ms de cinco riesgos asociados al desarrollo de la capa de
la presentacin # el enlace con el cliente.
.oordinar la instalacin del producto # cualquier herramienta de
instalacin utili$ada..
.oordinar las presentaciones del equipo.
Coordinador de <ase de Datos
El principal objetivo del .oordinador de Cases de 5atos es lograr un producto
cu#a capa de base de datos sea de calidad. 1us principales responsabilidades
son4
.oordinar la elaboracinImantenimiento de los requerimientos, dise,o e
implementacin de la capa de la base de datos.
.ustodiar # respaldar los artefactos asociadas a la capa de la base de
datos.
Eplicitar las decisiones de dise,o para la capa # sus justificaciones.
;provechar plenamente las habilidades # potencialidades de los dems
miembros del equipo.
6anejar no ms de cinco riesgos asociados al desarrollo de la capa de
la base de datos.
.oordinar la transcripcin de datos a la base de datos.
Aie!bro de e,uipo
El principal objetivo de cada miembro del equipo es contribuir a la efectividad
de su equipo. 1us responsabilidades inclu#en4
.olaborar proactivamente en el logro de las metas del equipo(
Entregar oportunamente los artefactos que le fueran encomendados(
2$
.umplir oportuna # disciplinadamente con las tareas que le designen, de
dise,o, programacin, prueba, documentacin, instalacin,
entrenamiento, revisin, administracin de herramientas o sitios web(
%articipar para lograr un desarrollo eitoso, un ambiente productivo # un
clima armonioso donde las diferencias de opinin se aprovechan para
enriquecer el trabajo(
Llevar # entregar oportunamente las estadsticas # registros
correspondientes(
;sistir puntualmente a las reuniones convocadas )planifique al menos
una reunin semanal hasta el fin del trimestre-.
.umplir con los estndares de codificacin, proceso # artefactos
asociados al desarrollo.
0espetar los estndares de trabajo del equipo.
2.' Babilidades 1 capacidades de SQA
;seguramiento de la calidad del software... Es bsico # sera fala$ pensar
siquiera en que la calidad podra llegar a Xin#ectarseY al producto software
finali$ando el proceso de desarrollo Zel viejo enfoque del control de la calidad.
El simple control no puede asegurarnos ms que que estaremos mu#
concientes de los dolores de cabe$a que tendremos # la cantidad de dinero que
perderemos. La calidad del producto software depende de tareas reali$adas
durante todo el proceso4 detectar errores en forma temprana ahorra esfuer$os,
tiempo # recursos.
Bo hacer las cosas bien se manifiesta en muchas formas. Estos problemas,
que listo a continuacin, son los ms generali$ados en las empresas del sector
cu#os procesos no tienen calidad # no tienen forma de asegurar la calidad del
producto software.
.ompromisos consistentemente incumplidos, epresados en t"rminos de
entregas tardas, afluencia constante de defectos de ltima hora Zalgo que
aqu en .olombia llaman coloquialmente XchicharronesYZ # costos
espiralados.
0educida visin gerencial en el progreso, con la ocurrencia de sorpresas
constantes.
%roblemas propios de la calidad, como demasiado XreprocesoY o XretrabajoY,
que las funciones no operen correctamente # un elevado nmero de quejas de
los clientes luego de la entrega Zlo cual no es menor si pensamos en el
impacto que esto puede tener sobre la imagen marca de la empresa al estar
dejando gran parte de las detecciones de defectos en manos de los clientes.
6oral pobre, que se percibe en forma de gente frustrada # la sensacin de que
nadie est a cargo.
2&
2.5 Acti+idades de SQA
Entre los principales objetivos del 1>; son la confiabilidad, el desempe,o, la
funcionalidad # el reuso. [ entre los principales elementos para la aplicacin de
pruebas estn la eperiencia, guas # estndares, m"tricas, revisiones, pruebas
# el reuso.
Las actividades del aseguramiento de la calidad del software contemplan
aquellas tareas del proceso de desarrollo de software que buscan asegurar el
dise,o, desarrollo # distribucin de una aplicacin eitosa u otra forma de
tecnologa de software. :curre durante todo el proceso de desarrollo, # cada
persona involucrada en este proceso tiene un impacto en la calidad de la
aplicacin resultante, es importante concentrarse que el aseguramiento de la
calidad no es una actividad separada que puede obtenerse fuera de la
organi$acin.
El 1>;, como actividad de proteccin en el proceso de desarrollo, comprende
procedimientos para la aplicacin efectiva de m"todos # herramientas,
revisiones t"cnicas formales, t"cnicas # estrategias de prueba, dispositivos
pa<aO#o<e, procedimientos de control de cambios, procedimientos de
aseguramiento de ajuste a los estndares # mecanismos de medida e
informacin.
Los principales elementos del 1>; son los siguientes4
*. 5efinicin # eperiencia
3. ?uas # estndares
L. 6"tricas
@. 0evisiones
*. ;utorevisiones
3. 0evisiones informales
L. 0evisiones de paso
@. 9nspecciones
J. %ruebas
*. &nitarias
3. 6dulo
L. 9ntegracin
@. 1istemas
M. ;nlisis # 0eporteo
2'
;unque algunas de las actividades de 1>; deben ser reali$adas por los
desarrolladores e ingenieros de software, puede establecerse un grupo 1>; en
la organi$acin. Las principales actividades de este grupo son4 establecer un
plan de 1>; para los pro#ectos( participar en el desarrollo de la descripcin del
proceso de software del pro#ecto( revisar las actividades de ingeniera de
software para verificar su ajuste al proceso definido( auditar los productos de
software designados para verificar el ajuste con los definidos como parte del
proceso( asegurar que las desviaciones del trabajo # los productos del software
se documenten # se manejen de acuerdo con un procedimiento establecido #
registrar lo que no se ajuste a los requisitos, e informar a los superiores.
;simismo, coordina el control # administracin de cambios, aunado a recopilar
# anali$ar las m"tricas del software.
&no de los elementos importantes del proceso de 1>; son las revisiones
t"cnicas, las cuales se constitu#en en reuniones conducidas por personal
t"cnico para personal t"cnico, donde se anali$an detalladamente los productos
generados, los eventos que surgen en forma imprevista, etc. %ara esta etapa el
uso de m"tricas es esencial. &na rama importante de esta disciplina es el 1>;
estadstico, donde los datos histricos permiten una mejora continua tanto del
producto generado en el pro#ecto, como de pro#ectos posteriores. Es
importante aseverar que la ingeniera de pruebas es otro factor fundamental
para el 1>;.
6uchas de las actividades a reali$ar deben estar incorporadas al proceso de
desarrollo utili$ado por la organi$acin( cabe recalcar que primeramente la
organi$acin deber tener definido su proceso o procesos de desarrollo de
software. ;unado a ello, si eisten herramientas automati$adas que dan
soporte al 1>; para probar aplicaciones # componentes de "stas, registrando
# ejecutando casos de prueba, as como generndolos en forma automtica se
logra conseguir una productividad alta.
25
2.6 A9todos 1 -erra!ientas
El objetivo primario de las revisiones t"cnicas formales )inspeccin- es
encontrar errores durante el proceso para evitar que se conviertan en defectos
despu"s de la entrega del software. El beneficio obvio de estas inspecciones es
el descubrimiento de errores al principio para que no se propaguen al paso
siguiente del proceso de desarrollo del software )catarata de errores de
6i$uno-.
&na serie de estudios )!08, Bippon Electric # 6itre .orp., entre otros- indican
que las actividades del dise,o introducen entre el J+\ # MJ\ de todos los
errores)# en ltimo lugar, todos los defectos- durante el proceso de software. 1i
embargo se ha demostrado que las inspecciones de software son efectivas en
un KJ\ a la hora de detectar errores ]7:BHM^.
.on la deteccin # la eliminacin de un gran porcentaje de errores, el proceso
de inspeccin reduce substancialmente el costo de los pasos siguientes en las
fases de desarrollo # mantenimiento.
&na de las principales estrategias que compone el modelo estrat"gico de
%arque1oft, es la CCAC
Certificacin de Calidad, que se ocupa de la definicin e implementacin de
los procesos de calidad necesarios para darle viabilidad al desarrollo de
software como actividad de ingeniera aplicada para hacer negocios.
La metodologa Ca>E6 )Cussines ;pplication >ualit# Evaluation 6ethod- para
hacer pruebas funcionales a sistemas de informacin se comen$ a desarrollar
a finales del 3++3, con el propsito de aportar una metodologa cuantitativa,
prctica # efectiva para evaluar # anali$ar la calidad de los sistemas de
informacin desarrollados en %arque1oft, independiente de la metodologa #
plataforma tecnolgica utili$ada para su desarrollo.
En la primera seccin de este documento se ilustra como la metodologa de
pruebas parte del conocimiento de la 9ndustria en temas relacionados con la
calidad como el modelo .66
].66+*^ o el estndar 91:2+++ ]9so2+++^ # se complementa con las
implicaciones de ser el soporte metodolgico de %arque1oft, que acta como
catali$ador en la apropiacin de prcticas de ingeniera aplicables a los
procesos de negocios, es decir que requiere metodologas con alto contenido,
giles, basadas en el sentido comn # orientadas al resultado.
5e modo que, a partir de esas funcionalidades se derivan procesos,
subprocesos, #, a partir de "stos, siguiendo un proceso de descomposicin
jerrquico, se identifican # especifican requerimientos de prueba que en otras
palabras son los atributos de calidad del producto.
26
9gualmente, se dedica la seccin L del documento para presentar el nivel de
soporte que brinda la herramienta de software ?reenUolution al proceso de
aseguramiento de calidad definido en la metodologa Ca>E6, adems de
mostrar un panorama de la misma.
27
UNIDAD III #stndares de calidad aplicados al software
.onocer la importancia de la aplicacin de estndares de calidad #
productividad en el desarrollo de un software.
".1 IS)
IS)
La :rgani$acin 9nternacional para la Estandari$acin )91:- es una
organi$acin internacional no gubernamental, compuesta por representantes
de los organismos de normali$acin ):Bs- nacionales, que produce normas
internacionales industriales # comerciales. 5ichas normas se conocen como
normas 91: # su finalidad es la coordinacin de las normas nacionales, en
consonancia con el ;cta =inal de la :rgani$acin 6undial del .omercio con el
propsito de facilitar el comercio, facilitar el intercambio de informacin #
contribuir con unos estndares comunes para el desarrollo # transferencia de
tecnologas.
#structura de la or.ani4acin
La :rgani$acin 91: est compuesta por tres tipos de miembros4
6iembros natos4 uno por pas, reca#endo la representacin en el :rganismo
nacional ms representativo.
6iembros correspondientes4 de los organismos de pases en vas de desarrollo
# que todava no poseen un comit" nacional de normali$acin. Bo toman parte
activa en el proceso de normali$acin pero estn puntualmente informados
acerca de los trabajos que les interesen.
6iembros suscritos4 pases con reducidas economas a los que les eige el
pago de tasas menores que a los correspondientes.
91: es un rgano consultivo de la :rgani$acin de las naciones unidas
.oopera estrechamente con la .omisin Electrot"cnica 9nternacional
)9nternatinal Electrotechnical .omisin, 9E.- que es responsable de la
estandari$acin de equipos el"ctricos.
5escripcin general de las normas 91:4
La familia de normas 91: 2+++ se compone por a aplicaciones fundamentales
denominadas4
Borma 91: 2++*
Borma 91: 2++3
Borma 91: 2++L
Borma 91: 2++@
"8
".2 S(IC#
)%rograma de simulacin con "nfasis en circuitos integrados- fue desarrollado
por la &niversidad de .alifornia, Cer<ele# en *2KJ por 5onald %ederson.
Es un estndar internacional cu#o objetivo es simular circuitos # luego elegir el
tipo de simulacin )temporal, en frecuencia, en continua # parametrico-
S(IC#
1oftware process improvement and capabillit# determination.
91:I9E. 911+@ es un emergente estandar internacinal de evaluacin #
determinacin de la capacidad # mejora continua de procesos de ingeniera de
software con la filosofa de desarrollar un conjunto de medidas de capacidad
estructuradas para todos los procesos del ciclo de vida # para todos los
participantes.
(3)()SI:)
Evaluacin del proceso de ingeniera
6ejora de proceso de 9ngeniera
5eterminacin de capacidades
DI3I@IDA AD
;dquisidores
1uministradores
Evaluadores
"." CAA
CAA
).apabilit# 6aturit# 6odel-
=ue dise,ado por4 1oftware Engineering 9nstitute )1E9- en Boviembre de *2HM.
Qu9 es
"1
Es un modelo de calida del software que clasifica las empresas de niveles. Este
modelo establece un conjunto de procesos agrupados en _reas clave de
proceso )`%;-.
Esta destinada a la evaluacin # mejora de procesos.
(ropsito
?uiar a las organi$aciones en la seleccin de estrategias de mejora
determinando la madure$ del proceso actual.
#+olucin
1e investiga con marco de mejora # la calidad de las empresas del resultado
fue la 18O.66 cu#a versin *.+ se publico en *22* se reviso la *.3 # ho# es
absoluto.
Caracter/sticas
;ctividades
.ompromisos
.apacidad
6edidas # anlisis
Uerificacin
CAA
Este t"rmino se puede referir a4
La visin general de los modelos basados en la madure$ de las
capacidades, modelo de capacidad # madure$.
El modelo de calidad especfico de desarrollo del software 18O.66 es
un modelo de proceso para el desarrollo # mantenimiento de sistemas
de software, dise,o sobre los criterios.
La calidad de un producto o sistemas.
El centro de modelamiento matemtico de la &niversidad de .hile.
".".1 Definicin del !odelo
Es el pro#ecto o reproduccin a escala reducida o no de un pie$a escultrica.
"2
El objetivo principal de este pro#ecto era el dise,o de un producto que mejora
la calidad del producto.
".".2 Ni+el inicial
El proceso de software es impredecible # poco controlado( pero esto no
significa que una organi$acin no produ$ca bien un software, sino que el coste
)financiamiento- humano, temporal es demasiado alto tanto como para los
usuarios.
"."." Ni+el repetido
En este nivel eiste una disciplina bsica en la gestin de procesos basados en
la repeticin de tareas apreciadas previamente, #a que ha# una planificacin en
t"rminos de coste, calendario # requisitos.
".".$ Ni+el definido
5efinido4 adems de una gestin de pro#ectos, a este nivel las organi$aciones
disponen de correctos procedimientos de coordinacin entre grupos, formacin
del personal, t"cnicas de 9ngeniera ms detallados # un nivel ms avan$ado
de m"tricas en los procesos. 1e implementan t"cnicas de revisin por pares.
".".& Ni+el ad!inistrati+o
1e caracteri$a porque las organi$aciones disponen de un conjunto de m"tricas
significativas de calidad # productividad, que se usan de modo sistemtico para
la toma de decisiones # la gestin de riesgos. El software resultante es de alta
calidad.
La organi$acin establece m"tricas para productos # procesos estrechando la
variacin de estos a as finalmente miden los resultados de calidad.
Los pro#ectos llevan a cabo un control sobre los reductos # procesos
estrechando la variacin en el desempe,o de su proceso de una manera de
caer dentro de los lmites aceptables para esto4
Los riesgos involucrados con la tecnologa de nuevos productos,
procesos # mercados son anali$ados cuidadosamente.
Eisten mediciones detallados del proceso # calidad del producto.
El proceso # el producto deben ser perfectamente conocidos #
controlados.
Este nivel permite a una organi$acin predecir tendencias en la calidad del
proceso # el producto.
""
".".' Ni+el opti!i4ado
La organi$acin completa esta volcada en la mejora continua de los procesos.
1e hace uso intensivo de las m"tricas # se gestiona el proceso de innovacin.
Eiste una evolucin continua en la optimi$acin del proceso.
91: 2++* es aplicable a sistemas que comprendan las actitudes de
dise,o, desarrollo, fabricacin, instalacin # servicio.
91: 2++3 es aplicable a sistemas que comprendan las actividades de
produccin, instalacin # servicios.
91: 2++L es aplicable a sistemas que comprendan epresin # pruebas
fiables.
91: 2++@ describe las directrices generales de la gestin de calidad #
los elementos de un sistema.
Los procesos de los pro#ectos # de la organi$acin estn orientados a la
mejora de las actividades.
6ejoras incrementales e innovadoras de los procesos que mediante m"tricas
son identificados, evaluados # puestos en prctica.
Los procesos que ha# que implementar para alcan$ar estos niveles son4
9nnovacin organi$acional
;nlisis 0esolucin del as causas
Aodelo de cascada
La implementacin debe de posponerse hasta que los objetivos se ha#an
comprendido
%rototipacin
Estudio de factibilidad
9ngeniera de requerimientos
5ise,o especificacin
.odificacin
Uerificacin
Entrega # mantenimiento
%ropsito
El desarrollo o mantenimiento de 1oftware
Aodelo en espiral
"$
.uatro tareas4
*. 5eterminar o fijar objetivos
=ijar tambi"n los productos definidos a obtener4 requerimientos,
especificacin manual de usuario.
=ijar las restricciones
9dentificacin de riesgos del apo#o # estrategias alternativas para
evitarlos.
Aa# una sola cosa que se hace una ve$4 planificacin inicial
previa.
3. ;nlisis de riesgo
1e estudian los riesgos potenciales # se selecciona una o varias
alternativas propuestas para reducir o eliminar los riesgos.
L. 5ependiendo del resultado
!areas de la actividad propia # se prueba
;nlisis de alternativas e identificacin resolucin de riesgos
5ependiendo del resultado de la evolucin de los riesgos, se elige un
modelo para el desarrollo.
@. %lanificar
0evisamos todo el hecho, evaluando # con ello decidimos si
continuaremos con las fases siguientes
Aodelo lineal
Etapas4
Becesidades
Especificaciones
;nlisis
5ise,o
9mplementacin
Ualidacin
6antenimiento # evaluacin
1on una serie de etapas que comprenden todas las actividades, desde el
momento en que surge la idea hacer un nuevo producto de software.
El seguimiento de la calidad que aborda principalmente L reas o t"cnicas4
6"tricas del software para el control del pro#ecto
Uerificacin # validacin a lo largo del ciclo de vida del software,
inclu#endo pruebas # procesos de revisin.
"&
A9todos de ordena!iento
A9todo de la burbu*a
El :rdenamiento de Curbuja )<ubble Sort en ingl"s- es un sencillo algoritmo
de ordenamiento. =unciona revisando cada elemento de la lista que va a ser
ordenada con el siguiente, intercambindolos de posicin si estn en el orden
equivocado. Es necesario revisar varias veces toda la lista hasta que no se
necesiten ms intercambios, lo cual significa que la lista est ordenada. Este
algoritmo obtiene su nombre de la forma con la que suben por la lista los
elementos durante los intercambios, como si fueran peque,as 'burbujas'.
!ambi"n es conocido como el !9todo del interca!bio directo.
5ado que solo usa comparaciones para operar elementos, se lo considera un
algoritmo de comparacin, siendo el ms sencillo de implementar.
&na manera simple de epresar el ordenamiento de burbuja en pseudocdigo
es la siguiente4
(ara -asta -a.a lo si.uienteD
Si entoncesD
3epita !ientras
A9todo SB#%%
El m"todo 1hell pertenece a los m"todos de clasificacin avan$ados,
nombrado as en honor a su desarrollador, 5onald 1hell.
Este m"todo utili$a una segmentacin entre los datos. =unciona comparando
elementos que est"n distantes( la distancia entre comparaciones decrece
conforme el algoritmo se ejecuta hasta la ultima fase, en la cual se comparan
los elementos ad#acentes, por esta ra$n se le llama ordenacin por
disminucin de incrementos.
La ordenacin de 1hell usa una secuencia, h*, h3, . . ., ht, conocida como la
secuencia de incrementos. ;l principio de todo proceso, se fija una secuencia
decreciente de incrementos. .ualquier secuencia funcionar en tanto que
empiece con un incremento grande, pero menor al tama,o del arreglo de los
datos a ordenar, # que el ltimo valor de dicha secuencia sea *.
"'
&na eleccin mu# comn )pero no tan eficiente- para la secuencia de
incrementos es adoptar la secuencia sugerida por 1hell4 ht a ]n I 3^, # h< a
]h<N* I 3^. ; continuacin se muestra un programa que implanta la ordenacin
de 1hell usando esta secuencia.
b include Siostream.hT
void main )void-
c
int a]*J^(
int n, inc, i, j, tmp(
cout SS'5e cuantos elementos es el arregloF '(
cin TT n(
for )ia*( iSan( iNN-
c
cout SS'9ntroduce el elemento ' SSiSS' 4 '(
cin TT a]i^(
d
inc a nI3(
while )inc T +-
c
for )i a inc N*( iSan( iNN-
c
tmp a a]i^(
jai(
while ) )jOinc- T + -
c
if )tmp S a]jOinc^-
c
"5
a]j^aa]jOinc^(
jajOinc(
d
else
brea<(
d II fin del while II
a]j^atmp(
d II fin del for II
inc a incI3(
d II fin del while II
cout SSendl(
for )ia*( iSan( iNN-
cout SS a]i^ SSendl(
d II fin de shell sort II
A9todo de insercin directa
El m"todo de insercin directa es el que generalmente utili$an los jugadores de
cartas cuando ordenan "stas, de ah que tambi"n se cono$ca con el nombre de
m"todo de la baraja.
La idea central de este algoritmo consiste en insertar un elemento del arreglo
en la parte i$quierda del mismo, que #a se encuentra ordenada. Este proceso
se repite desde el segundo hasta el nOesimo elemento.
Ejemplo4
1e desean ordenarse las siguientes clave del arreglo ;4 *J, MK, +H, *M, @@, 3K,
*3, LJ
%rimera pasada
;]3^ S ;]*^ MK S *J Bo ha# intercambio
;4 *J, MK, +H, *M, @@, 3K, *3, LJ
1egunda pasada
;]L^ S ;]3^ +H S MK 1i ha# intercambio
;]3^ S ;]*^ +H S *J 1i ha#
"6
;4 *J, +H, MK, *M, @@, 3K, *3, LJ
!ercera pasada
;]@^ S ;]L^ +H S *J 1i ha# intercambio
;]L^ S ;]3^ +H S *J 1i ha# intercambio
;a +H, *J, MK, *M, @@, 3K, *3, LJ
Aasta la s"ptima pasada el arreglo queda ordenado4 +H, *3, *J, *M, 3K, LJ, @@,
MK.
A9todo QUICE S)3:
El m"todo de ordenamiento >uic< 1ort es actualmente el ms eficiente # velo$
de los m"todos de ordenacin interna. Es tambi"n conocido con el nombre del
m"todo rpido # de ordenamiento por particin, en el mundo de habla hispana.
Este m"todo es una mejora sustancial del m"todo de intercambio directo
1e trata de ubicar a en la posicin correcta del arreglo, de tal forma que todos
los elementos que se encuentran a su i$quierda sean menores o iguales a #
todos los elementos que se encuentren a su derecha sean ma#ores o iguales a
.
"7
UNIDAD I; Calidad enfocada al desarrollo del software
.onocer # aplicar los estndares de calidad para el desarrollo de software.
$.1 Que es la calidad del Software.
La calidad del software es el conjunto de cualidades que lo caracteri$an # que
determinan su utilidad # eistencia. La calidad es sinnimo de eficiencia,
fleibilidad, correccin, confiabilidad, mantenibilidad, portabilidad, usabilidad,
seguridad e integridad.
La calidad del software es medidle # vara de un sistema a otro o de un
programa a otro. &n software elaborado para el control de naves espaciales
debe ser confiable al nivel de 'cero fallas'( un software hecho para ejecutarse
una sola ve$ no requiere el mismo nivel de calidad( mientras que un producto
de software para ser eplotado durante un largo perodo )*+ a,os o ms-,
necesita ser confiable, mantenible # fleible para disminuir los costos de
mantenimiento # perfeccionamiento durante el tiempo de eplotacin.
La calidad del software puede medirse despu"s de elaborado el producto. %ero
esto puede resultar mu# costoso si se detectan problemas deriva dos de
imperfecciones en el dise,o, por lo que es imprescindible tener en cuenta tanto
la obtencin de la calidad como su control durante todas las etapas del ciclo de
vida del software.
$.2 Co!o obtener calidad del software !etodolo./a co!o estndares
La obtencin de un software con calidad implica la utili$acin de metodologas
o procedimientos estndares para el anlisis, dise,o, programacin # prueba
del software que permitan uniformar la filosofa de trabajo, en aras de lograr
una ma#or confiabilidad, mantenibilidad # facilidad de prueba, a la ve$ que
eleven la productividad, tanto para la labor de desarrollo como para el control
de la calidad del software.
La poltica establecida debe estar sustentada sobre tres principios bsicos4
tecnolgico, administrativo # ergonmico.
El principio tecnolgico define las t"cnicas a utili$ar en el proceso de desarrollo
del software.
El principio administrativo contempla las funciones de planificacin # control del
desarrollo del software, as como la organi$acin del ambiente o centro de
ingeniera de software.
$8
El principio ergonmico define la interfa$ entre el usuario # el ambiente
automati$ado.
La adopcin de una buena poltica contribu#e en gran medida a lograr la
calidad del software, pero no la asegura. %ara el aseguramiento de la calidad
es necesario su control o evaluacin.
$." Co!o controlar la calidad del software
%ara controlar la calidad del software es necesario, ante todo, definir los
parmetros, indicadores o criterios de medicin, #a que, como bien plantea
!om 5e 6arco, 'usted no puede controlar lo que no se puede medir'.
Las cualidades para medir la calidad del software son definidas por
innumerables autores, los cuales las denominan # agrupan de formas
diferentes. %or ejemplo, 7ohn, 8ile# define m"tricas de calidad # criterios,
donde cada m"trica se obtiene a partir de combinaciones de los diferentes
criterios. La 6etodologa para la evaluacin de la calidad de los medios de
programas de la .9., de 0usia, define indicadores de calidad estructurados en
cuatro niveles jerrquicos4 factor, criterio, m"trica, elemento de evaluacin,
donde cada nivel inferior contiene los indicadores que conforman el nivel
precedente. :tros autores identifican la calidad con el nivel de complejidad del
software # definen dos categoras de m"tricas4 de complejidad de programa o
cdigo, # de complejidad de sistema o estructura.
!odos los autores coinciden en que el software posee determinados ndices
medibles que son las bases para la calidad, el control # el perfeccionamiento de
la productividad.
&na ve$ seleccionados los ndices de calidad, se debe establecer el proceso de
control, que requiere los siguientes pasos4
5efinir el software que va a ser controlado4 clasificacin por tipo, esfera
de aplicacin, complejidad, etc., de acuerdo con los estndares
establecidos para el desarrollo del software.
1eleccionar una medida que pueda ser aplicada al objeto de control.
%ara cada clase de software es necesario definir los indicadores # sus
magnitudes.
.rear o determinar los m"todos de valoracin de los indicadores4
m"todos manuales como cuestionarios o encuestas estndares para la
medicin de criterios periciales # herramientas automati$adas para medir
los criterios de clculo.
5efinir las regulaciones organi$ativas para reali$ar el control4 qui"nes
participan en el control de la calidad, cundo se reali$a, qu" documentos
deben ser revisados # elaborados, etc.
; partir del anlisis de todo lo anterior, nuestro .entro se encuentra enfrascado
en un pro#ecto para el ;seguramiento de la .alidad del 1oftware );.1-, vlido
$1
para cualquier entidad que se dedique a la investigacin, produccin #
comerciali$acin del software, el cual inclu#e la elaboracin de un 1istema de
9ndicadores de la .alidad del 1oftware, la confeccin de una 6etodologa para
el ;seguramiento de la .alidad del 1oftware # el desarrollo de herramientas
manuales # automati$adas de apo#o para la aplicacin de las t"cnicas #
procedimientos del ;.1, de forma tal que se conforme un 1istema de
;seguramiento de la .alidad del 1oftware.
$.$ Costo de la calidad del Software.
Es el uso de puntos funcin para a#udar a calcular el costo real del software.
La ma#ora de las organi$aciones subestima en gran medida el costo del
software.
El costo real del software es la suma de todos los costos durante la vida de un
pro#ecto, inclu#endo los mejoramientos esperados # los costos de
mantenimiento, de hecho, el clculo real debera ser el valor presente de todos
los desarrollos mejoras # costos de mantenimiento esperado durante la vida del
pro#ecto.
Este tipo de anlisis demuestra, la recompensa de invertir en un dise,o #
anlisis de primera.
.uando ms se invierte en un pro#ecto, ms se va a ahorrar en un futuro
costos de mantenimiento # mejoras.
El uso de puntos funcin para a#udar a estimar el costo de pro#ectos, la
programacin # es el esfuer$o la estimacin eitosa usando puntos funcin se
basa en varias t"cnicas de estimacin4 !op 5own4 ;naloga # consejo de
epertos.
Loa estimacin !op 5own es una t"cnica de estimacin que calcula el
programa entero, costo # esfuer$o usando parmetros amplios.
Los parmetros amplios # las comparaciones estn basadas en datos
histricos usando t"cnica de analogas.
Lograr la estimacin eitosa, se debe considerar lo siguiente4
!ipo de plataforma de Aardware mainframe, cliente, servidor, %.
!ipo de lenguaje( cobol, ., .NN
!ipo de pro#ecto4 software del sistema, software intermedio, software de
aplicacin
!ipo de sistema operativo4 6U1, 8indows, &ni
&na ve$ que los pro#ectos han sido determinados obtener4
$2
6edida histrica de entrega )horas-
5iagramas histricos )duracin de programa-
.ostos histricos
$.& No!enclara 1 certificacion isop 7881 2888
Es un m"todo de trabajo, que se considera tan buena que es el mejor para
mejorar la calidad # satisfaccin de cara al consumidor. La versin actual es del
a,o 3+++ 91: 2++*43+++( que no ha sido adoptado como modelo a seguir para
obtener la certificacin de calidad # es a lo que tienden # debe aspirar toda
empresa competitiva, que quiera permanecer # sobrevivir en el eigente
mercado actual.
Estos principios bsicos de la gestin de la calidad son reglas de carcter
social encaminadas mejorar la marcha # funcionamiento de una organi$acin
mediante la mejora de sus relaciones internas.
Estas normas han de combinarse con los principios t"cnicos para conseguir
una mejora de la satisfaccin del consumidor.
91: 2++*43+++ especifica los requisitos para los sistemas de gestin aplicables
a toda organi$acin que necesita demostrar su capacidad para proporcionar
productos que cumplan los requisitos de sus clientes los reglamentos.
4.6 Nor!a IS)FI#C 712'
5escribe un modelo en 3 partes para la calidad del producto del software, a la
calidad interna # eterna, # a la calidad en uso, la primera parte del modelo
especifica M caractersticas para la calidad interna # eterna, que se subdividen
posteriormente en dos caractersticas.
Estas subcaractersticas se manifiestan eternamente cuando el software se
usa como parte de un sistema informtico # son el resultado de los atributos
eternos del software.
Esta parte de la 91:I9E. 2*3M no elabora el modelo interno # eterno ms all
del nivel de subcaratersticas.
$.5 Anlisis de factores ,ue deter!ina la calidad de software
Los atributos de calidad de un producto de software se divide en interno #
eterno.
.orrecta4 cuando se desenvuelve de acuerdo con las especificaciones
de funcionamiento que provee, es decir, es la equivalencia entre el
software # las especificaciones del mismo.
$"
.onfiable4 la confiabilidad de un software se puede determinar en
funcin de la confiabilidad de otro del mismo tipo.
0obusto4 capacidad del programa de responder a la entrada de datos
;migable4 se refiere a que eiste consistencia en las interfaces
Uerificable4 un software es verificable si las propiedades del mismo
pueden ser llevados totalmente.
%ortable4 es cuando un sistema puede ser transferido a otro
%roductividad4 es la eficiencia en sus procesos, es decir, rendimientos
de los mismos.
:portunidad4 se refiere a la liberacin del producto cuando el cliente lo
necesita # con las caractersticas requeridas
$.6 Anlisis del proceso del ciclo de +ida del software
Proceso.
.uando se constru#e un producto o se presta un servicio se siguen una serie
de pasos para lograr cumplir las tareas necesarias en un cierto orden. &n
proceso es una serie de pasos que involucran actividades, restricciones #
recursos que producen una salida determinada )producto o servicio- utili$ando
para ello un conjunto de herramientas # t"cnicas.
Todos los procesos tienen estas caractersticas:
e establecen las principales actividades del proceso.
e utili$an recursos )horas hombre, equipos, dinero-.
e estn sujetos a restricciones )calendario, presupuesto, f-.
e genera productos intermedios # finales.
e puede constituirse como una cadena de subprocesos, cada uno con su
propio modelo.
e cada actividad tiene criterios de entradas # salidas( puede saberse
cuando comien$a # cuando termina una actividad.
e las actividades se organi$an en secuencia( resulta claro el orden
relativo de una actividad respecto a las dems.
e tiene un conjunto de principios orientadores que describen las metas
de cada actividad.
$$
e las restricciones pueden aplicarse a una actividad, recurso o producto.
&n proceso es ms que un procedimiento. &n procedimiento es una
manera estructurada de combinar herramientas # t"cnicas para generar
un producto. &n proceso es un conjunto de procedimientos organi$ados
de tal modo que los productos construidos satisfagan un conjunto de
metas o estndares * de J.
(roceso de desarrollo o ciclo de +ida del software
El proceso que nos interesa es el proceso de desarrollo del software. .uando
un proceso implica construccin de algn producto suele denominarse al
proceso ciclo de vida. En particular, el ciclo de vida del software describe la
vida de un producto de software desde su concepcin hasta su
implementacin, entrega, utili$acin # mantenimiento.
Aodelos de procesos en in.enier/a de software
Es posible concebir diferentes modelos de proceso para arribar a un mismo
producto( las diferencias estarn en las actividades priori$adas, su importancia
relativa, la secuencia de reali$acin, los principios orientadores, las
herramientas # t"cnicas elegidas. Entre los modelos ms comunes
eperimentados por la ingeniera de software se cuentan4
e modelo en cascada )g*2K+-.
e modelo de prototipos )g*2KJ-.
e modelo de transformaciones )g*2H*-
e modelo en espiral )g*2HH-.
e desarrollo por fases4 incrementos e iteraciones )g*22M-.
e proceso unificado )g*222-.
e programacin etrema )g3+++-. Bota4 las fechas son aproimadas,
generalmente de alguna publicacin donde por primera ve$ se propone
el modelo o a partir de la cual cobra vigencia. &na fecha lejana no
$&
significa necesariamente inutilidad u obsolescencia( los procesos
modernos incorporan muchos principios de modelos ms viejos.
;dems, cada pro#ecto puede responder mejor a un modelo que a otro,
independientemente de la edad del modelo. %ara un proceso de desarrollo de
software son de inter"s las siguientes caractersticas4
e el proceso debe describirse de manera fleible, que permita a las
personas dise,ar # construir el software con algn grado de libertad en
la eleccin de las herramientas # t"cnicas preferidas o ms adecuadas.
e el proceso debe guiar las acciones permitiendo eaminar, comprender,
controlar # mejorar las actividades que abarca.
e los procesos deben permitir capturar la eperiencia # transferirla a los
dems.
e cada etapa de un proceso de desarrollo de software es en s misma un
proceso o coleccin de procesos capa$ de ser descrito como un
conjunto de actividades, cada actividad con sus propias entradas,
salidas, restricciones # recursos.
e la descripcin de un proceso puede hacerse de muchas formas,
tetuales, grficas o combinadas.
#le!entos del proceso.
El producto logrado a a trav"s de la reali$acin de un pro#ecto es el resultado
de la intervencin de muchas personas. El proceso de desarrollo gua los
esfuer$os de esas personas, marcando los pasos necesarios para lograr
culminar el pro#ecto. El proceso puede a#udarse de herramientas con las
cuales se busca facilitar o automati$ar algunas tareas.
(roducto.
El producto resultante de un pro#ecto de desarrollo de software inclu#e todos
los elementos )artefactos- creados durante la reali$acin del pro#ecto4 modelo,
cdigo fuente, ejecutables, documentacin. &n sistema de software es el
conjunto de todos los artefactos necesarios para representarlo en forma
$'
comprensible por mquinas u hombres, destinado a las mquinas, los
trabajadores # los 3 de J interesados en el pro#ecto. Las mquinas son las
herramientas, compiladores # computadores donde se instalar el software.
Los trabajadores son directores, arquitectos de software, dise,adores,
programadores, personal de gestin, administracin # apo#o. Los interesados
son inversores, usuarios, personal de comerciali$acin, agentes de regulacin,
otros. Las personas # mquinas involucradas en el desarrollo de un sistema de
software son llamados a veces trabajadores del pro#ecto ]7acobson3+++, cap.
3^.
&n artefacto designa cualquier tipo de informacin creada, producida,
cambiada o utili$ada por los trabajadores )hombres o mquinas- durante el
desarrollo del sistema. Los artefactos pueden ser tanto de ingeniera como de
gestin. 6s formalmente, un artefacto es una pie$a de informacin tangible
*- creada, modificada # usada por los trabajadores al reali$ar actividades
3- donde se representa un rea de responsabilidad
L- candidata a ser tenida en cuenta al reali$ar el control de configuracin. &n
artefacto puede ser un modelo, un elemento de un modelo o un documento. La
construccin de un sistema es la construccin de modelos. 5iferentes modelos
pueden describir diferentes perspectivas del sistema. &n modelo es una
abstraccin del sistema, especificando el sistema modelado desde un cierto
punto de vista # en determinado nivel de abstraccin. 6s formalmente, un
modelo es una abstraccin semnticamente cerrada del sistema. Es una vista
autocontenida del sistema4 un usuario del modelo no necesita recurrir a
informacin fuera del propio modelo, ni a otros modelos ]7acobson3+++, cap.
3^.
(ersonas.
Los constructores del pro#ecto son arquitectos de software, desarrolladores,
encargados de pruebas, personal de gestin( usuarios, clientes, inversores #
otros interesados tambi"n participan en la construccin. Las personas se vern
afectadas por diversos aspectos organi$ativos # de gestin del pro#ecto4
e viabilidad del pro#ecto4 el pro#ecto debe ser posible( una evaluacin temprana
de la viabilidad puede detener un pro#ecto imposible.
$5
e gestin del riesgo4 identificacin de los riesgos ma#ores, definicin de
polticas de aversin al riesgo )como evitar o manejar el riesgo- contribu#en a la
confian$a # tranquilidad de todos los involucrados.
e estructura de los equipos4 las personas trabajan mejor en grupos reducidos,
de seis a ocho personas. La divisin en subsistemas con interfaces claras
permite trabajar con varios equipos manteniendo su coordinacin.
e plan de pro#ecto4 una estimacin realista de tiempos # recursos permite armar
un plan de trabajo fundamentado # posible, eliminando la desalentadora
sensacin de no terminar nunca.
e facilidad de comprensin del pro#ecto4 la visin global del pro#ecto provista
por la descripcin de la arquitectura permite a todos los implicados conocer qu"
se est haciendo # para qu"( la comprensin de lo que se est haciendo
permite a la gente trabajar mejor.
e cumplimiento4 la conclusin eitosa de cada etapa, hecha posible por un plan
realista, evita la frustracin del atraso o el incumplimiento. Las tareas #
responsabilidades de las personas intervinientes en el pro#ecto irn cambiando
a lo largo del mismo, o an pueden desempe,arse en diferentes conjuntos de
tareas # especialidades al mismo tiempo( el papel de las personas como
trabajadores cambiar, o se desempe,arn como diferentes tipos de
trabajadores. El t"rmino trabajador designa un conjunto de tareas #
responsabilidades asumidas por una persona o un grupo ]7acobson3+++, cap.
3^.
(ro1ecto.
El pro#ecto es un elemento organi$ativo a trav"s del cual se gestiona el
desarrollo de software. El resultado de un pro#ecto es una versin de un
producto. 1e parte de un pro#ecto inicial con el cual se evala la viabilidad, se
identifican los riesgos # se define el plan de pro#ecto. La construccin se
reali$ar en una serie de iteraciones( cada iteracin constitu#e un mini pro#ecto
con requisitos, dise,o, implementacin # prueba. L de J.
$6
(roceso
&n proceso de desarrollo de software es una definicin del conjunto completo
de actividades necesarias para transformar los requerimientos del usuario en
un producto. &n proceso es un patrn o plantilla sobre la cual se definen los
pro#ectos. %uede decirse que un pro#ecto es una instancia de un proceso, una
aplicacin concreta a un emprendimiento particular de los principios, forma de
trabajo # recomendaciones de un proceso. &n proceso de desarrollo de
software consiste en la definicin del conjunto completo de actividades
necesarias para convertir los requerimientos del usuario en un conjunto
consistente de artefactos que conforman el producto de software, as como
para convertir los cambios surgidos en los requerimientos en un nuevo conjunto
consistente de artefactos de software ]7acobson3+++, cap. 3^.
Aodelo
&n modelo es una simplificacin de la realidad. 1e constru#en modelos para
comprender mejor el sistema en desarrollo. El modelado persigue estos
objetivos4 e visuali$ar cmo ser el sistema deseado( e especificar la estructura
o el comportamiento del sistema( e proveer plantillas descriptivas para usar
como gua en la construccin del sistema( e documentar las decisiones
adoptadas. 1e constru#en modelos de los sistemas complejos porque resulta
mu# difcil comprender el sistema en su totalidad. La eleccin de modelos tiene
una profunda influencia sobre la forma de enfrentar un problema # como se
llega a la solucin. Es preciso elegir bien los modelos. Los mejores modelos
reflejan la realidad en todos # slo aquellos aspectos importantes para el
sistema en desarrollo. &n modelo puede ser presentado en diferentes niveles
de detalle, desde diferentes perspectivas, a trav"s de un conjunto de modelos
casi independientes pero coordinados entre s ]Cooch*222, cap. *^.
Ar,uitectura
El dise,o de arquitectura de un sistema ofrece una visin global del sistema.
6s formalmente, la arquitectura de un sistema de software es un conjunto de
decisiones significativas acerca de la organi$acin de ese sistema, la seleccin
de elementos estructurales e interfaces componentes del sistema junto con su
comportamiento, la composicin de esos elementos estructurales en
subsistemas, # el estilo que orienta esa organi$acin. 9nclu#e no slo la
$7
funcionalidad )lo que hace- sino tambi"n restricciones )limitantes-,
compromisos sobre uso, rendimiento, comprensin, fleibilidad, reutili$acin,
economa, tecnologa # est"tica ]7acobson3+++, cap. 3^. Bo es posible
comprender la arquitectura de un sistema medianamente complejo si no se la
epresa a trav"s de diversas vistas complementarias4
e una vista de casos de uso para mostrar los requerimientos del sistema(
e una vista de dise,o para capturar el vocabulario del dominio del problema tal
como lo conocen los usuarios # del dominio de la solucin tal como la imaginan
los desarrolladores.
e una visin de procesos, donde se modelan los procesos e hilos de ejecucin
mediante los cuales el sistema reali$ar sus tareas.
e una vista de implementacin, donde se consigna la relacin entre los distintos
componentes de software que colaboran entre s para cumplir los cometidos
del sistema.
e una vista de despliegue donde se muestra la distribucin fsica de los
componentes en diferentes equipos # ubicaciones. .ada una de estas vistas
comprende aspectos estructurales )estticos, cmo es- # de comportamiento
)dinmicos, cmo funciona-. En conjunto, estas vistas son los Gplanos del
software/, anlogos a los planos de un edificio, un puente, una mquina o un
diagrama de circuitos ]Cooch*222, cap. *^. @ de J
Berra!ientas
Las herramientas usadas en la reali$acin de un pro#ecto de desarrollo de
software es el software usado para automati$ar o facilitar las tareas del
personal interviniente en el pro#ecto. %uede incluir procesadores de palabras,
programas de diagramacin, ambientes integrados de desarrollo o software
especfico para ingeniera de software )herramientas .;1E, G.omputer ;ided
1oftware Engineering/, ingeniera de software asistida por computador-. El
proceso # las herramientas estn estrechamente relacionados( se eligen o
constru#en las herramientas de acuerdo con el proceso de desarrollo a seguir.
0eferencias # lecturas recomendadas. El contenido de este documento est
basado en las fuentes citadas a continuacin, cu#a lectura o consulta no
pretenden sustituir. Lecturas recomendadas.
&8
e ]Larman3++L^ Larman, .raig. &6L # patrones. &na introduccin al anlisis #
dise,o orientado a objetos # al %roceso &nificado, 3a. edicin. 6adrid, 3++L.
91CB H@3+JL@LH3.
e ]=owler*22K^ =owler, 6artin # 1cott, `endall. &6L distilled. ;ppl#ing the
1tandard :bject 6odelling Language. ;ddison 8esle# Longman, 9nc., *22K.
91CB +3+*L3JML3.
e ]%fleeger3++3^ %=LEE?E0, 1A;09 L;80EB.E. 9ngeniera de software,
teora # prctica, *a. edicin. Cuenos ;ires, %earson educacin, 3++3. 91CB4
2HK2@M+K*J.
$.7 2UNCI)N#S D# #;)%UCI)N D#% S)2:0A3#
5urante los primeros a,os de la era de la computadora, el software se
contemplaba como un a,adido. La programacin de computadoras era un 'arte
de andar por casa' para el que eistan pocos m"todos sistemticos. El
desarrollo del software se reali$aba virtualmente sin ninguna planificacin,
hasta que los planes comen$aron a descalabrarse # los costes a correr. Los
programadores trataban de hacer las cosas bien, # con un esfuer$o heroico, a
menudo salan con "ito. El software se dise,aba a medida para cada
aplicacin # tenia una distribucin relativamente peque,a.
La ma#ora del software se desarrollaba # era utili$ado por la misma persona u
organi$acin. La misma persona lo escriba, lo ejecutaba #, si fallaba, lo
depuraba. 5ebido a este entorno personali$ado del software, el dise,o era un
proceso implcito, reali$ado en la mente de alguien #, la documentacin
normalmente no eista.
La segunda era en la evolucin de los sistemas de computadora se etienden
desde la mitad de la d"cada de los sesenta hasta finales de los setenta. La
multiprogramacin # los sistemas multiusuario introdujeron nuevos conceptos
de interaccin hombre O maquina. Las t"cnicas interactivas abrieron un nuevo
mundo de aplicaciones # nuevos niveles de sofisticacin del hardware # del
software. Los sistemas de tiempo real podan recoger, anali$ar # transformar
datos de mltiples fuentes, controlando as los procesos # produciendo salidas
en milisegundos en lugar de minutos. Los avances en los dispositivos de
almacenamiento en lnea condujeron a la primera generacin de sistemas de
gestin de bases de datos.
La segunda era se caracteri$o tambi"n por el establecimiento del software
como producto # la llegada de las 'casas del software'. Los patronos de la
industria, del gobierno # de la universidad se aprestaban a 'desarrollar el mejor
paquete de software' # ganar as mucho dinero.
&1
.onforme creca el numero de sistemas informticos, comen$aron a
etenderse las bibliotecas de software de computadora. Las casas
desarrollaban pro#ectos en los que se producan programas de decenas de
miles de sentencia fuente. !odos esos programas, todas esas sentencias
fuente tenan que ser corregidos cuando se detectaban fallos, modificados
cuando cambiaban los requisitos de los usuarios o adaptados a nuevos
dispositivos hardware que se hubieran adquirido. Estas actividades se
llamaron colectivamente mantenimiento del software.
La tercera era en la evolucin de los sistemas de computadora comen$ a
mediados de los a,os setenta # continuo mas all de una d"cada. El sistema
distribuido, mltiples computadoras, cada una ejecutando funciones
concurrente # comunicndose con alguna otra, increment notablemente la
complejidad de los sistemas informticos. Las redes de rea local # de rea
global, las comunicaciones digitales de alto ancho de banda # la creciente
demanda de acceso 'instantneo' a los datos, supusieron una fuerte presin
sobre los desarrolladores del software.
La conclusin de la tercera era se caracteri$o por la llegada # amplio uso de los
microprocesadores. El microprocesador ha producido un etenso grupo de
productos inteligentes, desde automviles hasta hornos microondas, desde
robots industriales a equipos de diagnsticos de suero sanguneo.
La cuarta era de la evolucin de los sistemas informticos se aleja de las
computadoras individuales # de los programas de computadoras, dirigi"ndose
al impacto colectivo de las computadoras # del software. %otentes maquinas
personales controladas por sistemas operativos sofisticados, en redes globales
# locales, acompa,adas por aplicaciones de software avan$adas se han
convertido en la norma.
La industria del software #a es la cuna de la economa del mundo. Las t"cnicas
de la cuarta generacin para el desarrollo del software estn cambiando en la
forma en que la comunidad del software constru#e programas informticos. Las
tecnologas orientadas a objetos estn despla$ando rpidamente los enfoques
de desarrollo de software ms convencionales en muchas reas de
aplicaciones.
1in embargo, un conjunto de problemas relacionados con el software ha
persistido a trav"s de la evolucin de los sistemas basados en computadora, #
estos problemas continan aumentando.
*. los avances del software continan dejando atrs nuestra
habilidad de construir software para alcan$ar el potencial del
hardware.
3. Buestra habilidad de construir nuevos programas no pueden ir al
mismo ritmo de la demanda de nuevos programas, ni podemos
construir programas lo suficientemente rpido como para cumplir las
necesidades del mercado # de los negocios.
&2
L. El uso etenso de computadoras ha hecho de la sociedad cada
ve$ ms dependiente de la operacin fiable del software. .uando el
software falla, pueden ocurrir da,os econmicos enormes #
ocasionar sufrimiento humano.
@. Luchamos por construir software informtico que tengan
fiabilidad # alta calidad.
J. Buestra habilidad de soportar # mejorar los programas eistentes
se ve amena$ada por dise,os pobres # recursos inadecuados.
En respuesta a estos problemas, las practicas de la 9ngeniera del 1oftware se
estn adoptando en toda la industria.
&"