Fund. Desarrollo Sistemas - Unidad II

Fundamentos de Desarrollo de Sistemas Unidad II
FUNDAMENTOS DE DESARROLLO DE SISTEMAS

UNIDAD II
INTRODUCCIN A LA INGENIERA DE SOFTWARE
2.1 DEFINICIN DE LA INGENIERA DE SOFTWARE
Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los
programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que
pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de software es un
producto diseado para un usuario".
En este contexto, la Ingeniera de Software (SE del ingls Software Engineering) es un
enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software", que en
palabras ms llanas, se considera que "la Ingeniera de Software es la rama de la ingeniera
que aplica los principios de la ciencia de la computacin y las matemticas para lograr
soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de
software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costoefectivos" [Cota 1994].
La Ingeniera de software es la rama de la ingeniera que crea y mantiene las
aplicaciones de software aplicando tecnologas y prcticas de las ciencias computacionales,
manejo de proyectos, ingeniera, el mbito de la aplicacin, y otros campos. El software es el
conjunto de instrucciones que permite al hardware de la computadora desempear trabajo til.
En las ltimas dcadas del siglo XX, las reducciones de costo en hardware llevaron a que el
software fuera un componente ubicuo de los dispositivos usados por las sociedades
industrializadas.
La ingeniera de software, como las disciplinas tradicionales de ingeniera, tiene que ver
con el costo y la confiabilidad. Algunas aplicaciones de software contienen millones de lneas de
cdigo que se espera que se desempeen bien en condiciones siempre cambiantes. En el 2002,
en los Estados Unidos, la Oficina de Estadsticas del Trabajo (U. S. Bureau of Labor Statistics)
cont 675.000 ingenieros de software de computadora con trabajo, y se estima que haya 1 milln
y medio en Europa, Asia y el resto del mundo. Esto significa aproximadamente el 60% de los
ingenieros de todas las reas.
Instituto Tecnolgico de Ciudad.Jurez
19
2.2 HISTORIA DE LA INGENIERA DE SOFTWARE

La Ingeniera del Software, trmino utilizado por primera vez por Fritz Bauer en la
primera conferencia sobre desarrollo de software patrocinada por el Comit de Ciencia de la
OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse segn Alan Davis
como "la aplicacin inteligente de principios probados, tcnicas, lenguajes y herramientas
para la creacin y mantenimiento, dentro de un costo razonable, de software que satisfaga las
necesidades de los usuarios"...
Su origen se debe a que el entorno actual de desarrollo de sistemas software viene

adoleciendo de:
Retrasos considerables en la planificacin
Poca productividad
Elevadas cargas de mantenimiento
Demandas cada vez ms desfasadas con las ofertas
Baja calidad y fiabilidad del producto
Dependencia de los realizadores

Esto es lo que se ha denominado comunmente Crisis del Software, que se ha
originado histricamente en los siguientes pasos:

Primera Fase. Los albores (1945-1955).
Programar no es una tarea diferenciada del diseo de una mquina
Uso de lenguaje mquina y ensamblador
Segunda Fase. El florecimiento (1955-1965).
Aparecen multitud de lenguajes
Era posible hacer casi todo
20
Tercera Fase. La crisis (1965-1970).
Desarrollo inacabable de grandes programas
Ineficiencia, errores, costo impredecible
Nada es posible
Cuarta Fase. Innovacin conceptual (1970-1980).
Fundamentos de programacin
Verificacin de programas
Metodologas de diseo
Quinta Fase. El diseo es el problema (1980-?).
Entornos de programacin
Especificacin formal
Programacin automtica
2.3 CARACTERSTICAS DEL SOFTWARE

Para poder comprender lo que es el software, es importante examinar las caractersticas
del software que lo hace diferente de otras cosas, que los hombres pueden construir. Cuando se
construye el hardware, el proceso creativo humano (anlisis, diseo, construccin y prueba) se
traduce finalmente en una forma fsica. Si construimos una nueva computadora, nuestro boceto
inicial, establecimiento del diseo normal y prototipo de prueba, evolucionan a un producto
fsico con pastillas de VLSI, tarjetas de circuito, fuentes de potencia, etc. El software es un
elemento lgico en vez de fsico del sistema. Por tanto, el software tiene unas
caractersticas considerablemente distintas a las del hardware.
El software es desarrollado; no es fabricado en un sentido lgico. Aunque existen algunas
similitudes entre el desarrollo del software y la construccin del hardware, las dos actividades
son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante
21
un buen 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, pero la relacin entre la gente dedicada y el trabajo realizado es completamente
diferente para el software. Ambas actividades requieren la construccin de un "producto", pero
los mtodos son diferentes.
Los costos del software se concentran en la ingeniera. Esto significa que los proyectos de
software no pueden ser gestionados cmo si fueran proyectos de fabricacin. En los ltimos
cinco aos se ha tratado en la literatura el concepto de "fsico de software". Es importante
observar que este trmino no implica que la fabricacin del hardware y el desarrollo del software
sean equivalentes. En vez de ello, el concepto fsico de software recomienda el uso de
herramientas automticas para el desarrollo del software.
2.4 MITOS DEL SOFTWARE

A) Es posible medir los principales atributos que forman o caracterizan a un software
de buena calidad. La idea aqu es que la calidad del software se caracteriza por ciertos atributos:
fiabilidad, flexibilidad, robustez, comprensin, adaptabilidad, modularidad, complejidad,
portabilidad, usabilidad, reutilizacin, eficiencia...., y que es posible medir cada uno de ellos, y
por consiguiente, caracterizar o medir la calidad del software en cuestin.
1) Es posible medir los atributos anteriores subjetivamente, pidiendo su opinin a
gentes que han usado el software que se est midiendo. Son confiables las opiniones de
usuarios experimentados. Es decir, (1) no es un mito, es algo real. Es fcil estar de acuerdo
en que un programa puede caracterizarse por los atributos anteriores. Adems, es convincente
que las opiniones de un grupo de usuarios respecto a la calidad, ergonoma, portabilidad... de un
software, sean confiables y dignas de tomarse en cuenta (opiniones subjetivas, pero confiables).
2) Otra forma de proceder es medir los atributos anteriores objetivamente,
midiendo atributos alternos en caso de que el atributo real sea difcil de medir (Mito B).
22
B) Para cada atributo a medir, hay una medicin confiable (objetiva) que puede llevarse
a cabo. La idea es que, dado que el atributo deseable es difcil de medir, se mide otro atributo
que est correlacionado con el primero.
C) En vez de medir la calidad del producto, midamos la calidad del proceso. Tener un
buen proceso implica producir software de buena calidad.
D) Es fcil saber cundo se tiene un buen proceso. Es fcil disear un buen proceso para
producir software.
E) Deben crearse campeones de la calidad, comits de calidad, y otras organizaciones
humanas cuya meta sea promover la calidad. Generalmente, estos comits (1) elaboran
normas que dicen cmo llevarse a cabo la confeccin de software, incluyendo formatos que
ciertos documentos intermedios y finales (manuales, digamos) deben seguir, y (2) observan que
el grupo productor se apegue a las normas (1).
F) La actitud frente a la calidad debe permear a cada codificador. El diseador o
programador debe estar constantemente pensando en calidad, tener f en que l har trabajos
de calidad, vigilar que la calidad de sus obras rebase un mnimo.
Si hacemos las cosas de la manera que dicta un comit internacional, lo estamos haciendo
bien, as se asegura la calidad del proceso y del software resultante. Es decir, de los muchos
procesos que podemos seguir, usemos uno que sea parte de una norma o estndar internacional,
o que sea el procedimiento que sigue una empresa que produce software de calidad (Oracle,
digamos).
2.5 CAPAS DE LA INGENIERA DE SOFTWARE

El IEEE Standard Glossary of Software Engineering Terminology (Stad. 610.12-1990)
ha desarrollado una definicin ms completa para ingeniera de software: Es La aplicacin de
un enfoque sistemtico, disciplinado y cuantificable para el desarrollo, operacin y
mantenimiento del software; es decir, la aplicacin de ingeniera al software. El estudio de
enfoques en la anterior definicin.
23
(Pressman) Caracteriza la Ingeniera de Software como una tecnologa multicapa,

ilustrada en la Figura.
Figura: Capas de la Ingeniera de Software.
Dichas capas se describen a continuacin:
Cualquier disciplina de ingeniera (incluida la ingeniera del software) debe descansar sobre
un esfuerzo de organizacin de Calidad. La gestin total de la calidad y las filosofas
similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de
enfoques cada vez ms robustos para la ingeniera del software.
El fundamento de la ingeniera de software es la Capa Proceso. El proceso define un marco

de trabajo para un conjunto de reas clave, las cuales forman la base del control de gestin de
proyectos de software y establecen el contexto en el cual: se aplican los mtodos tcnicos, se
producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se
gestiona adecuadamente.
Los Mtodos de la ingeniera de software indican cmo construir tcnicamente el software.

Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo,
construccin de programas, pruebas y mantenimiento. Estos mtodos dependen de un
conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades
de modelado y otras tcnicas descriptivas.
Las Herramientas de la ingeniera del software proporcionan un soporte automtico o

semi-automtico para el proceso y los mtodos, a estas herramientas se les llama
herramientas CASE (Computer-Aided Software Engineering).
24
Dado lo anterior, el objetivo de la ingeniera de software es lograr productos de software

de calidad (tanto en su forma final, como durante su elaboracin), mediante un proceso apoyado
por mtodos y herramientas.
2.6 EL PROCESO DE SOFTWARE

Un proceso de desarrollo de software tiene como propsito la produccin eficaz y
eficiente de un producto software que rena los requisitos del cliente. Dicho proceso, en
trminos globales se muestra en la Figura 2 .
Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las
personas involucradas. Aunque un proyecto de desarrollo de software es equiparable en muchos
aspectos a cualquier otro proyecto de ingeniera, en el desarrollo de software hay una serie de
desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A
continuacin se explican algunas particularidades asociadas al desarrollo de software y que
influyen en su proceso de construccin.
Un producto de software en s es complejo, es prcticamente inviable conseguir un 100%
de confiabilidad de un programa por pequeo que sea. Existe una inmensa combinacin de
factores que impiden una verificacin exhaustiva de las todas posibles situaciones de ejecucin
que se puedan presentar (entradas, valores de variables, datos almacenados, software del
sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).
Un producto de software es intangible y por lo general muy abstracto, esto dificulta la
definicin del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos
software similares. Esto hace que los requisitos sean difciles de consolidar tempranamente. As,
los cambios en los requisitos son inevitables, no slo despus de entregado en producto sino
tambin durante el proceso de desarrollo.
Adems, de las dos anteriores, siempre puede sealarse la inmadurez de la ingeniera del
software como disciplina, justificada por su corta vida comparada con otras disciplinas de la
ingeniera. Sin embargo, esto no es ms que un intil consuelo.
25
Requisitos nuevos
o modificados
Proceso de Desarrollo
de Software
Sistema nuevo
o modificado
Figura 1: proceso de desarrollo de software.

El proceso de desarrollo de software no es nico. No existe un proceso de software
universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta
diversidad, es difcil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de

actividades fundamentales que se encuentran presentes en todos ellos [4]:
1. Especificacin de software: Se debe definir la funcionalidad y restricciones
operacionales que debe cumplir el software.
2. Diseo e Implementacin: Se disea y construye el software de acuerdo a la
especificacin.
3. Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el
cliente.
4. Evolucin: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Adems de estas actividades fundamentales, Pressman [1] menciona un conjunto de

actividades protectoras, que se aplican a lo largo de todo el proceso del software. Ellas se
sealan a continuacin:
Seguimiento y control de proyecto de software.
Revisiones tcnicas formales.
Garanta de calidad del software.
Gestin de configuracin del software.
Preparacin y produccin de documentos.

26
Gestin de reutilizacin.
Mediciones.
Gestin de riesgos.
Pressman Caracteriza un proceso de desarrollo de software como se muestra en la Figura

3. Los elementos involucrados se describen a continuacin:
Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco
de trabajo que son aplicables a todos los proyectos de software, con independencia del
tamao o complejidad.
Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software,
hitos de proyectos, entregas y productos de trabajo del software, y puntos de garanta de
calidad, que permiten que las actividades del marco de trabajo se adapten a las caractersticas
del proyecto de software y los requisitos del equipo del proyecto.
Las actividades de proteccin, tales como garanta de calidad del software, gestin de
configuracin del software y medicin, abarcan el modelo del proceso. Las actividades de
proteccin son independientes de cualquier actividad del marco de trabajo y aparecen
durante todo el proceso.
Figura 2: Elementos del proceso del software

27
Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de
software es establecer las relaciones entre elementos que permitan responder Quin debe hacer
Qu, Cundo y Cmo debe hacerlo [5].
Figura 3: Relacin entre elementos del proceso del software
En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus

relaciones. As las interrogantes se responden de la siguiente forma:
Quin: Las Personas participantes en el proyecto de desarrollo desempeando uno o ms

Roles especficos.
Qu: Un Artefacto1 es producido por un Rol en una de sus Actividades. Los Artefactos se
especifican utilizando Notaciones especficas. Las Herramientas apoyan la elaboracin de
Artefactos soportando ciertas Notaciones.
Cmo y Cundo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el
proceso de desarrollo. El avance del proyecto est controlado mediante hitos que establecen
un determinado estado de terminacin de ciertos Artefactos.
Un artefacto es una pieza de informacin que (1) es producida, modificada o usada por el proceso, (2) define un rea de responsabilidad
para un rol y (3) est sujeta a control de versiones. Un artefacto puede ser un modelo, un elemento de modelo o un documento.
28
La composicin y sincrona de las actividades est basada en un conjunto de Principios y

Prcticas. Las Prcticas y Principios enfatizan ciertas actividades y/o la forma como deben
realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en
componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios,
etc.
2.7 SOFTWARE DE ALTA CALIDAD

Considerando que la calidad es un trmino bastante impreciso se ha decidido establecer
este tema como punto de partida. Como complemento se trata el tema del manejo de la
complejidad puesto que es un tpico fundamental dentro de una metodologa, que es la
herramienta fundamental con la que se pretende guiar el proceso de elaboracin de un
producto software de alta calidad.
Calidad en la ingeniera del software. En una versin sucinta la calidad en la
ingeniera del software es un grupo de caractersticas que representa la efectividad y la eficiencia
de un sistema de informacin. Es importante enfatizar en dos puntos :
Un software de calidad debe ser eficaz, es decir, que debe realizar las funciones
establecidas, debe ser amigable. Un usuario debe utilizar el software porque produce
resultados confiables, realiza todas las operaciones que se requieren, ejecuta las operaciones
en un tiempo aceptado y es fcilmente usado por el grupo de usuarios a quien este dirigido.
Un software de calidad debe ser eficiente, es decir el costo de su desarrollo tomando

todos los recursos y el costo de su operacin debe ser tal que las organizaciones involucradas
en su desarrollo y uso obtengan el mximo beneficio o por lo menos un beneficio aceptable
en un perodo de tiempo establecido.
Para ilustrar el concepto de calidad de manera ms profunda, es necesario considerar
algunos aspectos fundamentales que caracterizan al software de calidad como son : solidez,
exactitud, completitud, mantenibilidad, reutilizabilidad, claridad en la documentacin, entre
otros que sern descritos a continuacin.
Aspectos bsicos de calidad de software.

La descripcin que se hace de los factores que influyen en un software de calidad
se basan principalmente en las ideas presentadas por Robert Dunn, Philip Crosby y
29
Roger S. Pressman. Sin embargo, tambin se han tomado algunos aportes de

Bertrand Meyer y Mauricio Fernando Alba.
Robert Dunn presenta la calidad en el software tomando dos puntos de vista : la

calidad en el proceso de desarrollo y la calidad en el producto final, estos dos grupos
principales los agrupa en los siguiente aspectos de calidad : confiabilidad, utilizabilidad,
mantenibilidad, y adaptabilidad. Roger Pressman describe similares factores de
calidad agrupados en tres grupos: calidad en operacin, calidad en revisin y calidad en
transicin.
2.8 FACTORES DE CALIDAD Y PRODUCTIVIDAD.

Siempre hay que preucuparse en incrementar la calidad del sofware en la que se debe
comprometer en llevar acabo dentro de un grupo de trabajo, pues asumiendo este rol, se desea
decir que en la ingeniera, se busca la calidad; la ingeniera del software es la produccin de
software de calidad. Se desea que los sistemas de software sean rpidos, fiables, fciles de usar,
legibles, modulares, estructurados y as sucesivamente. Pero estos adjetivos describen dos tipos
de cualidades diferentes.
Por una parte, se consideran cualidades tales como la velocidad o la facilidad de uso, cuya
presencia o ausencia en un producto de software puede ser detectada por sus usuarios. Estas
propiedades pueden ser denominadas factores de calidad externos. Otras cualidades aplicables
a un producto de software, como la Modularidad o legibilidad son factores internos,
perceptibles slo por profesionales de la informtica que tienen acceso al cdigo fuente.
En ltima instancia, slo importan los factores externos. Si se una un navegador Web o se
vive cerca de una planta nuclear controlada por computadora, importa poco que el software sea
legible o modular si los grficos tardan aos en cargarse o si la introduccin de datos errneos
hace explotar la planta.La clave para obtener los factores externos radica en los internos: para
30
que los usuarios disfruten de las cualidades visibles, los diseadores y los implementadotes
deben aplicar tcnicas internas que aseguren las cualidades ocultas.
1. Una revisin de los factores externos:

1.1 Correccin
La correccin es la cualidad principal. Si un sistema no hace lo que se supone que debe

hacer, poco importan el resto de consideraciones que hagamos sobre l si es rpido, si tiene
una bonita interfaz de usuario
Pero esto es ms fcil de decir que de lograr. Incluso el primer paso hacia la correccin es
ya difcil: debemos ser capaces de especificar los requisitos del sistema de una forma precisa, lo
que es en s una ardua tarea.
Los mtodos que aseguran la correccin son usualmente condicionales. Un sistema de
software importante, incluso uno pequeo segn los estndares de hoy, implica a tantas reas
que sera imposible garantizar su correccin manejando todas las componentes y propiedades
en un solo nivel. En cambio, es necesaria una solucin multinivel, en la que cada nivel confa en
la correccin de los inferiores:
Hardware ----> Sistema Operativo----> Compilador ----> Sistema de Aplicacin
En la solucin condicional de la correccin, slo hay que preocuparse en garantizar que
cada nivel sea correcto bajo el supuesto de que los niveles inferiores son correctos.
1.2 Robustez
31
La robustez complementa la correccin. La correccin tiene que ver con el

comportamiento de un sistema en los casos previstos por su especificacin; la robustez
caracteriza lo que sucede fuera de tal especificacin.
La robustez es por naturaleza una nocin ms difusa que la correccin. Puesto que tiene
que ver aqu con casos no previstos por la especificacin, no es posible decir, como con la
correccin, que el sistema debera realizar sus tareas en tal caso; donde las tareas son
conocidas, el caso excepcional formara parte de la especificacin y regresaramos al terreno de
la correccin.
Siempre habr casos que la especificacin no contemple explcitamente. El papel del
requisito de robustez es asegurar que si tal caso surgiese el sistema no causar eventos
catastrficos; debera producir mensajes de error apropiados, terminar su ejecucin
limpiamente en lo posible.
1.3 Extensibilidad
El software se supone que es soft (blando), y realmente lo es en un principio; nada es ms

fcil de cambiar que un programa si se tiene acceso a su cdigo fuente.El problema de
extensibilidad es un problema de escala. Para programas pequeos realizar cambios no es
normalmente una tarea difcil; pero a medida que el software crece comienza a ser cada vez ms
difcil de adaptar. La extensibilidad es necesaria porque en la base de todo software
encontramos algn fenmeno humano y de ah su volatilidad.
32
El cambio es omnipresente en el desarrollo del software: cambios en los requisitos, de

nuestra comprensin de los requisitos, de los algoritmos, de la representacin de los datos, de
las tcnicas de implementacin. Ofrecer soporte para los cambios es un objetivo bsico de la
tecnologa de objetos. Aunque muchas de las tcnicas que mejoran la extensibilidad se pueden
aplicar con pequeos ejemplos, su relevancia slo se ve con claridad en los grandes proyectos.
Hay dos principios esenciales para mejorar la extensibilidad:
Simplicidad del diseo: una arquitectura simple siempre ser ms fcil de

adaptar a los cambios que una compleja.
Descentralizacin: cuanto ms autnomos sean los mdulos, ms alta es la

probabilidad de que un cambio afecte a un solo mdulo, o a un nmero pequeo
de mdulos, en lugar de provocar una reaccin en cadena de cambios en el sistema
completo.
1.4 Reutilizacin
La necesidad de la reutilizacin surge de la observacin de que los sistemas software a

menudo siguen patrones similares; debera ser posible explotar esta similitud y evitar reinventar
soluciones a problemas que ya han sido encontradas con anterioridad. Capturando tal patrn,
un elemento de software reutilizable se podr aplicar en muchos desarrollos diferentes. La
reutilizacin tiene una influencia sobre todos los dems aspectos de la calidad del software, ya
que al resolver el problema de la reutilizacin se tendr que escribir menos software y en
consecuencia se podrn dedicar entonces mayores esfuerzos a mejorar los otros factores, tales
como la correccin y la robustez.
1.5 Compatibilidad
33
La compatibilidad es importante debido a que los sistemas software no se desarrollan en

el vaco: necesitan interactuar con otros. Pero con mucha frecuencia los sistemas tienen
dificultades para interactuar porque hacen suposiciones contradictorias sobre el resto del
mundo. Un ejemplo es la amplia variedad de formatos de archivos soportados por muchos
sistemas operativos. Un programa puede usar directamente como entrada los resultados de otro
slo si los formatos de archivos son compatibles.La clave de la compatibilidad recae en la
homogeneidad del diseo y en acordar convenciones estndares para la comunicacin entre
programas. Los enfoques incluyen:
Formatos de archivos estndares, como en el sistema Unix, donde cualquier

archivo de texto es simplemente una secuencia de caracteres.
Estructuras de datos estndares como en los sistemas Lisp, donde tanto los datos
como los programas, se representan mediante rboles binarios.
Interfaces de usuario estndares, como en las diferentes versiones de Windows

donde todas las herramientas utilizan un solo paradigma para la comunicacin con
el usuario, basado en componentes estndares tales como ventanas, conos,
mens, etc.
1.6 Eficiencia
Casi sinnimo de eficiencia es la palabra rendimiento. La comunidad del software

muestra dos tipos de actitud con relacin a la eficiencia:
Algunos desarrolladores tienen una obsesin con las cuestiones de rendimiento y

le dedican gran cantidad de esfuerzos a presuntas optimizaciones.
34
Por otro lado, existe la tendencia de soslayar las cuestiones de eficiencia, como se
evidencia en las frases de la industria hgalo correcto antes de hacerlo rpido y
de todos modos los modelos de computadoras del ao que viene van a ser un 50%
ms rpidos.
De manera ms general, la preocupacin por la eficiencia debe sopesarse con otros

objetivos tales como la extensibilidad y la reutilizacin; optimizaciones extremas pueden hacer
al software tan especializado que limite el cambio y la reutilizacin. Es ms, la potencia creciente
del hardware de las computadoras nos permite tener una actitud ms relajada con respecto a
tratar de ganar hasta el ltimo byte o microsegundo.
1.7 Portabilidad (transportabilidad)
La portabilidad tiene que ver con las variaciones no slo del hardware fsico sino ms
generalmente de la mquina hardware-software, la que realmente programamos y que incluye
el sistema operativo, el sistema de ventanas y otras herramientas fundamentales. Muchas de las
incompatibilidades existentes entre las plataformas son injustificadas, y convierte a la
portabilidad en un asunto primordial tanto para los que desarrollan como para los que usan el
software.
1.8 Facilidad de uso
La definicin insiste en los diferentes niveles de experiencia de los posibles usuarios. Este
requisito plantea uno de los mayores retos de los diseadores de software preocupados por la
facilidad de uso: cmo proporcionar explicaciones y guas detalladas a los usuarios novatos sin
35
fastidiar a los usuarios expertos que quieren ir directo al grano.Una de las claves de la facilidad
de uso es la simplicidad estructural. Un sistema bien diseado, construido de acuerdo a una
estructura clara y bien pensada, tiende a ser ms fcil de aprender y usar que uno confuso.
Los buenos diseadores de interfaces siguen una poltica prudente. Hacen las menos
suposiciones posibles sobre los usuarios. Cuando se disea un sistema interactivo, se debe
esperar que los usuarios sean miembros de la raza humana y que sepan leer, mover un ratn,
presionar un botn y teclear (lentamente); no mucho ms. Si el software est dirigido a un rea
especializada de aplicacin, se puede dar por supuesto que los usuarios estn familiarizados con
sus conceptos bsicos. Pero incluso esto es arriesgado.
1.9 Funcionalidad
Uno de los problemas ms difciles a los que se enfrenta un jefe de proyecto es conocer
cuanta funcionalidad es suficiente. La presin para ofrecer ms facilidades (conocida como
featurism), est constantemente presente. Sus consecuencias son malas para los proyectos
internos, donde las presiones vienen de los usuarios de la misma compaa, y son peores para
los productos comerciales, ya que la parte ms destacada de los anlisis comparativos suele ser
una tabla donde se enumeran una por una las propiedades que ofrecen los distintos productos
analizados.
El featurism es realmente la combinacin de dos problemas, uno ms difcil que el otro.
El problema ms fcil es la prdida de consistencia como consecuencia de estar aadiendo
nuevas propiedades, lo que puede afectar a su facilidad de uso. Los usuarios se quejan con razn
de que toda la parafernalia que acompaa a una nueva versin de un producto lo hace
tremendamente complejo. Tales comentarios no deberan preocuparnos en exceso, puesto que
las nuevas propiedades no surgen de la nada: la mayor parte de las veces han sido solicitadas por
los usuarios otros usuarios. Lo que a unos les puede resultar algo superfluo puede ser una
facilidad indispensable para otros.
La solucin aqu es trabajar una y otra vez sobre la consistencia del producto global,
tratando de que todo encaje en un molde general. Un buen producto software est basado en un
36
nmero pequeo de potentes ideas; incluso si tiene muchas propiedades especializadas, stas
deberan explicarse como consecuencia de los conceptos bsicos. El gran plan debe estar
visible y todo debera ocupar su sitio dentro de l.
1.10 Oportunidad
La oportunidad es una de las mayores frustraciones de nuestra industria. Un gran

producto software que aparece demasiado tarde puede no alcanzar su objetivo. Esto es cierto en
otras industrias tambin, pero pocas evolucionan tan rpidamente como el software.La
oportunidad es todava, para grandes proyectos, un fenmeno poco comn. Cuando Microsoft
anunci que la ltima versin de su principal sistema operativo, que llevaba realizando varios
aos, saldra al mercado un mes antes de lo previsto, el suceso fue lo suficientemente relevante
como para encabezar los titulares de Computer World.
1.11 Otras cualidades:

Adems de las cualidades analizadas, existen otras que afectan a los usuarios de sistemas
software y a la gente que compra estos sistemas o encarga su desarrollo. En particular:
Verificabilidad: es la facilidad para preparar procedimientos de aceptacin,

especialmente datos de prueba y procedimientos para detectar fallos y localizar
errores durante las fases de validacin y operacin.
Integridad: es la capacidad de los sistemas software de proteger sus diversos

componentes (programas, datos, etc.) contra modificaciones y accesos no
autorizados.
Reparabilidad: es la capacidad para facilitar la reparacin de los defectos.
37
Economa: junto con la oportunidad, es la capacidad que un sistema tiene de

completarse con el presupuesto asignado o por debajo del mismo.
2. Sobre la documentacin:
En una lista de factores de calidad del software, uno podra esperar encontrar la presencia
de una buena documentacin como uno de los requisitos. Pero ste no es un factor de calidad
separado; la necesidad de documentacin es una consecuencia de otros factores de calidad vistos
en el acpite anterior. Se pueden distinguir tres tipos de documentacin:
La necesidad de documentacin externa, que permite a los usuarios conocer la

potencia de un sistema y usarlo convenientemente, es una consecuencia de la
definicin de facilidad de uso.
La necesidad de documentacin interna, que permite a los desarrolladores de

software comprender la estructura e implementacin de un sistema, es una
consecuencia del requisito de extensibilidad.
La necesidad de documentacin de la interfaz de un mdulo, que permite a

los desarrolladores de software comprender las funciones proporcionadas por un
mdulo sin tener que comprender su implementacin, es una consecuencia del
requisito de reutilizacin. Tambin se desprende de la extensibilidad, ya que una
documentacin de la interfaz de un mdulo permite determinar cundo cierto
cambio afecta a un determinado mdulo.
En lugar de tratar la documentacin como un producto propio del software, es preferible

producir software lo ms autodocumentado posible. Esto se aplica a los tres tipos de
documentacin:
Incluyendo facilidades de ayuda en lnea y siguiendo normas para interfaces

claras y consistentes, se alivia la tarea de los autores de los manuales de usuario y
de otras formas de documentacin externa.
38
Un buen lenguaje de implementacin puede eliminar muchas de las necesidades

de documentacin interna si favorece la claridad y la estructura.
La notacin soportar la ocultacin de informacin y otras tcnicas para separar la

interfaz de los mdulos de su implementacin. Ser posible entonces utilizar
herramientas para producir automticamente documentacin de la interfaz del
mdulo a partir del texto de los mdulos.
39

Fund. Desarrollo Sistemas - Unidad II

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Fund. Desarrollo Sistemas - Unidad II

Cargado por

Copyright:

Formatos disponibles

Fundamentos de Desarrollo de Sistemas Unidad II

FUNDAMENTOS DE DESARROLLO DE SISTEMAS

Fundamentos de Desarrollo de Sistemas Unidad II

2.2 HISTORIA DE LA INGENIERA DE SOFTWARE

Su origen se debe a que el entorno actual de desarrollo de sistemas software viene

Retrasos considerables en la planificacin

Elevadas cargas de mantenimiento

Demandas cada vez ms desfasadas con las ofertas

Baja calidad y fiabilidad del producto

Dependencia de los realizadores

originado histricamente en los siguientes pasos:

Programar no es una tarea diferenciada del diseo de una mquina

Uso de lenguaje mquina y ensamblador

Segunda Fase. El florecimiento (1955-1965).

Aparecen multitud de lenguajes

Era posible hacer casi todo

Instituto Tecnolgico de Ciudad.Jurez

Fundamentos de Desarrollo de Sistemas Unidad II

Tercera Fase. La crisis (1965-1970).

Desarrollo inacabable de grandes programas

Ineficiencia, errores, costo impredecible

Cuarta Fase. Innovacin conceptual (1970-1980).

Quinta Fase. El diseo es el problema (1980-?).

2.3 CARACTERSTICAS DEL SOFTWARE

Fundamentos de Desarrollo de Sistemas Unidad II

2.4 MITOS DEL SOFTWARE

Instituto Tecnolgico de Ciudad.Jurez

Fundamentos de Desarrollo de Sistemas Unidad II

2.5 CAPAS DE LA INGENIERA DE SOFTWARE

Instituto Tecnolgico de Ciudad.Jurez

Fundamentos de Desarrollo de Sistemas Unidad II

(Pressman) Caracteriza la Ingeniera de Software como una tecnologa multicapa,

Figura: Capas de la Ingeniera de Software.

Dichas capas se describen a continuacin:

El fundamento de la ingeniera de software es la Capa Proceso. El proceso define un marco

Los Mtodos de la ingeniera de software indican cmo construir tcnicamente el software.

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

Instituto Tecnolgico de Ciudad.Jurez

Fundamentos de Desarrollo de Sistemas Unidad II

Dado lo anterior, el objetivo de la ingeniera de software es lograr productos de software

2.6 EL PROCESO DE SOFTWARE

Instituto Tecnolgico de Ciudad.Jurez

Fundamentos de Desarrollo de Sistemas Unidad II

Figura 1: proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de

Adems de estas actividades fundamentales, Pressman [1] menciona un conjunto de

Seguimiento y control de proyecto de software.

Revisiones tcnicas formales.

Garanta de calidad del software.

Gestin de configuracin del software.

Preparacin y produccin de documentos.

Fundamentos de Desarrollo de Sistemas Unidad II

Pressman Caracteriza un proceso de desarrollo de software como se muestra en la Figura

Figura 2: Elementos del proceso del software

Fundamentos de Desarrollo de Sistemas Unidad II

Figura 3: Relacin entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus

Quin: Las Personas participantes en el proyecto de desarrollo desempeando uno o ms

Fundamentos de Desarrollo de Sistemas Unidad II

La composicin y sincrona de las actividades est basada en un conjunto de Principios y

2.7 SOFTWARE DE ALTA CALIDAD

Un software de calidad debe ser eficiente, es decir el costo de su desarrollo tomando

Aspectos bsicos de calidad de software.