Fundamentos de Desarrollo de Sistemas

Prepar: Jos Luis Duch Gary.

2 INTRODUCCIN A LA INGENIERA DE SOFTWARE.

La situacin actual en los sistemas informticos se caracteriza por una rpida evolucin de los componentes hardware, que incrementan continuamente sus prestaciones manteniendo o incluso disminuyendo sus precios, junto con una fuerte tendencia a la estandarizacin (computadoras personales, estaciones de trabajo con sistema operativo UNIX, sistemas distribuidos funcionando sobre plataformas heterogneas, etc.) y una gran diversidad de marcas y modelos con prestaciones y precios similares. En este escenario, la potencia de los grandes computadoras de las dcadas pasadas est hoy disponible en un mini ordenador e incluso en un ordenador personal. El software es el mecanismo que nos permite utilizar y explotar este potencial. Esto hace que, a la hora de plantearnos la adquisicin de un sistema informtico completo, ya sea para gestionar una empresa, para controlar un proceso industrial, o para uso domstico, el software es lo que marca la diferencia. Entre varios productos de caractersticas hardware similares, nos decidiremos por una determinada compaa vendedora basndonos en las prestaciones, inteligencia, calidad y facilidad de uso de su software. Por otra parte, el desarrollo de software no es una tarea fcil. La complejidad actual de los sistemas informticos hace a veces necesario el desarrollo de proyectos de software de decenas de miles de lneas de cdigo. Esto no puede ser abordado directamente, empezando a programar sin ms. Es necesario analizar qu es lo que tenemos que hacer, cmo lo vamos a hacer, cmo se van a coordinar todas las personas que van a intervenir en el proyecto y cmo vamos a controlar el desarrollo del mismo de forma que al final obtengamos los resultados esperados. Como vemos, el software es actualmente, dentro de cualquier sistema basado en el uso de computadoras, el componente cuyo desarrollo presenta mayores problemas: es el ms difcil de planificar, el que tiene mayor probabilidad de fracaso, y el que tiene menos posibilidades de que se cumplan las estimaciones de costos iniciales. Por otra parte, la demanda de software (y tambin la complejidad del software que se demanda) aumentan continuamente, lo que aumenta la magnitud de estos problemas. De todas formas, no hay que ser demasiado catastrofistas. El desarrollo de software es una actividad muy reciente (apenas tiene 50 aos), si la comparamos con otras actividades de ingeniera (p.ej. la construccin de puentes o incluso la ingeniera elctrica, de la que deriva la ingeniera de hardware), y la disciplina que se encarga de establecer un orden en el desarrollo de sistemas de software (esto es, la Ingeniera del software) es an ms reciente. Existen buenos mtodos de desarrollo de software pero quizs el problema est en que no estn lo suficientemente difundidos o valorados. Slo recientemente, estas tcnicas estn logrando una amplia aceptacin.

Prepar: Ing. Jos Luis Duch Gary.

Como se ver ms adelante el trmino ingeniera de software fue acuado en 1968 como una respuesta al nivel de progreso desolador del objetivo de desarrollar software de calidad a tiempo y dentro del presupuesto. Los desarrolladores de software no fueron capaces de definir objetivos concretos, predecir los recursos necesarios para lograr esos objetivos y manejar las expectativas de los clientes. Con mucha frecuencia se prometa la luna y la construccin de un vehculo lunar, y se entregaba un par de ruedas cuadradas. El nfasis de la ingeniera de software est en las dos palabras: ingeniera y software. Un ingeniero es capaz de construir un producto de alta calidad usando componentes ya elaborados e integrndolos bajo restricciones de tiempo y presupuesto. El ingeniero se enfrenta a menudo con problemas mal definidos y con soluciones parciales, y tiene que apoyarse en mtodos empricos para evaluar soluciones. Los ingenieros que trabajan en campos de aplicacin como el diseo de aeronaves de pasajeros y la construccin de puentes han resuelto en forma satisfactoria retos similares. Los ingenieros de software no han tenido tanto xito.

Fallas en el software.
Considere los siguientes ejemplos [Neumann, 1995]: 1. El error del ao 1900. En 1992, Mary, de Winona, Minnesota, recibi una invitacin para que asistiera a un jardn de nios. En ese entonces Mary tena 104 aos. 2. Error del ao bisiesto. A un supermercado le pusieron una multa de 1,000 dlares por tener carne que haba caducado por un da, el 29 de febrero de 1988. El programa de computadora que imprimi la fecha de caducidad en las etiquetas de la carne no tom en cuenta que 1988 era ao bisiesto. 3. Mal uso de interfaz. El 10 de abril de 1990, en Londres, un tren subterrneo sali de la estacin sin su conductor. El conductor haba oprimido el botn que arrancaba el tren confiando en el sistema que impeda que el tren se moviera mientras las puertas estuvieran abiertas. El operador del tren haba abandonado su lugar para cerrar una puerta que estaba atorada. Cuando finalmente la puerta se cerr, el tren simplemente se fue. 4. Seguridad. El 2 de noviembre de 1988 un programa que se auto propaga, al que posteriormente se le llam el gusano de Internet, fue lanzado en Internet. El programa explot la vulnerabilidad de los servicios de red, como la del programa de envo de correo de Unix, para replicarse a s mismo de una computadora a otra. Por desgracia, al llegar el gusano de Internet a una mquina, consuma todos los recursos de cmputo disponibles y haca que la mquina infectada dejara de funcionar. Se estima que se afect 10% de todos los nodos de Internet. Se necesitaron varios das para erradicar la infeccin. 5. Con retraso y excedido en el presupuesto.

Prepar: Ing. Jos Luis Duch Gary.

En 1995 los errores en el sistema de manejo de equipaje automatizado del nuevo aeropuerto internacional de Denver causaron que se daaran las maletas. El aeropuerto abri con 16 meses de retraso, con un exceso de gasto de 3.2 mil millones de dlares y con un sistema para el manejo de equipaje en su mayor parte manual. 6. Entrega a tiempo. Despus de 18 meses de desarrollo, se entreg un sistema de 200 millones de dlares a una compaa de seguros de salud en Wisconsin en 1984. Sin embargo, el sistema no funcion en forma correcta: se expidieron 60 millones de dlares de pagos extras. Se necesitaron tres aos para componer el sistema. 7. Complejidad innecesaria. El avin de carga C-17 de McDonnell Douglas se excedi 500 millones de dlares en el presupuesto a causa de problemas en su software de electrnica de aviacin. El C-17 inclua 19 computadoras a bordo, 80 microprocesadores y seis lenguajes de programacin diferentes. Cada una de las fallas descritas antes se debi a un problema relacionado con software. En algunos casos los desarrolladores no anticiparon situaciones que ocurren rara vez (una persona que vive ms de cien aos, aos bisiestos que tienen un impacto en las fechas de caducidad). En otros casos los desarrolladores no anticiparon que el usuario hara mal uso del sistema (la opresin de un botn, la exploracin de las facilidades de depuracin del envo de correo). En otros casos las fallas del sistema resultaron por fallas de administracin (entrega tarda y con presupuesto excedido, entrega a tiempo de un sistema incorrecto, complejidad innecesaria) Los sistemas de software son creaciones complejas: realizan muchas funciones, estn construidos para lograr muchos objetivos diferentes y con frecuencia conflictivos, comprenden muchos componentes, muchos de sus componentes son en s mismos complejos y hechos a la medida, muchos participantes de disciplinas diferentes intervienen en el desarrollo de estos componentes, el proceso de desarrollo y el ciclo de vida del software a menudo abarcan muchos aos y, por ltimo, los sistemas complejos son difciles de comprender por completo para una sola persona. Muchos sistemas son tan difciles de comprender, incluso durante su fase de desarrollo, que nunca llegan a ser terminados: a stos se les llama vaporware. Los proyectos de desarrollo de software estn sujetos a cambios constantes. Debido a que los requerimientos son complejos, necesitan ser actualizados cuando se descubren errores y cuando los desarrolladores tienen una mejor comprensin de la aplicacin. Si el proyecto dura muchos aos, la rotacin de personal es alta y requiere entrenamiento constante. El tiempo entre los cambios tecnolgicos con frecuencia es ms corto que la duracin del proyecto. La suposicin ampliamente difundida entre los gerentes de proyecto de software de que hay que abordar todos los cambios y que los requerimientos pueden congelarse, conduce a que se despliegue un sistema irrelevante.

Prepar: Ing. Jos Luis Duch Gary.

2.1 DEFINICIN DE INGENIERA DEL SOFTWARE.

El desarrollo de sistemas de software complejos no es una actividad trivial, que pueda abordarse sin una preparacin previa. El considerar que un proyecto de desarrollo de software poda abordarse como cualquier otro ha llevado a una serie de problemas que limitan nuestra capacidad de aprovechar los recursos que el hardware pone a nuestra disposicin. Los problemas tradicionales en el desarrollo de software, no van a desaparecer de la noche a la maana, pero identificarlos y conocer sus causas es el nico mtodo que nos puede llevar hacia su solucin. No existe una frmula mgica para solucionar estos problemas, pero combinando mtodos aplicables a cada una de las fases del desarrollo de software, construyendo herramientas para automatizar estos mtodos, utilizando tcnicas para garantizar la calidad de los productos desarrollados y coordinando todas las personas involucradas en el desarrollo de un proyecto, podremos avanzar mucho en la solucin de estos problemas. De ello se encarga la disciplina llamada Ingeniera del software. Una de las primeras definiciones que se dio de la Ingeniera del software es la siguiente: El establecimiento y uso de principios de ingeniera robustos, orientados a obtener software econmico, que sea fiable y funcione de manera eficiente sobre mquinas reales. Sin embargo el trmino Ingeniera del software se usa con una variedad de significados diferentes: 1. Como el trmino usual contemporneo de un amplio rango de actividades que se sola llamar programacin y anlisis de sistemas; 2. Como un trmino amplio de todos los aspectos de la prctica de la programacin de computadoras, en oposicin a la teora, que es llamada ciencia computacional o computacin. 3. La ingeniera de software es (1) la aplicacin de un mtodo sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software, esto es, la aplicacin de la ingeniera al software y (2) el estudio de los mtodos de (1), estndar IEEE 610.12 4. El modelo de la Ingeniera del software parte del mundo real. Como el mundo real cambia, el software debe cambiar tambin, y la Ingeniera del software estudia la evolucin de estos modelos y como se enfrentan a los requisitos cambiantes.

2.2 HISTORIA DE LA INGENIERA DEL SOFTWARE.

2.2.1 ORGENES.
El trmino Ingeniera del software fue usado ocasionalmente al final de la dcada de los 50's e inicios de los 60's. El trmino fue popularizado por la Conferencia sobre Ingeniera de Software de la OTAN en 1968 que tuvo lugar en Garmish, Alemania, y ha sido ampliamente utilizado desde entonces.

Prepar: Ing. Jos Luis Duch Gary.

Hemos dicho que el software era el factor decisivo a la hora de elegir entre varias soluciones informticas disponibles para un problema dado, pero esto no ha sido siempre as. En los primeros aos de la informtica, el hardware tena una importancia mucho mayor que en la actualidad. Su costo era comparativamente mucho ms alto y su capacidad de almacenamiento y procesamiento, junto con su fiabilidad, era lo que limitaba las prestaciones de un determinado producto. El software se consideraba como un simple aadido, a cuyo desarrollo se dedicaba poco esfuerzo y no se aplicaba ningn mtodo sistemtico. La programacin era un arte de andar por casa, y el desarrollo de software se realizaba sin ninguna planificacin. La mayora del software se desarrollaba y era utilizado por la misma persona u organizacin. La misma persona lo escriba, lo ejecutaba y, si fallaba, lo depuraba. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estara all cuando se encontrara algn error. Debido a este entorno personalizado del software, el diseo era un proceso implcito, realizado en la mente de alguien y la documentacin normalmente no exista. En este contexto, las empresas de informtica se dedicaron a mejorar las prestaciones del hardware, reduciendo los costos y el consumo de los equipos, y aumentando la velocidad de clculo y la capacidad de almacenamiento. Para ello, tuvieron que dedicar grandes esfuerzos a investigacin y aplicaron mtodos de ingeniera industrial al anlisis, diseo, fabricacin y control de calidad de los componentes del hardware. Como consecuencia de esto, el hardware se desarroll rpidamente y la complejidad de los sistemas informticos aument notablemente, necesitando de un software cada vez ms complejo para su funcionamiento. Surgieron entonces las primeras casas de software, y el mercado se ampli considerablemente. Con ello aument la movilidad laboral, y con la marcha o partida de un trabajador desaparecan las posibilidades de mantener o modificar los programas que ste haba desarrollado. Al no utilizarse metodologa alguna en el desarrollo del software, los programas contenan numerosos errores e inconsistencias, lo que obligaba a una depuracin continua, incluso mucho despus de haber sido entregados al cliente. Estas continuas modificaciones no hacan sino aumentar la inconsistencia de los programas, que se alejaban cada vez ms de la correccin y se hacan prcticamente ininteligibles. Los costos se disparaban y frecuentemente era ms rpido (y por tanto ms barato) empezar de nuevo desde cero, desechando todo el trabajo anterior, que intentar adaptar un programa preexistente a un cambio de los requisitos. Sin embargo, los nuevos programas no estaban exentos de errores ni de futuras modificaciones, con lo que la situacin volva a ser la misma. Haba comenzado la denominada crisis del software. Hoy en da, la distribucin de costos en el desarrollo de sistemas informticos ha cambiado drsticamente. El software, en lugar del hardware, es el elemento principal del costo. Esto ha hecho que las miradas de los ejecutivos de las empresas se centren en el software y a que se formulen las siguientes preguntas: Por qu lleva tanto tiempo terminar los programas? Por qu es tan elevado el costo? Por qu no es posible encontrar todos los errores antes de entregar el software al cliente?

Prepar: Ing. Jos Luis Duch Gary.

Por qu resulta tan difcil constatar el progreso conforme se desarrolla el software? Estas y otras muchas preguntas son una manifestacin del carcter del software y de la forma en que se desarrolla y han llevado a la aparicin y la adopcin paulatina de la Ingeniera del software.

2.2.2 LA INGENIERA DE SOFTWARE EN NUESTROS DAS

La ingeniera de software afecta a la economa y las sociedades de muchas maneras. 1. Econmicamente. En los EEUU, el software contribuy a 1/4 de todo el incremento del PIB durante los 90's (alrededor de 90,000 millones de dlares por ao), y 1/6 de todo el crecimiento de productividad durante los ltimos aos de la dcada (alrededor de 33,000 millones de dlares por ao). La ingeniera de software contribuy a $1 billn de crecimiento econmico y productividad en esa dcada. Alrededor del globo, el software contribuye al crecimiento econmico en formas similares, aunque es difcil de encontrar estadsticas confiables. 2. Socialmente. La ingeniera de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrnico (E-mail), la WWW y la mensajera instantnea permiten a la gente interactuar en nuevas formas. El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los proyectos exitosos donde se han usado mtodos de ingeniera de software incluyen a Linux, el software del trasbordador espacial, los cajeros automticos y muchos otros.

2.3 CARACTERSTICAS DEL SOFTWARE.

Una definicin de software podra ser la siguiente: Software: (1) instrucciones de ordenador que cuando se ejecutan proporcionan la funcin y el comportamiento deseado, (2) estructuras de datos que facilitan a los programas manipular adecuadamente la informacin, y (3) documentos que describen la operacin y el uso de los programas. Por tanto, el software incluye no slo los programas de ordenador, sino tambin las estructuras de datos que manejan esos programas y toda la documentacin que debe acompaar al proceso de desarrollo, mantenimiento y uso de dichos programas. Segn esto, el software se diferencia de otros productos que los hombres puedan construir en que es, por su propia naturaleza lgico. En el desarrollo del hardware, el proceso creativo (anlisis, diseo, construccin, prueba) se traduce finalmente en una forma material, en algo fsico. Por el contrario, el software es inmaterial y por ello tiene unas caractersticas completamente distintas al hardware. Entre ellas podemos citar:

Prepar: Ing. Jos Luis Duch Gary.

1. En sentido estricto el software se desarrolla, no se fabrica. Existen similitudes entre el proceso de desarrollo del software y el de otros productos industriales, como el hardware. En ambos casos existen fases de anlisis, diseo y desarrollo o construccin, y la buena calidad del producto final se obtiene mediante un buen diseo. Sin embargo, en la fase de produccin del software pueden producirse problemas que afecten a la calidad y que no existen, o son fcilmente evitables, en el caso del software Por otro lado, en el caso de produccin de hardware a gran escala, el costo del producto acaba dependiendo exclusivamente del costo de los materiales empleados y del propio proceso de produccin, reducindose la repercusin en el costo de las fases de ingeniera previas. En el software, el desarrollo es una ms de las labores de ingeniera, y la produccin a gran o pequea escala no influye en el impacto que tiene la ingeniera en el costo, al ser el producto inmaterial. Por otro lado, la replicacin del producto (lo que sera equivalente a la produccin del producto hardware) no presenta problemas tcnicos, y no se requiere un control de calidad individualizado. Los costos del software se encuentran en la ingeniera (incluyendo en sta el desarrollo), y no en la produccin, y es ah donde hay que incidir para reducir el costo final del producto. 2. El software no se estropea. Podemos comparar las curvas de ndices de fallos del hardware y el software en funcin del tiempo. En el caso del hardware figura 1.1, se tiene la llamada curva de baera, que indica que el hardware presenta relativamente muchos fallos al principio de su vida. Estos fallos son debidos fundamentalmente a defectos de diseo o a la baja calidad inicial de la fase de produccin. Una vez corregidos estos defectos, la tasa de fallos cae hasta un nivel estacionario y se mantiene as durante un cierto periodo de tiempo. Posteriormente, la tasa de fallos vuelve a incrementarse debido al deterioro de los componentes, que van siendo afectados por la suciedad, vibraciones y la influencia de muchos otros factores externos. Llegados a este punto, podemos sustituir los componentes defectuosos o todo el sistema por otros nuevos, y la tasa de fallos vuelve a situarse en el nivel estacionario. El software no es susceptible a los factores externos que hacen que el hardware se estropee. Por tanto la curva debera seguir la forma de la figura 1.2. Inicialmente la tasa de fallos es alta, debido a la presencia de errores no detectados durante el desarrollo, los denominados errores latentes. Una vez corregidos estos errores, la tasa de fallos debera alcanzar el nivel estacionario y mantenerse ah indefinidamente. Pero esto no es ms que una simplificacin del modelo real de fallos de un producto de software. Durante su vida, el software sufre cambios, debidos al mantenimiento. El mantenimiento puede deberse a la correccin de errores latentes o a cambios en los requisitos iniciales del producto. Conforme se hacen cambios es bastante probable que se introduzcan nuevos errores, con lo que se producen picos en la curva de fallos.

Prepar: Ing. Jos Luis Duch Gary.

Estos errores pueden corregirse, pero el efecto de los sucesivos cambios hace que el producto se aleje cada vez ms de las especificaciones iniciales de acuerdo a las cuales fue desarrollado, conteniendo cada vez ms errores latentes. Adems, con mucha frecuencia se solicita y se emprende un nuevo cambio antes de haber conseguido corregir todos los errores producidos por el cambio anterior. Por estas razones, el nivel estacionario que se consigue despus de un cambio es algo superior al que el que haba antes de efectuarlo figura 1.3, degradndose poco a poco el funcionamiento del sistema. Podemos decir entonces que el software no se estropea, pero se deteriora. Adems, cuando un componente software se deteriora, no podemos sustituirlo por otro, como en el caso del hardware: no existen piezas de repuesto. Cada fallo del software indica un fallo en el diseo o en el proceso mediante el cual se transform el diseo en cdigo mquina ejecutable. La solucin no es sustituir el componente defectuoso por otro (que sera idntico y contendra los mismos errores) sino un nuevo diseo y desarrollo del producto. Por tanto, el mantenimiento del software tiene una complejidad mucho mayor que el mantenimiento del hardware. 3. La mayora del software se construye a medida. El diseo de hardware se realiza, en gran medida, a base de componentes digitales existentes, cuyas caractersticas se comprueban en un catlogo y que han sido exhaustivamente probados por el fabricante y los usuarios anteriores. Estos componentes cumplen unas especificaciones claras y tienen unas interfaces definidas. El caso del software es bien distinto. No existen catlogos de componentes, y aunque determinados productos como sistemas operativos, editores, entornos de ventanas y bases de datos se venden en grandes ediciones, la mayora del software se fabrica a medida, siendo la reutilizacin muy baja. Se puede comprar software ya desarrollado, pero slo como unidades completas, no como componentes que pueden ser reensamblados para construir nuevos programas. Esto hace que el impacto de los costos de ingeniera sobre el producto final sea muy elevado, al dividirse entre un nmero de unidades producidas muy pequeo. Se ha escrito mucho sobre reutilizacin del software, y han sido muchos los intentos para conseguir aumentar el nivel de reutilizacin, normalmente con poco xito. Uno de los ejemplos de reutilizacin ms tpicos, que ha venido usndose desde hace tiempo, son las bibliotecas. Durante los aos sesenta se empezaron a desarrollar bibliotecas de subrutinas cientficas, reutilizables en una amplia gama de aplicaciones cientficas y de ingeniera. La mayor parte de los lenguajes modernos incluyen bibliotecas de este tipo, as como otras para facilitar la entrada/salida y ms recientemente los entornos de ventanas. Sin embargo esta aproximacin no puede aplicarse fcilmente a otros problemas tambin de uso muy frecuente, como puede ser la bsqueda de un elemento en una estructura de datos, debido a la gran variacin que existe en cuanto a la organizacin interna de estas estructuras y en la composicin de los datos que contienen. Existen algoritmos para resolver estos problemas, pero no queda ms remedio que programarlos una y otra vez, adaptndolos a cada situacin particular.

Prepar: Ing. Jos Luis Duch Gary.

Un nuevo intento de conseguir la reutilizacin se produjo con la utilizacin de tcnicas de programacin estructurada y modular. Sin embargo, se dedica por lo general poco esfuerzo al diseo de mdulos lo suficientemente generales para ser reutilizables, y en todo caso, no se documentan ni se difunden todo lo que sera necesario para extender su uso, con lo que la tendencia habitual es disear y programar mdulos muy semejantes una y otra vez. La programacin estructurada permite disear programas con una estructura ms clara, y que, por tanto, sean ms fciles de entender. Esta estructura interna ms clara y estudiada, permite la reutilizacin de mdulos dentro de los programas, o incluso dentro del proyecto que se est desarrollando, pero la reutilizacin de cdigo en proyectos diferentes es muy baja. La ltima tendencia para conseguir la reutilizacin es el uso de tcnicas orientadas a objetos, que permiten la programacin por especializacin. Los objetos, que encapsulan tanto datos como los procedimientos que los manejan -los mtodos- , haciendo los detalles de implementacin invisibles e irrelevantes a quien los usa, disponen de interfaces claras, los errores cometidos en su desarrollo pueden ser depurados sin que esto afecte a la correccin de otras partes del cdigo y pueden ser heredados y reescritos parcialmente, haciendo posible su reutilizacin an en situaciones no contempladas en el diseo inicial.

2.4 MITOS DEL SOFTWARE

1. El costo de computadores es menos que l de dispositivos analgicos o electromecnicos. La verdad es que el hardware es barato. Pero el costo de escribir y certificar software muy confiable y seguro, ms el costo del mantenimiento puede ser enorme. Por ejemplo, el software del trasbordador espacial (400.000 palabras) cuesta ms de US$100.000.000 por ao en mantener. Un sistema electromecnico es frecuentemente ms barato, particularmente si se pueden usar diseos estndares. 2. Es fcil cambiar el software. Los cambios son fciles, pero hacer cambios sin introducir errores es muy difcil. Hay que verificar el software de nuevo con cada cambio. Tambin, con cambios el software se pone frgil. 3. Los computadores proveen ms confiabilidad que los dispositivos que reemplazan. Es verdad que el software no falla como dispositivos normales, pero hay poca evidencia que indica que el comportamiento errneo de software no es un problema significativo. Estudios de sistemas muy crticos a la seguridad han mostrado que hasta 10% de los mdulos se desviaron de la especificacin en un modo o ms de operacin. Muchos errores eran pequeos, pero aproximadamente 1 en 20 produca efectos directos y observables en el sistema controlado.

Prepar: Ing. Jos Luis Duch Gary.

Parece que la solucin es sencillamente implementar el software correctamente. Pero esto es mucho ms difcil que esperado. Por ejemplo, el software del trasbordador espacial ha sido usado desde 1980 y la NASA ha invertido recursos enormes en la verificacin y mantenimiento de este software. Sin embargo, desde la operacin del trasbordador se han encontrado 16 errores de grado de severidad 1 (pueden producir una prdida del trasbordador y su tripulacin). Otros errores de menor severidad han ocurrido durante misiones (tres amenazaron el cumplimiento de la misin) a pesar que la NASA tiene uno de los procesos de desarrollo y verificacin de software ms completos actualmente. Aun cuando sea posible escribir software sin errores, las condiciones ideales para desarrollar software (dinero y tiempo sin lmites) nunca existen. 4. Mayor confiabilidad de software aumenta la seguridad. Se puede mejorar la confiabilidad de software eliminando errores sin relacin a la seguridad del sistema, as aumentando la confiabilidad sin aumentar la seguridad. Tambin, la confiabilidad de software se define como conformidad con los requerimientos, mientras que la mayora de los errores de software crtico a la seguridad son debidos a errores en los requerimientos. El software puede ser correcto y todava causar accidentes graves. 5. La prueba o verificacin formal del software puede eliminar todos los errores. Las limitaciones de las pruebas de software son bien conocidas, bsicamente hay demasiados estados en software real para probarlo completamente. En el futuro la verificacin puede checar la consistencia entre las especificaciones y la implementacin, pero esto requiere que las especificaciones (escritas en notacin formal) estn libres de errores. Tambin, muchos errores importantes son debidos a cosas que no estn en el cdigo, por, muchos accidentes relacionados al software han involucrado sobrecarga en una red. Como ejemplo podemos citar a un sistema para los servicios de emergencia dej de funcionar cuando recibi demasiadas llamadas. 6. El rehus de software aumenta la seguridad. Aunque el rehus puede aumentar la confiabilidad, puede disminuir la seguridad. La razn es porque engendra el falso sentido de seguridad y porque no se consideraron los peligros especficos del sistema nuevo cuando el software fue diseado originalmente. Ejemplos: El Therac-20, partes de lo cual se usaban en el Therac-25, contena el mismo error que caus dos muertes en el Therac-25. El error no caus problemas en el Therac20 porque result solamente en un plomo fundido en vez de una sobredosis masiva de radiacin. Software de control del trfico areo usado muchos aos en los Estados Unidos no se pudo reutilizar en Gran Bretaa. Los desarrolladores norteamericanos habian ignorado el problema de cero grados de longitud. Prepar: Ing. Jos Luis Duch Gary.

10

Software de aviacin escrito para uso en el hemisferio boreal frecuentemente crea problemas cuando es usado en el hemisferio austral. Tambin software para cazas F-16 ha causado accidentes cuando usado en Israel en aviones volados sobre el Mar Muerto, donde la altitud es menor que el nivel del mar. La seguridad no es una propiedad nica del software, sino es una combinacin del diseo de la programacin y del ambiente en el que se usa. 7. Los computadores permiten un control ms fino ya que pueden revisar parmetros ms frecuentemente, hacer clculos en tiempo real, y tomar acciones rpidamente Es verdad. Pero un control ms fino permite que el proceso se pueda operar ms cerca a su ptimo, y se pueden reducir los mrgenes de seguridad. Los sistemas que resultan tienen beneficios econmicos, porque en teora se cerrarn menos y la productividad se puede aumentar con control ms ptimo. Pero la disminucin en los mrgenes puede negar los beneficios posibles, quizs sin la capacidad de alcanzar la confiabilidad usado como el argumento para reducir los mrgenes. 8. Los sistemas automatizados permiten a los operadores trabajar ms lejos de reas peligrosas. Debido a una carencia de conocimiento de los peligros, ms accidentes ocurren cuando los operadores tienen que entrar en las reas peligrosas. Por ejemplo, un robot mat a un trabajador en una planta que los diseadores asuman requera poca intervencin no incluyeron pasarelas ni avisos audibles de movimiento. La suposicin original era que se cerrara la planta para el mantenimiento, pero la realidad era que los trabajadores tenan que rescatar los robots 15 a 20 veces por da. 9. Con la eliminacin de operadores se eliminan los errores humanos. Los errores de operadores se reemplazan con errores de diseo y mantenimiento; los diseadores hacen los mismos tipos de errores como los operadores. Tambin, cuando se elimina el contacto directo con el sistema, los humanos pierden la informacin necesaria para tomar decisiones. 10. Los computadores pueden proveer mejor informacin a los operadores. En teora es verdad, pero esto es muy difcil lograr. Bsicamente los computadores permiten que se provee demasiada informacin y en una forma menos til para algunos propsitos que la instrumentacin tradicional.

Prepar: Ing. Jos Luis Duch Gary.

11

11. El software no falla. Es verdad solamente para una definicin estrecha de falla. Un resultado del reemplazo de dispositivos mecnicos por computadores es la incapacidad de predecir modos de falla. La mayora de los sistemas mecnicos tienen un nmero limitado de modos de falla, y se los pueden disear para fallar en una manera segura. Esto normalmente no es posible con el software.

2.5 CAPAS DE LA INGENIERA DE SOFTWARE.

La Ingeniera del software abarca un conjunto de tres elementos clave: Procesos, mtodos y herramientas que faciliten al administrador el control del desarrollo y le suministre a los implementadores las bases para construir de forma productiva software de alta calidad. La Ingeniera del software es una tecnologa multicapa. Como muestra la Figura 2.1, cualquier enfoque de ingeniera (incluida Ingeniera del software) debe apoyarse sobre un compromiso de organizacin de calidad.

FIGURA 2.1. Capas de la Ingeniera del software.

1. El proceso El fundamento de la Ingeniera del software es la capa de proceso.El proceso define un marco de trabajo para un conjunto de reas clave de proceso (ACPs) que se deben establecer para la entrega efectiva de la tecnologa de la Ingeniera del software. Las reas claves del proceso forman la base del control de administracin de proyectos del software y establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. El proceso define la secuencia en que se aplican los mtodos, los documentos que se requieren, los controles que permiten asegurar la calidad y las directrices que permiten a los gestores evaluar los progresos.

Prepar: Ing. Jos Luis Duch Gary.

12

El proceso de la Ingeniera del software es la unin que mantiene juntas las capas de tecnologa y que permite un desarrollo racional y oportuno de la Ingeniera del software. 2. Los mtodos. Indican cmo construir tcnicamente el software, y abarcan una amplia serie de tareas que incluyen la planificacin y estimacin de proyectos, el anlisis de requisitos, el diseo de estructuras de datos, programas y procedimientos, la codificacin, las pruebas y el mantenimiento. Los mtodos introducen frecuentemente una notacin especfica para la tarea en cuestin y una serie de criterios de calidad. 3. Las herramientas. Proporcionan un soporte automtico o semiautomtico para utilizar los mtodos. Existen herramientas automatizadas para cada una de las fases vistas anteriormente, y sistemas que integran las herramientas de cada fase de forma que sirven para todo el proceso de desarrollo. Estas herramientas se denominan CASE (Computer Assisted Software Engineering).

2.6 EL PROCESO DE SOFTWARE.

Pero, qu es exactamente el proceso del software desde un punto de vista tcnico? Dentro del contexto de esta unidad, definimos un proceso de software como un marco de trabajo de las tareas que se requieren para construir software de calidad. Es proceso sinnimo de Ingeniera del software? La respuesta es s y no. Un proceso de software define el enfoque que se toma cuando el software es tratado por la ingeniera. Pero la Ingeniera del software tambin comprende las tecnologas que tienen el proceso, mtodos tcnicos y herramientas automatizadas. An ms importante es que la Ingeniera del software la realizan personas creativas, con conocimiento, que deberan trabajar dentro de un proceso del software definido y avanzado que es apropiado para los productos que construyen y para las demandas de su mercado. La intencin de este captulo es proporcionar un estudio del estado actual del proceso del software y puntualizar sobre el estudio detallado de los temas de administracin y tcnicos presentados en este libro. Un proceso de software se puede caracterizar como se muestra en la Figura 2.2. Se establece un marco comn del proceso definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamao o complejidad. Un nmero de conjuntos de tareas cada uno es una coleccin de tareas de trabajo de Ingeniera del software, hitos de proyectos, productos de trabajo, y puntos de garanta de calidad que permiten que las actividades del marco de trabajo se adapten a las caractersticas del proyecto del software y a los requisitos del equipo del proyecto. Finalmente, las actividades de proteccin tales como garanta de calidad del software, administracin de configuracin del software y medicin abarcan el modelo de procesos. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Prepar: Ing. Jos Luis Duch Gary.

13

En los ltimos aos, se ha hecho mucho nfasis en la madurez del proceso. El Software Engineering Institute (SEI) ha desarrollado un modelo completo que se basa en un conjunto de funciones de Ingeniera del software que deberan estar presentes conforme las organizaciones alcanzan diferentes niveles de madurez del proceso. Este tema se ver con detalle en la siguiente unidad.

2.7 CALIDAD DEL SOFTWARE.

Se define la calidad de software como la ausencia de errores de funcionamiento, la adecuacin a las necesidades del usuario, y el alcance de un desempeo apropiado (tiempo, volumen, espacio), adems del cumplimiento de los estndares. Los objetivos que la calidad persigue son: La aceptacin (utilizacin real por parte del usuario) y la Mantenibilidad (posibilidad y facilidad de correccin, ajuste y modificacin durante largo tiempo). Para alcanzar estos objetivos, es necesaria una actitud y compromiso de todo el personal que se encuentre en el desarrollo del proyecto, y en todas y cada una de las etapas (en general, planeacin, anlisis, diseo, programacin, pruebas, mantenimiento) correspondientes al ciclo de vida que se hubiese seleccionado para el proyecto. En forma adicional durante el proceso de aplicacin de las metodologas se requiere tener en cuenta: 1. Realizacin de revisiones tcnicas formales durante cada etapa. 2. Realizacin de pruebas y revisiones por personas externas al proyecto. 3. Elaboracin de la adecuada documentacin del software, y de los cambios. 4. Verificacin del cumplimiento de los estndares de desarrollo. 5. Medicin permanente de la productividad del proceso y de la calidad de los resultados. 6. Desarrollo y ajustes de modelos estadsticos de calidad y productividad. 7. Control de la desviacin de los promedios de calidad y productividad. Uno de los elementos que permite dar garanta acerca de la calidad del software es la aplicacin de mtricas, aplicadas a un software determinado, garantizando calidad as, como lo afirma Pressman: La garanta de calidad del software, es una actividad de proteccin que se aplica a lo largo de todo el proceso de Ingeniera del software Todos los elementos anteriormente enumerados indican herramientas que se deben tener en cuenta al momento de desarrollar un software, agrupando en una definicin estos elementos se afirma que : Un software debe estar desarrollado en concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo software, si cumple los aspectos sealados se puede afirmar que se posee un software de calidad.

Prepar: Ing. Jos Luis Duch Gary.

14

Teniendo en cuenta esto, se puede afirmar que: 1. Los requisitos del software son la base de las medidas de la calidad. 2. Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la Ingeniera del software, si no se distinguen esos criterios no habr calidad en el software. 3. Existe un conjunto de requisitos implcitos que a menudo no se mencionan, si no se alcanzan estos requerimientos podra la calidad quedar en entredicho. Los requisitos son llamados por los usuarios finales elementos obvios, los cuales el diseador no debe dejar pasar sin explicacin. Para estar seguros de las anteriores afirmaciones se tienen en cuenta factores que se pueden medir, estos son llamados factores de calidad. Los factores de calidad se agrupan en dos bloques de la siguiente manera: 1. Factores que pueden ser medidos directamente (errores, lneas, tiempo) 2. Factores que slo pueden ser medidos indirectamente (facilidad de uso, mantenimiento) En si uno de los propsitos de la ingeniera de software es producir software de calidad. La garanta de calidad del software es una actividad de proteccin que se aplica a lo largo de todo del proceso de ingeniera. La garanta de calidad de software combina procedimientos para la aplicacin efectiva de los mtodos y herramientas, las revisiones tcnicas formales, las tcnicas y estrategias de prueba, los procedimientos de control de cambios, los procedimientos de garanta de ajuste a los estndares y los mecanismos de medida e informacin.

2.7.1 CONCEPTOS DE CALIDAD.

Nunca dos cosas son iguales este fenmeno de variacin entre muestras, se aplica a todos los productos. Todas las piezas fabricadas segn un proceso de ingeniera exhiben alguna variacin. El control de la variacin es el centro del control de calidad. Se desea minimizar la variacin. Un fabricante quiere reducir la variacin entre los productos que se fabrican cuando estos se fabrican en serie. De un proyecto a otro, queremos reducir la diferencia entre los recursos necesarios planificados para terminar un proyecto y los recursos reales utilizados, entre los que incluye personal equipo y tiempo. En general nos gustara asegurarnos que nuestro programa de aplicacin de pruebas abarque un porcentaje conocido del software de una entrega a otra. No solo queremos reducir el nmero de defectos que se extraen para ese campo, sino tambin nos gustara asegurarnos que los errores ocultos tambin se reducen de una entrega a otra.

Prepar: Ing. Jos Luis Duch Gary.

15

1. Calidad. Se puede definir calidad como una caracterstica o atributo de algo. Como un atributo de un artculo, la calidad se refiere a las caractersticas mensurables: cosas que se pueden comparar con estndares. Sin embargo el software en su gran extensin, como entidad intelectual, es ms difcil de caracterizar que los objetos fsicos. La calidad del diseo se refiere a las caractersticas que especifican los ingenieros de software para un artculo. La calidad de concordancia es el grado de cumplimiento de las especificaciones de diseo durante su realizacin. 2. Control de calidad. El control de calidad es una serie de inspecciones, revisiones y pruebas utilizadas a lo largo del ciclo de desarrollo del software para asegurar que cumple con los requisitos asignados. El control de calidad incluye un bucle de realimentacin que creo el producto. Este enfoque ve el control de calidad como parte del proceso de fabricacin. 3. Garanta de calidad. Esta consiste en la auditoria y las funciones de informacin de administracin. Su objetivo en informar a la administracin de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms profunda y segura con respecto a lo que se pide del producto. 1. - Los requisitos del software son la base de medidas de calidad. La falta de concordancia con los requisitos anteriores es una falta de calidad. 2.-Los estndares especificados definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. 3. -Existe un conjunto de requisitos implcitos que a menudo no se mencionan. Actividades para la garanta de calidad de software. Estas comprenden una gran variedad de tareas asociadas con dos constitutivos diferentes los ingenieros de software y un grupo de SQA que tiene la responsabilidad de llevar a cabo la garanta de calidad. Los ingenieros afrontan la calidad aplicando mtodos tcnicos y medidas en el desarrollo del software y el grupo de la SQA las reglas para ayudar al equipo en la consecucin de un producto final de calidad. Participacin en el desarrollo de la descripcin del proceso de software. Revisin de las actividades de Ingeniera del software para verificar su ajuste al proceso de software definido. Auditoria de los productos para verificar el ajuste con los requisitos definidos.

Prepar: Ing. Jos Luis Duch Gary.

16

Asegurar que las desviaciones de los trabajos y los productos se documenten y Registrar lo que no se ajuste los requisitos. Revisiones tcnicas formales. Es una actividad de garanta de calidad que es llevada a cabo por los ingenieros. Sus objetivos son: Descubrir errores en la funcin, la lgica o la implementacin. Verificar que el software bajo revisin alcanza sus requisitos. Garantizar que a sido representado de acuerdo con ciertos estndares predefinidos. Conseguir un software desarrollado de forma uniforme. Hacer que los proyectos sean manejables. Directrices para la revisin. Revisar el producto, no al productor. Fijar una agenda y mantenerla. Limitar el debate y las impugnaciones. Enunciar reas de problemas, pero no intentar resolver cualquiera que se manifieste. Tomar notas escritas. Limitar el nmero de participantes e insistir en la preparacin anticipada. Desarrollar una lista de comprobacin para cada producto. Disponer de recursos. Llevar a cabo un buen entrenamiento de todos los revisores. Repasas las revisiones anteriores. 4. El costo de la calidad. Este incluye todos los costos asociados a la bsqueda de la calidad o en las actividades relacionadas en la obtencin de la misma. Sirve para proporcionar una lnea base del control actual de calidad, para buscar oportunidades para reducir este costo y para proporcionar una base normalizada de comparacin misma que siempre tiene un precio y una vez echo esto tenemos los datos necesarios para evaluar el lugar donde hay oportunidades de mejorar nuestros precios. Los costos de calidad se pueden dividir en costos asociados con la prevencin, la evaluacin y los fallos. Entre los costos de prevencin se incluyen: Planificacin de calidad. Revisin tcnicas formales. Prepar: Ing. Jos Luis Duch Gary.

17

Equipo de pruebas. Formacin. Entre los costos de evaluacin estn: Inspeccin en el proceso y entre procesos. Aplicacin de casos de prueba. Los costos de fallos externos incluyen: Resolucin de quejas. Devolucin y sustitucin del producto. Soporte de lneas de ayuda. 4. Revisiones de software. Sirven para detectar defectos que puedan ser eliminados o purificar las actividades que suceden como resultado del anlisis, el diseo y la codificacin. Una revisin tcnica formal es el filtro ms efectivo desde el punto de vista de garanta de calidad. 5. Impacto de los defectos del software sobre el costo. Implica un problema de calidad que es descubierto despus de entregar el software a los usuarios finales. Su objetivo es encontrar errores durante el proceso de forma que se convierta en defectos despus de la entrega del software descubriendo errores que al principio para que no se propague al paso siguiente del proceso del software. 6. Amplificacin y eliminacin de defectos. Se usa para ilustrar la generacin y deteccin de errores durante los pasos de diseo preliminar, diseo detallado y codificacin del proceso. Durante cada paso se pueden generar errores que pasan inadvertidos. La revisin puede fallar al descubrir nuevos errores y errores de pasos anteriores. Para llevar acabo revisiones se debe dedicar tiempo y esfuerzo para que luego encuentre benficos de costo demostrable. 5. Anlisis de riesgos y seguridad del software. Esta es una garanta de calidad del software que se centra en la identificacin y evaluacin de los riesgos potenciales que pueden producir un impacto negativo en el software y hacer que falle el sistema completo. Se puede dirigir un proceso de anlisis y modelacin identificando los riesgos y clasificndolos por su importancia y su grado de riesgo.

Prepar: Ing. Jos Luis Duch Gary.

18

Algunas tcnicas usadas son: El anlisis del rbol de fallos. La lgica de tiempo real. Cuando se han identificado y analizado los riesgos, se pueden especificar requisitos del software relacionados con su seguridad. La especificacin puede contener una lista de sucesos no deseables y las respuestas del sistema deseado a dichos sucesos.

2.7.2 EL PLAN SQA.

Proporciona un mapa para institucionalizar la garanta de calidad del software. Uno de los esquemas recomendado es: 1. Propsito del plan. 2. Referencia. 3. Administracin. a. Organizacin. b. Tareas. c. Responsabilidad. 4. Documentacin. a. Propsito. b. Documentos requeridos. c. Otros documentos. 5. Estndares, prcticas y convenciones. a. Propsito. b. Convenciones. 6. Revisiones y auditorias. a. Propsito. b. Requisitos de revisin. 7. Prueba. 8. Informacin sobre problemas y accin correctora. 9. Herramientas tcnicas y metodologas. 10. Control de cdigos. 11. Control de medios. 12. Control de distribucin. 13. Recopilacin de registros.

Prepar: Ing. Jos Luis Duch Gary.

19

14. Formacin. 15. Administracin de riesgos.

2.7.3 LOS ESTNDARES DE CALIDAD ISO 9000.

Un sistema de garanta de calidad se puede definir como la estructura organizativa, responsabilidades, procedimientos, procesos y recursos que permitan implementar el enfoque de calidad ISO. ISO los define como una metodologa que pueden aplicarse a cualquier negocio con independencia de los productos o servicios ofrecidos.

2.7.3.1 El enfoque ISO 9001.

Este es un enfoque de calidad que se aplica a la Ingeniera del software con 20 requisitos que deben estar presentes en un sistema, estos son: Responsabilidad de la administracin. Sistema de calidad. Revisin de contrato. Control de diseo. Control de datos y documento. Compras. Control del producto. Posibilidad de seguimiento del producto. Control del proceso. Inspeccin y prueba. Control de inspeccin. Inspeccin y estado de prueba. Control de producto no aceptado. Accin correctora y preventiva. Tratamiento, almacenamiento, empaquetamiento, preservacin y entrega. Control de registros de calidad. Auditorias internas de calidad. Formacin. Servicios. Tcnicas estadsticas.

Prepar: Ing. Jos Luis Duch Gary.

20

Watts Humprey en su libro: Administrando el proceso del software, dijo: La mayora de los errores ms desastrosos ocurren ms frecuentemente cuando el proyecto est bajo presin. Esto es causado principalmente por una perdida de control. Mientras los programadores invariablemente intentan documentar sus cambios cuando tengan tiempo, es extremadamente difcil recordar precisamente que se hizo y porque. Los sistemas automatizados que manejan peticiones de cambios, reportes de problemas, proveen una excelente plataforma para registrar el estatus del proyecto.

2.8 FACTORES DE CALIDAD Y PRODUCTIVIDAD.

La descripcin que se hace de los factores que influyen en un software de calidad se basa 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. Roger Pressman describe similares factores de calidad agrupados en tres grupos: calidad en operacin, calidad en revisin y calidad en transicin. 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. A continuacin se presentan los factores de calidad de acuerdo a los criterios dados por Dunn. 1. Confiabilidad. Este trmino es necesario separarlo en varios elementos que permiten darle al software el matiz de fiable. Sus componentes son: Completitud. Consistencia y precisin. Solidez. Simplicidad. Calidad en los procesos de desarrollo. Seguridad y Verificabilidad, estas dos ltimas que se determinan con el sistema en uso. 2. Usabilidad. Si bien es cierto que la confiabilidad es un factor muy importante en la calidad del software tambin lo es el hecho de que es necesario considerar otros factores como los que se mencionan en esta seccin puesto que de nada sirve un software que funcione correcta y confiablemente si el usuario prefiere no utilizarlo. Exactitud de los procesos.

Prepar: Ing. Jos Luis Duch Gary.

21

Claridad y exactitud de la documentacin. Completitud. Eficiencia y verificabilidad del software. Claridad y amigabilidad de la interfaz. 3. Mantenibilidad. Este aspecto de calidad involucra los elementos que simplifican la labor de prevencin, correccin o ampliacin del cdigo del programa. Retomar un cdigo escrito meses antes es un trabajo dispendioso y agobiante, en especial cuando las aplicaciones no cuentan con la caracterstica a la cual aqu se hace referencia. Se pueden considerar como atributos de este aspecto: Exactitud y claridad en la documentacin. Modularidad acoplamiento. Facilidad de lectura. Simplicidad. 4. Portabilidad. Es la capacidad que posee un sistema de informacin que le permite funcionar en diferentes plataformas ya sean hardware o de software. A continuacin se describen cada uno de los aspectos de calidad mencionados: 5. Calidad en los procesos de desarrollo. Se resume en la frase bien planeado y cuidadosamente ejecutado. Este aspecto asegura la confiabilidad, puesto que el plan que se realice para desarrollar el sistema, debe incluir pruebas bien seleccionadas que evalen la confiabilidad del programa en cualquier situacin. 6. Claridad y amigabilidad de la interfaz De igual forma la interfaz debe ser clara y agradable al usuario, las interfaces complejas son causa de la no utilizacin de los sistemas de informacin. 7. Claridad y exactitud de la documentacin. Hay que anotar que toda aplicacin requiere de una documentacin suficientemente clara con el fin de que cualquier persona con conocimientos bsicos en computacin pueda aprender la forma de operacin sin que requiera la asesora de los desarrolladores o conocedores de la herramienta, a menos que se trate de eventualidades donde realmente sea necesario consultar al proveedor. 8. Completitud o adecuacin.

Prepar: Ing. Jos Luis Duch Gary.

22

Se refiere a que los resultados de operaciones sean acordes al comportamiento del mundo real desde todos los estados y condiciones permitidos por la aplicacin, es decir, el programa debe reflejar la realidad. Un programa es inconsistente si presenta respuestas errneas en algunos casos. Una mala especificacin de rangos en un dominio sobre los cuales realizan diferentes operaciones matemticas puede llevar a que algunos clculos se realicen dentro de lmites inapropiados, obtenindose resultados errneos. Otro caso de inconsistencia se presenta cuando ocurren eventos que paran abruptamente la ejecucin del programa, slo un sistema de calidad podr conservar datos consistentes despus de una falla. 9. Eficiencia y verificabilidad del software. Otro aspecto que no debe pasar por alto es el de la verificablidad, puesto que es imprescindible contar con los requerimientos, y sobretodo en aquellos sistemas donde se obtengan resultados que no sean visibles. 10. Exactitud de los procesos. Un programa no ser utilizado por un usuario si sus resultados no son exactos. Tampoco se puede garantizar el uso de un programa que no presta las utilidades que el usuario requiere, es decir, que sea incompleto. Adems, un programa ineficiente que no cumpla con los requerimientos de tiempo, memoria o flexibilidad no podr satisfacer las expectativas de quienes lo utilizan. 11. Robustez o solidez. Se refiere a la capacidad del software de defenderse de las acciones anormales que llevan al sistema a un estado no deseado o por lo menos no previsto, causando un comportamiento inesperado, indeseado y posiblemente errneo. El software de hoy, debe estar en capacidad de analizar los datos que recibe para hacer cumplir requerimientos o condiciones del software y enfrentar de la mejor manera los errores cometidos por un usuario al utilizar la aplicacin. Es importante resaltar, que la solidez no siempre es generada por la digitacin inapropiada del usuario, sino tambin por un mal procesamiento o un mal encadenamiento de procesos. El resultado de un proceso, aunque sea correcto, puede estar fuera de los lmites permitidos en los parmetros del mdulo que lo recibe y si este mdulo no controla los parmetros que le entran caer en un estado inesperado. 12. Seguridad y auditabilidad. Son importantes, puesto que un usuario no puede confiar en los datos de un sistema que no le ayude a controlar el acceso de personas no autorizadas o a detectar errores de operacin en los que se introducen y generan datos errneos. 13. Simplicidad. Promueve la utilizacin de estructuras de fcil manipulacin con el fin de evitar que el programador se aleje del problema que desea resolver. Adems, se reduce la probabilidad de cometer errores. As que, no es aconsejable hacer uso de estructuras complejas a menos que se necesite cumplir con requerimientos de vital importancia tales como tiempos mximos de proceso u otros similares.

Prepar: Ing. Jos Luis Duch Gary.

23

Otro autor que contribuye con el aspecto de las medidas en el software es McCall, l y sus colegas proponen tres factores de calidad a saber: Factor 1. Caractersticas operativas, relacionadas con las operaciones del producto. Correccin. Fiabilidad. Eficiencia. Integridad. Facilidad de uso. Factor 2. Capacidad de soportar cambios, relacionado con la revisin del producto. Facilidad de mantenimiento. Flexibilidad. Facilidad de prueba. Factor 3. Adaptabilidad, relacionado con la transicin del producto. Portabilidad. Reusabilidad: Reutilizabilidad. Interoperabilidad. McCall propone para las mtricas asociadas al software un nivel de evaluacin entre cero (0) y diez (10) como medidas. Adems, aclara que las mtricas y la evaluacin son procesos subjetivos. Los elementos que se pueden tener en cuenta para la evaluacin son: Auto documentacin: Que el archivo ejecutable entregue documentacin significativa. Completitud: Se han implementado las funciones requeridas. Concisin: Compacto en lneas de cdigo. Consistencia: Uso de mtodos de diseo, tcnicas de documentacin a travs del desarrollo. Eficiencia en la ejecucin: Medida del tiempo de ejecucin. Estandarizacin de los datos: Manejar tipos abstractos de datos (TAD) a travs del programa. Exactitud: Preciso en clculos y control. Facilidad de auditoria: Comprobar la conformidad con los estndares. Facilidad de expansin: Facilidad de ampliar diseos arquitectnicos, de datos, o procedimiento. Facilidad de operacin: Facilidad de traza: Realizar ingeniera inversa. Que tan fcil es devolverme a los requerimientos. Formacin: Debe poseer un buen sistema de ayudas para que los nuevos usuarios apliquen el sistema. Generalidad: Amplitud de aplicacin potencial de los componentes del programa. Es decir, los mdulos creados pueden ser tiles en otras aplicaciones del mismo tipo, o aplicaciones que manejen tipos de datos semejantes.

Prepar: Ing. Jos Luis Duch Gary.

24

Independencia del hardware: Que los diseos sean independientes de la mquina o mquinas que se tienen destinadas para el software. Independencia del sistema software: Hasta donde el programa es independiente de la plataforma de desarrollo. Instrumentacin: En que grado el programa muestra funcionamiento e identifica errores. Modularidad: Divisin del programa en componentes funcionales, .acoplamiento, cohesin. Normalizacin de las comunicaciones: Que tanto se usan estndares, interfaces, protocolos, entre otros elementos que pueden ser de importancia. Seguridad: Simplicidad: El sistema de informacin debe ser fcil de entender. Tolerancia de errores: Que tanto se pierde al ocurrir un dao grave.

Prepar: Ing. Jos Luis Duch Gary.

25

TABLA DE CONTENIDO.

2.1 2.2

Definicin De Ingeniera del software. ............................................................ 4 Historia de la ingeniera del software.............................................................. 4

2.3 2.4 2.5 2.6 2.7

Caractersticas del software. ........................................................................... 6 Mitos del software ............................................................................................ 9 Capas de la ingeniera de software. .............................................................. 12 El proceso de software. ................................................................................. 13 Calidad del software....................................................................................... 14

2.8

Factores de calidad y productividad............................................................. 21

Prepar: Ing. Jos Luis Duch Gary.

26