BASES DE DATOS I

Fundamentos de Desarrollo de Sistemas Unidad II

FUNDAMENTOS DE DESARROLLO DE SISTEMASUNIDAD IIINTRODUCCIN A LA INGENIERA DE SOFTWARE2.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 costo-efectivos" [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.

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 realizadoresEsto 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 ensambladorSegunda Fase. El florecimiento (1955-1965).

Aparecen multitud de lenguajes Era posible hacer casi todoTercera Fase. La crisis (1965-1970).

Desarrollo inacabable de grandes programas Ineficiencia, errores, costo impredecible Nada es posibleCuarta Fase. Innovacin conceptual (1970-1980).

Fundamentos de programacin Verificacin de programas Metodologas de diseoQuinta 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 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).

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.

(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).

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.

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.

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

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 Artefacto 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.

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 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 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

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.

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

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.

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

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.

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.

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.

PAGE 38Instituto Tecnolgico de Ciudad.Jurez