Pagina -> 1

DOSIER
ESCUELA INDUSTRIAL PEDRO DOMINGO MURILLO INFORMATICA INDUSTRIAL DOCENTE : LIC. ADRIAN QUISBERT VILELA MATERIA: INF-266 INGENIERIA DE SOFTWARE

Pagina -> 2

UNIDAD I. Introduccin a la Ingeniera del Software.

Introduccin. 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 (ordenadores 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 ordenadores de las dcadas pasadas est hoy disponible en un miniordenador 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 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 ordenadores, 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 costes 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. 1.2.- Evolucin de la industria del software. 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 coste 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

Pagina -> 3

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 costes 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 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 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 costes 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 costes en el desarrollo de sistemas informticos ha cambiado drsticamente. El software, en lugar del hardware, es el elemento principal del coste. 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 coste ? Por qu no es posible encontrar todos los errores antes de entregar el software al cliente ? 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. 1.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.

Pagina -> 4

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: 1.- El software se desarrolla, no se fabrica en sentido estricto. 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 coste del producto acaba dependiendo exclusivamente del coste de los materiales empleados y del propio proceso de produccin, reducindose la repercusin en el coste 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 coste, 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. El diferente impacto que tiene la ingeniera en el desarrollo de productos hardware y software puede verse en el siguiente ejemplo: Produccin Coste unitario / Coste unitario / Ingeniera o Desarrollo 100 unidades 100.000 unidades Hardware 1000 50 c.u. 60 50.01 Software 1000 2000 30 0.03 Tabla 1.1. Influencia de los costes de ingeniera en el coste total del producto Los costes 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 coste 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.
n d ic e d e fa llo

tie m p o

Pagina -> 5

Figura. 1.1. Curva de fallos del hardware 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.
n d ic e d e fa llo

tie m p o

Figura 1.2. Curva ideal de fallos del software Pero esto no es ms que una simplificacin del modelo real de fallos de un producto 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. 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.
n d ic e d e fa llo

tie m p o

Figura 1.3. Curva real de fallos del software 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

Pagina -> 6

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

Pagina -> 7

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: Definicin 1. 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 Definicin 2. [Ingeniera de Software es] el establecimiento y uso de principios de ingeniera adecuados para obtener econmicamente software que sea confiable y trabaje eficientemente en mquinas reales.[Fritz Bauer] Definicin 3. Es la disciplina tecnolgica y administrativa dedicada a la produccin sistemtica de productos de Software, que son desarrollados y modificados a tiempo y dentro de un presupuesto definido (Fairley). Es el enfoque sistemtico para el desarrollo, operacin, mantenimiento y eliminacin del Software. Objetivo de las organizaciones fabricantes de software: producir software de buena calidad de una manera sistemtica y previsible. La ingeniera del software abarca un conjunto de tres elementos clave: mtodos, herramientas y procedimientos, que faciliten al gestor el control el proceso de desarrollo y suministren a los implementadores bases para construir de forma productiva software de alta calidad. 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. 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). Los procedimientos definen 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.

Pagina -> 8

Por otra parte la Ingeniera de Software tiene algunas diferencias. La Ingeniera de Software no es Ciencia Informtica Un cientfico construye con el objetivo de aprender; un ingeniero aprende con el objetivo de construir. La distincin entre ingeniera y ciencia en el software es el mismo que en otras disciplinas: Los cientficos aprenden lo que es verdadero, como verificar hiptesis y como extender el conocimiento en su campo. Los ingenieros aprenden lo que es verdadero, lo que es til y como aplicar conocimiento bien entendido para resolver problemas prcticos. Cientficos Conocimientos enfocados y especializados. Reportan bsicamente a sus colegas cientficos. No necesitan licencia. Ingenieros Conocimientos comprobados, efectivos y confiables de mbito mas general. Se necesita un amplio entendimiento de todos los factores que intervienen en el desarrollo del producto. Responsabilidad con el pblico. Generalmente necesitan licencia para ejercer. Segn el Instituto de Ingenieros Elctricos y Electrnicos IEEE: La Ingeniera de Software es la aplicacin de un enfoque sistemtico, disciplinado, cuantificable al desarrollo, operacin y mantenimiento del software, o sea, la aplicacin de ingeniera al software. Peculiaridades de la Ingeniera de Software El producto software es enteramente conceptual. No tiene propiedades fsicas como peso, color o voltaje, y, en consecuencia no est sujeto a leyes fsicas o elctricas. Su naturaleza conceptual crea una distancia intelectual entre el software y el problema que el software resuelve. Difcil para una persona que entiende el problema entender el sistema software que lo resuelve. Para probar es necesario disponer de un sistema fsico. El mantenimiento no es slo una substitucin de componentes. reas de Conocimiento En el mbito acadmico, especficamente en la docencia Universitaria, hay cinco reas de conocimiento y capacidades necesarias para el Ingeniero de Software ( Lin Zucconi. Proceedings of the 8th SEI CSEE Conference on Software Engineering Education, New Orleans, March 1995): Ciencias de la Computacin, Ingeniera de Sistemas y de Software Plataformas especficas de hardware Dominio de conocimiento de la Aplicacin Habilidades personales, interpersonales, y tica Cultura empresarial 1.4.- Aplicaciones del software. El software puede aplicarse a numerosas situaciones del mundo real. En primer lugar, a todos aquellos problemas para los que se haya establecido un conjunto especfico de acciones que lleven a su resolucin (esto es, un algoritmo). En estos casos, utilizaremos lenguajes de programacin procedimentales para implementar estos algoritmos. Tambin puede aplicarse a situaciones en las que el problema puede describirse formalmente, por lo

Pagina -> 9

general en forma recursiva. En estos casos no necesitamos describir el mtodo de resolucin, es decir cmo se resuelve el problema, sino que bastar con describir en problema en s, indicando cul es la solucin deseada, y utilizaremos lenguajes declarativos para ello. Tambin puede aplicarse a problemas que los humanos resolvemos utilizando multitud de reglas heursticas posiblemente contradictorias, para lo cual utilizaremos un sistema experto e incluso para problemas de los cuales no tenemos una idea clara de cmo se resuelven, pero de los que conocemos cul es la solucin apropiada para algunos ejemplos de los datos de entrada. En este caso utilizaremos redes neuronales. En cualquier caso, es difcil establecer categoras genricas significativas para las aplicaciones del software. Conforme aumenta la complejidad del mismo se hace ms complicado establecer compartimentos ntidamente separados. No obstante la siguiente clasificacin ha venido aceptndose tradicionalmente: Software de sistemas. Est formado por todos aquellos programas cuya finalidad es servir al desarrollo o al funcionamiento de otros programas. Estos programas son muy variados: editores, compiladores, sistemas operativos, entornos grficos, programas de telecomunicaciones, etc. pero se caracterizan por estar muy prximos al hardware, por ser utilizados concurrentemente por numerosos usuarios y por tratarse de programas de amplia difusin, no estando diseados normalmente a medida. Esto permite un mayor esfuerzo en su diseo y optimizacin, pero tambin les obliga a ser muy fiables, cumpliendo estrictamente las especificaciones para las que fueron creados. Software de tiempo real. Esta formado por todos aquellos programas que miden, analizan y controlan los sucesos del mundo real a medida que ocurren, debiendo reaccionar de forma correcta a los estmulos de entrada en un tiempo mximo prefijado. Deben, por tanto, cumplir unos requisitos temporales muy estrictos y, dado que los procesos que controlan pueden ser potencialmente peligrosos, tienen que ser fiables y tolerantes a fallos. Por otro lado, no suelen ser muy complejos y precisan de poca interaccin con el usuario. Software de gestin. El procesamiento de informacin de gestin constituye, casi desde los inicios de la informtica la mayor de las reas de aplicacin de los ordenadores. Estos programas utilizan grandes cantidades de informacin almacenadas en bases de datos con objeto de facilitar las transacciones comerciales o la toma de decisiones. Adems de las tareas convencionales de procesamiento de datos, en las que el tiempo de procesamiento no es crtico y los errores pueden ser corregidos a posteriori, incluyen programas interactivos que sirven de soporte a transacciones comerciales. Software cientfico y de ingeniera. Otro de los campos clsicos de aplicacin de la informtica. Se encarga de realizar complejos clculos sobre datos numricos de todo tipo. En este caso la correccin y exactitud de las operaciones que realizan es uno de los requisitos bsicos que deben de cumplir. El campo del software cientfico y de ingeniera se ha visto ampliado ltimamente con el desarrollo de los sistemas de diseo, ingeniera y fabricacin asistida por ordenador (CAD, CAE y CAM), los simuladores grficos y otras aplicaciones interactivas que lo acercan ms al software de tiempo real e incluso al software de sistemas. Software de ordenadores personales. El uso de ordenadores personales y de uso domstico se ha generalizado a lo largo de la pasada dcada. Aplicaciones tpicas son los procesadores de textos, las hojas de clculo, bases de datos, aplicaciones grficas, juegos, etc. Son productos de amplia difusin orientados a usuarios no profesionales, por lo que entre sus requisitos se encuentran la facilidad de uso y el bajo coste.

Pagina -> 10

Software empotrado. Software empotrado es aquel que va instalado en otros productos industriales, como por ejemplo la electrnica de consumo, dotando a estos productos de un grado de inteligencia cada vez mayor. Se aplica a todo tipo de productos, desde un vdeo domstico hasta un misil con cabeza atmica, pasando por algunos sistemas de control de los automviles, y realiza funciones muy diversas, que pueden ir desde complicados clculos en tiempo real a sencillas interacciones con el usuario facilitando el manejo del aparato que los incorpora. Comparten caractersticas con el software de sistemas, el software de tiempo real, el software de ingeniera y cientfico y el software de ordenadores personales. Software de inteligencia artificial. El software basado en lenguajes procedmentales es til para realizar de forma rpida y fiable operaciones que para el ser humano son tediosas e incluso inabordables. Sin embargo, es difcilmente aplicable a problemas que requieran la aplicacin de funciones intelectuales ms elevadas, por triviales que nos puedan parecer. El software de inteligencia artificial trata de dar respuesta a estas deficiencias, basndose en el uso de lenguajes declarativos, sistemas expertos y redes neuronales. Como vemos, el software permite aplicaciones muy diversas, pero en todas ellas podemos encontrar algo en comn: el objetivo es que el software desempee una determinada funcin, y adems, debe hacerlo cumpliendo una serie de requisitos. Esos pueden ser muy variados: correccin, fiabilidad, respuesta en un tiempo determinado, facilidad de uso, bajo coste, etc., pero siempre existen y no podemos olvidarnos de ellos a la hora de desarrollar el software. 1.5. Problemas del software. Hemos hablado de una crisis del software. Sin embargo, por crisis entendemos normalmente un estado pasajero de inestabilidad, que tiene como resultado un cambio de estado del sistema o una vuelta al estado inicial, en caso de que se tomen las medidas para superarla. Teniendo en cuenta esto, el software, ms que padecer una crisis podramos decir que padece una enfermedad crnica. Los problemas que surgieron cuando se empez a desarrollar software de una cierta complejidad siguen existiendo actualmente, sin que se haya avanzado mucho en los intentos de solucionarlos. Estos problemas son causados por las propias caractersticas del software y por los errores cometidos por quienes intervienen en su produccin. Entre ellos podemos citar: La planificacin y la estimacin de costes son muy imprecisas. A la hora de abordar un proyecto de una cierta complejidad, sea en el mbito que sea, es frecuente que surjan imprevistos que no estaban recogidos en la planificacin inicial, y como consecuencia de estos imprevistos se producir una desviacin en los costes del proyecto. Sin embargo, en el desarrollo de software lo ms frecuente es que la planificacin sea prcticamente inexistente, y que nunca se revise durante el desarrollo del proyecto. Sin una planificacin detallada es totalmente imposible hacer una estimacin de costes que tenga alguna posibilidad de cumplirse, y tampoco se pueden identificar las tareas conflictivas que pueden desviarnos de los costes previstos. Entre las causas de este problema podemos citar: No se recogen datos sobre el desarrollo de proyectos anteriores, con lo que no se acumula experiencia que pueda ser utilizada en la planificacin de nuevos proyectos. Los gestores de los proyectos no estn especializados en la produccin de software. Tradicionalmente, los responsables del desarrollo del software han sido ejecutivos de nivel medio y alto sin conocimientos de informtica, siguiendo el principio de Un buen gestor puede gestionar cualquier proyecto. Esto es cierto,

Pagina -> 11

pero no cabe duda de que tambin es necesario conocer las caractersticas especficas del software, aprender las tcnicas que se aplican en su desarrollo y conocer una tecnologa que evoluciona continuamente. La productividad es baja. Los proyectos software tienen, por lo general, una duracin mucho mayor a la esperada. Como consecuencia de esto los costes se disparan y la productividad y los beneficios disminuyen. Uno de los factores que influyen en esto, es la falta de unos propsitos claros o realistas a la hora de comenzar el proyecto. La mayora del software se desarrolla a partir de una especificaciones ambiguas o incorrectas, y no existe apenas comunicacin con el cliente hasta la entrega del producto. Debido a esto son muy frecuentes las modificaciones de las especificaciones sobre la marcha o los cambios de ltima hora, despus de la entrega al cliente. No se realiza un estudio detallado del impacto de estos cambios y la complejidad interna de las aplicaciones crece hasta que se hacen virtualmente imposibles de mantener y cada nueva modificacin, por pequea que sea, es ms costosa, y puede provocar el fallo de todo el sistema. Debido a la falta de documentacin sobre cmo se ha desarrollado el producto o a que las sucesivas modificaciones - tambin indocumentadas - han desvirtuado totalmente el diseo inicial, el mantenimiento de software puede llegar a ser una tarea imposible de realizar, pudiendo llevar ms tiempo el realizar una modificacin sobre el programa ya escrito que analizarlo y desarrollarlo entero de nuevo. La calidad es mala. Como consecuencia de que las especificaciones son ambiguas o incluso incorrectas, y de que no se realizan pruebas exhaustivas, el software contiene numerosos errores cuando se entrega al cliente. Estos errores producen un fuerte incremento de costes durante el mantenimiento del producto, cuando ya se esperaba que el proyecto estuviese acabado. Slo recientemente se ha empezado a tener en cuenta la importancia de la prueba sistemtica y completa, y han empezado a surgir conceptos como la fiabilidad y la garanta de calidad. El cliente queda insatisfecho. Debido al poco tiempo e inters que se dedican al anlisis de requisitos y a la especificacin del proyecto, a la falta de comunicacin durante el desarrollo y a la existencia de numerosos errores en el producto que se entrega, los clientes suelen quedar muy poco satisfechos de los resultados. Consecuencia de esto es que las aplicaciones tengan que ser diseadas y desarrolladas de nuevo, que nunca lleguen a utilizarse o que se produzca con frecuencia un cambio de proveedor a la hora de abordar un nuevo proyecto. Crisis de Software (mitos de la ingeniera) MITOS DEL SOFTWARE Mitos de gestin Tenemos ya un libro lleno de estndares y procedimientos para construir software. No es suficiente? Nuestra gente dispone de las herramientas de desarrollo de software ms avanzada, les compraremos los computadores ms nuevos.

Pagina -> 12

Si fallamos en la planificacin, aadimos ms programadores para recuperar el tiempo perdido.

Mitos del cliente Una declaracin general de objetivos es suficiente para empezar los programas. Los detalles luego. Los requisitos del proyecto cambian continuamente pero los cambios se acomodan fcilmente. El software es flexible.

Mitos de los desarrolladores Apenas escribimos el programa y hacemos que funcione nuestro trabajo ha terminado. Hasta que no tengo el programa "ejecutndose" realmente no tengo forma de comprobar su calidad. Lo nico que se entrega al terminar el proyecto es el programa funcionando.

Problemas del software Insatisfaccin requerimientos del cliente por falta de una buena definicin de los

De cada 6 proyectos de software 2 son abandonados US$16.000 millones son gastados en sistemas de software que nunca sern utilizados Aeropuerto de Denver: Sistema previsto para octubre de 1993. EN junio de 1994 no estaba funcionando y el costo diario en intereses era de US$1.1 millones No se tienen datos histricos sobre el proceso de Desarrollo de Software. No se pueden hacer buenas estimaciones. No se puede evaluar con precisin la eficacia de las nuevas herramientas, tcnicas o estndares. Tecnologa de la informacin representa el 40% de los gastos de USA.

Pagina -> 13

Mercado de ambientes de desarrollo de software: >US$5000 millones Costo en recursos humanos: >US $250.000 millones

Que se puede esperar de la industria de software Creacin de empleo calificado generacin de exportaciones no tradicionales de alto valor agregado Facilitar el proceso de modernizacin de las economas nacionales

METAS DE LA INGENIERIA DE SOFTWARE Mejorar la calidad de los procesos de fabricacin de software. Mejorar la calidad de los productos de Software. Aumentar la productividad y satisfaccin profesional de los ingenieros de esta disciplina.

Pagina -> 14

UNIDAD 2. MODELOS DE DESARROLLO DE SOFTWARE 2.1.- Concepto de ciclo de vida. Por ciclo de vida, se entiende la sucesin de etapas por las que pasa el software desde que un nuevo proyecto es concebido hasta que se deja de usar. Cada una de estas etapas lleva asociada una serie de tareas que deben realizarse, y una serie de documentos (en sentido amplio: software) que sern la salida de cada una de estas etapas y servirn de entrada en la etapa siguiente. Existen diversos modelos de ciclo de vida, es decir, diversas formas de ver el proceso de desarrollo de software, y cada uno de ellos va asociado a un paradigma de la ingeniera del software, es decir, a una serie de mtodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto. En este tema veremos algunos de los principales modelos de ciclo de vida. La eleccin de un paradigma u otro se realiza de acuerdo con la naturaleza del proyecto y de la aplicacin, los mtodos a usar y los controles y entregas requeridos. 2.2.- El ciclo de vida en cascada ( o ciclo de vida clsico). Este paradigma es el ms antiguo de los empleados en la IS y se desarroll a partir del ciclo convencional de una ingeniera. No hay que olvidar que la IS surgi como copia de otras ingenieras, especialmente de las del hardware, para dar solucin a los problemas ms comunes que aparecan al desarrollar sistemas de software complejos. Es un ciclo de vida en sentido amplio, que incluye no slo las etapas de ingeniera sino toda la vida del producto: las pruebas, el uso (la vida til del software) y el mantenimiento, hasta que llega el momento de sustituirlo (Figura 2.1)

Pagina -> 15

I n g e n ie ra d e l Sis te m a An lis is Dis e o Co d ific a c i n Prue b a U tiliza c i n

M a n te n im ie n to Sus tituc i n

Figura 2.1. Ciclo de vida en cascada. El ciclo de vida en cascada exige un enfoque sistemtico y secuencial del desarrollo de software, que comienza en el nivel de la ingeniera de sistemas y avanza a travs de fases secuenciales sucesivas. Estas fases son las siguientes: Anlisis del sistema. El software es siempre parte de un sistema mayor, por lo que siempre va a interrelacionarse con otros elementos, ya sean hardware, mquinas o personas. Por esto, el primer paso del ciclo de vida de un proyecto consiste en un anlisis de las caractersticas y el comportamiento del sistema del cual el software va a formar parte. En el caso de que queramos construir un sistema nuevo, por ejemplo un sistema de control, deberemos analizar cules son los requisitos funciones del sistema, y luego asignaremos un subconjunto de estos requisitos y funciones al software. En el caso de un sistema ya existente (supongamos, por ejemplo, que queremos informatizar una empresa) deberemos analizar el funcionamiento de la misma, - las operaciones que se llevan a cabo en ella -, y asignaremos al software aquellas funciones que vamos a automatizar. La ingeniera del sistema comprende, por tanto, los requisitos globales a nivel del sistema, as como una cierta cantidad de anlisis y de diseo a nivel superior, es decir sin entrar en mucho detalle. Anlisis de requisitos del software. El anlisis de requisitos debe ser ms detallado para aquellos componentes del sistema que vamos a implementar mediante software. El ingeniero del software debe comprender cules son los datos que se van a manejar, cul va a ser la funcin que tiene que cumplir el software, cules son los int erfaces requeridos y cul es el rendimiento y otros requisitos no funcionales que se esperan lograr.

Pagina -> 16

Los requisitos, tanto del sistema como del software deben documentarse y revisarse con el cliente. Como resultado del la fase de anlisis, obtendremos la especificacin de requisitos del software. Diseo. El diseo se aplica a cuatro caractersticas distintas del software: la estructura de los datos, la arquitectura de las aplicaciones, la estructura interna de los programas y las interfaces. El diseo es el proceso que traduce los requisitos en una representacin del software de forma que pueda conocerse la arquitectura, funcionalidad e incluso la calidad del mismo antes de comenzar la codificacin. Al igual que el anlisis, el diseo debe documentarse y forma parte de la configuracin del software (el control de configuraciones es lo que nos permite realizar cambios en el software de forma controlada y no traumtica para el cliente). Codificacin. La codificacin consiste en la traduccin del diseo a un formato que sea comprensible para la mquina. Si el diseo es lo suficientemente detallado, la codificacin es relativamente sencilla, y puede hacerse - al menos en parte - de forma automtica, usando generadores de cdigo. Podemos observar que estas primeras fases del ciclo de vida consisten bsicamente en una traduccin: en el anlisis del sistema, los requisitos, la funcin y la estructura de este se traducen a un documento: el anlisis del sistema que est formado en parte por diagramas y en parte por descripciones en lenguaje natural. En el anlisis de requisitos se profundiza en el estudio del componente software del sistema y esto se traduce a un documento, tambin formado por diagramas y descripciones en lenguaje natural. En el diseo, los requisitos del software se traducen a una serie de diagramas que representan la estructura del sistema software, de sus datos, de sus programas y de sus interfaces. Por ltimo, en la codificacin se traducen estos diagramas de diseo a un lenguaje fuente, que luego se traduce - se compila - para obtener un programa ejecutable. Prueba. Una vez que ya tenemos el programa ejecutable, comienza la fase de pruebas. El objetivo es comprobar que no se hayan producido errores en alguna de las fases de traduccin anteriores, especialmente en la codificacin. Para ello deben probarse todas las sentencias, no slo los casos normales y todos los mdulos que forman parte del sistema. Utilizacin. Una vez superada la fase de pruebas, el software se entrega al cliente y comienza la vida til del mismo. La fase de utilizacin se solapa con las posteriores - el mantenimiento y la sustitucin - y dura hasta que el software, ya reemplazado por otro, deje de utilizarse. Mantenimiento. El software sufrir cambios a lo largo de su vida til. Estos cambios pueden ser debidos a tres causas: Que, durante la utilizacin, el cliente detecte errores en el software: los errores latentes. Que se produzcan cambios en alguno de los componentes del sistema informtico: por ejemplo cambios en la mquina, en el sistema operativo o en los perifricos. Que el cliente requiera modificaciones funcionales (normalmente ampliaciones) no contempladas en el proyecto. En cualquier caso, el mantenimiento supone volver atrs en el ciclo de vida, a las etapas de codificacin, diseo o anlisis dependiendo de la magnitud del cambio.

Pagina -> 17

El modelo en cascada, a pesar de ser lineal, contiene flujos que permiten la vuelta atrs. As, desde el mantenimiento se vuelve al anlisis, el diseo o la codificacin, y tambin desde cualquier fase se puede volver a la anterior si se detectan fallos. Estas vueltas atrs no son controladas, ni quedan explcitas en el modelo, y este es uno de los problemas que presenta este paradigma Sustitucin / Implantacin La vida del software no es ilimitada y cualquier aplicacin, por buena que sea, acaba por ser sustituida por otra ms amplia, ms rpida o ms bonita y fcil de usar. La sustitucin de un software que est funcionando por otro que acaba de ser desarrollado es una tarea que hay que planificar cuidadosamente y que hay que llevar a cabo de forma organizada. Es conveniente realizarla por fases, si esto es posible, no sustituyendo todas las aplicaciones de golpe, puesto que la sustitucin conlleva normalmente un aumento de trabajo para los usuarios, que tienen que acostumbrarse a las nuevas aplicaciones, y tambin para los implementadores, que tienen que corregir los errores que aparecen. Es necesario hacer un trasvase de la informacin que maneja el sistema viejo a la estructura y el formato requeridos por el nuevo. Adems, es conveniente mantener los dos sistemas funcionando en paralelo durante algn tiempo para comprobar que el sistema nuevo funcione correctamente y para asegurarnos el funcionamiento normal de la empresa an en el caso de que el sistema nuevo falle y tenga que volver a alguna de las fases de desarrollo. La sustitucin implica el desarrollo de programas para la interconexin de ambos sistemas, el viejo y el nuevo, y para trasvasar la informacin entre ambos, evitando la duplicacin del trabajo de las personas encargadas del proceso de datos, durante el tiempo en que ambos sistemas funcionen en paralelo. El ciclo de vida en cascada es el paradigma ms antiguo, ms conocido y ms ampliamente usado en la IS. No obstante, ha sufrido diversas crticas, debido a los problemas que se plantean al intentar aplicarlo a determinadas situaciones. Entre estos problemas estn: En realidad los proyectos no siguen un ciclo de vida estrictamente secuencial como propone el modelo. Siempre hay iteraciones. El ejemplo ms tpico es la fase de mantenimiento, que implica siempre volver a alguna de las fases anteriores, pero tambin es muy frecuente en que una fase, por ejemplo el diseo, se detecten errores que obliguen a volver a la fase anterior, el anlisis. Es difcil que se puedan establecer inicialmente todos los requisitos del sistema. Normalmente los clientes no tienen conocimiento de la importancia de la fase de anlisis o bien no han pensado en todo detalle que es lo que quieren que haga el software. Los requisitos se van aclarando y refinando a lo largo de todo el proyecto, segn se plantean dudas concretas en el diseo o la codificacin. Sin embargo, el ciclo de vida clsico requiere la definicin inicial de todos los requisitos y no es fcil acomodar en l las incertidumbres que suelen existir al comienzo de todos los proyectos. Hasta que se llega a la fase final del desarrollo: la codificacin, no se dispone de una versin operativa del programa. Como la mayor parte de los errores se detectan cuando el cliente puede probar el programa, no se detectan hasta el final del proyecto, cuando son ms costosos de corregir y ms prisa (y ms presiones) hay por que el programa se ponga definitivamente en marcha. Todos estos problemas son ciertos, pero de todas formas es mucho mejor desarrollar software siguiendo el modelo de ciclo de vida en cascada que hacerlo sin ningn tipo de guas. Adems, este modelo describe una serie de pasos genricos que son aplicables a

Pagina -> 18

cualquier otro paradigma, refirindose la mayor parte de las crticas que recibe a su carcter secuencial. 2.3.- El modelo contractual. El modelo de ciclo de vida en cascada, no nos indica nada sobre la relacin entre las diversas partes involucradas en el desarrollo de software, ni tampoco sobre los documentos que sirven de entrada y salida de cada una de las fases del proceso. Por ello, se ha propuesto el modelo contractual, que no es ms que una extensin ms detallada del modelo clsico, por los que tiene los mismos inconvenientes. Fig. 2.2. El modelo contractual (fotocopia) En este modelo, cada fase de desarrollo, ya sea el anlisis, el diseo, la implementacin, etc., es contemplada como el sujeto de un contrato entre dos partes, llamadas respectivamente el proveedor y el cliente. La finalizacin de cada fase se produce con la firma, por parte del cliente y del proveedor, de un documento contractual, (en sentido amplio: software) producido por el proveedor a partir de una solicitud de servicios que el cliente ha facilitado al inicio de la fase. En cada fase existen, por tanto, un proveedor y un cliente. El cliente realiza una peticin de servicios, expresando sus necesidades. A partir de esta peticin, el proveedor redacta un contrato de servicio, cuyos detalles se discuten con el cliente. Finalmente, se firma el contrato y se pasa a la fase siguiente, en la que el proveedor se convierte en cliente (en una especie de subcontratacin). As, en la fase de anlisis, el cliente que ha encargado el proyecto acta de cliente y el analista acta de proveedor, y esta fase termina con un acuerdo de ambos respecto a que la especificacin del sistema, redactada a partir de la definicin informal de requisitos realizada por el cliente, es satisfactoria y puede servir de contrato para formalizar la transaccin entre ambos. En la fase de diseo, el analista acta de cliente, y proporciona como peticin de servicios la especificacin. A su vez, esta fase acaba cuando el diseo realizado por el diseador es aceptado como satisfactorio y conforme con los trminos del contrato, por el analista. Y as sucesivamente. El modelo contractual, tiene la ventaja de dar un mayor rigor a la transicin entre cada una de las fases del ciclo de vida y permite determinar quin es el responsable en caso de que surjan problemas. As, el cliente es responsable de los incrementos de coste producidos por un cambio en los requisitos, puesto que pretende que se realice un servicio que no estaba previsto en el contrato, y el proveedor es responsable de los gastos ocasionados (o de aceptar una disminucin en el precio) si el producto finalmente entregado no cumple todas las condiciones del contrato, es decir, si contiene errores o se entrega con retraso. 2.4.- Uso de tcnicas de cuarta generacin. Por tcnicas de cuarta generacin se entiende un conjunto muy diverso de mtodos y herramientas que tienen por objeto el facilitar el desarrollo de software. Pero todos ellos tienen algo en comn: facilitan al que desarrolla el software el especificar algunas caractersticas del mismo a alto nivel. Luego, la herramienta genera automticamente el cdigo fuente a partir de esta especificacin. Los tipos ms habituales de generadores de cdigo cubren uno o varios de los siguientes aspectos:

Generacin de cdigo. A partir de una especificacin de los requisitos se genera

automticamente toda la aplicacin.

Generacin de pantallas. Permiten disear la pantalla dibujndola directamente,

incluyendo adems el control del cursor y la gestin de errores de los datos de entrada.

Pagina -> 19

Generacin de informes. (de forma similar a las pantallas). Gestin de entornos grficos. Proporcionan un entorno que facilita el uso de
ventanas (edicin, control del cursor, movimiento, cambio de tamao, etc.)

(derivados normalmente de SQL). Con ello no es necesario conocer la estructura de los ficheros o tablas ni de sus ndices. Esta generacin automtica permite reducir la duracin de las fases del ciclo de vida clsico, especialmente la fase de codificacin, quedando el ciclo de vida segn se indica en la figura 2.3. Al igual que en otros paradigmas, el proceso comienza con la recoleccin de requisitos, que pueden ser traducidos directamente a cdigo fuente usando un generador de cdigo. Sin embargo el problema es el mismo que se plantea en el ciclo de vida clsico: es muy difcil que se puedan establecer todos los requisitos desde el comienzo: el cliente puede no estar seguro de lo que necesita, o, aunque lo sepa, puede ser difcil expresarlo de la forma en que precisa la herramienta de cuarta generacin para poder entenderla. Si la especificacin es pequea, podemos pasar directamente del anlisis de requisitos a la generacin automtica de cdigo, sin realizar ningn tipo de diseo. Pero si la aplicacin es grande, se producirn los mismos problemas que si no usamos tcnicas de cuarta generacin: mala calidad, dificultad de mantenimiento y poca aceptacin por parte del cliente). Es necesario, por tanto, realizar un cierto grado de diseo (al menos lo que hemos llamado una estrategia de diseo, puesto que el propio generador se encarga de parte de los detalles del diseo tradicional: descomposicin modular, estructura lgica y organizacin de los ficheros, etc.).

Acceso a bases de datos utilizando lenguajes de consulta de alto nivel

Re c o le c c i n d e re q u is ito s Es tra te g ia d e Dis e o Ge n e ra c i n d e c d ig o Prue b a U tiliza c i n

M a n te n im ie n to Sus tituc i n

Figura 2.3. Ciclo de vida usando tcnicas de cuarta generacin. Las herramientas de cuarta generacin se encargan tambin de producir automticamente la documentacin del cdigo generado, pero esta documentacin es de ordinario muy parca y,

Pagina -> 20

por ello, difcil de seguir. Es necesario completarla hasta obtener una documentacin con sentido. Con respecto a las pruebas, podramos pensar que no son necesarias, supuesto que el cdigo generado es correcto, y que no contiene los tpicos errores de la codificacin manual. Pero en cualquier caso es necesaria la fase de pruebas, en primer lugar para comprobar la eficiencia del cdigo generado (la generacin automtica de los accesos a bases puede producir cdigo muy ineficiente cuando el volumen de informacin es grande (p.ej.: las distintas formas de relacionar tablas en SQL), tambin para detectar los errores en la especificacin a partir de la cual se gener el cdigo, y, por ltimo, para que el cliente compruebe si el producto final satisface sus necesidades. El resto de las fases del ciclo de vida usando estas tcnicas es igual a las del paradigma del ciclo de vida en cascada, del que este no es ms que una adaptacin a las nuevas herramientas de produccin de software. Como conclusin, podemos decir que, mediante el uso de tcnicas de cuarta generacin no se han obtenido (afortunadamente) los resultados previstos cuando estas herramientas comenzaron a desarrollarse a principios de los ochenta (estos resultados incluan la desaparicin de la codificacin manual y con ello de los programadores, e incluso de los analistas, al poder encargarse el propio cliente con unos pequeos conocimientos tcnicos de manejar el generador), puesto que los avances en procesamiento de lenguaje natural (siempre ambiguo) no han sido (ni se espera que sean en un futuro prximo) demasiado grandes ni se han desarrollado lenguajes formales de especificacin con la potencia expresiva necesaria. Sin embargo, estas herramientas consiguen reducir el tiempo de desarrollo de software, eliminando las tareas ms repetitivas y tediosas (ej. control de la entrada/salida por terminal) y aumentan la productividad de los programadores, por lo que son ampliamente utilizadas en la actualidad, especialmente si nos referimos a el acceso a bases de datos, la gestin de la entrada/salida por terminal y la generacin de informes, y forman parte de muchos de los lenguajes de programacin que se usan actualmente, sobre todo en el campo del software de gestin (ej.: Informix, Natural). No obstante, entre las crticas ms habituales estn:

No son ms fciles de utilizar que los lenguajes de tercera generacin. En

concreto, muchos de los lenguajes de especificacin que utilizan pueden considerarse como lenguajes de programacin, de un nivel algo ms alto que los anteriores, pero que no logran prescindir de la codificacin en s, sino que simplemente la disfrazan de especificacin. estar generado automticamente no pueden hacer uso de los trucos habituales para aumentar el rendimiento, que se basan en el buen conocimiento de cada caso particular. Esta crtica podra aplicarse a cualquier lenguaje de programacin con respecto al ensamblador (los programas codificados en ensamblador siempre sern ms rpidos y ms pequeos que los generados por cualquier compilador), pero la reduccin de los tiempos de desarrollo y el continuo aumento de la potencia de clculo de los ordenadores compensan ampliamente esta menor eficiencia (salvo en excepciones). herramientas de cuarta generacin estn orientadas a la generacin de informes a partir de grandes bases de datos, pero ltimamente estn surgiendo herramientas que generan esquemas de cdigo para aplicaciones de ingeniera y de tiempo real.

El cdigo fuente que producen es ineficiente.(el ejemplo de antes de SQL). Al

Slo son aplicables al software de gestin. Esto es cierto, la mayora de las

Pagina -> 21

2.5.- Construccin de prototipos. Dos de las crticas que se hacan al modelo de ciclo de vida en cascada eran que es difcil tener claros todos los requisitos del sistema al inicio del proyecto, y que no se dispone de una versin operativa del programa hasta las fases finales del desarrollo, lo que dificulta la deteccin de errores y deja tambin para el final el descubrimiento de los requisitos inadvertidos en las fases de anlisis. Para paliar estas deficiencias se ha propuesto un modelo de ciclo de vida basado en la construccin de prototipos. En primer lugar, hay que ver si el sistema que tenemos que desarrollar es un buen candidato a utilizar el paradigma de ciclo de vida de construccin de prototipos o al modelo en espiral. En general, cualquier aplicacin que presente mucha interaccin con el usuario, o que necesite algoritmos que puedan construirse de manera evolutiva, yendo de lo mas general a lo ms especfico es una buena candidata. No obstante, hay que tener en cuenta la complejidad: si la aplicacin necesita que se desarrolle una gran cantidad de cdigo para poder tener un prototipo que ensear al usuario, las ventajas de la construccin de prototipos se vern superadas por el esfuerzo de desarrollar un prototipo que al final habr que desechar o modificar mucho. Tambin hay que tener en cuenta la disposicin del cliente para probar un prototipo y sugerir modificaciones de los requisitos. Puede ser que el cliente no tenga tiempo para andar jugando o no vea las ventajas de este mtodo de desarrollo. Tambin es conveniente construir prototipos para probar la eficiencia de los algoritmos que se van a implementar, o para comprobar el rendimiento de un determinado componente del sistema, por ejemplo, una base de datos o el soporte hardware, en condiciones similares a las que existirn durante la utilizacin del sistema. Es bastante frecuente que el producto de ingeniera desarrollado presente un buen rendimiento durante la fase de pruebas realizada por los ingenieros antes de entregarlo al cliente (pruebas que se realizarn normalmente con unos pocos registros en la base de datos o un nico terminal conectado al sistema), pero que sea muy ineficiente, o incluso inviable, a la hora de almacenar o procesar el volumen real de informacin que debe manejar el cliente. En estos casos, la construccin de un prototipo de parte del sistema y la realizacin de pruebas de rendimiento, sirven para decidir, antes de empezar la fase de diseo, cul es el modelo ms adecuado de entre la gama disponible para el soporte hardware o cmo deben hacerse los accesos a la base de datos para obtener buenas respuestas en tiempo cuando la aplicacin est ya en funcionamiento. En otros casos, el prototipo servir para modelar y poder mostrar al cliente cmo va a realizarse la E/S de datos en la aplicacin, de forma que ste pueda hacerse una idea de como va a ser el sistema final, pudiendo entonces detectar deficiencias o errores en la especificacin aunque el modelo no sea ms que una cscara vaca. Segn esto un prototipo puede tener alguna de las tres formas siguientes: un prototipo, en papel o ejecutable en ordenador, que describa la interaccin hombre-mquina y los listados del sistema. un prototipo que implemente algn(os) subconjunto(s) de la funcin requerida, y que sirva para evaluar el rendimiento de un algoritmo o las necesidades de capacidad de almacenamiento y velocidad de clculo del sistema final. un programa que realice en todo o en parte la funcin deseada pero que tenga caractersticas (rendimiento, consideracin de casos particulares, etc.) que deban ser mejoradas durante el desarrollo del proyecto. La secuencia de tareas del paradigma de construccin de prototipos puede verse en la figura 2.4.

Pagina -> 22

Si se ha decidido construir un prototipo, lo primero que hay que hacer es realizar un modelo del sistema, a partir de los requisitos que ya conozcamos. En este caso no es necesario realizar una definicin completa de los requisitos, pero s es conveniente determinar al menos las reas donde ser necesaria una definicin posterior ms detallada. Luego se procede a disear el prototipo. Se tratar de un diseo rpido, centrado sobre todo en la arquitectura del sistema y la definicin de la estructura de las interfaces ms que en aspectos procedimentales de los programas: nos fijaremos ms en la forma y en la apariencia que en el contenido. A partir del diseo construiremos el prototipo. Existen herramientas especializadas en generar prototipos ejecutables a partir del diseo. Otra opcin sera utilizar tcnicas de cuarta generacin. La posibilidad ms reciente es consiste en el uso de especificaciones formales, que ltimamente tienden al desarrollo de entornos interactivos (ej. OBJ) que

Pagina -> 23

faciliten el desarrollo incremental de especificaciones y permitan la prueba de estas especificaciones. En cualquier caso, el objetivo es siempre que la codificacin sea rpida, aunque sea en detrimento de la calidad del software generado. Una vez listo el prototipo, hay que presentarlo al cliente para que lo pruebe y sugiera modificaciones. En este punto el cliente puede ver una implementacin de los requisitos que ha definido inicialmente y sugerir las modificaciones necesarias en las especificaciones para que satisfagan mejor sus necesidades. A partir de estos comentarios del cliente y los cambios que se muestren necesarios en los requisitos, se proceder a construir un nuevo prototipo y as sucesivamente hasta que los requisitos queden totalmente formalizados, y se pueda entonces empezar con el desarrollo del producto final. Por tanto, el prototipado es una tcnica que sirve fundamentalmente para la fase de anlisis de requisitos, pero lleva consigo la obtencin de una serie de subproductos que son tiles a lo largo del desarrollo del proyecto: Parte del trabajo realizado durante la fase de diseo rpido (especialmente la definicin de pantallas e informes) puede ser utilizada durante el diseo del producto final. Adems, tras realizar varias vueltas en el ciclo de construccin de prototipos, el diseo del mismo se parece cada vez ms al que tendr el producto final. Durante la fase de construccin de prototipos ser necesario codificar algunos componentes del software que tambin podrn ser reutilizados en la codificacin del producto final, aunque deban de ser optimizados en cuanto a correccin o velocidad de procesamiento. No obstante, hay que tener en cuenta que el prototipo no es el sistema final, puesto que normalmente apenas es utilizable. Ser demasiado lento, demasiado grande, ineficiente, inadecuado para el volumen de datos necesario, contendr errores (debido al diseo rpido), ser demasiado general (sin considerar casos particulares, que debe tener en cuenta el sistema final) o estar codificado en un lenguaje o para una mquina inadecuadas, o a partir de componentes software previamente existentes. No hay que preocuparse de haber desperdiciado tiempo o esfuerzos construyendo prototipos que luego habrn de ser desechados, si con ello hemos conseguido tener ms clara la especificacin del proyecto, puesto que el tiempo perdido lo ahorraremos en las fases siguientes, que podrn realizarse con menos esfuerzo y en las que se cometern menos errores que nos obliguen a volver atrs en el ciclo de vida. Hay que tener en cuenta que un anlisis de requisitos incorrecto o incompleto, cuyos errores y deficiencias se detecten a la hora de las pruebas o tras entregar el software al cliente, nos obligar a repetir de nuevo las fases de anlisis, diseo y codificacin, que habamos realizado cuidadosamente, pensando que estabamos desarrollando el producto final. Al tener que repetir estas fases, s que estaremos desechando una gran cantidad de trabajo, normalmente muy superior al esfuerzo de construir un prototipo basndose en un diseo rpido, en la reutilizacin de trozos de software preexistentes y en herramientas de generacin de cdigo para informes y manejo de ventanas. Uno de los problemas que suelen aparecer siguiendo el paradigma de construccin de prototipos, es que con demasiada frecuencia el prototipo pasa a ser parte del sistema final, bien sea por presiones del cliente, que quiere tener el sistema funcionando lo antes posible o bien porque los tcnicos se han acostumbrado a la mquina, el sistema operativo o el lenguaje con el que se desarroll el prototipo. Se olvida aqu que el prototipo ha sido construido de forma acelerada, sin tener en cuenta consideraciones de eficiencia, calidad del

Pagina -> 24

software o facilidad de mantenimiento, o que las elecciones de lenguaje, sistema operativo o mquina para desarrollarlo se han hecho basndose en criterios como el mejor conocimiento de esas herramientas por parte los tcnicos que en que sean adecuadas para el producto final. El utilizar el prototipo en el producto final conduce a que ste contenga numerosos errores latentes, sea ineficiente, poco fiable, incompleto o difcil de mantener. En definitiva a que tenga poca calidad, y eso es precisamente lo que queremos evitar aplicando la ingeniera del software. 2.6.- El modelo en espiral. El modelo en espiral combina las principales ventajas del modelo de ciclo de vida en cascada y del modelo de construccin de prototipos. Proporciona un modelo evolutivo para el desarrollo de sistemas de software complejos, mucho ms realista que el ciclo de vida clsico, y permite la utilizacin de prototipos en cualquier etapa de la evolucin del proyecto. Este es un modelo relativamente nuevo (fue propuesto en 1988) y no ha sido tan usado como los dos anteriores, aunque es de esperar que se extienda cada vez ms. Otra caracterstica de este modelo es que incorpora en el ciclo de vida el anlisis de riesgos. (que ya veremos lo que es). Los prototipos se utilizan como mecanismo de reduccin del riesgo, permitiendo finalizar el proyecto antes de haberse embarcado en el desarrollo del producto final, si el riesgo es demasiado grande. Fig. 2.5. El modelo en espiral. El modelo en espiral define cuatro tipos de actividades, y representa cada uno de ellos en un cuadrante: Planificacin. Consiste en determinar los objetivos del proyecto, las posibles alternativas y las restricciones. Esta fase equivale a la de recoleccin de requisitos del ciclo de vida clsico e incluye adems la planificacin de las actividades a realizar en cada iteracin. Anlisis de riesgo. Una de las actividades de la gestin de proyectos es el anlisis de riesgos. El desarrollo de cualquier proyecto complejo lleva implcito una serie de riesgos: unos relativos al propio proyecto (los riesgos que pueden hacer que el proyecto fracase) y otros relativos a las decisiones que deben tomarse durante su desarrollo (los riesgos asociados a que una de estas decisiones sea errnea). El anlisis de riesgos consiste en cuatro actividades principales:

Identificar los riesgos. Pueden ser: riesgos del proyecto (presupuestarios, de

organizacin, del cliente. etc.), riesgos tcnicos (problemas de diseo, codificacin, mantenimiento), riesgos del negocio (riesgos de mercado: que se adelante la competencia o que el producto no se venda bien).

Estimacin de riesgos. Consiste en evaluar, para cada riesgo identificado, la

probabilidad de que ocurra y las consecuencias, es decir, el coste que tendr en caso de que ocurra.

Evaluacin de riesgos. Consiste en establecer unos niveles de referencia para el

incremento de coste, de duracin del proyecto y para la degradacin de la calidad que si se superan harn que se interrumpa el proyecto. Luego hay que relacionar cuantitativamente cada uno de los riesgos con estos niveles de referencia, de

Pagina -> 25

forma que en cualquier momento del proyecto podamos calcular si hemos superado alguno de los niveles de referencia. que se detecten los riesgos tan pronto como aparezcan, se intenten minimizar sus daos y exista un apoyo previsto para las tareas crticas (aqullas que ms riesgo encierran). Ingeniera. Consiste en el desarrollo del sistema o de un prototipo del mismo. Evaluacin del cliente. Consiste en la valoracin, por parte del cliente, de los resultados de la ingeniera. En la primera iteracin se definen los requisitos del sistema y se realiza la planificacin inicial del mismo. A continuacin se analizan los riesgos del proyecto, basndonos en los requisitos iniciales y se procede a construir un prototipo del sistema. Entonces el cliente procede a evaluar el prototipo y con sus comentarios, se procede a refinar los requisitos y a reajustar la planificacin inicial, volviendo a empezar el ciclo. En cada una de las iteraciones se realiza el anlisis de riesgos, teniendo en cuenta los requisitos y la reaccin del cliente ante el ltimo prototipo. Si los riesgos son demasiado grandes se terminar el proyecto, aunque lo normal es que se siga avanzando a lo largo de la espiral. Con cada iteracin, se construyen sucesivas versiones del software, cada vez ms completas, y aumenta la duracin de las operaciones del cuadrante de ingeniera, obtenindose al final el sistema de ingeniera completo. La diferencia principal con el modelo de construccin de prototipos, es que en ste los prototipos se usan para perfilar y definir los requisitos. Al final, el prototipo se desecha y comienza el desarrollo del software siguiendo el ciclo clsico. En el modelo en espiral, en cambio, los prototipos son sucesivas versiones del producto, cada vez ms detalladas (el ltimo es el producto en s) y constituyen el esqueleto del producto de ingeniera. Por tanto deben construirse siguiendo estndares de calidad. 2.7.- Visin genrica de la ingeniera del software. Independientemente del paradigma que se utilice, del rea de aplicacin, y del tamao y la complejidad del proyecto, el proceso de desarrollo de software contiene siempre una serie de fases genricas, existentes en todos los paradigmas. Estas fases son la definicin, el desarrollo y el mantenimiento.

Gestin de riesgos. Consiste en supervisar el desarrollo del proyecto, de forma

Pagina -> 26

Definicin. La fase de definicin se centra en el qu. Durante esta fase, se intenta identificar: qu informacin es la que tiene que ser procesada. qu funcin es la que debe realizarse. qu restricciones existen (rendimiento, eficiencia, seguridad, precisin, etc.). qu interfaces existen con otros sistemas. qu criterios de validacin se necesitan para conseguir que el sistema final sea correcto. Aunque los pasos concretos dependen del modelo de ciclo de vida utilizado, en general se realizarn tres tareas especficas: Anlisis del sistema. Como ya hemos visto, el anlisis del sistema define el papel de cada elemento de un sistema informtico, estableciendo cul es el papel del software dentro de ese sistema. Anlisis de requisitos del software. El anlisis del sistema proporciona el mbito del software, su relacin con el resto de componentes del sistema, pero antes de empezar a desarrollar es necesario hacer una definicin ms detallada de la funcin del software. Existen dos formas de realizar el anlisis y refinamiento de los requisitos del software. Por una parte, se puede hacer un anlisis riguroso del mbito de la informacin para establecer modelos del flujo y la estructura de la informacin. Luego se amplan unos modelos para convertirlos en una especificacin del software. La otra alternativa consiste en construir un prototipo del software, que ser evaluado por el cliente para intentar consolidar los requisitos. Los requisitos de rendimiento y las limitaciones de recursos se traducen en directivas para la fase de diseo. El anlisis y definicin de los requisitos es una tarea que debe llevarse a cabo conjuntamente por el desarrollador de software y por el cliente. La especificacin de requisitos del software es el documento que se produce como resultado de esta etapa. Planificacin del proyecto software. Durante esta etapa se lleva a cabo el anlisis de riesgos, se definen los recursos necesarios para desarrollar el software y se establecen las estimaciones de tiempo y costes. El propsito de esta etapa de planificacin es proporcionar una indicacin preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se hayan establecido. Posteriormente, la gestin del proyecto durante el desarrollo del mismo realiza y revisa el plan de proyecto de software. Desarrollo. La fase de desarrollo se centra en el cmo. cmo ha de ser la arquitectura de la aplicacin. cmo han de ser las estructuras de datos. cmo van a ser las interfaces. cmo ha de traducirse el diseo a un lenguaje de programacin. cmo han de implementarse los detalles procedimentales de los mdulos.

Pagina -> 27

cmo van a realizarse las pruebas. Aunque, al igual que antes, los pasos concretos dependen del modelo de ciclo de vida utilizado, en general se realizarn cuatro tareas especficas: Diseo. El diseo del software traduce los requisitos a un conjunto de representaciones (grficas, en forma de tabla o basadas en algn lenguaje apropiado) que describen cmo van a estructurarse los datos, cul va a ser la arquitectura de la aplicacin, cul va a ser la estructura de cada programa y cmo van a ser las interfaces. Es necesario seguir criterios de diseo que nos permitan asegurar la calidad del producto. Una vez finalizado el diseo es necesario revisarlo para asegurar la completitud y el cumplimiento de los requisitos del software. Codificacin. En esta fase, el diseo se traduce a un lenguaje de programacin, dando como resultado un programa ejecutable. La buena calidad de los programas desarrollados depende en gran medida de la calidad del diseo. Una vez codificados los programas debe revisarse su estilo y claridad, y se comprueba que haya una correspondencia con la estructura de los mismos definida en la fase de diseo. El listado fuente de cada mdulo (o el programa fuente en soporte magntico) pasa a formar parte de la configuracin del sistema. Pruebas. Una vez que tenemos implementado el software es preciso probarlo, para detectar errores de codificacin, de diseo o de especificacin. Las pruebas son necesarias para encontrar el mayor nmero posible de errores antes de entregar el programa al cliente. Es necesario probar cada uno de los componentes por separado (cada uno de los mdulos o programas) para comprobar el rendimiento funcional de cada una de estas unidades. A continuacin se procede a integrar los componentes para probar toda la arquitectura del software, y probar su funcionamiento y las interfaces. En este punto hay que comprobar si se cumplen todos los requisitos de la especificacin. Se debe desarrollar un plan y procedimiento de pruebas y guardar informacin sobre los casos de pruebas y los resultados de las mismas. Garanta de calidad. Una vez terminada la fase de pruebas, el software est casi preparado para ser entregado al cliente. Mantenimiento. La fase de mantenimiento se centra en los cambios que va a sufrir el software a lo largo de su vida til. Como ya hemos dicho, estos cambio pueden deberse a la correccin de errores, a cambios en el entorno inmediato del software o a cambios en los requisitos del cliente, dirigidos normalmente a ampliar el sistema. La fase de mantenimiento vuelve a aplicar los pasos de las fases de definicin y de desarrollo, pero en el contexto de un software ya existente y en funcionamiento. Figura 2.6. Diagrama de etapas de la Ingeniera del Software. 2.8. Ingeniera inversa y reingeniera del software. Los modelos descritos en las secciones anteriores dan una visin directa de la IS como un proceso evolutivo en el que el software pasa por etapas sucesivas de gestacin, construccin, uso y sustitucin. Sin embargo existen determinadas tareas dentro de la IS que obligan a realizar el camino inverso, lo que ha llevado a acuar el trmino de ingeniera inversa. Como ya habamos visto en el tema anterior, en sus primeros tiempos, e incluso recientemente, el software se desarrollaba sin ninguna planificacin, lo que ha llevado a la

Pagina -> 28

existencia de numerosas aplicaciones actualmente en funcionamiento que carecen por completo de documentacin. Con el tiempo, y con la marcha de las personas que las han programado, desaparece por completo el conocimiento que se tiene sobre estas aplicaciones, y despus de aos de procesamiento automtico de la informacin, incluso las personas que las manejan desconocen cules son exactamente las transformaciones que realizan sobre los datos que manejan. Esto causa graves problemas a la hora de intentar realizar cualquier cambio en estas aplicaciones, al intentar optimizarlas o adaptarlas para que funcionen sobre nuevos ordenadores, sistemas operativos o lenguajes o a la hora de reescribirlas segn los nuevos estilos de trabajo con ordenador (primero fue la entrada de datos interactiva usando pantallas de texto, hoy son los entornos grficos de ventanas). La ingeniera inversa consiste en analizar un programa en un esfuerzo de representarlo en un mayor nivel de abstraccin que el cdigo fuente, de forma que se extraiga informacin del diseo de datos, de la arquitectura y del detalle procedimental del mismo, para poder entenderlo. La reingeniera del software no slo recupera informacin sobre el diseo de un programa existente sino que utiliza esta informacin para reestructurar o reconstruir el programa existente, con vistas a adaptarlo a un cambio, a ampliarlo o a mejorar su calidad general, con el objetivo de conseguir una mayor facilidad de mantenimiento en el futuro (esto es lo que se denomina mantenimiento preventivo). Existen herramientas CASE especializadas en ingeniera inversa y reingeniera, pero as como las herramientas de ingeniera normal producen buenos resultados, stas son an muy rudimentarias, estando muy limitados tanto su campo de aplicacin como los resultados que producen. Visin genrica de la Ingeniera del Software. Definicin. Qu? Anlisis del sistema. Establecer el mbito del software. Anlisis de requisitos del sistema software. Definicin detallada de la funcin del software. Planificacin. Anlisis de riesgos. Asignacin de recursos. Definicin de tareas. Estimacin de costes. Cmo?

Desarrollo.

Diseo. Arquitectura de la aplicacin. Estructura de los datos. Estructura interna de los programas. Diseo de las interfaces. Codificacin. Pruebas. Mantenimiento. El cambio. Correccin de errores. Cambios en el entorno. Cambios en los requisitos.

Pagina -> 29

UNIDAD III INGENIERIA DE REQUERIMIENTOS 3.1. Introduccin.

En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los aos, la Ingeniera de Software ha introducido y popularizado una serie de estndares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en s. Se han publicado muchos libros y artculos relacionados con este tema, con el modelado de procesos del negocio y la reingeniera. Un nmero creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en da la economa global depende ms de sistemas automatizados que en pocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva dcada de procesos y estndares de calidad. Sin embargo, cmo explicamos la alta incidencia de fallos en los proyectos de software? Por qu existen tantos proyectos de software vctimas de retrasos, presupuestos sobregirados y con problemas de calidad? Cmo podemos tener una produccin o una economa de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema? Tal vez suene ilgico pero, a pesar de los avances que ha dado la tecnologa, an existen procesos de produccin informales, parciales y en algunos casos no confiables. La Ingeniera de Requerimientos cumple un papel primordial en el proceso de produccin de software, ya que enfoca un rea fundamental: la definicin de lo que se desea producir. Su principal tarea consiste en la generacin de especificaciones correctas que describan con claridad, sin ambigedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas. La razn principal para escoger este tema se fundament en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro pas somos partcipes de este problema a diario, en donde se ha vuelto comn la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas. Tal "personalizacin", la mayora de las veces, termina retrasando el proyecto en meses, o incluso en aos. La problemtica del ao 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados. El reemplazo de plataformas y tecnologas obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definicin de los requerimientos. Estudios realizados muestran que ms del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participacin del usuario, requerimientos incompletos y el cambio a los requerimientos, tambin ocupan sitiales altos en los motivos de fracasos. Con este trabajo se pretende alcanzar los siguientes objetivos: Resaltar la importancia que tiene la Ingeniera de Requerimientos dentro del ciclo de desarrollo. Dar a conocer las diferentes alternativas que existen para identificar requerimientos. Ayudar a comprender la diferencia que existe entre las diferentes tcnicas utilizadas en la IR. Minimizar las dudas que se tiene sobre los casos de uso.

Pagina -> 30 Mostrar la utilizacin de herramientas CASE dentro de la administracin de requisitos.

3.2. La ingeniera de requerimientos y sus principales actividades Qu son Requerimientos? Normalmente, un tema de la Ingeniera de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuacin se presenta la definicin que aparece en el glosario de la IEEE . (1) Una condicin o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condicin o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estndar, especificacin u otro documento formal. (3) Una representacin documentada de una condicin o capacidad como en (1) o (2). Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales. Los requerimientos funcionales definen las funciones que el sistema ser capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con caractersticas que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares, etc. Caractersticas de los requerimientos Las caractersticas de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de caractersticas tanto individualmente como en grupo. A continuacin se presentan las ms importantes. Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin, es decir, si se proporciona la informacin suficiente para su comprensin. Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento. No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin. El lenguaje usado en su definicin, no debe causar confusiones al lector. Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas. Dificultades para definir los requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. Son difciles de expresar en palabras (el lenguaje es ambiguo). Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difcil de manejar. Nunca son iguales. Algunos son ms difciles, ms riesgosos, ms importantes o ms estables que otros. Los requerimientos estn relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. Cada requerimiento tiene propiedades nicas y abarcan reas funcionales especficas. Un requerimiento puede cambiar a lo largo del ciclo de desarrollo. Son difciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Ingeniera de Requerimientos vs. Administracin de Requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniera de Requerimientos. La meta de la ingeniera de requerimientos (IR) es entregar una especificacin de requisitos de software correcta y completa. A continuacin se darn algunas definiciones para ingeniera de requerimientos. "Ingeniera de Requerimientos es la disciplina para desarrollar una especificacin completa,

Pagina -> 31 consistente y no ambigua, la cual servir como base para acuerdos comunes entre todas las partes involucradas y en dnde se describen las funciones que realizar el sistema" Boehm 1979. "Ingeniera de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987. "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinacin de mtodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987. "Ingeniera de requerimientos es un enfoque sistmico para recolectar, organizar y documentar los requerimientos del sistema; es tambin el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software Importancia de la Ingeniera de Requerimientos Los principales beneficios que se obtienen de la Ingeniera de Requerimientos son: Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, as como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimacin de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeo, etc.). Mejora la comunicacin entre equipos: La especificacin de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no ser exitoso. Evita rechazos de usuarios finales: La ingeniera de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniera de Requerimientos Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles especficos dentro de la planificacin del proyecto; el conocimiento de cada papel desempeado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR. No conocer estos intereses puede ocasionar una comunicacin poco efectiva entre clientes y desarrolladores, que a la vez traera impactos negativos tanto en tiempo como en presupuesto. Los roles ms importantes pueden clasificarse como sigue: Usuario final: Son las personas que usarn el sistema desarrollado. Ellos estn relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; estn familiarizados con los procesos especficos que debe realizar el software, dentro de los parmetros de su ambiente laboral. Sern quienes utilicen las interfaces y los manuales de usuario. Usuario Lder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde ser empleado el software desarrollado. Ellos proporcionan al equipo tcnico los detalles y requerimientos de las interfaces del sistema. Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, stas personas son las responsables de la administracin de cambios, de la implementacin y resolucin de anomalas. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado. Analistas y programadores: Son los responsables del desarrollo del producto en s; ellos interactan directamente con el cliente.

Pagina -> 32 Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseadores de base de datos, entre otros. Puntos a considerar durante la Ingeniera de Requerimientos Aunque la lista no est completa, se enumeran los puntos ms importantes. Objetivos del negocio y ambiente de trabajo Aunque los objetivos del negocio estn definidos frecuentemente en trminos generales, son usados para descomponer el trabajo en tareas especficas. En ciertas situaciones IR se enfoca en la descripcin de las tareas y en el anlisis de sistemas similares. Esta informacin proporciona la base para especificar el sistema que ser construido; aunque frecuentemente se aadan al sistema tareas que no encajan con el ambiente de trabajo planificado. El nuevo sistema cambiar el ambiente de trabajo, sin embargo, es muy difcil anticipar los efectos actuales sobre la organizacin. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en produccin; tambin ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atencin a la IR es la principal. Frecuentemente la especificacin inicial es tambin la especificacin final, lo que obstaculiza la comunicacin y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados. Punto de vista de los clientes Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario. Diferentes puntos de vistas tambin pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos. El tamao y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos. Barreras de comunicacin La ingeniera de requerimientos depende de una intensa comunicacin entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicacin. Para remediar esto, se deben abordar nuevas tcnicas operacionales que ayuden a superar estas barreras y as ganar experiencia dentro del marco del sistema propuesto. Evolucin e integracin del sistema Pocos sistemas son construidos desde cero. En la prctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integracin de componentes de varios proveedores. Para encontrar una solucin a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseo; esto minimizar la cantidad de fallas directas en el cdigo. Documentacin de requerimientos

Pagina -> 33 Los documentos de ingeniera de requerimientos son largos. La mayora estn compuestos de cientos o miles de pginas; cada pgina contiene muchos detalles que pueden tener efectos profundos en el resto del sistema. Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamao, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificacin de gran tamao, pues difcilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta despus de haberse construido el sistema. Actividades de la Ingeniera de Requerimientos En el proceso de IR son esenciales diversas actividades. En este documento sern presentadas secuencialmente, sin embargo, en un proceso de ingeniera de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado. Dependiendo del tamao del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varan tanto en nmero como en nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso. A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son: Anlisis del Problema Evaluacin y Negociacin Especificacin Validacin Evolucin

Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniera de Software MODELO Oliver and Steiner 1996 EIA / IS-632 IEEE Std 1220- CMM nivel 1994 Repetitivo (2) RUP

Actividades Evaluar la informacin disponible Definir mtricas efectivas

Anlisis de Anlisis de Identificacin de Anlisis del requerimientos Requerimientos requerimientos Problema Anlisis funcional Estudio de los requerimientos Identificacin de Comprender las restricciones del necesidades de sistema a los involucrados desarrollar Anlisis de los requerimientos Definir el sistema

Crear un Sntesis modelo del comportamiento del sistema Crear un modelo de los objetos Ejecutar el anlisis Crear un plan Anlisis y control del sistema

Validacin de requerimientos

Anlisis funcional Evaluacin y estudio de funciones Verificacin de

Representacin Analizar el de los alcance del requerimientos proyecto Comunicacin de los requerimientos Validacin de Modificar la definicin del sistema Administrar los

Pagina -> 34

secuencial de construccin y pruebas

funciones

requerimientos

cambios de requerimientos

Sntesis Estudio y evaluacin del diseo Verificacin fsica Control A continuacin se explicar cada una de ellas, presentndolas en el orden en que deben ser aplicadas para un nuevo proyecto.Anlisis del Problema El objetivo de esta actividad es entender las verdaderas necesidades del negocio.Antes de describir qu pasos deben cumplirse en esta actividad, debemos tener una definicin clara el trmino "Problema". "Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean" . Aqu vemos nuevamente la importancia que tiene una buena comunicacin entre desarrolladores y clientes; de esta comunicacin con el cliente depende que entendamos sus necesidades. A travs de la definicin de problema, podemos ver entonces que la actividad de "Anlisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel para resolverlo. Durante el anlisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes Comprender el problema que se est resolviendo: Es importante determinar quin tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que debe formar para realizar una transaccin bancaria". Perspectiva del cliente = Prdida de tiempo Perspectiva del banco = Posibles prdidas de clientes Posibles soluciones pueden ser, determinar por qu demoran los cajeros, colocar una nueva caja (implica contratacin de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (telfono, internet, mediante cajeros automticos, autobancos, etc). Como puede verse, mltiples soluciones aplican para el mismo problema, sin embargo, slo una de ellas ser la ms factible. Las soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva tcnica como la del negocio. Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto. Por ejemplo, las palabras pignoracin, retencin, valor en suspenso, custodia, garanta, entre otras, son utilizadas para referirse a la accin de dejar una prenda (puede ser cualquier forma de ahorros) como garanta de una deuda adquirida. La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems de ser reutilizable en otros proyectos. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas.

Pagina -> 35 Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema? Quin mercadear, vender, y/o distribuir el sistema? Quin se beneficiar por el retorno de inversin del sistema?

Como vemos, debe conocerse la opinin de todo aqul que de una u otra forma est involucrado con el sistema, ya sea directa o indirectamente. Definir los lmites y restricciones del sistema: Este punto es importante pues debemos saber lo que se est construyendo, y lo que no se est construyendo, para as entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restriccin ambiental, presupuestaria, de tiempo, tcnica y de factibilidad que limite el sistema que se va a construir. Evaluacin y negociacin de los requerimientos La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluacin de los mismos antes de definir si son adecuados para el cliente. El trmino "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades tcnicas y econmicas, a la vez que se buscan resultados completos, correctos y sin ambigedades. En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstraccin y descomposicin de cada problema presentado. Los principales pasos de esta actividad son: Descubrir problemas potenciales: En este paso se asegura que todas las caractersticas descritas en el punto 1.1 estn presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc. Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un requerimiento en trminos de implementacin. A esta caracterstica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de diseo y prueba de cada requisito. La prioridad de cada requerimiento depender de las necesidades que tenga el negocio. En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operacin crtica del negocio. Si existe algn proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario. Una vez hecha esta categorizacin de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por ms que ste sea slo deseable. Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (pueden implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales (puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas (ha sido aprobado por los clientes el presupuesto?). En la actividad de evaluacin y negociacin, se incrementa la comunicacin entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos: Documentar todos los requerimientos a un nivel de detalle apropiado. Mostrar todos los requerimientos a los involucrados en el sistema. Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos. Establecer las relaciones entre requerimientos que indiquen dependencias. Negociar con flexibilidad para que exista un beneficio mutuo. Enfocarse en intereses y no en posiciones.

Pagina -> 36 Especificacin de Requisitos de Software (SRS) La especificacin de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripcin completa de las necesidades y funcionalidades del sistema que ser desarrollado; describe el alcance del sistema y la forma en como har sus funciones, definiendo los requerimientos funcionales y los no funcionales. En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra informacin que sirva de soporte y gua para fases posteriores. Es importante destacar que la especificacin de requisitos es el resultado final de las actividades de anlisis y evaluacin de requerimientos; este documento resultante ser utilizado como fuente bsica de comunicacin entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementacin del sistema. Los clientes y usuarios utilizan la SRS para comparar si lo que se est proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborar las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolucin del sistema. La SRS posee las mismas caractersticas de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada caracterstica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y as sucesivamente. Las caractersticas de la SRS son verificadas en la actividad de Validacin, descrita en el punto 3.4. La estandarizacin de la SRS es fundamental pues ayudar, entre otras cosas, a facilitar la lectura y escritura de la misma. Ser un documento familiar para todos los involucrados, adems de asegurar que se cubren todos los tpicos importantes. Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. En el anexo #1 se muestra una plantilla completa para la especificacin de requisitos. Validacin de Requisitos La validacin es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; adems revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes. En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validacin garantiza que todos los requerimientos presentes en el documento de especificacin sigan los estndares de calidad. No debe confundirse la actividad de evaluacin de requerimientos con la validacin de requerimientos. La evaluacin verifica las propiedades de cada requerimiento, mientras que la validacin revisa el cumplimiento de las caractersticas de la especificacin de requisitos. Durante la actividad de validacin pueden hacerse preguntas en base a cada una de las caractersticas que se desean revisar. A continuacin se presentan varios ejemplos: Estn incluidas todas las funciones requeridas por el cliente? (completa) Existen conflictos en los requerimientos? (consistencia) Tiene alguno de los requerimientos ms de una interpretacin? (no ambigua) Est cada requerimiento claramente representado? (entendible) Pueden los requerimientos ser implementados con la tecnologa y el presupuesto disponible? (factible) Est la SRS escrita en un lenguaje apropiado? (clara) Existe facilidad para hacer cambios en los requerimientos? (modificable) Est claramente definido el origen de cada requisito? (rastreable) Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)

La validacin de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado. Evolucin de los requerimientos

Pagina -> 37 Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cmo los objetivos de la organizacin pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolucin es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto. Los requerimientos cambian por diferentes razones. Las ms frecuentes son: Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas. Porque cambi el problema que se estaba resolviendo. Porque los usuarios cambiaron su forma de pensar o sus percepciones. Porque cambi el ambiente de negocios. Porque cambi el mercado en el cual se desenvuelve el negocio.

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una caracterstica en particular, modificacin que a la vez puede tener impacto en otros requerimientos. Por esto, la administracin de cambios involucra actividades como establecer polticas, guardar histricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones. Tener versiones de los requerimientos es tan importante como tener versiones del cdigo, ya que evita tener requerimientos emparchados en un proyecto Entre algunos de los beneficios que proporciona el control de versiones estn: Prevenir cambios no autorizados. Guardar revisiones de los documentos de requerimientos. Recuperar versiones previas de los documentos. Administrar una estrategia de "releases". Prevenir la modificacin simultnea a los requisitos.

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

Pagina -> 38

UNIDAD IV PLANIFICACIN DE PROYECTOS DE SOFTWARE 4.1. Introduccin. Segn vimos en el tema anterior, existen diversos modelos de ciclo de vida para el desarrollo de software, pero en todos ellos se puede observar la existencia de una fase denominada Anlisis de requisitos. Entre las tareas que hay que realizar en esta fase estn el estudio de las caractersticas y la funcin del sistema, la definicin de los requisitos del software y del sistema del que el software forma parte, as como la planificacin inicial del proyecto y, posiblemente, algunas tareas relacionadas con el anlisis de riesgos. Todas estas tareas deben realizarse al comienzo del proyecto, pero el principal problema que se nos presenta es que, en estos momentos iniciales, es difcil tener una idea clara - o, al menos, es difcil llegar a expresarla - de cules son los requisitos del sistema y del software, y llegar a comprender en su totalidad la funcin que el software debe realizar. Por esto, algunos de los modelos de ciclo de vida estudiados proponen enfoques cclicos de refinamiento de los requisitos o incluso de todo el proceso de desarrollo de software. El anlisis de requisitos es el primer paso del proceso de ingeniera del software. Es aqu donde se refina la declaracin general del mbito del software en una especificacin concreta que se convierte en la base de todas las actividades de ingeniera del software que siguen. Algunos modelos de ciclo de vida distinguen una fase de anlisis de requisitos y otra de especificacin del sistema. En cualquier caso, el anlisis del sistema concluye con la especificacin de los requisitos del mismo. El anlisis se centra en los mbitos de informacin, funcional y de comportamiento del problema en cuestin. Para comprender mejor lo que se requiere se divide el problema en partes y se desarrollan representaciones o modelos que muestran la esencia de los requisitos (modelo esencial) y, posteriormente, los detalles de implementacin (modelo de implementacin). Como resultado del anlisis se desarrolla la especificacin de requisitos, un documento que describe el problema analizado y muestra la estructura de la solucin propuesta. La forma de especificar un sistema tiene una gran influencia en la calidad de la solucin implementada finalmente. Tradicionalmente los ingenieros de software han venido trabajando con especificaciones incompletas, inconsistentes o errneas, lo que invariablemente lleva a la confusin y a la frustracin en todas las etapas del ciclo de vida. Como consecuencia de esto, la calidad, la correccin y la completitud del software disminuyen. A lo largo del curso, veremos que los requisitos del software se pueden analizar de varias formas diferentes, no necesariamente excluyentes, cada una de ellas asociadas a un modelo del ciclo de vida. Las tcnicas de anlisis que veremos conducen a una especificacin en papel o basada en ordenador (si utilizamos herramientas de anlisis o CASE), que contiene descripciones grficas y textuales (normalmente en lenguaje natural o alguna forma de pseudocdigo) de los requisitos del software. Por otro lado, la construccin de prototipos lleva a una especificacin ejecutable, es decir, el prototipo sirve como representacin de los requisitos. Por ltimo, los lenguajes de especificacin formal conducen a representaciones de los requisitos que pueden ser analizadas o verificadas formalmente. Sin embargo, sea cual sea el mtodo elegido, existen una serie de caractersticas comunes:

Pagina -> 39

Mtodos de anlisis. Caractersticas comunes. Realizan una abstraccin de las caractersticas del sistema, es decir, consisten en desarrollar un modelo del mismo. Representan el sistema de forma jerrquica, basndose en mecanismos de particin del problema y estableciendo varios niveles de detalle. Definen cuidadosamente las interfaces del sistema, tanto las interfaces externas, que relacionan el sistema con su entorno, como de las internas, las que se establecen entre los distintos mdulos definidos. Sirven de base para las etapas posteriores de diseo y de implementacin. Distinguen entre requisitos esenciales y de implementacin. No prestan demasiada atencin a la representacin de las restricciones o de criterios de validacin (exceptuando los mtodos formales). Es por esta ltima deficiencia por la que surge la necesidad de los mtodos de especificacin formal, especialmente en aquellos sistemas en los que la correccin, completitud o fiabilidad del software juegan un papel fundamental. Ejemplos de este tipo de sistemas pueden ser los protocolos de comunicacin, el software de control de una central nuclear o el de gestin del trfico areo. Anlisis de requisitos del sistema. El anlisis de requisitos del sistema constituye el primer intento de comprender cul va a ser la funcin y mbito de informacin de un nuevo proyecto. El objetivo es conseguir representar un sistema en su totalidad, incluyendo hardware, software y personas, mostrando la relacin entre los diversos componentes y sin entrar en la estructura interna de los mismos. En algunos casos se nos plantearn diferentes posibilidades y tendremos que realizar un estudio de cada una de ellas. Indudablemente, los esfuerzos realizados en esta fase producen beneficios en las fases posteriores. Sin embargo se nos pueden plantear las siguientes dudas:

Cunto tiempo debe dedicarse al anlisis del sistema? Depender de la

naturaleza, el tamao y la complejidad de la aplicacin. Una directriz que se podra aplicar es dedicar entre un 10% y un 20% del esfuerzo total estimado al anlisis del sistema y otro 10% o 20% al anlisis de requisitos del software. El esfuerzo que se le dedica normalmente es mucho menor. En la mayora de los proyectos la mayor parte del esfuerzo se va en la codificacin, precisamente por la dificultad de realizar la codificacin cuando no se ha hecho un buen anlisis previo.

Quin debe hacerlo? La respuesta es fcil: el analista de sistemas. Este debe

ser una persona con buena formacin tcnica y con experiencia. No obstante, el analista no trabaja de forma aislada sino en estrecho contacto con el personal de direccin, tcnico y administrativo tanto del cliente como del que desarrolla el software.

Por qu es una tarea tan difcil? Bsicamente porque consiste en la traduccin

de unas ideas vagas de necesidades de software en un conjunto concreto de

Pagina -> 40

funciones y restricciones. Adems el analista debe extraer informacin dialogando con muchas personas y cada una de ellas se expresar de una forma distinta, tendr conocimientos informticos y tcnicos distintos, y tendr unas necesidades y una idea del proyecto muy particulares. 4.2. Objetivos del anlisis de requisitos del sistema. El papel del analista de sistemas es el de definir los elementos de un sistema informtico dentro del contexto del sistema en que va a ser usado. Hay que identificar las funciones del sistema y asignarlas a alguno de sus componentes. Para ello, el analista de sistemas parte de los objetivos y restricciones definidos por el usuario y realiza una representacin de la funcin del sistema, de la informacin que maneja, de sus interfaces y del rendimiento y las restricciones del mismo. En la mayora de los casos, el proyecto empieza con un concepto ms bien vago y ambiguo de cul es la funcin deseada. Entonces el analista debe delimitar el sistema, indicando el mbito de funcionamiento y el rendimiento deseados. Por ejemplo, en el caso de un sistema de control, no basta con decir algo as como el sistema debe reaccionar rpidamente en caso de que la seal de entrada supere los lmites de seguridad sino que hay que definir cules son los lmites de seguridad de la seal de entrada, en cunto tiempo debe producirse la reaccin y cmo ha de ser esta reaccin. Una vez que se ha logrado delimitar la funcin, el mbito de informacin, las restricciones, el rendimiento y las interfaces del sistema, el analista debe proceder a la asignacin de funciones. Las funciones del sistema deben de ser asignadas a alguno de sus componentes (ya sean stos software, hardware o personas). El analista debe estudiar varias opciones de asignacin (considerando, por ejemplo, la posibilidad de automatizar o no alguna de estas funciones), teniendo en cuenta las ventajas e inconvenientes de cada una de ellas (en cuanto a viabilidad, costes de desarrollo y funcionamiento y fiabilidad) y decidirse por una de ellas, o bien presentar un estudio razonado de las opciones a quienes tengan que tomar la decisin. Para explicar todo lo anterior podemos poner el siguiente ejemplo: Especificacin informal del sistema de clasificacin de paquetes. El sistema de clasificacin de paquetes debe realizarse de forma que los paquetes que se mueven a lo largo de una cinta transportadora sean identificados (para lo cual van provistos de un cdigo numrico) y clasificados en alguno de los seis contenedores situados al final de la cinta. Los paquetes de cada tipo aparecen en la cinta siguiendo una distribucin aleatoria y estn espaciados de manera uniforme. La velocidad de la cinta debe ser tan alta como sea posible; como mnimo el sistema debe ser capaz de clasificar 10 paquetes por minuto. La carga de paquetes al principio de la cinta puede realizarse a una velocidad mxima de 20 paquetes por minuto. El sistema debe funcionar las 24 horas del da, siete das a la semana. Funcin del sistema. Realizar la clasificacin de paquetes que llegan por una cinta transportadora en seis compartimentos distintos, dependiendo del tipo de cada paquete.

Pagina -> 41

Informacin que se maneja. Los paquetes disponen de un cdigo numrico de identificacin. Debe existir una tabla o algoritmo que asigne a cada nmero de paquete el contenedor donde debe ser clasificado. Interfaces del sistema. El sistema de clasificacin se relaciona con otros dos sistemas. Por un lado tenemos la cinta transportadora. Parece conveniente que el sistema de clasificacin pueda parar el funcionamiento de la cinta o del sistema de carga de paquetes en la cinta, en caso de que no pueda realizar la clasificacin (por ejemplo si se produce una avera). Por otro lado, el sistema deposita paquetes en los contenedores, pero no se establece ningn mecanismo de vaciado o sustitucin de los contenedores si se llenan. El sistema debera ordenar la sustitucin o vaciado del contenedor o esperar mientras un contenedor est lleno. Como la descripcin realizada por el cliente no establece los mecanismos para solventar estas dos situaciones estos detalles deben ser discutidos con el cliente. Rendimiento. El sistema debe ser capaz de clasificar al menos 10 paquetes por minuto. No es necesario que el sistema sea capaz de clasificar ms de 20 paquetes por minuto. Restricciones. El sistema debe tener un funcionamiento continuo. Por tanto, debemos evitar la parada del sistema incluso en el caso de que para alguno de los componentes del mismo se averen. El documento no indica restricciones sobre la eficacia del sistema, es decir, sobre cul es el porcentaje mximo que se puede tolerar de paquetes que pueden ser clasificados de forma errnea. Estos detalles tambin deben ser aclarados con el cliente.

Pagina -> 42

Asignacin de funciones. Podemos considerar tres asignaciones posibles: Asignacin 1. Esta asignacin propone una solucin manual para implementar el sistema. Los recursos que utiliza son bsicamente personas, y se requiere adems algo de documentacin, definiendo las caractersticas del puesto de trabajo y del sistema de turnos y una tabla que sirva al operador para relacionar los cdigos de identificacin de los paquetes con el contenedor donde deben ser depositados. La inversin necesaria para poner en marcha este sistema es mnima, pero requiere una gran cantidad de mano de obra (varios turnos de trabajo y operadores de guardia) con lo que los costes de funcionamiento sern elevados. Adems hay que tener en cuenta que lo rutinario del trabajo provocar una falta de motivacin en los operarios, lo que a la larga se acabar traduciendo en un mayor absentismo laboral. Todos estos factores deben de tenerse en cuenta a la hora de elegir esta u otra opcin. Asignacin 2. En este caso, la solucin es automatizada. Los recursos que se utilizan son: hardware (el lector de cdigos de barras, el controlador, el mecanismo de distribucin), software (para el lector de cdigos de barras y el controlador, y una base de datos que permita asignar a cada cdigo su contenedor) y personas (si en caso de avera la distribucin se va a hacer manualmente). Cualquiera de los elementos hardware y software tendrn la correspondiente documentacin sobre cmo han sido construidos y un manual de usuario. Aqu si hay que realizar una cierta inversin, para comprar o desarrollar los componentes del sistema, pero los costes de funcionamiento sern sin duda menores (slo el consumo de energa elctrica). Hay que tener en cuenta que el uso de dispositivos mecnicos (el mecanismo de distribucin) va a introducir unos costes de mantenimiento y paradas por avera o mantenimiento con una cierta frecuencia. Asignacin 3. Los recursos que utilizamos aqu son: hardware (el lector, el brazo robot), software (el del lector, el del robot, incluyendo la tabla o algoritmo de clasificacin) y la documentacin y manuales correspondientes a estos elementos. En este caso la inversin inicial es, sin duda, la ms elevada. Los costes de funcionamiento son bajos pero hay que considerar tambin el coste de mantenimiento del robot, que posiblemente tenga que ser realizado por personal especializado. Los nicos motivos que nos haran decidir por esta opcin en vez de la anterior vendran dados por una mayor velocidad, un menor nmero de errores o unas menores necesidades de mantenimiento o frecuencia de averas. Por otra parte esta solucin puede tener problemas de viabilidad (si no encontramos un brazo robot que sea capaz de atrapar los paquetes segn pasan por la cinta). Adems de las tres opciones propuestas, el ingeniero de sistemas debe considerar tambin la adopcin de soluciones estndar al problema. Hay que estudiar si existe ya un producto comercial que realice la funcin requerida para el sistema o si alguna de las partes del mismo pueden ser adquiridas a un tercero. Aparte de considerar el precio de estos productos habr que tener tambin en cuenta los costes del mantenimiento y el riesgo que se asocia al depender de una tecnologa que no es propia (es la empresa proveedora estable?, cul es la calidad de sus productos?) valorando todo esto frente a los riesgos asociados a realizar el desarrollo nosotros mismos.

Pagina -> 43

La labor del ingeniero o analista de sistemas consiste, en definitiva, en asignar a cada elemento del sistema un mbito de funcionamiento y de rendimiento. Despus, el ingeniero del software se encargar de refinar este mbito para el componente software del sistema y de producir un elemento funcional, que sea capaz de ser integrado con el resto de los elementos del sistema. 4.3. Fases del anlisis de sistemas. El anlisis del sistema comprende las siguientes fases o tareas: Identificacin de las necesidades del cliente. Evaluacin de la viabilidad econmica, tcnica y legal del sistema. Asignacin de funciones a cada uno de los elementos del sistema. Obtencin de una definicin del sistema que sea la base del trabajo posterior.

4.3.1. Identificacin de las necesidades. Para identificar las necesidades, el analista del sistema debe reunirse con el cliente o con su representante. Juntos, proceden a definir los objetivos del sistemas, la informacin que se va a suministrar, la informacin que se va a obtener, las funciones y el rendimiento requerido. El analista debe ser capaz de distinguir entre lo que necesita el cliente (lo que es para l imprescindible), y lo que quiere el cliente (aquello que le sera til pero no imprescindible). 4.3.2. Estudio de viabilidad. Cualquier proyecto sera viable si dispusisemos de recursos humanos, temporales y econmicos ilimitados. Pero los recursos son siempre limitados: existen restricciones sobre el nmero de personas que se pueden dedicar (especialmente si se trata de personal del cliente), sobre cuanto dinero nos podemos gastar en el proyecto (si la inversin necesaria para el desarrollo es demasiado alta el sistema no compensar los ahorros que se produzcan con su uso) y sobre los tiempos de entrega (nadie compra software a cinco aos vista, adems, segn pasa el tiempo aumentan las posibilidades de que cambien los requisitos). Por esto, es conveniente estudiar la viabilidad del proyecto lo antes posible, puesto que as se pueden ahorrar meses de esfuerzos y millones de pesetas en el desarrollo de un proyecto que al final se muestre como inviable. El estudio de viabilidad est muy relacionado con el anlisis de riesgos: si el riesgo de un proyecto es grande, se reducen las posibilidades de producir software de calidad, es decir, disminuye la viabilidad. Nos centraremos fundamentalmente en tres aspectos:

Viabilidad econmica. Consiste en comparar los beneficios futuros de la

utilizacin del sistema con los costes de su desarrollo. La justificacin econmica es normalmente la principal consideracin a la hora de decidir realizar o no cualquier proyecto. Por esto, aparte de decidir la viabilidad o no viabilidad se necesita tambin un anlisis econmico completo (no slo si va a producir beneficios sino qu beneficios va a producir, a qu plazo, etc.).

Viabilidad tcnica. Consiste en determinar si es posible desarrollar o no el

producto, teniendo en cuenta sus restricciones, basndonos en los recursos humanos y tcnicos a nuestro alcance. Como los objetivos, funciones y rendimiento son confusos al inicio del proyecto, cualquier cosa puede parecer

Pagina -> 44

inicialmente viable. Debido a esto, es conveniente revisar el estudio de viabilidad tcnica una vez que las especificaciones estn ms claras. Adems, el anlisis de viabilidad tcnica debe ser completado con un estudio tcnico del sistema en proyecto, que permita determinar las caractersticas tcnicas del nuevo sistema y qu mejoras introduce sobre el proceso actual.

Viabilidad legal. Consiste en determinar si el proyecto infringe alguna disposicin

legal sobre el derecho a la intimidad de las personas, las normas de seguridad en el trabajo, de calidad de los productos, las leyes de Copyright si se van a utilizar componentes comprados a terceros para integrarlos en el sistema o basarnos en ellos para el desarrollo del producto software, y otras. 4.3.4. Anlisis econmico. El anlisis econmico del proyecto consistir en sealar los costes de desarrollo del proyecto y compararlos con los beneficios que producir una vez desarrollado. Los costes de desarrollo pueden ser cuantificados fcilmente (inversiones en equipos e infraestructura, horas-hombre necesarias en las fases de anlisis, diseo y codificacin). Sin embargo, suele ser ms difcil determinar los beneficios futuros que producir el proyecto una vez listo para ser usado. Algunos de estos beneficios pueden ser tangibles (disminucin del tiempo necesario para realizar determinadas tareas) pero otros muchos son intangibles (mayor satisfaccin o cualificacin profesional de los usuarios del sistema, incremento de la capacidad de produccin, etc.), por lo que puede ser difcil realizar comparaciones costebeneficio directas. Hay que tener en cuenta que la mayora de los sistemas de procesamiento de la informacin se realizan teniendo como principal objetivo una mayor cantidad, calidad y rapidez de acceso a la informacin, de forma que se pueda realizar una mejor gestin de la empresa. Todos estos beneficios citados son intangibles y, aunque se traducirn sin lugar a dudas en beneficios tangibles (ahorro en los costes de produccin o en las tareas administrativas, incremento de ventas como resultado de una mayor rapidez de respuesta a las necesidades del mercado, etc.) es muy difcil formular numricamente esta relacin. Por este motivo, los beneficios intangibles se incluirn en el anlisis econmico para reforzar la justificacin del proyecto, pero esta justificacin debe basarse en la medida de lo posible en los beneficios, medibles y demostrables que producir el nuevo sistema. Los costes y beneficios pueden ser directos o indirectos dependiendo de si es posible establecer una relacin de los mismos con la implantacin del software. Por ejemplo un aumento de la capacidad de gestin de un almacn es un beneficio directo de la implantacin de un sistema informtico para el control del mismo. El acondicionamiento del almacn para adaptarlo al nuevo sistema (redistribucin de espacios, etc.) puede considerarse un coste indirecto. La nica forma de demostrar estos beneficios ser comparando los modos de trabajo con el nuevo sistema con los modos de trabajo actuales. El nuevo sistema, cambiar los modos de trabajo de la empresa u organizacin en la que se instale de forma que se producir: una disminucin del tiempo necesario para realizar determinadas tareas. una menor necesidad de mano de obra para realizar el trabajo actual.

Pagina -> 45

un aumento de productividad, que permitir aumentar la produccin con la mano de obra actual. Cualquiera de los tres puntos anteriores puede ser evaluado cuantitativamente, de forma que se puede determinar el ahorro que se producir con la puesta en marcha del nuevo sistema. Pongamos como ejemplo el sistema de clasificacin de paquetes visto antes. Supongamos que el sistema actual es el que corresponde a la Asignacin 1 (es decir, es un sistema manual) y que el nuevo sistema es el indicado en la Asignacin 3 (utilizacin de un lpiz ptico y de un brazo robot). En primer lugar, calculemos los costes del sistema actual. Supongamos que para el funcionamiento en turno ininterrumpido, incluyendo operadores de guardia, necesitamos 7 operadores y que el coste salarial (incluyendo cargas sociales) de cada operador es de 2.5 M/ao. Podemos calcular el coste/hora del sistema actual, que resulta ser de 2000 ptas./hora, aproximadamente. Supongamos tambin que las inversiones necesarias para poner en marcha el sistema nuevo son de 40 M, que los costes de mantenimiento del brazo robot son de 1 M/ao y los costes de funcionamiento (gastos de electricidad) son de 2 M/ao. Adems, debido a las paradas por mantenimiento y averas, el sistema nuevo solo estar til el 95% del tiempo, debiendo efectuarse la clasificacin manual el 5% del tiempo restante. Esto resulta en unos gastos de puesta en marcha de 40M y unos gastos de funcionamiento de 3.875 M/ao. Podemos representar los beneficios y costes acumulados del nuevo sistema en una grfica (fig. 3.1) y calcular el tiempo de amortizacin (el punto donde se cortan ambas curvas: indica cunto tiempo ha de pasar para que los beneficios del sistema nuevo compensen los costes iniciales de puesta en marcha). Este tiempo de amortizacin resulta ser de 2.9 aos, aproximadamente. Un buen estudio de viabilidad econmica no es sencillo, puesto que resulta difcil la cuantificacin y el tratamiento de muchos de los elementos que intervienen en el mismo. Adems un buen anlisis requiere una labor mucho ms compleja de operaciones, estudios y recogida de informacin que la mostrada en el ejemplo anterior. 4.3.4. Anlisis tcnico. Con el anlisis tcnico se pretende estudiar las caractersticas tcnicas del nuevo sistema: capacidad, rendimiento, fiabilidad, seguridad, etc., de forma que se complemente el anlisis de coste-beneficio con las mejoras tcnicas que pueda proporcionar el sistema a los modos de trabajo de la empresa u organizacin donde se implante. Para hacer un buen anlisis tcnico tendremos que modelar el sistema de alguna forma, y realizar un estudio analtico de las caractersticas del modelo propuesto o bien realizar algn tipo de simulacin con el modelo. Los resultados del anlisis tcnico son otro de los criterios que permitirn decidir si seguir o no con el proyecto. Si el riesgo tcnico es alto, o si el modelo o las simulaciones muestran que el sistema en proyecto no va a conseguir substanciales mejoras sobre el sistema actual, podemos cancelar el proyecto. 4.3.5. Asignacin de funciones. Como ya habamos visto, para cada elemento del sistema puede haber una o varias asignaciones posibles. Es necesario estudiar cada una de las alternativas desde el punto de vista econmico y tcnico y elegir cul es la ms adecuada. Para elegir entre las distintas alternativas debemos fijar una serie de parmetros de evaluacin. Normalmente los parmetros de evaluacin sern de orden econmico (coste de las inversiones, ahorro que se producir con el sistema nuevo), pero tambin pueden tenerse en cuenta parmetros relacionados con la fiabilidad del sistema, su capacidad, su rendimiento o la mejora de calidad de los productos, si se trata de un sistema de produccin. Hay que ordenar cada uno de estos parmetros de acuerdo a su importancia, lo que depender de los objetivos generales de cada proyecto, y ver cul de las distintas

Pagina -> 46

alternativas obtiene una mejor evaluacin de acuerdo con los parmetros establecidos. Cuando dos o ms alternativas satisfagan los parmetros de evaluacin principales, optaremos entre ellas observando los parmetros de segundo orden y as sucesivamente. Por ejemplo, en el caso del sistema de clasificacin de paquetes, la alternativa elegida depender de qu parmetros consideremos ms importantes. Si queremos que la inversin inicial sea pequea la mejor alternativa ser la primera. Si pretendemos en cambio unos costes de funcionamiento moderados, valorando que el plazo de amortizacin sea corto, la mejor opcin ser la segunda. Si damos ms importancia a la fiabilidad y al bajo mantenimiento del sistema, la mejor opcin puede ser la tercera.

Sistema de clasificacin de paquetes. Criterios de evaluacin. Inversin inicial Coste funcionamiento Tiempo amortizacin Fiabilidad Mantenimiento Alternativa 1 Nula Grande Nulo Moderada Nulo Alternativa 2 Moderada Moderado Moderado Pequea Grande Alternativa 3 Grande Moderado Grande Grande Moderado

4.4. Representacin de la arquitectura del sistema. Una vez que hemos realizado la asignacin de funciones podemos hacer un diagrama del sistema que represente las relaciones entre sus elementos y que sirva de base para el trabajo posterior. Para ello utilizaremos los diagramas de arquitectura. Si la complejidad del sistema as lo aconseja podemos utilizar estos diagramas formando una jerarqua de niveles, en el nivel superior representaremos el sistema mediante un diagrama de contexto, e iremos detallando ms la arquitectura en sucesivos diagramas de flujo. 4.4.1. Plantilla de diagramas de arquitectura. Para que los diagramas tengan un formato estndar, los dividiremos en cinco regiones:

4.4.2. Diagrama de contexto. El diagrama de contexto representa el sistema en relacin con su entorno. Sirve para definir los lmites del sistema y muestra todos los productores y consumidores de informacin del sistema.

Pagina -> 47

El centro del diagrama de contexto estar ocupado por el sistema, representado por una caja de esquinas redondeadas. A su alrededor se situarn una serie de entidades o agentes externos (el entorno de sistema) representados mediante cajas de esquinas cuadradas. Cada agente externo representa un productor o consumidor de informacin del sistema. Cada agente externo se sita en la regin del diagrama que le corresponda, segn su papel sea el de productor, consumidor, usuario o supervisor. El sistema se relaciona con los agentes externos a travs de flujos de informacin y/o materiales, representados mediante arcos orientados. 4.4.3. Diagramas de flujo. Podemos describir la arquitectura del sistema en mayor grado de detalle a base de expandir el diagrama de contexto en una jerarqua de diagramas de flujo. Cada subsistema del diagrama de contexto puede dar lugar a un diagrama de flujo, donde se describir el sistema en mayor detalle, descomponindolo en nuevos subsistemas relacionados mediante flujos de informacin. Cada subsistema ocupa una regin del diagrama dependiendo de cul sea su funcin (adquisicin de datos, salida de datos, interfaz, etc.). Un detalle importante es que debe mantenerse la consistencia entre los diagramas de distinto nivel. Al expandir un determinado subsistema en un diagrama de flujo, los flujos de informacin que conectan dicho subsistema con otros o con agentes externos, deben figurar tambin (coincidiendo en nmero, sentido y nombre) en el diagrama de flujo resultado de dicha expansin. Estos flujos de informacin, tendrn un extremo libre, el que los conectaba con subsistemas que quedan fuera del mbito del nuevo diagrama de flujo. Anlisis de requisitos del software. Como resultado de la fase de anlisis de requisitos del sistema, se ha asignado una funcin y un rendimiento al componente software del mismo. Para conseguir esta funcin y rendimiento, el ingeniero del software debe construir - o adquirir - una serie de componentes software. Desgraciadamente, los componentes software estn muy poco estandarizados, por lo que las dos nicas opciones sern el adquirir un sistema software comercial que cumpla con los requisitos - si este sistema existe y logramos encontrarlo - o desarrollar (o encargar el desarrollo) de un sistema software a la medida. 4.5. Objetivos del anlisis de requisitos del software. El anlisis de requisitos del software tiene como objeto desarrollar una representacin del software que pueda ser revisada y aprobada por el cliente y es una tarea que sirve de enlace entre la asignacin de funciones al software que se ha hecho en el anlisis del sistema y el diseo del software. Desde el punto de vista del analista de sistemas, el anlisis de requisitos del software define con mayor precisin las funciones y rendimiento del software, las interfaces que ha de tener con otros componentes del sistema y las restricciones que debe cumplir. Desde el punto de vista del diseador, el anlisis de requisitos proporciona una representacin de la informacin y la funcin del sistema que l se encargar de traducir en un diseo de datos y programas. Por ltimo, el anlisis de requisitos, incluido en la especificacin del proyecto, permite a todos (incluido aqu el cliente) valorar la calidad del software una vez que haya sido construido. La labor del analista debe centrarse en el qu, no en el cmo. (qu datos debe manejar el sistema software?, qu funcin debe realizar?, qu interfaces debe tener?, y qu restricciones tiene que cumplir?) El anlisis de requisitos puede entenderse como una tarea de anlisis sntesis: el ingeniero del software debe analizar el problema y los objetivos del cliente y, a partir de esto, sintetizar soluciones.

Pagina -> 48

Inicialmente, el, ingeniero del software o analista, estudia la especificacin resultado del anlisis del sistema, con el objetivo de comprender cul es el papel del software en el contexto del sistema. Tambin debe revisar el plan del proyecto software (la planificacin de proyectos se ve el ao que viene) para comprobar las estimaciones que se han hecho a la hora de planificar el proyecto. A continuacin, debe ponerse en contacto con el equipo tcnico y de gestin del cliente, para poder conocer los objetivos bsicos del software tal como los entiende el cliente. Con la informacin obtenida de la especificacin del sistema y de las entrevistas con el cliente/usuario el analista debe ir definiendo y refinando los flujos y la estructura de la informacin, la funcin del programa y su papel en el contexto del sistema, las caractersticas de las interfaces y las restricciones de diseo. Con este conocimiento que se va adquiriendo del sistema software, el analista debe sintetizar una o varias soluciones al problema, comprobando que se ajustan al plan del proyecto y a las necesidades del cliente. Este proceso de anlisis del problemas y sntesis de soluciones debe proseguir hasta que el analista y el cliente acuerden una solucin y se pueda especificar el software de forma adecuada para que se puedan efectuar las siguientes fases de desarrollo. Como ayuda en este proceso de anlisis-sntesis, el analista utiliza modelos para entender mejor los flujos de informacin y la funcin de cada elemento del sistema software. Estos modelos servirn de base para el diseo de software. A partir de estos modelos pueden desarrollarse prototipos del sistema software. Esto estar especialmente indicado cuando el cliente no est seguro de lo que quiere realmente o cuando el analista necesite comprobar si una solucin determinada resuelve efectivamente el problema. Los prototipos pueden ser utilizados por el cliente para refinar los requisitos o comprobar la validez de la solucin propuesta. 4.6. El papel del analista. El analista es el principal puente que se establece entre el cliente y los desarrolladores. No slo desarrollar su trabajo en la fase de anlisis de requisitos sino que lo normal es que est presente en todas las revisiones que se hagan a lo largo del desarrollo del proyecto. En su trabajo, el analista debe entrevistarse con mltiples personas, que tendrn una visin distinta del problema y de su solucin incluso tendrn intereses contrapuestos. Un buen analista, por tanto, debe facilidad de comunicacin, debe ser capaz de extraer informacin relevante a partir de fuentes confusas o contradictorias, reorganizar esta informacin para sintetizar soluciones y debe servir de mediador entre las partes. Adems de todo esto, debe tener los conocimientos tcnicos y la experiencia necesarios para poder aplicar la informtica a los problemas del cliente, debe conocer o ser capaz de asimilar conocimientos sobre el campo de actividad del cliente y debe tener claros los principios bsicos de la ingeniera del software para poder incorporar estos principios a los requisitos del sistema de forma que se desarrolle software de calidad. 4.7. Recogida inicial de requisitos Uno de los mayores problemas que surgen en la fase de recogida inicial de requisitos es cmo organizar toda la informacin que adquiere el analista en sus entrevistas con las personas involucradas en un proyecto y cmo poner de acuerdo a todas estas personas sobre cul es la solucin ms adecuada. Mientras que los mtodos clsicos se basan en entrevistas bilaterales (el analista y cada una de las partes) con lo que dejan para el analista toda la labor de organizacin y obtencin de un consenso, ltimamente se tiende a prcticas ms relacionadas con el brainstorming en el que cada parte expone sus ideas y propuestas y se produce un debate de forma que las posiciones vayan acercndose sucesivamente hasta que se llegue a un consenso. El mtodo de trabajo sera el siguiente:

Pagina -> 49

Inicialmente se llevan a cabo unas reuniones preliminares con el cliente (el que ha encargado el proyecto) con vistas a aclarar el mbito del problema y los objetivos generales de una solucin del mismo. Como resultado de estas reuniones, el analista y el cliente redactan una descripcin breve del problema y los objetivos del proyecto y el esquema general de la solucin. A continuacin se convoca una reunin en la que deben estar representados el analista, el cliente y el equipo de desarrollo. Los invitados a la reunin deben conocer previamente la descripcin del problema y su solucin redactada anteriormente y se les pide que elaboren una relacin preliminar de los objetos o entidades que pueden identificar en el sistema o su entorno, las operaciones que se realizan o sirven para interrelacionar estos objetos, las restricciones que debe cumplir el sistema y los rendimientos que se esperan del mismo. Para conducir la reunin se nombra a un moderador neutral. La reunin comienza discutiendo la necesidad y justificacin del proyecto (es decir, debatiendo el documento preliminar). Una vez que todo el mundo est de acuerdo en la necesidad de desarrollar el producto, se puede pasar a presentar cada una de las listas de objetos, operaciones, restricciones y rendimientos realizadas individualmente. A partir de estas listas individuales se crean listas combinadas, en las que se agrupa lo redundante pero no se elimina nada. Puede entonces comenzar la discusin sobre la lista combinada, en la que se pueden aadir nuevos elementos, eliminar otros o reescribirla de forma que refleje correctamente el sistema a desarrollar. Hay que realizar una miniespecificacin de cada uno de los elementos de las listas, donde se defina brevemente cada uno de dichos elementos. El desarrollo de estas miniespecificaciones puede descubrir nuevos elementos o demostrar que alguno de ellos est incluido en otro. Se pueden dejar en el aire ciertos aspectos siempre y cuando se registre que deben ser tratados posteriormente. Una vez concluida la reunin el analista debe elaborar un borrador de especificacin del proyecto, combinando las miniespecificaciones de cada elemento, que servir de base para todo su trabajo posterior. Este enfoque en equipo de la recogida inicial de requisitos proporciona numerosas ventajas, entre las que se pueden citar la comunicacin multilateral de todos los involucrados en el proyecto, el refinamiento instantneo y en equipo de los requisitos a partir de las ideas previas individuales y la obtencin de un documento que sirva de base para el proceso de anlisis. Recogida inicial de requisitos. Mtodo de trabajo. Redaccin de un documento inicial: Descripcin del problema. Objetivos. Propuesta de solucin (si es posible). Creacin de listas individuales de: Objetos: del sistema y del entorno Operaciones: relacin entre los objetos Restricciones Rendimiento Creacin de una lista conjunta Discusin de la lista conjunta Redaccin de miniespecificaciones Redaccin de un borrador de la especificacin 4.8. Especificacin preliminar. La especificacin preliminar debe indicar qu es lo que hay que hacer, pero no cmo hay que hacerlo. Debe ser una descripcin de las necesidades y no una propuesta de

Pagina -> 50

solucin. El cliente debe indicar qu caractersticas son imprescindibles y cules opcionales, y debe evitar describir la estructura interna del sistema, para no reducir la flexibilidad en la implementacin. Caractersticas como, rendimiento, protocolos de comunicacin, standares de la IS (construccin modular, previsin de expansiones futuras, etc.), y, en algunos casos, la eleccin del soporte hardware y el lenguaje de implementacin, pueden figurar en esta especificacin. Otras decisiones de diseo, como el uso de un determinado algoritmo, no tienen nada que ver con el anlisis y no son propiamente requisitos del sistema. La especificacin preliminar no es un documento inmutable. Normalmente ser ambiguo, incompleto, incorrecto e inconsistente. Incluso aunque estn expresados de forma precisa, algunos de los requisitos reflejados pueden causar efectos secundarios no deseados (gran cantidad de informacin almacenada, tiempos de carga o de ejecucin muy grandes) o llevar a costes de implementacin demasiado grandes, frente a unos beneficios pequeos o innecesarios. Es necesario tomar la decisin de cumplir o no estos requisitos. 4.9. Principios del anlisis de requisitos. A lo largo de la historia de la Ingeniera del Software se han ido desarrollando diversos mtodos de anlisis del software, y diversas herramientas para facilitar el uso de estos mtodos. Cada uno de los mtodos tiene sus peculiaridades, utiliza una notacin grfica o textual distinta y tiene un campo de aplicacin distinto. Sin embargo todos se basan en un conjunto de principios fundamentales. Principios de anlisis de requisitos del software Identificar y representar el mbito de informacin del problema. Modelar la informacin, la funcin y el comportamiento del sistema. Descomponer el problema de forma que se reduzca la complejidad. Avanzar desde lo ms general a lo ms detallado Los dos primeros puntos se refieren, por tanto, a conseguir representar el sistema y la informacin que maneja mediante un diagrama o una representacin textual que permita comprender fcilmente qu informacin se maneja y qu funciones se realizan con esta informacin. Los dos ltimos se refieren a un mtodo de trabajo top-down, que permita la divisin del problema en subproblemas, y vaya avanzando de los ms general a lo ms especfico, de forma que la sntesis de la solucin siga una estructura jerrquica. 4.9.1. El mbito de informacin. La tarea que realiza el software va a consistir siempre en procesar informacin: cualquier aplicacin que consideremos responde a una estructura de entradaprocesamiento-salida, donde el software se encarga de procesar unos determinados datos de entrada para producir unos datos de salida. Pero en un sistema software, la informacin no est representada slo por datos sino tambin por sucesos o eventos. En el sistema de clasificacin de paquetes se procesa el nmero de identificacin de cada paquete, obtenindose el contenedor donde debe ser almacenado. Pero tambin se procesan sucesos: la clasificacin de paquetes se para si sucede que los contenedores se llenan; o se genera un informe de los paquetes procesados si el operador lo solicita. Los eventos son normalmente datos de tipo lgico (la activacin o desactivacin de la seal de un sensor, por ejemplo) y su procesamiento est ligado con el control del sistema. En un sentido general, podemos decir que la informacin que maneja un sistema software se divide en datos y eventos. Los datos se refieren normalmente a la informacin que procesa el sistema y los eventos a cundo debe procesarse esa informacin. El mbito de informacin del sistema admite, por tanto, dos puntos de vista: por un lado, el flujo de datos (cmo se mueven los datos por el sistema y cmo se van transformando estos datos), y por otro, el flujo de control (cmo se controla el sistema y cundo hay que realizar cada procesamiento).

Pagina -> 51

4.9.2. Modelado del sistema software. Los modelos se utilizan en el campo de la ingeniera para entender mejor lo que se quiere construir. En la Ingeniera del Software se utilizan modelos para la informacin que transforma el software (modelos de datos), para las funciones que transforman esa informacin (modelos de procesos) y tambin para definir el comportamiento del sistema (modelos de control). Todos los mtodos de anlisis que veremos posteriormente son en realidad mtodos de modelado de sistemas. Los modelos que se realizan en la fase de anlisis sirven para tres cosas: Utilidad de los modelos Ayudan al analista a entender la informacin, la funcin y el comportamiento del sistema, con lo que el anlisis puede hacerse de forma ms fcil y sistemtica. Sirven de base para el trabajo del diseador. La arquitectura de las aplicaciones y los datos debe corresponderse con los modelos del anlisis. Sirven tambin para realizar la validacin del producto una vez desarrollado. Por una parte, el sistema final debe comportarse como indica el modelo. Por otra, el sistema final permite comprobar la consistencia y la eficacia de la especificacin. Para realizar un modelo podemos utilizar una notacin grfica (y el modelo estar representado mediante una serie de diagramas) o bien una notacin textual (y tendremos modelos en lenguaje natural o en un lenguaje de especificacin ms formal). 4.9.3. Descomposicin del sistema. La descomposicin se utiliza para abordar problemas que son demasiado grandes o demasiado complejos para resolverlos directamente. Mediante descomposicin, el problema se divide en subproblemas ms sencillos, que realizan una funcin ms clara y que pueden entenderse ms fcilmente. La descomposicin se puede aplicar a los mbitos de la informacin, de la funcin o del comportamiento. 4.9.4. Anlisis de lo general a lo especfico. Descomponiendo un problema en subproblemas, y definiendo modelos de cada uno de estos problemas y subproblemas, llegaremos a establecer una jerarqua de modelos, que irn desde el ms general (el de arriba del todo) a los ms especficos (en los niveles bajos de la jerarqua). Cada modelo de la jerarqua produce, por descomposicin de las funciones que realiza, una serie de modelos, cada uno de los cuales realiza una de estas funciones y que tendrn un mayor nivel de detalle.
sistema

a1

a2

b1

b2

b11

b12

b13

Fig. 3.3. Jerarqua de modelos

Pagina -> 52

4.10. Principios de especificacin. La especificacin, independientemente del modo en que se realice, puede ser vista como un proceso de representacin. Los requisitos se representan de forma que conduzcan finalmente a una correcta implementacin del sistema.. Podemos establecer una serie de principios que deben seguirse para obtener una buena especificacin. Estos principios son los siguientes: Principios de la especificacin. Es necesario separar funcionalidad e implementacin. El lenguaje de especificacin debe estar orientado al proceso. La especificacin debe abarcar todo el sistema del que el software es parte. La especificacin debe abarcar tambin el entorno del sistema. La especificacin debe modelar el dominio del problema. La especificacin debe ser operativa. La especificacin debe ser ampliable y tolerante a la incompletitud. La especificacin debe estar localizada y dbilmente acoplada. Es necesario separar funcionalidad e implementacin. Una especificacin es, por definicin, una descripcin de lo que se quiere realizar, no de cmo se va a realizar o implementar. Como ejemplo de esto podemos tomar una especificacin formal expresada mediante algn lenguaje declarativo: dado un conjunto de valores de entrada se produce otro de salida. Estas especificaciones se centran exclusivamente en el qu y no en el cmo. Esto es debido a que el resultado es una funcin matemtica de la entrada. En estos casos de lo que se trata es de buscar alguna o todas las soluciones, tales que se cumpla P(entrada), donde P es un predicado que representa al sistema. El lenguaje de especificacin debe estar orientado al proceso. El ejemplo anterior muestra cmo se modelan sistemas que no estn afectados por el entorno. Sin embargo, un caso ms general debe considerar un sistema que interacte con un entorno dinmico, modificando su comportamiento segn los estmulos que recibe. Este podra ser el caso de un sistema empotrado. En este caso no podemos representar el sistema mediante una funcin matemtica que relacione la entrada y la salida, sino que debemos emplear una descripcin orientada al proceso, en la que la especificacin del qu se consigue estableciendo un modelo del comportamiento deseado en trminos de respuestas funcionales a distintos estmulos del entorno. La especificacin debe abarcar todo el sistema del que el software es parte. Un sistema est compuesto de partes que interactan. El comportamiento de un componente especfico, como es el software, slo puede ser definido en el contexto del sistema completo. Por tanto, la especificacin debe describir todos los componentes del sistema, estableciendo las interfaces entre estos componentes, y no slo el componente software La especificacin debe abarcar tambin el entorno del sistema. Por el mismo motivo, hay que especificar tambin el entorno en el que opera el sistema. La especificacin del entorno permite describir la interfaz del sistema de la misma forma que las interfaces de los componentes del mismo. De esta forma podemos representar sistemas dinmicos cuyo comportamiento vara dependiendo de los estmulos que reciban del entorno. Esta especificacin del entorno no se hace con vistas a implementarlo, puesto que ya nos viene dado y no podemos modificarlo, sino que sirve para definir los lmites del sistema y su interfaz, permitiendo adems probarlo.

Pagina -> 53

La especificacin debe modelar el dominio del problema. La especificacin del sistema ha de ser un modelo del dominio del problema, en vez de un modelo de diseo o implementacin. Debe describir el sistema tal como es percibido por los expertos en el dominio de aplicacin. Los elementos del sistema deben corresponderse con objetos reales de dicho dominio, ya sean individuos, mquinas u organizaciones, y las acciones que se realizan deben corresponderse con lo que realmente ocurre en el dominio del problema. Adems, deben poder describirse en la especificacin las reglas o leyes que gobiernan los objetos del dominio de aplicacin. Algunas de estas leyes son restricciones sobre los estados del sistema, del tipo de dos objetos no pueden estar en el mismo lugar al mismo tiempo y otras describen cmo responden los objetos cuando se acta sobre ellos (por ejemplo las leyes del movimiento de Newton). En este caso, son parte inherente de las especificaciones del sistema. Para que esto sea posible, el formato de la especificacin y su contenido deben ser adecuados al problema. La especificacin debe ser operativa. La especificacin ha de servir para determinar si una implementacin concreta la satisface. Esto puede hacerse bien mediante la verificacin de la correccin del sistema implementado, cosa que normalmente no puede demostrarse, o bien mediante una serie de casos de prueba elegidos arbitrariamente. A partir de los resultados de una implementacin sobre un conjunto arbitrario de datos de entrada, debe ser posible usar la implementacin para validar estos resultados, a pesar de que la especificacin no describa el cmo sino solamente el qu. Este principio no establece que la especificacin tenga que ser ejecutable, sino ms bien que pueda ser utilizada para demostrar teoremas. La especificacin debe ser ampliable y tolerante a la incompletitud. Una especificacin es un modelo o abstraccin de un sistema real, por tanto nunca ser completa, y puede desarrollarse a distintos niveles de detalle. Normalmente el desarrollo de especificaciones se hace de forma incremental, estando en cada momento elementos del sistema parcialmente especificados. Aunque esto debilita el anlisis, las herramientas de prueba de las especificaciones y de comprobacin de que las implementaciones son correctas deben ser capaces de manejar especificaciones incompletas. La especificacin debe estar localizada y dbilmente acoplada. Durante su desarrollo, una especificacin sufre continuas modificaciones. Por este motivo, la estructura de la especificacin debe permitir que estas modificaciones se realicen lo ms fcilmente posible. El principio de localidad establece que si es necesario modificar un elemento de la especificacin, esta modificacin se realice slo en un punto de la misma. El principio del acoplamiento dbil establece que se puedan aadir y quitar partes de la especificacin fcilmente. Par cumplir estos dos principios la especificacin ha de ser no redundante y modular, con interfaces breves y bien definidas. Marco de la Gestin de Proyectos Con el marco de gestin de proyectos lo que se desea es mejorar y gestionar mejor los proyectos software.

Pagina -> 54

Sistemas / proyectos mas complejos Imperativo mejorar la prediccin y control de dichos sistemas / proyectos Utilizar tcnicas para el desarrollo de las especificaciones y diseo no es suficiente. El proceso de construccin de software tiene que ser gestionado y dirigido de manera rigurosa y cuantitativa. Enfoque en el Proyecto y Procesos Claves del xito en las gestin del desarrollo de software: Gestin del proyecto de desarrollo de SW Utilizacin de tcnicas y actividades de gestin requeridas para obtener un producto software de alta calidad, de acuerdo a las necesidades de los usuarios, dentro de un presupuesto y con una planificacin de tiempos establecidos previamente Gestin del proceso de software Conjunto de tcnicas y actividades que permiten una adecuacin de los procesos personales del los constructores y de los productos que participan en el proyecto La gestion de proyectos consiste en en considerar los siguientes aspectos: Estimacin de duracin, coste y esfuerzo Planificacin Seguimiento

La Estimacin segn el Diccionario: Es un conjunto de aproximado de valores para algo que ha de ser hecho. Segn Larry Putman Estimacin es la actividad que permite obtener, principalmente, respuestas aproximadas a las siguientes preguntas: Cunto costar? Cunto tiempo llevar hacerlo? Para resolver estas interrogantes existe las mtricas de calidad de software como se mencionan a continuacin:

Pagina -> 55

Mtricas de Software Clasificacin Mtricas de Producto Complejidad del diseo Tamao del producto final Documentacin producida Mtricas de proceso Tiempo de desarrollo Esfuerzo en das/hombre Nivel medio de experiencia de programadores. Mtricas de Producto Tamao Lineas de Cdigo Linea de texto de un programa que no es comentario ni linea en blanco NCLOC) Tambin se cuentan las lineas de comentario para obtener otros indicadores (CLOC) No se debe utilizar esta medida directamente en la estimacin de esfuerzo o productividad. Funcionalidad Cantidad de funciones que un producto proporciona Mtodo mas conocido: Function Point Analysis La funcionalidad es un atributo muy importante y es la mejor aproximacin existente hasta la fecha Estimacin mediante Puntos de Funcin Una de las tareas ms importantes en la elaboracin de un proyecto es la planificacin de los diferentes procesos a realizar y sus dependencias, como consecuencia de esta planificacin se podr fijar una fecha de entrega del proyecto, evaluar su costo y los recursos necesarios. El anlisis de la aplicacin (DFD, E-R) ser el punto de partida para evaluar la complejidad de la aplicacin por medio de los puntos de funcin, que nos darn una valoracin del esfuerzo necesario en el desarrollo. Con los Puntos de Funcin se realizar una aproximacin del esfuerzo en horas y por ltimo se realizar un reparto del tiempo entre las diferentes tareas y se estudiarn sus dependencias. Los Puntos de Funcin miden la aplicacin desde una perspectiva del usuario, dejando de lado los detalles de codificacin. Es una tcnica totalmente independiente de todas las consideraciones de lenguaje y ha sido aplicada en ms de 250 lenguajes diferentes. Se supone que FPA evala con fiabilidad

El valor comercial de un sistema para el usuario Tamao del proyecto, coste y tiempo de desarrollo Calidad y productividad del programador mis Esfuerzo de adaptacin, modificacin y mantenimiento

Pagina -> 56

Posibilidad de desarrollo propio Beneficios de implementacin en el lenguaje apropiado.

Un Punto de Funcin se define como una funcin comercial de usuario final. De esta manera un programa que tenga x PFs entrega x funciones al usuario final. El mejor modo de trabajo es la interaccin analista-usuario. El proceso requiere dos etapas fundamentales: 1. Se identifican las funciones disponibles para el usuario y se organizan en cinco grupos (mejor en este orden) Salidas Consultas Entradas Ficheros Interfaces.

Despus se clasifica y pondera cada funcin por su nivel de complejidad (simple, media, compleja). 2. Se ajusta este total de acuerdo con unas caractersticas del entorno. Puntos de Funcin. Los Puntos de funcin es una tcnica que trata de medir una aplicacin basndose en sus caractersticas externas. Por un lado se evala los requerimientos de la aplicacin midiendo los accesos a ficheros, informes, etc. y por otro se evala el entorno de la aplicacin. Elementos de Funcin. En este mtodo se contabilizan los accesos a ficheros, entradas al sistema, salidas y consultas. En todos los elementos de funcin se evala para cada flujo de datos la cantidad de campos que transmite y l nmero de ficheros que son accedidos como consecuencia del proceso que recibe el flujo. Entradas desde el exterior del sistema.

Son entradas todos los flujos de datos procedentes del exterior de la aplicacin. Ejemplos de entradas seran pantallas de entrada de datos y otros tipos de entradas a travs de perifricos. Se evalan los procesos que tienen datos que entran desde el exterior y como consecuencia se actualiza algn fichero lgico, el proceso es completo y exclusivo de entrada o los datos elementales son diferentes de otras entradas. Entradas . Se debe contar cada dato nico de usuario o entrada de control que se introduce en los lmites de la aplicacin y actualiza un fichero lgico interno, conjunto de datos, tabla o

Pagina -> 57

dato independiente. Esto incluye ficheros de entrada y transacciones recibidas de otras aplicaciones. Una entrada se considera nica si 1. tiene un formato diferente 2. tiene el mismo formato que otra entrada pero requiere una lgica diferente de procesamiento, o se modifica un fichero interno lgico diferente. Supongamos que tenemos dos pantallas de entrada, cada una con el mismo formato pero con diferente lgica de procesamiento. Se cuenta cada pantalla como una entrada diferente; pero si tuvieran la misma lgica slo se contara una. Lo mismo sucede con la repeticin de pantallas. Supongamos que tenemos un pantalla cuya funcin es actualizar un fichero o un conjunto de datos. Puesto que cada una de las tres funciones de actualizacin (aadir, cambiar, borrar) requiere diferente lgica de procesamiento tendremos tres entradas, no una. Cada fichero tendr tres entradas, as como una salida (el fichero formateado de salida) y una consulta. Tipos de entradas pueden ser: El ratn Documentos MICR Transacciones de cintas Pantallas sensitivas Lectores de cdigo de barras, etc.

Todas las entradas se evalan y se agrupan en funcin de la siguiente tabla: DIFICULTAD ENTRADAS 0 o 1 Ficheros accedidos 2 Ficheros accedidos 3 o + Ficheros accedidos Numero de Campos o Atributos de la Entrada. 1-4 Atributos. 5-15 Atributos 16 o ms Atributos Baja Baja Media 3 3 6 Baja Media Alta 3 6 9 Media Alta Alta 6 9 9

Salidas al exterior del sistema.

Son salidas todos los flujos de datos procedentes de procesos que transmiten informacin al usuario o a otra aplicacin, ejemplos de salidas serian pantallas de introduccin de informacin, listados y comunicacin con otras aplicaciones. Se evalan los procesos que envan datos al exterior, el proceso es completo y el proceso es exclusivo de salida o los datos elementales son diferentes de otras salidas. Salidas .

Pagina -> 58

Se debe contar cada dato nico de usuario o salida de control generado proceduralmente y que sale del lmite de la aplicacin. Esto incluye informes y mensajes a otras aplicaciones y usuarios. Una salida se considera nica si 1. Tiene formato diferente 2. Tiene el mismo formato que otra salida pero requiere diferente lgica de procesamiento. Adems de las pantallas y los listados (papel o pantalla), tambin pueden ser salidas: Fichero de transaccin enviado a otra aplicacin Facturas Cheques Fichas perforadas Transacciones automticas Mensajes al usuario Cintas Grficos Ficheros back-up, etc.

No se deben contar como salidas: Cabeceras de columna, ttulos, nmero de pgina Mensajes individuales (informacin, confirmacin o respuestas a consultas de error) Salida en igual formato y lgica que ya se hay contado para otro soporte.

Todas las salidas son evalan y se agrupan en funcin de la siguiente tabla: DIFICULTAD SALIDAS 0 o 1 Ficheros accedidos 2 o 3Ficheros accedidos 4 o + Ficheros accedidos Consultas. Numero de Campos o Atributos de la Salida. 1-5 Atributos. 6-19 Atributos 20 o ms Atributos Baja Baja Media 4 4 5 Baja Media Alta 4 5 7 Media Alta Alta 5 7 7

Son consultas los procesos que combinan flujos de datos procedentes de entrada y salida. Los procesos no modifican la informacin del sistema, ejemplos de consultas serian pantallas de consulta de informacin. Se evalan los procesos que reciben una peticin del exterior y como consecuencia se envan datos al exterior, no se recuperan datos, no se calculan datos derivados y el proceso no actualiza ficheros internos.

Pagina -> 59

Todas las consultas se evalan en las tablas de entradas y salidas seleccionando la de mayor peso. Consultas. Se debe contar cada combinacin nica de entrada/salida en la que la entrada online definida por el usuario genera una salida inmediata on-line. Las consultas se pueden proporcionar hacia o desde otra aplicacin; por ejemplo, responder a otra aplicacin que pregunta por el precio de un producto se contara como una consulta. Una consulta se considera nica si 1. Tiene un formato diferente de otras bien en su entrada o salida 2. Tiene el mismo formato, tanto entrada como salida, que otra consulta pero requiere diferente lgica de procesamiento en cualquiera de los dos. Una consulta directa en una base de datos o fichero maestro es aquella que 1. Utiliza claves simples para recuperar datos especficos -esto es, un registro simple o grupo de registros, no un rango. 2. Requiere respuesta inmediata, y 3. No realiza funciones de actualizacin (aunque se pueden efectuar clculos). Las consultas pueden aparecer en consulta de usuario/display sin actualizacin de fichero u otra entidad lgica fichero de transaccin que sale del lmite de la aplicacin si est accesible al usuario on-line pantalla de seleccin de men (todas las pantallas de men cuentan como una consulta) mensaje de informacin o pantalla de ayuda. Ficheros Lgicos Internos.

Son Ficheros Lgicos Internos agrupaciones de datos tal y como los ve el usuario, ejemplos de ficheros serian Clientes, Artculos, Facturas. Los ficheros se cuentas una sola vez independientemente del nmero de procesos. Se cuentan los ficheros que son una agrupacin lgica de datos identificable por el usuario, los datos que son mantenidos por nuestra aplicacin y la agrupacin de datos que no ha sido contada como un fichero de interfaz externo. Ficheros . Se debe contar cada grupo lgico mayor de datos de usuario o de informacin de control mantenidos dentro de los lmites de la aplicacin. El mtodo de Puntos de Fusin distingue entre dos tipos de ficheros: ficheros con transacciones temporales y ficheros con registros lgicos de datos permanentes. Slo los almacenamientos de datos permanentes se ven como ficheros lgicos. Cuando se mantienen dentro de la aplicacin se clasifican como "ficheros internos lgicos". Si se comparten entre aplicaciones se clasifican como interfaces y cmo ficheros internos lgicos.

Pagina -> 60

Las transacciones, por el contrario, se considera que son sucesos que desencadenan cambios en los ficheros lgicos internos; no se clasifican como ficheros. Un fichero transaccin se puede clasificar como entrada si es ledo para actualizar datos en un fichero lgico interno. Un fichero transaccin puede ser un interface o una salida si trasfiere transacciones de actualizacin a otra aplicacin. Cuando se utiliza anlisis estructurado cada almacenamiento de datos contendr al menos un fichero lgico interno. Hay que enfatizar que hablamos de ficheros lgicos. Supongamos que un fichero fsico contiene dos claves diferentes, entonces contaramos dos ficheros lgicos internos, puesto que cada camino presenta diferente informacin. Del mismo modo, cada vista lgica del usuario en una base de datos se cuenta como un fichero. Se pueden encontrar ficheros en : etc. bases de datos: 1 por vista lgica o camino de acceso ficheros maestros: 1 por cada grupo de claves tablas mantenidas por los usuarios: estados, tarifas, mensajes, fichero de procesamiento batch ndices de referencias cruzadas

Los ficheros lgicos Internos lo evaluamos en funcin a la siguiente tabla: DIFICULTAD LOGICOS 1 Entidad Reg. Lgico 2-5 Entidad Reg. Lgico 6 +Entidad Reg. Lgico Numero de Campos o Atributos de la Salida. 1-19 Atributos. 20-50 Atributos 51 o ms Atributos Baja Baja Media 7 7 10 Baja Media Alta 7 10 15 Media Alta Alta 10 15 15

Ficheros Lgicos Externos.

Son Ficheros Lgicos Externos agrupaciones de datos tal y como los ve el usuario pero que no estn mantenidos por esta aplicacin. Como ejemplos se podran citar ficheros de Cdigos Postales o informacin de ficheros que se utilizan solo para consultas. Se cuentan los ficheros que son una agrupacin lgica de datos identificable por el usuario, los datos son mantenidos por otra aplicacin y la agrupacin de datos no ha sido contada como un fichero de interfaz Interno. Interfaces. Se debe contar como uno cada fichero lgico de otro grupo de datos (o informacin de control) que se enva fuera de los lmites de la aplicacin, o se comparte o es recibido desde otra aplicacin. Los ficheros que se comparten entre aplicaciones se cuentan como ficheros y como interfaces en cada aplicacin en la que se utilizan; de

Pagina -> 61

otro modo slo se puntuar como fichero en aquella aplicacin que utilice o mantenga el fichero (la otra slo recibir puntos de interface). Esto es, cada fichero interface debe ser tambin un fichero interno lgico en esa aplicacin, en otra o en ambas; o puede ser un fichero de transaccin o de impresin generado en la propia aplicacin. Las interfaces habitualmente involucran ficheros maestros, no transacciones. Hay diferencia entre ficheros maestros lgicos y ficheros transaccin. Si las aplicaciones se relacionan a travs de transacciones entonces se puntuarn entrada, salida, y/o consulta, y, quiz, interface. Si lo hacen a travs de ficheros maestros entonces se puntuar interface y, quiz, fichero. Un fichero transaccin no se contar como interface si el formato con el que lo recibe el otro programa es el mismo (no hay conexin). El programa receptor lo contara como entrada. Si el programa que lo enva realiza el trabajo de conversin entonces se contar (para ste) una salida y un interface. Los interfaces se pueden encontrar en: 1. Ficheros lgicos internos accesibles desde otra aplicacin 2. Ficheros lgicos internos accedidos en otra aplicacin 3. Base de datos compartida 4. Lista de parmetros compartida 5. Fichero de impresin exportado 6. Fichero transaccin compartido que requiere conversin. Se contarn como un interface Fichero de registros de otra aplicacin (en la otra aplicacin (+1 fichero, +1 interface) Fichero de registros a otra aplicacin (+1 fichero) (otra aplicacin +1 interface) Fichero de registros a varias aplicaciones (+1 fichero) - afecta al peso de complejidad tambin. Fichero de registros compartido entre dos o ms aplicaciones (+1 fichero) (para las otras aplicaciones: +1 interface, +1 fichero en cada aplicacin si realizan mantenimiento) Base de datos compartida con otras aplicaciones (+1 fichero) 1 interface por cada vista realmente enviada (para la otra aplicacin: +1 fichero, +1 interface por cada vista utilizada) Base de datos compartida de otras aplicaciones (+1 fichero) 1 interface por cada vista utilizada (para la otra aplicacin: +1 fichero, +1 interface por vista) Fichero transaccin de otra aplicacin con conversin de datos (+1 entrada) Fichero transaccin enviado a otra aplicacin con conversin de datos (+1 salida). Los ficheros transaccin slo se cuentan en una aplicacin (no en las dos) Lista de parmetros.

Pagina -> 62

Los ficheros lgicos Internos se evalan en funcin a la siguiente tabla: DIFICULTAD DE INTERFAZ 1 Entidad Reg. Lgico 2-5 Entidad Reg. Lgico 6 +Entidad Reg. Lgico Ejemplo Prctico: Despus de contabilizar los puntos de funcin de un sistema de inventarios se obtienen los siguientes resultados: Tipo De Dificultad Peso Cantidad Total Puntos Elemento Entradas Simple 3 9 27 Media 4 2 8 Compleja 6 Total Puntos de Funcin Entradas: Salidas Simple 4 4 16 Media 5 1 5 Compleja 7 Total Puntos de Funcin Salidas: Consultas Sal Simple 4 Ent Media 4 9 36 Sal Media 5 Ent Compleja 6 Sal Compleja 7 Total Puntos de Funcin Consultas: Fich. Internos Simple 7 5 35 Media 10 2 20 Compleja 15 Total Puntos de Funcin Ficheros Internos: Fich. Simple 5 Interfaces Media 7 Compleja 10 Total Puntos de Funcin Ficheros Interfaces: Total Puntos de Funcin sin ajustar Total Elemento Numero de Campos o Atributos de la Salida. 1-19 Atributos. 20-50 Atributos 51 o ms Atributos Baja Baja Media 5 5 7 Baja Media Alta 5 7 10 Media Alta Alta 7 10 10

35

21

36

55

0 147

Factores de Complejidad. En esta fase se miden las caractersticas externas de la aplicacin basndose en el entorno en el que aplicacin se implanta, se valora una serie de factores de complejidad evalundolos en una escala de 0 al 5.

Pagina -> 63

Para poder resolver fcilmente la estimacin de los factores de complejidad responder a cada una de las siguientes catorce preguntas y asignarles un valor entre 0 y 5, donde 0 es no influencia, 1 es incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es esencial. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Requiere el sistema copias de seguridad y de recuperacin fiables? Requiere comunicacin de datos? Existen funciones de procesamiento distribuido? Es crtico el rendimiento? Se ejecutar el sistema en un entorno operativo existente y fuertemente utilizado? Requiere entrada de datos interactiva? Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre mltiples pantallas u operaciones? Se actualizan los archivos maestros de forma interactiva? Son complejas las entradas, las salidas, los archivos o las peticiones? Es complejo el procesamiento interno? Se ha diseado el cdigo para ser reutilizable? Estn incluidas en el diseo la conversin y la instalacin? Se ha diseado el sistema para soportar mltiples instalaciones en diferentes organizaciones? Se ha diseado la aplicacin para facilitar los cambios y para ser fcilmente utilizada por el usuario?

Pagina -> 64

Ejemplo Prctico: Asignando valores y respuestas a las preguntas planteadas sobre hacia el ejemplo anterior obtendremos la siguiente tablas de estimacin de los factores de complejidad: Factor de Complejidad Comunicacin de Datos Proceso Distribuido Rendimiento Descripcin del Valor Valor Sistema Aislado 0 Sistema Totalmente Centralizado 0 Rendimiento estudiado durante el diseo, 1 pero sin especiales requerimientos Operacional Existen las restricciones usuales 1 3 5 3 3 1 4 1 1 0 3 26

1 2 3 4 5 6

Se prevn horas puntas diarias Las entradas de datos interactivas superan el 30 % 7 Eficiencia con el Usuario Final Seis o ms factores 8 Actualizaciones en Lnea Actualizacin en lnea de ficheros lgicos importantes 9 Complejidad del Proceso Interno La aplicacin llevar incorporados sistemas de seguridad y control 10 Reusabilidad del Cdigo Se pretende reutilizar entre 40% y el 50 % 11 Contempla la Conversin de e Se ha solicitado Facilidad de instalacin Instalacin 12 Facilidad de Operacin Se proveer de procesos de arranque, back-up y recuperacin, pero con operador 13 Instalaciones Mltiples Un solo lugar 14 Facilidad de Cambios El Sistema puede tener cambios medios Factor De Complejidad Total 1. Calculo de los Puntos de Funcin Ajustados.

Configuracin Compartida Ratio de Transacciones Entrada de Datos EN-LINEA

El clculo d los puntos de funcin ya ajustados se realiza empleando la siguiente formula: PFA = PFsA *(0.65 + (0.01 * FdCT ) Donde: PFsA = Puntos de Funcin sin ajustar (resultado de la sumatoria de lprimera tabla) FdCT= Factor de Complejidad total (resultado de la sumatoria de la segunda tabla) 0.65 y 0.01 Constantes determinadas por el autor Aplicando la formula al ejemplo que se esta desarrollando se tendr el siguiente resultado: PFA = 147 * ( 0.65 + (0.01 * 26) = 133.77

Pagina -> 65

Estimacin del Esfuerzo requerido por la aplicacin. En esta fase de la planificacin temporal se realiza una aproximacin de la cantidad de horas de trabajo necesarias para realizar este proyecto. En base a las estadsticas de produccin de la empresa se obtiene una media de las horas de trabajo necesarias para cada punto de funcin, esta aproximacin depender de varios factores como el lenguaje de programacin y la experiencia de los trabajadores. Para proyectos de tamao medio se obtiene la siguiente tabla: Entorno Lenguaje Ensamblador Cobol Lenguajes 4GL C Visual Basic Delphi Horas / Punto Funcin 20 a 30 10 a 20 5 a 10 10 a 15 5 a 10 ( aprox ) 4 a 8 ( aprox ) Lneas Cdigo/PuntoFuncin 300 100 20

La Herramienta utilizada para el desarrollo de la aplicacin ser Delphi. En esta planificacin se realiza una aproximacin de 5 Horas/Punto Funcin por ser Delphi una herramienta extendida en el mercado, de uso sencillo y conocida por los trabajadores. Utilizaremos la siguiente formula para calcula el esfuerzo: Esfuerzo = PFA * Promedio Organizacin (Lenguaje) Debemos tener en cuenta que en una jornada de 8 horas de trabajo slo 5 son productivas, tambin que un mes tiene 20 das de trabajo y un ao once meses. Con todo esto se obtiene que al ao se trabajan unos 220 das reales. Esfuerzo = 133.77 * 5 ( P .F * Horas da) = 668.85 Horas Esfuerzo = 668.85 / 8 (Horas / Horas Da) = 84 Das Esfuerzo = 84 / 20 ( Das / Das Mes ) = 4 Meses (aprox) Teniendo en cuenta el numero de trabajadores, en este caso dos, el proyecto podr realizarse en algo menos de 2 meses (unos 60 das aproximadamente). De todas formas, pensando en los posibles retrasos y teniendo en cuenta que el cliente no tiene excesiva prisa en recibir el programa, el proyecto se realizar en tres meses para as tener un pequeo margen de maniobra. Descomposicin de esfuerzo por fases. Teniendo una aproximacin del esfuerzo de la aplicacin se centrar en el reparto del tiempo en las diferentes fases del desarrollo de un proyecto, estas fases se descompondrn en tareas a las cuales tambin se asignar tiempos de duracin, tambin se analizar sus de pendencias y as realizar una planificacin temporal del proyecto.

Pagina -> 66

Despus de estudiar las diferentes fases en el desarrollo del proyecto identificamos las siguientes fases y asignamos el tiempo necesario parar cada una: Planificacin elemental de sistemas 3% 18 % 6% y 12 %

Anlisis y especificacin de requisitos Medicin y estimacin Adaptacin a nuevos entornos aprendizaje Diseo 21 % Implementaron 20 % Pruebas 7% Documentacin % Formacin usuario final 7% Ahora se deber descomponer las fases en tareas analizando sus dependencias para despus poder planificar su orden de realizacin. Planificacin elemental de sistemas Estudio de los sistemas de la empresa Anlisis y especificacin de requisitos Estudio previabilidad Identificacin de los requisitos del usuario Identificacin de los requisitos de rendimiento Hardware y Software Identificacin de los requisitos de interfaz Medicin y estimacin Planificacin Presupuesto inicial Entrega al cliente. Adaptacin a nuevos entornos y aprendizaje Delphi multiplataforma BD Paradox Diseo de BD de componentes Software de documentacin Mostrar prototipo al cliente. Implementacin de bases de datos de Software de interfaz Pruebas de componentes Software de integracin de componentes de implantacin del sistema Documentacin Manual de usuario Pliego de condiciones Presupuesto detallado Entrega al cliente.

Pagina -> 67

Formacin al usuario final Cursillo de formacin Presupuesto de la Aplicacin El costo de la aplicacin a desarrollar se hace en funcin de las horas dedicadas en su implementacin obtenidas de la planificacin estimada, la aplicacin se instala incluyendo como hardware un servidor central multiusuario. Se calcula el costo de la mano de obra en funcin de los diferentes salarios para analista, programadores, etc. Actividad Anlisis y Diseo Programacin Formacin Documentacin y Pruebas Presupuesto Software (en Bs.) APLICACIONES Planificacin elemental de sistemas Anlisis y especificacin de requisitos Medicin y estimacin Adaptacin a nuevos entornos aprendizaje Diseo Implementacin Pruebas Documentacin Formacin usuario final Porcentaje de tiempo empleado 3% 18% 6% y 12% Tiempo en horas por aplicacin 20 120 40 Costo de mano de obra hora Bs 60,00 Bs 60,00 Bs 60,00 60,00 60,00 50,00 45,00 45,00 40,00 Costo total mano de obras por aplicacin Bs 1.203,93 Bs 7.223,58 Bs 2.407,86 Bs 4.815,72 Bs 8.427,51 Bs 6.688,50 Bs 2.106,88 Bs 1.805,90 Bs 1.872,78 Bs 36.552,65 $ 4.704,33 Costo Hora 60 Bs.50 Bs.40 Bs.45 Bs.-

80 Bs 21% 140 Bs 20% 134 Bs 7% 47 Bs 6% 40 Bs 7% 47 Bs Costo total en Bs. Costo total en Dlares (7.77)

Presupuesto Hardware Procesador Memoria Disco duro Tarjeta de sonido Tarjeta grfica Disquetera Lector y grabadora CD-ROM DVD Mdem interno Intel Pentium IV 1600 MHz 128 MB SDRAM PC 133 40 GB Ultra DMA SoundBlaster 128 Aceleradora 3D, 32 MB/SDRAM 1,44 MB 8x 4x 32x 8x Fax-Mdem interno 56K

Pagina -> 68

Altavoces Monitor Micrfono Teclado Ratn Impresora Scanner Lector de cdigo de barras Software

Dolby Surround 17'' De sobremesa Botones adicionales navegar por Internet Intellimouse de Microsoft Lser HP HP Microsoft Microsoft Windows XP Total presupuesto hardware: 21550 Bs.

Oferta al Cliente Bs. 36.552,65 21.550,00 58.102,65 $us 4.704,33 2.773,50 7.477,83

Costo total de Software Costo total de Hardware Costo total del Proyecto

El costo de la aplicacin a desarrollar asciende a 58.102,65 Bs. En un principio el proyecto se desarrolla por el inters de un nico cliente y por tanto como el producto es slo para l, este cliente debera desembolsar la totalidad del costo. Sin embargo, este precio no se le puede cobrar al cliente ya que es muy elevado y muy probablemente el cliente se negara a aceptar tal presupuesto y buscara otra empresa para que le desarrollara la aplicacin. Por lo tanto se hace sumamente necesario encontrar la manera de poder permitirnos el cobrar menos dinero al cliente sin que nosotros suframos perdidas. Una buena solucin es analizar el sector al que va dirigida esta aplicacin y averiguar si tendra otros posibles compradores, adems de nuestro cliente. De ser as, podramos dividir el costo de la aplicacin entre varios clientes y el precio final al cliente de la aplicacin sera mucho ms bajo y competitivo. En conclusin, para realizar una oferta al cliente se analizar dos factores que tienen incidencia sobre el precio de la aplicacin: El desarrollo puede ser reutilazado en otras aplicaciones por lo su costo se podra repartir entre varias aplicaciones pudiendo obtener un precio de venta menor. Los precios de productos similares existentes en el mercado que nos sirvan de referencia.

Pagina -> 69

Como consecuencia de estos dos factores se realizar una oferta al cliente de 10.000 Bs. por ser un precio competitivo en el mercado y estimando que este desarrollo se reutilizar en al menos dos proyectos ms. Sotfware Hardware Oferta Global al Cliente 10.000 Bs. 21.550 Bs. 31.550,00 Bs. 4.060,48 $us

Pagina -> 70

Unidad V METODOS DE PRUEBA DE SOFTWARE

Se llama PRUEBA del Software al proceso en el que se ejecuta un sistema con el objetivo de detectar fallos. Se llama DEPURACIN al proceso en el que se localiza el defecto que es la causa de un fallo, se determina la forma de corregirlo, se evala el efecto de la correccin y se lleva a cabo la correccin. Por lo general, despus del proceso de depuracin ser necesario repetir el proceso de prueba, para garantizar que el defecto qued efectivamente corregido y que no se introdujeron nuevos defectos. El coste de deteccin de los defectos suele ser mucho mayor que el coste de correccin de los mismos, y este es un punto en contra de las pruebas como tcnica de control de calidad, ya que siempre es necesario un paso de diagnstico hasta que se localiza la causa de los fallos. En otras actividades de control de calidad, por el contrario, como pueden ser las revisiones, se localizan directamente los defectos, no sus sntomas, por lo que nos ahorramos el proceso de diagnstico. En un proyecto grande la prueba se puede llevar hasta el 50 o 60% del esfuerzo dedicado al proyecto. Por eso es muy importante seleccionar bien las pruebas que se van a realizar, teniendo en cuenta que slo las pruebas que revelan defectos son las que realmente merecen la pena. El objetivo del proceso de prueba no es, como pudiera parecer, demostrar que el software est libre de defectos, sino precisamente descubrir defectos. Por ello, se deben seleccionar especialmente aquellos casos de prueba que incidan en las secciones del programa ms complejas, en los valores lmite de las variables, en la tolerancia a fallos del diseo. Aunque la prueba es una parte importante del Control de Calidad, es importante darse cuenta de que no es la nica. A continuacin veremos cules son las actividades que es necesario realizar para probar un sistema software, y cules son los principales mtodos de prueba que se pueden utilizar. A continuacin vamos a ver los dos grupos en que se clasifican los mtodos de prueba: - Mtodos de caja negra - Mtodos de caja blanca Mtodos de caja negra En este tipo de mtodos, el objeto que se desea probar se ve como una caja negra. Esto quiere decir que la eleccin de los casos de prueba no se va a basar en el conocimiento que se tenga acerca de la estructura del objeto, sino en el conocimiento acerca de la funcionalidad deseada (descripcin funcional). A la prueba de caja negra tambin se le llama prueba funcional o prueba orientada al diseo. Una prueba de caja negra exhaustiva requerira la generacin de un caso de prueba por cada combinacin posible (vlida o no vlida) de los valores de entrada, lo cual resulta imposible en la mayor parte de los casos por producirse una explosin combinatoria. Por eso se utilizan diferentes criterios a la hora de restringir el conjunto de casos de prueba. Los mtodos de seleccin del conjunto de casos de prueba ms usuales son:

Pagina -> 71

Mtodo de clases de equivalencia Consiste en dividir las posibles entradas al sistema en clases de equivalencia, de tal forma que todos los miembros de una misma clase de equivalencia prueben las mismas propiedades en el sistema, por lo que slo va a ser necesario seleccionar un elemento de cada clase de equivalencia. Anlisis de valores frontera o valores lmite Consiste en seleccionar como casos de prueba aquellos valores de entrada que caen en la frontera de las clases de equivalencia (justo a un lado, justo al otro y justo en la frontera). Grafos causa/efecto y tablas de decisin Consiste en crear un grafo causa/efecto a partir de las especificaciones, y seleccionar suficientes casos de prueba como para asegurar la cobertura del grafo. Se llama causas a las caractersticas de los datos de entrada y efectos a las clases de salidas que puede proporcionar el programa. A partir del grafo causa/efecto se construye una tabla de decisin que refleje las dependencias entre causas y efectos. Lo que se hace entonces es reducir la tabla de decisin y seleccionar slo un caso de prueba para todas las causas que producen el mismo efecto, o para cada columna de la tabla de decisin. Adivinacin de errores Consiste en tratar de imaginar cules son los errores que se pueden haber cometido con mayor probabilidad, y generar casos de prueba para comprobar dichos errores.

Mtodos de caja blanca o caja transparente En este tipo de mtodos, el objeto que se desea probar se ve como una caja blanca. Esto quiere decir que la eleccin de los casos de prueba se va a basar en el conocimiento que se tenga acerca de la estructura del objeto (diseo detallado, diagramas de flujo de datos y de control, cdigo fuente). A la prueba de caja blanca tambin se le llama prueba estructural. Los mtodos de caja blanca se pueden clasificar, a su vez, en dos grupos: - Los basados en mtricas de cobertura - los basados en mtricas de complejidad 1. Mtodos basados en mtricas de cobertura: Todo programa se puede representar mediante un grafo de flujo de control, donde cada nodo es una sentencia o una secuencia de sentencias. Los arcos dirigidos en el grafo representan el flujo de control. Para cada conjunto de datos de entrada el programa se ejecutar a travs de un camino concreto dentro de este grafo. Cuando el programa incluye estructuras iterativas, el nmero de posibles caminos en el grafo puede ser infinito. Una prueba de caja blanca exhaustiva requerira la generacin de un caso de prueba por cada posible camino. Como esto no es posible, por lo general, se utilizan mtricas que dan una indicacin de la calidad de un determinado conjunto de casos de prueba en funcin del grado de cobertura del grafo que consiguen. Las mtricas ms utilizadas son: Cobertura de sentencias Cobertura de segmentos entre decisiones. Cobertura de decisiones de ramificacin Cobertura de condiciones Cobertura de todas las combinaciones de condiciones Cobertura de caminos

Pagina -> 72

2. Mtodos basados en mtricas de complejidad: Las mtricas de complejidad ms utilizadas en la generacin de casos de prueba son las de MacCabe: Complejidad ciclomtica (arcos - nodos + 2 * nmero de componentes conexos) Complejidad esencial (complejidad ciclomtica - nmero de subgrafos propios de entrada y salida nica) Complejidad real (nmero de caminos ejecutados)
Actividades de Control

C ontroles estticos

Controles dinm icos

Mtodos de caja negra

Mtodos de caja blanca

- Mtodo de clases de equivalencia - Anlisis de valores frontera - Grafos causa/efecto - Adivinacin de errores - etc.

m tricas de cobertura

m tricas de com plejidad

- de sentencias - de segmentos - de decisiones de ram ificacin - de condiciones - de combinaciones de condiciones - de cam inos

- Com plejidad ciclom tica - Com plejidad esencial - Com plejidad real

Metodologa de prueba Cada uno de los diferentes tipos de prueba implica la realizacin de un conjunto de actividades estndar, as como la produccin de un conjunto de salidas estndar. Actividades estndar de prueba Planificacin de la prueba Diseo de la prueba Determinacin de los casos de prueba Planificacin del procedimiento de prueba Ejecucin de la prueba Anlisis y evaluacin de la prueba Salidas estndar asociadas Plan de pruebas Documento de diseo de la prueba Especificacin de los casos de prueba Especificacin del procedimiento de prueba Informe de los casos de prueba Informe de la prueba

A continuacin vamos a ver cada una de estas actividades en detalle.

Pagina -> 73

1. Planificacin de la prueba: Esta actividad consiste en la creacin de un plan de pruebas en el que se registra: - El objetivo del proceso de prueba. - Los objetos que hay que probar. -Las caractersticas que se van a probar y las que no. - El mtodo de prueba a utilizar. - Los recursos que se van a emplear. - El plan de tiempos. - Los productos a generar durante las pruebas - El reparto de las responsabilidades. 2. Diseo de la prueba: Esta actividad consiste en dar instrucciones detalladas acerca de: - cmo llevar a cabo la prueba para alcanzar los objetivos deseados, - de qu forma se van a utilizar los mtodos de prueba, - qu objetos se van a probar en cada una de las pruebas y - qu criterios se van a utilizar para determinar si el objeto pasa o no pasa la prueba. 3. Determinacin de los casos de prueba: Esta actividad consiste en especificar el conjunto de casos de prueba a utilizar en funcin del diseo realizado para la prueba. Para cada caso de prueba habr que especificar: - qu objetos se van a probar, - qu entradas se les van a dar y - cules son las salidas esperadas. 4. Planificacin del procedimiento de prueba: Esta actividad consiste en fijar un conjunto de pasos para la ejecucin de la prueba. Se especifica detalladamente: - la secuencia exacta de ejecucin de los distintos casos de prueba, - los requisitos que hay que cumplir para la ejecucin de cada caso y - las condiciones de terminacin de cada uno de ellos. 5. Ejecucin de la prueba: Esta actividad consiste en ejecutar cada caso de prueba, segn el procedimiento especificado en el paso anterior, y registrar los incidentes o problemas encontrados durante la misma. 6. Anlisis y evaluacin de la prueba: Se examinan los resultados de la prueba y se decide si se han alcanzado los objetivos propuestos o se debe repetir la prueba.

Unidad VI ESTRATEGIAS DE PRUEBA DE SOFTWARE

Pagina -> 74

En el presente capitulo se vera las diferentes estrategias de prueba de software las cuales se mencionan a continuacin. Tipos de pruebas El proceso de prueba conlleva la realizacin de un conjunto de tareas a lo largo del ciclo de vida del sistema. De acuerdo con el estndar IEEE 1012-1986 el conjunto mnimo de pruebas que se deben realizar son: - Prueba modular, prueba unitaria o prueba de componentes - Prueba de integracin - Prueba del sistema - Prueba de aceptacin Tambin se suele realizar otro tipo de prueba llamada prueba de regresin. La prueba modular consiste en la prueba de cada mdulo aislado del resto del sistema. La prueba de integracin se realiza a medida que los diferentes mdulos del sistema se integran en el mismo. Ya se ha realizado la prueba modular, y se supone que todos mdulos son correctos. El objetivo fundamental de esta prueba es comprobar que las interfaces entre los distintos mdulos son correctas. Algunas de las comprobaciones que es necesario realizar son: - Correccin en la sintaxis en la invocacin de procedimientos y funciones. - Compatibilidad de tipos entre los argumentos del procedimiento o funcin y los parmetros de llamada. - Correccin y completitud de las especificaciones de los mdulos. Se pueden utilizar tres posibles estrategias de integracin: - De arriba a abajo (top-down): Consiste en empezar la integracin y la prueba por los mdulos que estn en los niveles superiores de abstraccin, e integrar incrementalmente los niveles inferiores. - De abajo a arriba (bottom-up): Consiste en empezar la integracin y la prueba por los mdulos que estn en los niveles inferiores de abstraccin, e integrar incrementalmente los niveles superiores. - De big-bang: Consiste en integrar y probar todo al mismo tiempo. La prueba del sistema se realiza cuando se han integrado todos los mdulos, y su objetivo es comprobar que el sistema satisface los requisitos del usuario, tanto los funcionales como los no funcionales. La prueba de aceptacin se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento, y su objetivo es demostrar al usuario que el sistema satisface sus necesidades.

Pagina -> 75

La prueba de regresin tiene como objetivo comprobar que toda nueva versin de un producto software es de no menos calidad que la versin anterior, es decir, que al introducir cambios no se ha reducido la valoracin de ninguna de las caractersticas de calidad que tena el producto.
Prueba Modular

Prueba de Integracin

Prueba del sistema

Prueba de aceptacin

Pagina -> 76

Unidad VII CONTROL DE CALIDAD DE SOFTWARE DEFINICIN DE CALIDAD DEL SOFTWARE En este apartado se van a presentar los conceptos bsicos y la terminologa propia de este rea. En primer lugar aclararemos qu se entiende por calidad en el contexto de la Ingeniera del Software. A continuacin pasaremos a analizar qu estructura y utilidad tiene un Modelo de Calidad. Qu es la calidad del software? La calidad est de moda, en todos los aspectos, pero especialmente en el desarrollo de software. El inters por la calidad crece de forma continua, a medida que los clientes se vuelven ms selectivos y comienzan a rechazar los productos poco fiables o que realmente no dan respuesta a sus necesidades. Ahora bien, qu es la calidad del software? A la hora de definir la calidad del software se pueden adoptar diferentes aproximaciones. Como primera aproximacin es importante diferenciar entre la calidad del PRODUCTO software y la calidad del PROCESO de desarrollo. No obstante, las metas que se establezcan para la calidad del producto van a determinar las metas a establecer para la calidad del proceso de desarrollo, ya que la calidad del producto va a estar en funcin de la calidad del proceso de desarrollo. Sin un buen proceso de desarrollo es casi imposible obtener un buen producto. La calidad del producto software se diferencia de la calidad de otros productos de fabricacin industrial, ya que el software tiene ciertas caractersticas especiales: El software es un producto mental, no restringido por las leyes de la Fsica o por los lmites de los procesos de fabricacin. Es algo abstracto, y su calidad tambin lo es. Se desarrolla, no se fabrica. El coste est fundamentalmente en el proceso de diseo, no en la produccin. Y los errores se introducen tambin en el diseo, no en la produccin. El software no se deteriora con el tiempo. No es susceptible a los efectos del entorno, y su curva de fallos es muy diferente de la del hardware. Todos los problemas que surjan durante el mantenimiento estaban all desde el principio, y afectan a todas las copias del mismo; no se generan nuevos errores. Es artesanal en gran medida. El software, en su mayora, se construye a medida, en vez de ser construido ensamblando componentes existentes y ya probados, lo que dificulta an ms el control de su calidad. Aunque se ha escrito mucho sobre la reutilizacin del software, hasta ahora se han conseguido pocos xitos tangibles. El mantenimiento del software es mucho ms complejo que el mantenimiento del hardware. Cuando un componente hardware se deteriora se sustituye por una pieza de repuesto, pero cada fallo en el software implica un error en el diseo o en el proceso mediante el cual se tradujo el diseo en cdigo mquina ejecutable. Es engaosamente fcil realizar cambios sobre un producto software, pero los efectos de estos cambios se pueden propagar de forma explosiva e incontrolada. Como disciplina, el desarrollo de software es an muy joven, por lo que las tcnicas de las que disponemos an no son totalmente efectivas o no estn totalmente calibradas. El software con errores no se rechaza. Se asume que es inevitable que el software presente errores.

Pagina -> 77

Tambin es importante destacar que la calidad de un producto software debe ser considerada en todos sus estados de evolucin (especificaciones, diseo, cdigo, ...). No basta con tener en cuenta la calidad del producto una vez finalizado, cuando los problemas de mala calidad ya no tienen solucin o la solucin es muy costosa. Los principales problemas a los que nos enfrentamos a la hora de hablar de la calidad de un producto software son: - La definicin misma de la calidad del software: Es realmente posible encontrar un conjunto de propiedades en un producto software que nos den una indicacin de su calidad? Para dar respuesta a estas preguntas aparecen los Modelos de Calidad. - Modelos de calidad: En los modelos de calidad, la calidad se define de forma jerrquica. Resuelven la complejidad mediante la descomposicin. La calidad es un concepto que se deriva de un conjunto de sub-conceptos. - La comprobacin de la calidad del software: Cmo medir el grado de calidad de un producto software? Aqu aparece el concepto de Control de Calidad, del que hablaremos en la unidad 2. - Control de Calidad: Actividades para evaluar la calidad de los productos desarrollados. - La mejora de la calidad del software: Cmo utilizar la informacin disponible acerca de la calidad del producto software para mejorar su calidad a lo largo del ciclo de vida? Tal y como veremos, no slo es posible medir la calidad, sino tambin construir la calidad durante el proceso de desarrollo del producto. En este eje aparecen dos conceptos importantes: - Gestin de Calidad: Determinacin y aplicacin de las polticas de calidad de la empresa (objetivos y directrices generales) - Garanta o Aseguramiento de Calidad: Conjunto de actividades planificadas y sistemticas necesarias para proporcionar confianza en que el producto software satisfar los requisitos dados de calidad. En esta unidad nos vamos a ocupar de la primera cuestin, la definicin de la calidad. Veamos la definicin que dan de la calidad algunos de los padres de la idea de la gestin de la calidad: Segn Deming, calidad es Conformidad con los requisitos y confianza en el funcionamiento Segn Juran, calidad es Adecuacin para su uso Crosby pone ms nfasis en la prevencin: hacerlo bien a la primera Veamos otras definiciones de calidad extradas de estndares internacionales: La calidad es la suma de todos aquellos aspectos o caractersticas de un producto o servicio que influyen en su capacidad para satisfacer las necesidades, expresadas o implcitas (ISO 8402) Grado con el cual el cliente o usuario percibe que el software satisface sus expectativas (IEEE 729-83) Capacidad del producto software para satisfacer los requisitos establecidos (DoD 2168) Lo que est claro a partir de estas definiciones es que la calidad es algo relativo. Siempre va a depender de los requisitos o necesidades que se desee satisfacer. Por eso, la evaluacin de la calidad de un producto siempre va a implicar una comparacin entre unos requisitos preestablecidos y el producto realmente desarrollado. El problema es que, por lo general, una parte de los requisitos van a estar explcitos (se encontrarn en la ERS, tanto los funcionales como otros requisitos), pero otra parte van a quedar implcitos (el usuario sabe lo que quiere, pero no siempre es capaz de expresarlo).

Pagina -> 78

Hay que intentar que queden implcitos la menor cantidad de requisitos posible. No se podr conseguir un producto de buena calidad sin una buena ERS. Teniendo esto en cuenta, en un producto software vamos a tener diferentes visiones de la calidad: Necesaria o Requerida: La que quiere el cliente. Programada o Especificada: La que se ha especificado explcitamente y se intenta conseguir. Realizada: La que se ha conseguido. Nuestro objetivo es conseguir que las tres visiones coincidan. A la interseccin entre la calidad Requerida y la calidad Realizada se le llama calidad Percibida, y es la nica que el cliente valora. Toda aquella calidad que se realiza pero no se necesita es un gasto intil de tiempo y dinero. Tambin est claro que las definiciones que se han dado de la calidad son demasiado generales e imprecisas como para que resulten de utilidad a la hora de construir un software de calidad. Por eso surge el concepto de Modelo de Calidad, que nos ayuda a definir la calidad del software de una forma ms precisa y til. Modelos de calidad del software Estructura de los modelos de calidad Los modelos de calidad del software vienen a ayudar en la puesta en prctica del concepto general de calidad que vimos en el apartado anterior, ofreciendo una definicin ms operacional. Unos de los modelos de calidad ms antiguos y extendidos es el de McCall [McCall, 1977], y de l han derivado otros modelos, como el de Boehm [Boehm, 78] o el SQM [Murine, 1988] En los modelos de calidad, la calidad se define de forma jerrquica. Es un concepto que se deriva de un conjunto de sub-conceptos, cada uno los cuales se va a evaluar a travs de un conjunto de indicadores o mtricas. Tienen una estructura, por lo general, en tres niveles:
Calidad del Software

Factores de Calidad

Criterios de calidad del Producto

Mtricas del Producto

Pagina -> 79

En el nivel ms alto de la jerarqua se encuentran los FACTORES de calidad, que representan la calidad desde el punto de vista del usuario. Son las caractersticas que componen la calidad. Tambin se les llama Atributos de Calidad Externos. - Cada uno de los factores se descompone en un conjunto de CRITERIOS de calidad. Son atributos que, cuando estn presentes, contribuyen al aspecto de la calidad que el factor asociado representa. Se trata de una visin de la calidad desde el punto de vista del producto software. Tambin se les llama Atributos de Calidad Internos. - Para cada uno de los criterios de calidad se definen entonces un conjunto de MTRICAS, que son medidas cuantitativas de ciertas caractersticas del producto que, cuando estn presentes, dan una indicacin del grado en que dicho producto posee un determinado atributo de calidad. La ventaja de los modelos de calidad es que la calidad se convierte en algo concreto, que se puede definir, que se puede medir y, sobre todo, que se puede planificar. Los modelos de calidad ayudan tambin a comprender las relaciones que existen entre diferentes caractersticas de un producto software. Una desventaja es que an no ha sido demostrada la validez absoluta de ninguno de estos modelos. Las conexiones que establecen entre caractersticas, atributos y mtricas se derivan de la experiencia, y de ah que existan mltiples modelos. El modelo de McCall Como ejemplo vamos a ver el modelo de McCall. El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto: - Operacin del producto - Revisin del producto - Transicin del producto El modelo de McCall se basa en 11 factores de calidad, que se organizan en torno a los tres ejes de la siguiente forma: PUNTO DE VISTA Operacin del producto FACTORES - Facilidad de uso - Integridad - Correccin - Fiabilidad - Eficiencia - Facilidad de mantenimiento - Facilidad de prueba - Flexibilidad - Facilidad de reutilizacin - Interoperabilidad - Portabilidad

Revisin del producto Transicin del producto

Pagina -> 80

VI SI ON

F A C IL ID A D D E M A N T E N IM IE N T O ( P u e d o a rre g l a rl o ? ) F A C IL ID A D D E P R U E B A ( P u e d o p ro b a rl o ? ) F L E X IB IL ID A D ( P u e d o m o d i fi c a r l o ? )

IN T E R O P E R A B IL ID A D ( P o d r c o m u n i c a rl o c o n o t ro s s i s t e m a s ? ) P O R T A B IL ID A D ( P o d r u t i l i z a rl o e n o t ra m q u i n a ? ) R E U S A B IL ID A D ( P o d r r e u t i l i z a r p a r t e d e l s o ft w a r e ? )

A TR N IO IC NS

RE

OP ER AC ION

C O R R E C C I O N ( H a c e e l s o ft w a r e l o q u e y o q u i e r o ? ) F I A B I L I D A D ( L o h a c e d e fo r m a e x a c t a t o d o e l t i e m p o ? ) E F IC IE N C IA ( S e e j e cu t ar s o b re m i h a rd w a re l o m e j o r p o s i b l e ? ) IN T E G R ID A D ( E s s e g u ro ? ) F A C IL ID A D D E U S O ( P u ed o e j e cu t a rl o ? )

Los factores de McCall se definen como sigue: 1. Correccin: Hasta qu punto un programa cumple sus especificaciones y satisface los objetivos del usuario. Por ejemplo, si un programa debe ser capaz de sumar dos nmeros y en lugar de sumar los multiplica, es un programa incorrecto. Es quizs el factor ms importante, aunque puede no servir de nada sin los dems factores. 2. Fiabilidad: Hasta qu punto se puede confiar en el funcionamiento sin errores del programa. Por ejemplo, si el programa anterior suma dos nmeros, pero en un 25% de los casos el resultado que da no es correcto, es poco fiable. 3. Eficiencia: Cantidad de cdigo y de recursos informticos (CPU, memoria) que precisa un programa para desempear su funcin. Un programa que suma dos nmeros y necesita 2 MB de memoria para funcionar, o que tarda 2 horas en dar una respuesta, es poco eficiente. 4. Integridad: Hasta qu punto se controlan los accesos ilegales a programas o datos. Un programa que permite el acceso de personas no autorizadas a ciertos datos es poco ntegro. 5. Facilidad de uso: El coste y esfuerzo de aprender a manejar un producto, preparar la entrada de datos e interpretar la salida del mismo. 6. Facilidad de mantenimiento: El coste de localizar y corregir defectos en un programa que aparecen durante su funcionamiento. 7. Facilidad de prueba: El coste de probar un programa para comprobar que satisface sus requisitos. Por ejemplo, si un programa requiere desarrollar una simulacin completa de un sistema para poder probar que funciona bien, es un programa difcil de probar. 8. Flexibilidad: El coste de modificacin del producto cuando cambian sus especificaciones.

Pagina -> 81

9. Portabilidad (o Transportabilidad): El coste de transportar o migrar un producto de una configuracin hardware o entorno operativo a otro. 10. Facilidad de Reutilizacin: Hasta qu punto se puede transferir un mdulo o programa del presente sistema a otra aplicacin, y con qu esfuerzo. 11. Interoperabilidad: El coste y esfuerzo necesario para hacer que el software pueda operar conjuntamente con otros sistemas o aplicaciones software externos. Cada uno de estos factores se descompone, a su vez, en criterios. En el modelo de McCall se definen un total de 23 criterios, con el siguiente significado: 1. Facilidad de operacin: Atributos del software que determinan la facilidad de operacin del software. 2. Facilidad de comunicacin: Atributos del software que proporcionan al usuario entradas y salidas fcilmente asimilables. 3. Facilidad de aprendizaje: Atributos del software que facilitan la familiarizacin inicial del usuario con el software y la transicin desde el modo actual de operacin. 4. Control de accesos: Atributos del software que proporcionan control de acceso al software y los datos que maneja. 5. Facilidad de auditora: Atributos del software que facilitan el registro y la auditora de los accesos al software. 6. Eficiencia en ejecucin: Atributos del software que minimizan el tiempo de procesamiento. 7. Eficiencia en almacenamiento: Atributos del software que minimizan el espacio de almacenamiento necesario. 8. Precisin: Atributos del software que proporcionan el grado de precisin requerido en los clculos y los resultados. 9. Consistencia: Atributos del software que proporcionan uniformidad en las tcnicas y notaciones de diseo e implementacin utilizadas. 10. Tolerancia a fallos: Atributos del software que posibilitan la continuidad del funcionamiento bajo condiciones no usuales. 11. Modularidad: Atributos del software que proporcionan una estructura de mdulos altamente independientes. 12. Simplicidad: Atributos del software que posibilitan la implementacin de funciones de la forma ms comprensible posible. 13. Completitud: Atributos del software que proporcionan la implementacin completa de todas las funciones requeridas. 14. Trazabilidad (Rastreabilidad): Atributos del software que proporcionan una traza desde los requisitos a la implementacin con respecto a un entorno operativo concreto. 15. Auto descripcin: Atributos del software que proporcionan explicaciones sobre la implementacin de las funciones. 16. Capacidad de expansin: Atributos del software que posibilitan la expansin del software en cuanto a capacidades funcionales y datos. 17. Generalidad: Atributos del software que proporcionan amplitud a las funciones implementadas. 18. Instrumentacin: Atributos del software que posibilitan la observacin del comportamiento del software durante su ejecucin (para facilitar las mediciones del uso o la identificacin de errores). 19. Independencia entre sistema y software: Atributos del software que determinan su independencia del entorno operativo. 20. Independencia del hardware: Atributos del software que determinan su independencia del hardware.

Pagina -> 82

21. Compatibilidad de comunicaciones: Atributos del software que posibilitan el uso de protocolos de comunicacin e interfaces estndar. 22. Compatibilidad de datos: Atributos del software que posibilitan el uso representaciones de datos estndar. 23. Concisin: Atributos del software que posibilitan la implementacin de una funcin con la menor cantidad de cdigo posible. La relacin Factores - Criterios que establece el modelo queda plasmada en la siguiente tabla: FACTOR Facilidad de uso CRITERIOS - Facilidad de operacin - Facilidad de comunicacin - Facilidad de aprendizaje Integridad Correccin - Control de accesos - Facilidad de auditora - Completitud - Consistencia - Trazabilidad Fiabilidad - Precisin - Consistencia - Tolerancia a fallos - Modularidad - Simplicidad Eficiencia Facilidad de mantenimiento - Eficiencia en ejecucin - Eficiencia en almacenamiento - Modularidad - Simplicidad - Consistencia - Concisin - Auto descripcin Facilidad de prueba - Modularidad - Simplicidad - Auto descripcin - Instrumentacin Flexibilidad - Auto descripcin - Capacidad de expansin - Generalidad

Pagina -> 83

- Modularidad Reusabilidad - Auto descripcin - Generalidad - Modularidad - Independencia entre sistema y software - Independencia del hardware Interoperabilidad - Modularidad - Compatibilidad de comunicaciones - Compatibilidad de datos Portabilidad - Auto descripcin - Modularidad - Independencia entre sistema y software - Independencia del hardware En cuanto a las mtricas, McCall propuso 41 mtricas, sobre todo mtricas de tipo subjetivo, es decir, mtricas que evaluadas por personas diferentes podran dar como resultado valores diferentes. An hoy en da no hay mtricas formales y objetivas que cubran todos los criterios del modelo de McCall.