INGENIERA DE SOFTWARE

DVILA HURTADO, LUIS ALBERTO

PROLOGO La asignatura de Ingeniera de Software brinda los conceptos, tcnicas, metodologas y herramientas para conseguir desarrollar software de calidad. La principal caracterstica del software en la actualidad es la ubicuidad. La mayora de los equipos elctricos actuales incluyen algn tipo de software. Este se utiliza para ayudar al funcionamiento de la industria manufacturera, a las escuelas y universidades, al cuidado de la salud, a las finanzas y al gobierno; mucha gente utiliza software de diferente clase para el entretenimiento y la educacin. La especificacin, el desarrollo, la administracin y la evolucin de estos sistemas de software integran la disciplina de ingeniera de software Esta asignatura centra su investigacin en estudiar la aplicacin de metodologas, tcnicas y herramientas en la obtencin de software que satisfaga los requerimientos empresariales
Por lo tanto, el presente trabajo es una recopilacin de todos los trabajos presentados en la asignatura de Ingeniera de Software, en el ciclo acadmico 2007-II

INDICE Pg.
1. PROPUESTA DE MTODO DE PROCESO PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN WEB BASADO EN COMPONENTES Murillo Cornejo Saulo 2. EVALUACIN Y PROPUESTA DE LA GESTIN DE RIESGOS DEL DEPARTAMENTO DE DESARROLLO DE SISTEMAS USAT Cruzalegui Cruzalegui, Jos A 3. HACIA UN ESTNDAR DE MTRICAS DE CALIDAD EN APLICACIONES ELEARNING Mnica Yolanda Villavicencio Montoya 4. MEJORA DE PROCESOS DE SOFTWARE BAJO UN NUEVO CAMBIO ORGANIZACIONAL. CASO PERUANO DE XITO DE LA PRIMERA INSTITUCIN FINANCIERA EN ALCANZAR EL NIVEL 3 DE MADUREZ DEL CMMI Meja Montao, Giuliana del Carmen 5. Pruebas de navegabilidad e interfaz de usuario de la WebApp de la USAT Ramrez Chirinos, Javier 6. MEJORAS PARA LA ADAPTACIN DE REQUISITOS EN LA WEB Faya Nishiyama Nelly 7. ESTUDIO COMPARATIVO Y PROPUESTA METODOLOGICA PARA LA EVALUACIN DE LA CALIDAD DE DISEO DE INTERFACES GRAFICAS DE USUARIO Bejarano Ramirez Zully 8. PROPUESTA METODOLGICA PARA UNA BUENA PRCTICA EN LA INGENIERA DE REQUERIMIENTOS Guzman Alvarado Cristhyan 9. EVALUACIN DE DIFERENTES ALGORITMOS DE ENCRIPTACIN PARA BRINDAR SEGURIDAD A LA BASE DE DATOS DE UN SISTEMA DE MATRCULA Montoya Vergara Evelyn 10. DESARROLLO DE UN SISTEMA WEB DE MATRICULAS Posada Linares Jorge Luis 207 129 100 3

31

52

70

145

175

186

PROPUESTA DE MTODO DE PROCESO PARA EL DESARROLLO DE SISTEMAS DE INFORMACIN WEB BASADO EN COMPONENTES1

RESUMEN La investigacin tiene propone establecer las especificaciones de un mtodo de proceso para el desarrollo de sistemas de informacin Web basado en componentes. Adems se pretende sealar ventajas de la propuesta frente a otros mtodos de proceso, definir las tareas de proceso bsicas que se incluirn en el mtodo de proceso, describir lo respecto a desarrollo Web y la reutilizacin de componentes. Palabras claves: Sistema de informacin Web, Componentes, mtodo de proceso. INTRODUCCIN El desarrollo de Sistemas Web de Informacin se ha convertido en una necesidad paraduchas organizaciones constituyendo una necesidad para establecer una ventaja competitiva. El proceso de desarrollo para dichos sistemas suele afirmarse que se trata de un mtodo de proceso identificado por una serie de caractersticas que no forman parte de los mtodos genricos. El desarrollo gil ha logrado apoderarse de la aceptacin para este tipo de sistemas, sistemas Web (Pressman, 2005). Esto se da ya que el tiempo para desarrollo de sistemas Web de calidad se vuelve cada vez ms corto ya que debe ponerse en el mercado lo antes posible (Piattini y Garca, 2003). Y ello se puede apreciar en los sitios Web para E-commerce y en general E-businnes. Por otro lado el desarrollo de software basado en componentes, que tiene por caracterstica la reutilizacin de componentes, Pressman, 2005 seala en cuanto a la calidad y oportunidad para el desarrollo de sistemas basado en componentes, aspectos que de manera intuitiva se hicieron notar en prrafos anteriores. El desarrollo de software basado en componentes define para s mismo un propio mtodo de desarrollo. Se plantea como problema: Cules seran las caractersticas de un mtodo de proceso que integre el desarrollo Web en conjunto con las tareas que definen al desarrollo de software basado en componentes? La investigacin tiene por objetivo general: desarrollar un mtodo de proceso para el desarrollo de sistemas de informacin Web basado en componentes. Adems se propone sealar ventajas de la propuesta frente a otros mtodos de proceso, definir las tareas de

Murillo Cornejo, Saulo Edison

proceso bsicas que se incluirn en el mtodo de proceso, describir lo respecto a desarrollo Web y la reutilizacin de componentes. Se debe tener en cuanta que los sistemas Web constituyen ente las innovaciones ms importantes que actualmente proveen beneficios para muchos negocios, no constituyen un modelo de software tradicional. Como asegura Pressman, ofrecen un arreglo de contenido y funcionalidad a diferencia de un software tradicional, los sistemas Web son diseados para servir a un numero muy grande de usuarios de caractersticas diversas (Pressman, 2005). El desarrollo de sistemas de informacin Web supone un desarrollo rpido y una implementacin oportuna para que el cliente pueda agregar valor a su empresa (Piattini y Garca, 2003). Lo que supone el anterior prrafo es que el desarrollo de sistemas Web a medida que se vuelven variadas las necesidades de los negocios, las caractersticas de los sistemas Web aumentan en su complejidad de contenido y funciones, por tanto, supone que el proceso en cuanto al tiempo como debe implementarse en poco tiempo, el desarrollo supone mejores tcnicas y estrategias que no tarden el desarrollo del sistema. La falta de adecuacin a procedimientos de la ingeniera de software tradicional parece justificarse en la prontitud en que estos deben ponerse en uso la flexibilidad de su desarrollo. Se afirma que se trata de una tecnologa sin conocimientos tericos as mismo lo que se trata es de proporcionar una metodologa de desarrollo que busque disciplinar (Paloma, et al, 2004). Por otro lado los la ingeniera de software basado en componentes est sujetan dentro de un marco de trabajo disciplinado, dentro de los procesos tradicionales. El desarrollo basado en componentes o la ingeniera de software basada en componentes surgi a finales de los 90 como un enfoque basado en la reutilizacin para el desarrollo de sistemas de software (Braude, p.310, 2003). Tal como Fraude seala se pueden utilizar componentes o partes de programas que ya han sido desarrollados, lo que denomina reutilizacin oportunista o desarrollar componentes para reutilizacin lo que denomina como reutilizacin sistemtica (Schach, 2006). La ventaja de investigar un desarrollo de sistemas Web utilizando el desarrollo de componentes, es no solo afrontar el hecho del crecimiento de la complejidad de sistemas de informacin Web sino tambin de poner el desarrollo Web bajo un enfoque disciplinado, proponiendo un marco de trabajo que contenga la flexibilidad y la utilizacin de componentes. Por hiptesis se tiene que el mtodo de proceso para el desarrollo de sistemas de informacin basado en componentes, tiene por tareas y caractersticas las presentadas en procesos tradicionales de desarrollo de software y adems de procesos de desarrollo Web, adems se aaden las caractersticas del desarrollo basado en componentes plasmndole proceso en una serie d artefactos que permitan relacionar los atributos del sistema

El presente trabajo contempla los contenidos tericos de respecto al desarrollo Web adems del contenido de desarrollo gil una propuesta que se acoge mucho ms al desarrollo de sistemas Web (Pressman, 2005), asimismo lo que concierne a desarrollo de sistemas de informacin basado en componentes y como es que se puede adaptar al desarrollo Web, la propuesta de un marco de trabajo para un desarrollo Web basado en componentes. ANTECEDENTES DE LA INVESTIGACIN Basndose en los trabajos de investigacin que a continuacin se muestran, la investigacin presenta busca ampliar el conjunto de conocimientos a partir del aporte de investigaciones cuyo aporte se describe a continuacin. Crnkovic, et al, (2002), muestra la nocin de que se debe tener en claro los conceptos de desarrollo basado en componentes, para fines de composicin, desarrollo e implementacin. Levi, y Arsonjan (2002) que trata sobre enfocar los procesos del negocio y los objetivos empresariales, para definir un exitoso diseo de arquitectura basado en componentes. Por otro lado Brambilla, et al, (2006), realiz una investigacin cuyo esfuerzo lo lleva a encontrar una manera de modelar aplicaciones Web, basndose en especificaciones de negocios y servicios remotos. Granell, C (2006), aporta un aproximacin para la composicin de servicios Web con el fin de facilitar el desarrollo de aplicaciones Web basadas en servicios flexibles y reutilizables, se describe una metodologa de composicin para la creacin, composicin, reutilizacin de componentes integrados para transformarlos finalmente en procesos ejecutables. SISTEMAS DE INFORMACIN WEB Paloma, M, et al (2004) sostiene que los sistemas Web pueden considerarse como un subconjunto de los sistemas hipermedia, los cuales organizan la informacin multimedia en una serie de unidades conceptuales, habitualmente denominadas Nodos, que estn relacionados por medio de enlaces navegables que hacen posible la libre exploracin del espacio de informacin. Para BAHLI, B y DI Tulio, D (2003) Las aplicaciones basadas en Web van desde simples sitios Web con informacin compleja, dinmica, interactiva, hasta sistemas transaccionales basados en Web. Ingeniera Web El problema de la ingeniera Web tal como lo sealaba Presman, R (2005) y Paloma, M, et al (2004) se trata de una Web enmaraada y de la falta de disciplina para el proceso Web; por la tanto, lo que la ingeniera Web ofrece es un conjunto de principios que en cierto modo disciplinen o establezcan un marcote trabajo estndar para llevar a cabo el desarrollo, despliegue y mantenimiento del sistemas Web.

Arquitectura de sistemas Web

Segn Pressman, R (2005) se sugiere un arquitectura de diseo en tres capas que desacople la interfaz de navegacin y de comportamiento de la aplicacin , y argumentan que mantener la separacin de la interfaz, aplicacin y navegacin simplifica la implementacin y mejora la reutilizacin. Castejn, J (2004) En todos los sistemas de este tipo y ortogonalmente a cada una de las capas de despliegue comentadas, podemos dividir la aplicacin en tres reas o niveles: Nivel de presentacin: es el encargado de generar la interfaz de usuario en funcin de las acciones llevadas a cabo por el mismo. Nivel de negocio: contiene toda la lgica que modela los procesos de negocio y es donde se realiza todo el procesamiento necesario para atender a las peticiones del usuario. Nivel de administracin de datos: encargado de hacer persistente toda la informacin, suministra y almacena informacin para el nivel de negocio. Dentro de los patrones de diseo de aplicacin bsica que pueden facilitar un diseo apropiado para este tipo de sistemas Uno de los que ha demostrado ser fundamental para aplicaciones web es el Modelo-Vista-Control (MVC). Modelo Vista Controlador

La vista contiene todas las funciones especficas de la interfaz y habilita la presentacin del contenido y lgica de procesamiento, e incluye los objetos de contenido , acceso a fuentes de datos/informacin externa, y toda la funcionalidad de procesamiento requerida por le usuario final. El modelo contiene todo el contenido especfico de la aplicacin y la lgica de procesamiento que son especficos de la aplicacin. El controlador gestiona el acceso al modelo y a la vista y coordina el flujo de datos entre ellos. Mtodos de desarrollo Web Para Paloma, M, et al (2004), un mtodo ofrece un marco racional que gua al diseador desde su concepcin inicial del problema hacia una solucin lgica y formal: Debe especificar los pasos a seguir y las actividades a realizar para desarrollar la aplicacin. Debe proponer una serie de herramientas o modelos con los que especificar todas las caractersticas de la aplicacin.

Escalona, Mara J y Gonzlez Romano, Jos (2007) ofrece una rpida descripcin de las metodologas existentes para el desarrollo Web de forma especfica sobre una lnea de tiempo, para ver cmo han ido evolucionando.

WSDM: Web Site Design Method. 1997

Define el sistema en base a los grupos de usuario. Su proceso de definicin de requisitos tiene por objetivo detectar los perfiles de usuario mediante dos tareas. Clasificacin de usuarios mediante el estudio del entorno. Descripcin de los grupos de usuario.

SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology. 1998 Esta propuesta ofrece un modelo de escenarios propia, denominada SAC, para representar los requisitos. Para el desarrollo de los mismos hace uso del diagrama de contexto propuesto en los DFD. En la actualidad ha cado en desuso, principalmente por el uso de los DFD. Sin embargo tiene algunas variantes propuesta por los mismos autores.

RNA: Relationship Navigational Analysis. 1998 Plantea una secuencia de pasos en la que separa el tratamiento de diferentes requisitos: Anlisis del Entorno Elementos de Inters Anlisis del Conocimiento Anlisis de la Navegacin Implementacin del Anlisis Est muy focalizada a un grupo de sistemas: Los sistemas legales y en la actualidad no es muy usada.

HFPM: Hypermedia Flexible Process Modeling. 1999 HFPM define un proceso detallado que cubre todo el ciclo de vida y que est compuesto por 13 fases. En la primera de ellas, modelado de requisitos, propone las tareas siguientes: Descripcin breve del problema Descripcin de los requisitos funcionales Realizacin del modelo de datos Modelado de la interfaz de usuario Modelado de los requisitos no funcionales

HFPM: Hypermedia Flexible Process Modeling. 1999 HFPM no est siendo trabajada actualmente, sin embargo, fue la primera en definir ciertos aspectos:

Incluye al usuario desde el principio del desarrollo. Introduce el concepto de la separacin de aspectos, propuesto para el anlisis, ya desde la Ingeniera de Requisitos. Establece la necesidad de definir modelos especficos para el usuario. Aunque no define ninguno. Establece la necesidad de elaborar manuales de usuario e incluir esto en el ciclo de vida.

OOHDM: Object Oriented Hypermedia Design Model. 1999 OOHDM es una propuesta ampliamente aceptada para la web. Inicialmente no propona la fase de Ingeniera de Requisitos y centraba su desarrollo en cuatro etapas.

UWE: UML-Based Web Engineering. 1999 UWE es una propuesta basada en el proceso unificado y UML pero adaptados a la web. En requisitos separa las fases de captura, definicin y validacin. Hace adems una clasificacin y un tratamiento especial dependiendo del carcter de cada requisito. En la actualidad ha evolucionado hacia el desarrollo MDD y define los conceptos en base a un conjunto de modelos.

W2000. 2001 Esta propuesta toma como base los conceptos de HDM para ampliar la notacin UML y adecuarla a la web. La fase de especificacin de requisitos en W2000 hace una separacin y un tratamiento diferente de los requisitos funcionales y los de navegacin. Utiliza para ello una extensin de los casos de uso de UML.

UWA: Ubiquituos Web Applications. 2001 El proyecto UWA ha nacido de la colaboracin de varios grupos. Su fase de tratamiento de requisitos se basa en los roles de usuario y en ir refinando los requisitos en un proceso iterativo mediante el que se clasifican los objetivos segn su carcter.

NDT: Navigational Development Tecniques. 2004 NDT es un proceso metodolgico para especificar, analizar y disear sistemas Web.

En el tratamiento de requisitos separa la captura, la definicin y la validacin de requisitos, proponiendo tcnicas especficas para cada uno de ellos. Ofrece adems una herramienta, NDT-Tool, que sirve como soporte en la aplicacin de sus tcnicas.

DDDP: Design-driven Requirements Elicitation. 2004 1. Esta propuesta para el tratamiento de requisitos es parte del proceso designDriven propuestos por Lowe y Ekluind. 2. Consiste en realizar la captura, la definicin y la validacin de requisitos durante el proceso de diseo. 3. Definido en base a un exhaustivo anlisis de best practices en el desarrollo de aplicaciones comerciales para la web. ANLISIS Y DISEO PARA APLICACIONES WEB Anlisis de sistemas Web Para crear un modelo de anlisis completo se elabora el mbito definido durante la actividad de formulacin. Anlisis del contenido. Se trata de la identificacin del espectro completo de contenido que se va a proporcionar. En el contenido se incluyen datos de texto, grficos, imgenes, vdeo y sonido. Anlisis de la interaccin. Se trata de la descripcin detallada de la interaccin del usuario y el sistema o modulo Web. Anlisis funcional. Los escenarios de utilizacin (casos de uso) creados como parte del anlisis de interaccin definen las operaciones que se aplicarn en el contenido de la aplicacin e implicarn otras funciones de procesamiento. Anlisis de la configuracin. Se efecta una descripcin detallada del entorno y de la infraestructura en donde reside el sistema Web (Internet, intranet o extranet). Adems, se deber identificar la infraestructura (es decir, la infraestructura de los componentes y el grado de utilizacin de la base de datos para generar el contenido).

Diseo de sistemas Web El diseo de sistemas Web debe trabajarse tomando en cuenta: la modularidad eficaz (exhibida con una cohesin alta y con un acoplamiento bajo), la elaboracin paso a paso, y cualquier otra heurstica de diseo del software conducir a sistemas y aplicaciones basados en Web ms fciles de adaptar, mejorar, probar y utilizar.

De hecho, la notacin de diagramas propuesta por UML puede adaptarse y utilizarse durante las actividades de diseo de sistemas Web. Configuraciones de diseo: son un enfoque genrico para resolver pequeos problemas que se pueden adaptar a una variedad ms amplia de problemas especficos; las configuraciones de diseo se pueden aplicar no solo a los

10

elementos funcionales de una aplicacin, sino tambin a los documentos, grficos y esttica general de un sitio Web. Diseo arquitectnico: El diseo arquitectnico para los sistemas y aplicaciones basados en Web se centra en la definicin de la estructura global del sistema y en la aplicacin de las configuraciones de diseo y plantillas constructivas. Patrones de diseo: Los patrones de diseo son un buen mtodo para resolver pequeos problemas que pueden adaptarse a una variedad mucho ms amplia de problemas especficos. En aplicaciones basadas en Web, los patrones de diseo pueden aplicarse en el nivel jerrquico, nivel de componentes y nivel de hipertexto. Diseo de navegacin: Establecida una arquitectura, una vez identificadas ciertos atributos del sistema (pginas, guiones, applets y otras funciones de proceso) de la arquitectura, se debe definir la navegacin que permitan acceder al contenido y a los servicios del sistema. Diseo de la interfaz: El diseo no debe depender del navegador para ayudar en la navegacin. La esttica nunca debe sustituir la funcionalidad. Las opciones de navegacin debern ser advertidas para el usuario casual. El usuario deber buscar la pantalla para determinar cmo enlazar con otro contenido o servicio.

INGENIERA DE SOFTWARE BASADO EN COMPONENTES La ISBC, segn Sommerville (2005) el proceso consiste en definir, implementar e integrar en sistemas componentes independientes dbilmente acoplados, es decir funcionalmente independiente. Aunque a decir verdad no siempre esto se cumple. Segn Pressman (2005) el proceso de ISBC se caracteriza por no slo identificar los componentes candidatos sino que tambin cualifica la Interfaz de cada componente, adaptar los componentes para eliminar las equivocaciones arquitectnicas, ensambla los componentes en un estilo arquitectnico seleccionado y actualiza los componentes conforme los requisitos del software cambian. El desarrollo de software basado en componentes puede verse como una extensin natural de la programacin orientada a objetos dentro del mbito de los sistemas abiertos y distribuidos (Piattini y Garca, 2003, 161). Tipos de Reutilizacin de componentes Para Braude (2003) al igual que Schach (2006) existen dos formas de reutilizacin: la oportunista o accidental y la sistemtica o premeditada.

Reutilizacin oportunista: los desarrolladores de un producto nuevo se dan cuenta de que pueden reutilizar un componente de un producto antes desarrollado en el producto nuevo. Reutilizacin sistmica: componentes del software construidos especficamente para reutilizarlos en el futuro.

Caractersticas de los componentes:

11

Los componentes son ms abstractos que las clases de objetos y se pueden considerar como proveedores independientes de servicios. Cuando un sistema necesita algn servicio, llama a un componente que provea ese servicio sin importarle que dicho componente se est utilizando o qu lenguaje de programacin utiliz para desarrollarse. Los componentes se comunican a travs de sus interfaces bien definidas, de forma que si estas interfaces se mantienen, un componente puede reemplazarse por otro que proporcione una funcionalidad adicional o mejorada. El componente es una entidad ejecutable e independiente. Su cdigo fuente no est disponible de tal forma que no se compila con los otros componentes del sistema. Los componentes publican su interfaz y todas interacciones son a travs de ella. La interfaz de los componentes se expresa en trminos de operaciones parametrizadas y nunca se expone su estado interno.

Ventajas de la Reutilizacin de componentes Cuando los componentes reutilizables se aplican a lo largo del proceso de software, se dedica menos tiempo a la creacin de planes, modelos, documentos, cdigo y datos que se requieren para crear un sistema fiable. Por lo tanto, se entrega al cliente el mismo nivel de funcionalidad con menos esfuerzo, lo que mejora la productividad. Los ahorros en el costo neto por la reutilizacin se estiman al proyectar el costo del proyecto si este fuese desarrollado desde cero, Co, y luego se resta la suma de los costos asociados con la reutilizacin, Cr, y el costo real del software en el momento de la entrega. La forma en la que podemos tratar con la complejidad y entregar mejor software ms rpidamente es reutilizar componentes software en vez de reimplementarlos.

Desarrollo de componentes para reutilizacin El componente debe reflejar abstracciones estables del dominio. stas son conceptos fundamentales en el dominio de la aplicacin que cambian lentamente. Los componentes deben ocultar la forma en que se representa su estado y deben proveer operaciones que permitan tener acceso y actualizar el estado. El componente debe ser independiente en too lo posible. De forma ideal, un componente no debe necesitar de otros para operar. En la realidad algunos componentes dependern de otros. Todas las excepciones deben ser parte de la interfaz del componente. Los componentes no deben manejar excepciones por s mismos puesto que diversas aplicaciones tendrn requerimientos diferentes prale manejo de excepciones.

Composicin de componentes

12

La composicin de componentes es el proceso de ensamblar componentes para crear un sistema. Composicin secuencial: donde los componentes constituyentes se ejecutan en secuencia. Composicin Jerrquica: un componente realiza una llamada a los servicios proporcionados por otro componente. Composicin Aditiva: las interfaces de dos o ms componentes se une para formar un nuevo componente.

Aspectos tecnolgicos Para que los componentes pueden distribuirse y ser accedidos de forma remota, necesitan tener un nombre o manejador nico asociado a ellos. En COM+, ste es un identificador nico de 128 bits. En el modelo de componentes CORBA y en EJB (Enterprice Java Beans), es un nombre jerrquico con una raz basado en un nombre de dominio de Internet. Los metadatos de componentes son datos sobre el mismo componente, tales como informacin sobre sus interfaces y atributos. Los metadatos son importantes para que los usuarios del componente puedan encontrar qu servicios se proporcionan y cules se requieren. Una parte importante de un modelo de componentes es una definicin de cmo los componentes deberan empaquetarse para su despliegue como entidades ejecutables independientes. La informacin de despliegue incluye informacin sobre contenidos de un paquete y su organizacin binaria. Los modelos de componentes no slo son estndares: son tambin la base para el middleware de sistemas que proporcionan el soporte para los componentes ejecutable. Los servicios proporcionados por la implementacin de un modelo de componentes pueden pertenecer a dos categoras (Sommerville, 2005). Servicios de plataforma: permiten a los componentes comunicarse entre s. CORBA es una ejemplo de una plataforma de modelos de componentes. Servicios Horizontales: independientes de la aplicacin. Aspectos tecnolgicos de componentes en Web La infraestructura Intenet/Intranet basada en los servidores Web y sus extensiones (ASP, JSP, PHP, Servlets, etc.) conforman el estndar de facto del desarrollo de aplicaciones Web distribuidas actual. La migracin de muchas aplicaciones (no slo las de comercio electrnico o portales) a esta arquitectura, y la adaptacin de los mtodos y notaciones de ingeniera del software a este entorno, hacen razonable el considerar dicha infraestructura como un soporte bsico del desarrollo (Gonzlez, et al, 2001). El uso de XML permite comunicar aplicaciones diferentes a travs de servicios Web. Ello posibilita la comunicacin entre aplicaciones realizadas con distintos lenguajes. Mediante

13

una capa deservicio web sobre una aplicacin ya existente, los sistemas externos puedan Lamar funciones de la aplicacin a travs de Internet (o intranet). Segn Yang y Papazoglou (2002) Web components are a packaging mechanism for developing web-based distributed applications in terms of combining existing (published) web services. Web components have a recursive nature in that they can be composed of published web services while in turn they are also considered to be themselves web services (albeit complex in nature). Yang, J. Papazoglou, M.(2002), Web Components: A Substrate for Web Service Reuse and Composition, Proceedings of 14th Conference on Advanced Information Systems Engineering (CAiSE02), Toronto. METODOLOGA DE DESARROLLO DE SISTEMAS DE INFORMACIN WEB BASADA EN COMPONENTES
Desarrollo de Modelo General Anlisis y especificacin de Requisitos Plan de Caracterizacin Anlisis de Dominio

Diseo

Construcci

Gestin de component

Fig. 1. Flujo de la Metodologa

El desarrollo de sistemas Web ( fig. 1) basado en componentes basa las expectativas en: la consideracin de ciclo o tiempos cortos de entrega por medio de una metodologa iterativa, el desarrollo gil (mitologas giles), desarrollo de sistemas utilizando tecnologa orientada a objetos y la ingeniera de componentes. La introduccin de los principios del desarrollo de sistemas basado en componentes es agilizar mucho ms el desarrollo de sistemas Web, dado que actualmente la tendencia es implementar sistemas corporativos tradicionales en la Web. Desarrollo de la Metodologa

14

Anlisis de dominio Pressman, R (2005) seala como fase inicial de ingeniera de sistemas basados en componentes que la finalidad de la ingeniera del dominio es identificar, construir, catalogar y diseminar un conjunto de componentes de software que sean aplicables para el software existente y futuro en un dominio particular. Bsicamente un dominio es: un rea de aplicacin de productos de software, centrado en un cuerpo de conocimientos; adems, de tener una economa de alcance asociado. Se Busca establecer un contexto de negocio (Montilva,J 2006). Proceso de anlisis del Dominio El proceso de anlisis de proceso est ubicado dentro de la ingeniera de software orientada a objetos. Definir el dominio que se investigar Categorizar los elementos extrados del dominio Recopilar una muestra representativa de las aplicaciones en el dominio Analizar cada aplicacin en la muestra y definir las clases de anlisis. Desarrollar un modelo de anlisis para las clases.

15

Para definir el dominio, sus caractersticas y sus componentes, se establece la siguiente plantilla (fig. 2).

Dominio Descripcin Caractersticas funcionales

Dominio Supremo

Valoracin

Clases de Dominio

Descripcin

Fig. 2. Artefacto N 1 Desarrollo de un Modelo General Se trata de encontrar las fronteras y las principales entradas y salidas sin necesidad de detalles, as como los procesos principales. El desarrollo del modelo general trata de especificar una serie de objetivos que el sistema debe cumplir en la interaccin con el usuario. El desarrollo de esta fase no se asemeja al diagrama de contexto del enfoque de Anlisis Estructurado, a diferencia de ste no busca definir jerarquas de los procesos. El sentido de esta fase es la de una lista de objetivos no necesariamente vistos como una funcin o un comportamiento sino ms bien como un papel dentro del sistema: Bsicamente un Modelo General trata de definir la navegacin y las operaciones posibles que pueden realizarse en cada interfaz o nodo del sistema. Es decir, describe la forma cmo opera el sistema y porqu lo hace.

16

El producto de esta fase es una narracin que es acompaada por la definicin de objetivos (Fig 3). Puede contener secuencias, as como, rupturas cronolgicas. Los objetivos pueden listarse de forma jerrquica para que sea ms fcil la siguiente fase de requisitos.

Dominio:

Narracin :

Jerarqua de Objetivos:

Fig. 3. Artefacto N 2

Anlisis y especificacin de requisitos Bsicamente en la ingeniera de software tradicional se ha tratado los requisitos funcionales y los requisitos no funcionales. Para otros autores existe una distincin entre requisitos de usuario y requisitos del sistema, y tambin requisitos funcionales, no funcionales y de dominio que es dada por Sommerville (2005), otra distincin est en requisitos normales, esperados y estimulantes, ofrecida por Pressman (2005). De forma particular la ingeniera Web necesita de no nuevas formas de requisitos pero s de formas de obtener requisitos. No obstante, es necesario agrupar de una forma diferente los requisitos de tal forma que sean fcilmente administrados. Paloma, et al (2004), analiza perspectivas de modelados, los cuales llevarn a los requisitos de manera que se pueda definir un modelo de desarrollo. Entre las perspectivas se toma en cuenta: la navegacin, aspectos funcionales, la presentacin, la estructura, el comportamiento y la seguridad.

17

Escalona y Koch (2002) definen dentro del anlisis de requisitos: Requisitos de datos, tambin denominados requisitos de contenido, requisitos conceptuales o requisitos de almacenamiento de informacin. stos requisitos responden a la pregunta de qu informacin debe almacenar y administrar el sistema. Requisitos de interfaz (al usuario), tambin llamados en algunas propuestas requisitos de interaccin o de usuario. Responden a la pregunta de cmo va a interactuar el usuario con el sistema. Requisitos navegacionales, recogen las necesidades de navegacin del usuario. Requisitos de personalizacin, describen cmo debe adaptarse el sistema en funcin de qu usuario interacte con l y de la descripcin actual de dicho usuario. Requisitos transaccionales o funcionales internos, recogen qu debe hacer el sistema de forma interna, sin incluir aspectos de interfaz o interaccin. Tambin son conocidos en el ambiente Web como requisitos de servicios. Requisitos no funcionales, son por ejemplo los requisitos de portabilidad, de reutilizacin, de entorno de desarrollo, de usabilidad, de disponibilidad, etc.

Se cuenta con una artefacto que nos permite agrupar los requisitos por los objetivos del sistema (fig 4).

Requisito

Tipo

Objetivo Relacionado

Fig. 4. Artefacto N 3

Plan de caracterizacin

18

 Descripcin de caractersticas El funcionamiento de la aplicacin debe tambin especificarse como en cualquier otro tipo de producto software. Este punto considera una caracterstica como bloques de funcionalidad. Estos bloques de funcionalidad tratan de relacionar el modelo lgico con los requisitos antes encontrados de tal manera que se vaya desarrollando modelos para el anlisis que puedan y obtener productos. En este punto las tareas a desarrollar son: Validar los requisitos. Negociacin con el cliente. Revisin con un grupo de usuarios prueba. Validacin y especificacin de requisitos y caractersticas

Funciones de caracterizacin Una caracterstica de dominio define algn atributo genrico de todos los productos que existen dentro de l. La premisa que lleva a esta etapa es que todo dominio tiene caractersticas agrupadas que se expresa como subsistemas o mdulos que tiene una funcin fcilmente identificable. Bsicamente el anlisis, hasta este punto, nos debe llevar a una serie de especificaciones jerrquicas. Un conjunto de caractersticas de dominio de un componente reutilizable se puede representar como Dp, donde cada elemento, Dpi, en el conjunto representan una caracterstica especfica del dominio. Un Dpi puede estar en un Dp o distintos Dp de otras aplicaciones, la idea es trabajar con una biblioteca de dominios que sus caractersticas bien definidas. Incluso un componente podra estar en otro dominio. As decimos que existe una clase de dominios. Los productos de esta fase consisten en dos informes, Informe de Dominio (fig 5) y el informe de escenario y funcionalidad (fig 6)

19

Dp

Dp{i-n}

Objetivo Relacionado

Fig. 5. Artefacto N 4 La relacin entre el conjunto de caractersticas (Dpi) y los objetivos relacionados deben traducirse en especificaciones para diagramas de actividad que forma parte de la notacion UML del diseo orientado a objetos. As mismo es posible realizar los diagramas de secuencia. Informe de escenario y funcionalidad: El escenario permite identificar los casos de uso para el anlisis.

Dpi

Escenario (Ei)

Funcionalidad

Clases Relacionada.

Fig. 6. Artefacto N 5

Diseo

Dentro de la fase de diseo se revisa aspectos relacionados con la arquitectura, la estructura, navegacin, presentacin, interfaz.

Las fases anteriores se consideran importantes ya que permiten al equipo de ingeniera pensar en piezas, como si se tratara de una artefacto que se nos proporciona en piezas y existe la necesidad de armarlo. Es importante tomar informacin se cmo se implementar y qu detalles se tomarn en cuenta.

20

Las entradas identificables para esta fase son: Dominio, y partes del dominio, Modelo General descrito, Funciones de caracterizacin, Tecnologa (base de datos, SO, etc. de salida y entrada). Una de las ideas bsicas de la fase de diseo son las restricciones sealadas en Paloma, et al, (2004): Restricciones tcnicas: sobre la plataforma tcnica, la forma en que va a distribuirse el producto. Restricciones cognitivas: se basa en la navegacin y en el diseo de interfaz y la presentacin bsicamente buscando la usabilidad. Restricciones no tcnicas: aspectos legales, seguridad y autenticidad.

Es importante seguir una plantilla de trabajo para determinar las especificaciones del diseo. WebHouse (2003) ofrece una lista de especificaciones que podran servir de modelo a seguir. Otro aspecto a considerar importante es la pirmide de diseo realizada por Pressman, R (2005) que nos da una idea de cmo llevar a cabo sistemticamente el diseo del sistema Web: diseo de componentes, diseo arquitectnico, navegacin de contenido, diseo esttico, diseo de la interfaz. El ltimo producto elaborado es importante para la fase de diseo. Pressman, R (2005) nos dice del diseo de contenido, que sera un primer avance del desarrollo conceptual del sistema Web. Por otro lado la OOHDM: Object Oriented Hypermedia Design Model. Diseada en 1999, proporciona el diseo conceptual que es en esencia el diseo de contenido ms las funciones. Y dentro de los productos de trabajo quedan especificados las clases, subsistemas y atributos. Luego de esa fase se puede seguir con el diseo de navegacin, diseo de arquitectura, diseo de interfaz En esta fase se puede tomar los casos de uso d anlisis como base para el diseo. Se realizan los casos de uso del diseo y se aade a la documentacin la Unidad Semntica de Navegacin. Otra de las notaciones que puede considerarse es la del Modelo de sitio Web Conceptual-funcional.

Este modelo contiene una visin de los que se llama las pginas o las interfaces grficas que el usuario visualiza por el navegador y servir para mostrar las partes de esas pginas, as como sealar las funciones asociadas a los elementos de las interfaces (fig 7).

21

Pagina

Element o

Funcionalida d

Fig. 7. Artefacto N 6 Caractersticas Es parecido al Mapa de sitio Web. Contiene elementos de pginas: banners, multimedia, Interfaces de aplicaciones, etc. incluso un Botn o un link. Las funcionalidades describen un comportamiento de un elemento. Un elemento puede llevarnos a otra pgina pero una pgina contiene elementos.

Se puede adjuntar un documento con la descripcin del Modelo de sitio Web conceptualFuncional. La narracin se har de forma jerrquica , empezando por la pgina. Gestin de componentes Esta fase y la siguiente, facilitan y dan un Marco de trabajo disciplinado para el desarrollo de Sistemas Web basados en componentes: La idea, es tener un claro conocimiento de ciertas pautas de la reutilizacin sistmica y de enero una base de datos de componentes reutilizables y tenerlos perfectamente documentados, sobre ello se realiza la bsqueda, seleccin y la respectiva validacin del o de los componentes necesario para el sistema que se est desarrollando. En caso de no tener el componente listo se debe especificar su diseo, el equipo de desarrollo debe facilitar esto mediante un formato y un plantilla, sobre lo cual se pueda realizar la documentacin y mantener un mismo estilo en el desarrollo de sistemas y componentes. Existen ciertas condiciones que deben tenerse en cuenta en esta fase que deben adjuntarse en la documentacin. Modo de Documentacin de un componente para reutilizacin (fig. 8).

22

Componente Candidato

Funcionalidad

Dominios

Colaboracin

Clases

Descripcin de interfaces

Fig. 8. Artefacto N 7 Construccin. Piattini, M y Garca, F. (2003) manifiestan que una vez seleccionado los componentes candidatos, es preciso realizar una adaptacin o extensin de los mismos a la hora de integrarlos. La fase de contricin considera la composicin de componentes y la construccin de componentes faltantes y de cdigo adicional que no es necesariamente reutilizable sino que forma parte de la composicin de componentes. Como el desarrollo Web se basa en procesos rpidos de metodologas giles y dentro de la programacin orientada a objetos (Pressman, 2005). Sin embargo, no lo hace el proceso de desarrollo de sistemas basados en componentes propuestos dentro del mbito de la ingeniera de software basada en componentes. La fase de construccin determina hasta qu punto dentro de un proceso incremental se ha avanzado de tal manera que se pueda dar satisfaccin a las prioridades especificadas y negociadas con el cliente. Para el caso de los componentes que en esta fase se construyan se hace uso de una plantilla que me permita documentarlo (fig. 9).

Componente

Funcionalidad

Subsistema

Colaboracin

Clases

Descripcin de interfaces

23

Fig. 9. Artefacto N 8 En esta fase es fundamental complementar desarrollar un diagrama de despliegue, especificando los componentes y las interfaces del sistema. Se hace uso de un documento de composicin (fig. 10).
Componente Colaborador Subsistema Tipo de composicin

Fig. 10. Artefacto N 9 Relacin entre artefactos introducidos La metodologa cuenta con artefactos propios, se consideran as mismo diagramas UML para el anlisis y diseo del sistema, la introduccin de componentes nuevos tiene por finalidad ayudar en el proceso de la metodologa con el fin de llevar desde el dominio y los requisitos hasta los componentes necesarios, as mismo, gestionar de una manera sistmica el desarrollo de sistemas Web, la introduccin de la descripcin de objetivos , el listado de funcionalidades, relacin de escenarios y el modelo de sitio conceptualfuncional tiene por finalidad describir de una manera natural el sistema explicado la interaccin del usuario, el entorno y los elementos grficos con los cuales interacta. DISCUSIN La metodologa cuenta con artefactos propios, se consideran as mismo diagramas UML para el anlisis y diseo del sistema, la introduccin de componentes nuevos tiene por finalidad ayudar en el proceso de la metodologa con el fin de llevar desde el dominio y los requisitos hasta los componentes necesarios, as mismo, gestionar de una manera sistmica el desarrollo de sistemas Web, la introduccin de la descripcin de objetivos , el listado de funcionalidades, relacin de escenarios y el modelo de sitio conceptualfuncional tiene por finalidad describir de una manera natural el sistema explicado la interaccin del usuario, el entorno y los elementos grficos con los cuales interacta. Mediante el siguiente ejemplo se puede apreciar los paso de la metodologa y la relacin entre los artefactos propuestos.

24

Desarrollo de sistemas de banca virtual Artefacto N 1-Anlisis de dominio

Dominio

Transacciones financieras virtuales

Dominio Supremo

Banca y finanzas

Descripcin

En este Dominio se realizar envo electrnico de dinero a otras cuentas bancarias Valoracin (1-4) 3

Caractersticas funcionales Envo de dinero entre cuentas de una mismo banco o diferentes Transacciones electrnicas de dinero Envos internacionales sin desplazamiento fsico Clases de Dominio Cuenta Cliente Banco Transferencia Descripcin

4 2

Gestiona las cuentas Gestiona la informacin del cliente Permite operar con distintos bancos Gestiona los movimientos o transacciones

Artefacto N 3 -Requisitos a considerar (solo del mdulo a trabajar) Lista de objetivos: Habilitar al usuario que realice transacciones bancarias [1] Realizar las transacciones de manera segura [2] Tener capacidad de interaccin sencilla [3] Presentar alternativas de transaccin [4]

Requisito

Tipo

Objetivo Relacionado

25

1 2 3 4 5 6 7

Acceder al mdulo de trasferencias Seleccionar tipos de transferencias Validar los datos del beneficiario Validar los datos del banco destino Validar datos de transferencia Validad operacin virtual Presentar datos de operacin

Transaccional Interfaz Datos Datos Datos Transaccional Interfaz, Navegacin Transaccional Interfaz, Navegacin Personalizacin

1 4 2 2 2 2 4

8 9

Controlar operacin de transferencia Realizar virtual constancia de operacin

4 3

10

Operar mediante controles visuales interactivos Presentar informacin interaccin gua de

11

Personalizacin

12

Presentar informacin retroalimentacin de transaccin

de

Interfaz

13

Actualizar informacin de cuenta del usuario Actualizar informacin transacciones de usuario Realizar una transaccin segura de

Transaccional

14

Transaccional

15

No funcional

26

Artefacto N 4- Informe de Dominio

Dp Transacciones financieras virtuales Dp{i-n} Trasferencias de dinero Objetivos Relacionado 1,3,4 (parte de este mdulo) 2 (parte de este mdulo) 1,3,4 1,3,4

Seguridad de transacciones financieras Pagos electrnicos Programar trasferencias

Artefacto N 5 - Informe de escenario y funcionalidad

Dpi Transferencia de dinero Escenario (Ei) Envo local Funcionalidad El usuario realizar ene. Envo de dinero entre cuentas locales (geogrficamente) Clases Relacionada. Cliente, Cuenta, Destinarttario, movimiento, Transaccin, OperacionesFinancieras LugarGeogrfico, conexinBD Envo entre cuentas El usuario realizar envo de dinero entre cuentas de su propiedad Cliente, Cuenta, movimiento, Transaccin, OperacionesFinancieras LugarGeogrfico, conexinBD Envo diferentes cuentas mismo banco El usuario realizar envo de dinero a una cuenta que no es de su propiedad Cliente, Cuenta, Beneficiario, movimiento, Transaccin, OperacionesFinancieras LugarGeogrfico, conexinBD Envo entre diferentes cuentas de diferentes Le usuario realizar envo de dinero a una cuenta que no pertenece al banco Cliente, Cuenta, Beneficiario, movimiento, Transaccin,

27

bancos

el cual est afiliando.

OperacionesFinancieras LugarGeogrfico, Banco, conexinBD

Artefacto N 6 Modelo de Sitios Conceptual-funcional

Label_Usuario

Pgina de transferencia entre cuentas propias

Combo_N Cuenta

[..] Botn_Aceptar
Procesa informacin, responde a confirmacin con un cuadro mensaje y al

Confirmacin de transaccin

28

Artefacto N 7 Componente para reutilizacin

Componente Candidato Trasacciones financieras [1] Transacciones de banca virtual[3] Transacciones virtuales Componentes de seguridad, Conexin a base de datos Cliente, Cuenta, Beneficiario, movimiento, Transaccin, OperacionesFinancieras LugarGeogrfico, Banco, conexinBD Trasacciones electrnicas[2] *Interfaz grfica con [descripciones anteriores] *Interfaz para base de datos Funcionalidad Dominios Colaboracin Clases Descripcin de interfaces

Artefacto N 8-Componente de reutilizacin y su relacin

Compone nte Transaccio nes de banca virtual[3] Funcionali dad Le usuario realizar envo de dinero a una cuenta que no pertenece al banco el cual est afiliando, envo a una cuenta propia del mismo banco, cuenta no propia Subsistem a Mdulo de trasferen cias de dinero de banca virtual Colaboraci n *Conexin a base de datos. *Conexin de seguridad. *conexin al sistema operativo. . *Compone ntes de pagos *componen tes de gestin de Clases Descripcin de interfaces *Interfaz grfica con [descripciones anteriores] *Interfaz para base de datos *Interfaz para clase de manejo de cuentas de otro banco

Cliente, Cuenta, Beneficiario, movimiento, Transaccin, Operaciones Financieras LugarGeogrfico, Banco, conexinBD ConexinBanco

29

propia (beneficiari a) del mismo banco, cuanta de otro banco.

cuentas

Artefacto N 9-Informe tcnico de composicin

Componente

Colaborador Directo *Conexin a base de datos. *componente transacciones interbancarias

Subsistema

Tipo de composicin

Transacciones de banca virtual[3]

Mdulo de trasferencias de dinero de banca virtual

Composicin Jerrquica, con otros componentes del dominio especfico,

Composicin aditiva con componentes de Base de datos, Componentes de servicios del sistema

30

Diagrama de despliegue

Servidor de BAse de datos CoenccinBD

1 : servidor de aplicaciones de Banco Servicios de Seguridad ServiciosSistema 1 Interfaz4 1 * Transacciones de banca virtual Interfaz3 * * * Interfaz2 * ConexinExteriorBAnco Interfaz1 * InterfazGrfica * Computadora Cliente Navegador

ServiciosBancoExterno

31

CONCLUSIONES La metodologa DSIWBC tiene por objetivo minimizar el tiempo de entrega de un sistema de informacin Web, teniendo consideraciones de calidad y eficiencia en la construccin del producto. Los beneficios asociados al DSIWBC, es la reusabilidad de componentes y beneficios en cuanto la creacin de sistemas web, en cuanto de ajusta a tendencias actuales del desarrollo Web: metodologas giles, programacin orientada a objetos, servicios Web. La metodologa propuesta, agiliza la identificacin de componentes por medio de la declaracin de objetivos y su relacin con la ingeniera del dominio y el modelo conceptual-funcional. Mediante los artefactos propuestos, el proceso de desarrollo se complementa, junto a diagramas tradicionales para el desarrollo de software y desarrollo Web, permitiendo una mejor especificacin funcional del sistema que se est desarrollando.

Recomendaciones para trabajos futuros Este trabajo no especifica el uso de mtricas ni tipos de pruebas de componentes, as como tampoco propone una herramienta, un software, para el desarrollo y la gestin de los artefactos especificados en la metodologa. Por lo que en trabajos futuros se recomienda profundizar ms en la temtica y elaborar mtricas y tipos pruebas que se ajusten a la metodologa, as como elaborar una herramienta que permita gestionar el proceso. BIBLIOGRAFA Braude, Eric J. (2003) Ingeniera de software: una perspectiva orientada a objetos. Alfaomega Grupo Editor. Mxico, DF. Granell, C. Reutilizacin de servicios Web mediante componentes integrados. Universidad de Jaume-I. Departamento de lenguajes y sistemas informticos. Castelln, 2006. Paloma Daz, Mara; Montero, Susana; Aedo, Ignacio (2004) Ingeniera de la web y patrones de diseo .Pearson Educacin., Madrid. Piattini Velthuis, Mario G.; Garca Rubio, Flix O. (2003). Calidad en el desarrollo y mantenimiento del software Alfaomega Grupo Editor. Mxico. Pressman, Roger S. (2005).Ingeniera de software: un enfoque prctico. 6 Edicin. Mc Graw-Hill Interamericana. Mxico, DF Schach, Stephen R. (2006) Ingeniera de software clsica y orientada a objetos. 6 Edicin. Mc Graw-Hill Interamericana. Mxico DF.

32

Sommerville, Ian (2005) Ingeniera de software. 7 Edicin. Pearson Education. Madrid. Marco Brambilla, M; Ceri, E; Fraternali, P y Manolescu, I (2006) Process Modeling in Web Applications , ACM Transactions on Software Engineering & Methodology; Oct2006, Vol. 15 Issue 4, p360-409, 50p. Disponible en: http://search.ebscohost.com/login.aspx?direct=true&db=iih&AN=23118730&lang=es& site=ehost-live Crnkovic, I, Hnkh,B; Kizilfan, Z (2002) Specification, Implementation, and Deployment of COMPONENTS , Communications of the ACM; Oct2002, Vol. 45 Issue 10, p35 -40, 6p, 2 diagrams, 1c. Disponible en: http://search.ebscohost.com/login.aspx?direct=true&db=iih&AN=7517683&lang=es&s ite=ehost-live Levi, K y Arsonjan, A. (2002) A Goal-driven Approach to ENTERPRISE COMPONENT IDENTIFICATION AND SPECIFICATION, Communications of the ACM; Oct2002, Vol. 45 Issue 10, p45 -52, 8p, 4 diagrams, 1c. Disponible en: http://search.ebscohost.com/login.aspx?direct=true&db=iih&AN=7517689&lang=es&s ite=ehost-live Gonzlez, E; Jurez, L; Sicilia, M, (2001 XML como tecnologa de componentes distribuidos: usos y posibilidades de las tecnologas estndares de Internet para el desarrollo de componentes software. URL : http://www.willydev.net/descargas/prev/sicilia.pdf (2007-10-10) Escalona, Mara y Gonzlez, Jos (2007) Metodologa y Tcnicas en Proyectos software para la Web.URL: www.lsi.us.es/docencia/pagina_asignatura.php?id=49 - 21k (2007-10-5) Castejn, Juan(2004) Arquitectura y diseo de sistemas Web modernos. Montilva, Jons (2006) Desarrollo de Software Basado en Lneas de Productos de Software. URL: www.ieee.org.ar/downloads/2006-montilva-productos.pdf (2007-09-29) WebHouse (2003) Especificaciones diseo Web. URL: http://www.webhouse.es/downloads/WebDesign.pdf (2007-10-12) Yang, J. Papazoglou, M (2002) Web Component: A Substrate for Web Service Reuse and Composition. URL: http://infolab.uvt.nl/pub/yangj-2002-65.pdf (2007-10-12) Escalona, Mara y Koch, Nora (2002)Ingeniera de Requisitos en Aplicaciones para la Web. URL: www.lsi.us.es/docs/informes/LSI-2002-4.pdf (2007-10-06)

33

EVALUACIN Y PROPUESTA DE LA GESTIN DE RIESGOS DEL DEPARTAMENTO DE DESARROLLO DE SISTEMAS USAT2

RESUMEN La presente investigacin se plante como objetivo evaluar la gestin de riesgo en el Departamento de Desarrollo de Sistemas de la USAT, de tal manera que mejorar su proceso de desarrollo para la obtencin de software de mayo calidad. Es as que la investigacin ha tomado en cuenta el marco terico sobre riesgo y la gestin de riesgo, as como las metodologas usadas actualmente a nivel mundial. Partiendo de esa base terica se procedi a evaluar al Departamento y despus de dicha evaluacin se propuso la disciplina de administracin de riesgos de MSF (Microsoft Solutions Framework).

Palabras claves: Riesgo, Gestin, SEI.

INTRODUCCIN El poner en marcha un proyecto para el desarrollo de un software es una labor que debe darse con mucho cuidado, porque de lo contrario la prdida sera abundante. Dentro de las tareas que se deben llevar a cabo para que el proyecto no termine en un fracaso, es la gestin de riesgo. La gestin de riesgo es el proceso por el cual el equipo del proyecto toma las medidas necesarias para hacer frente a posibles adversidades que si llegarn a convertirse en realidad generara prdida y hasta el fracaso total del proyecto. Por otro lado, la Universidad Catlica Santo Toribio de Mogrovejo cuenta con un Departamento de Desarrollo de Sistemas, el cual implementa software acadmicos y administrativos para el uso de la Universidad. Debido a la importancia de su labor, se decidi realizar una evaluacin de la gestin de riesgo del Departamento, y a partir de dicha evaluacin proponer una metodologa que mejore el proceso de desarrollos de software. Para cometer con su objetivo, la investigacin se ha desarrollado en cuatro captulos, los cuales van a permitir primero hacer una revisin terica sobre todo lo relacionado a
Cruzalegui Cruzalegui, Jos A

34

gestin de riesgo, despus se realiza la evaluacin de la gestin de riesgo en el departamento, para terminar con la protesta que ayude al equipo a mejorar el proceso del desarrollo de software. En el primer captulo, se detalla todos lo concerniente al la investigacin, su objetivo principal, la justificacin y la hiptesis, as tambin como los antecedentes a la investigacin. En el siguiente captulo se desplaya en todo lo concerniente a riesgo y gestin de riesgo, y tambin se exponen las metodologas utilizadas en la actualidad por los distintos equipos de software. En el tercer captulo se muestran los resultados de la evaluacin que se le hizo al Departamento de Desarrollo de sistemas; y en el ltimo captulo se presenta la propuesta con su respectiva aplicacin.

RIESGO. Concepto. Existen distintos autores que conceptualizan dicho trmino, entre esos conceptos se tienen: El riesgo es la posibilidad de sufrir prdida. En un proyecto de desarrollo, la prdida describe el impacto al proyecto que podra aparecer como la disminucin de calidad del producto final, costes crecientes, demoras en la terminacin y/o faltas (Webster 2004) El riesgo y la oportunidad van tomados de la mano. Muchos proyectos del desarrollo se esfuerzan en superar capacidades actuales y alcanzar algo que no se ha hecho antes. La oportunidad para el adelanto no puede ser alcanzada sin tomar riesgo. El riesgo en s mismo no es malo; el riesgo es esencial para progresar, y muchas veces forma parte del proceso de aprendizaje. Pero debemos aprender como balancear las consecuencias negativas posibles del riesgo contra las ventajas potenciales de su oportunidad asociada (Van Scoy 2001) El riesgo se relaciona con los acontecimientos futuros. El hoy y el ayer estn ms all de esta relacin, pues ya se ha cosechado lo que previamente se sembr con nuestras acciones pasadas. La pregunta es: podemos, por tanto, al cambiar nuestras acciones presentes, crear en lo futuro una oportunidad para una situacin diferente, y esperanzadoramente mejor, para nosotros mismos? Esto significa, que el riesgo implica cambio, como cambios de mentalidad, opinin, acciones o lugares [en tercer lugar] el riesgo implica eleccin y la incertidumbre que sta conlleva. Por ende, paradjicamente, el riesgo, al igual que la muerte y los impuestos, es una de las pocas certezas en la vida (Charette 1989) De forma simple, se puede concebir un riesgo como una probabilidad que una circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el software que se est desarrollando y para la organizacin (Sommervile, 2005) Un riesgo es algo que puede ocurrir en el curso de un poryecto que, segn el peor resultado, afectara de manera negativa y significativa. Por ejemplo, Rational

35

Corporation asegura que ms del 70% los proyectos de software tienen problemas o un deterioro severo (Fraude 2003) Se podra definir riesgo como cualquier elemento potencial que puede provocar resultados insatisfactorios en el desarrollo de un proyecto (Snchez et al. 2003) Caractersticas. Incertidumbre. No existe ni un riesgo que tenga una probabilidad al 100% que ocurra. Prdida. Cuando el riesgo suceda ocurrirn consecuencias o prdidas no deseadas. Categoras. a. Riesgos del Proyecto. Estos afectan directamente el plan del proyecto. Si estos riesgos suceden afectarn la calendarizacin o recursos del proyecto. Segn Pressman los riesgos del proyecto identifican potenciales problemas en: Presupuesto. Calendarizacin. Personal (plantillas y organizacin) Recursos. Participantes. Requisitos. Esto implicar costos por diversas razones como pueden ser: Sobrecostos por mayor cantidad de horas trabajo Multas por incumplimiento Inversiones para impedir mayores retrasos Como ejemplo, de riesgo de proyecto, se puede mencionar la prdida de un diseador experimentado. b. Riesgos tcnicos. Los riesgos tcnicos producen problemas de calidad o rendimiento del software que se est desarrollando; y ocurren porque en un principio el problema pareca ms fcil de resolver. Si llegan hacerse realidad los riesgos tcnicos, dificultan la implementacin. Estos riesgos identifican potenciales problemas en: Diseo. Implementacin. Interfaz. Verificacin. Mantenimiento. Otros factores de riesgo son la ambigedad de la especificacin, incertidumbre tcnica, la obsolescencia tcnica y la tecnologa de punta (Pressman, 2005). Un ejemplo sera que el rendimiento de un componente que se adquiri sea menor al esperado.

36

c. Riesgos del Negocio. Estos problemas afectan a la organizacin que desarrolla o suministra al software (Sommerville 2005). Entre los tipos de riesgos del negocio se encuentran: De mercado: desarrollar un producto que nadie quiere o necesita. Estratgico: desarrollar un producto que no encaja dentro del plan estratgico de la compaa. De comercializacin: desarrollar productos que no saben como venderlos. De direccin: prdida de apoyo de gestin por cambios de objetivos o de personal De presupuesto: Perder el presupuesto o personal asignado Como ejemplo de este riesgo, es que un competidor introduzca un nuevo producto. Se debe resaltar que, los problemas no son exclusivos entre s, si un programador experto abandona el proyecto, esto es un riesgo para el proyecto (debido a que la entrega del sistema se puede retrasar), para el producto (debido a que un sustituto puede ser no tan experto y cometer muchos errores) y para el negocio (debido a que esa experiencia puede no contribuir a negocios futuros) (Sommerville 2005) Existe otra clasificacin propuesta por Charette: Riesgos conocidos. Se establecen o se conocen despus de un estudio detallado del plan de trabajo del proyecto. Ejemplo: Fechas de entrega poco realistas, falta de especificaciones. Riesgos predecibles. Los cuales pueden ser extrapolados de experiencias anteriores. Ejemplo: Cambios de personal, mala comunicacin con clientes. Riesgos impredecibles. No se conocen ni se pueden predecir, se solucionan solo de forma reactiva.

GESTIN DE RIESGO. Concepto. Entre los distintos conceptos se tienen: Una tarea importante del gestor de proyectos es anticipar los riesgos a la programacin del proyecto o a la calidad del software a desarrollar y emprender acciones para evitar los riesgos. Los resultados de este anlisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el anlisis de consecuencias cuando el riesgo ocurra (Sommervile 2005) La gestin de riesgo del software es la prctica de los procesos, mtodos, y herramientas necesarios para manejar riesgos en un proyecto. Proporciona un ambiente disciplinado para la toma de decisin proactiva, determinando continuamente qu puede ir mal; determinar cules riesgos requieren ms

37

seguimiento y ocupacin en funcin de su importancia y que acciones tomar para ocuparse de esos riesgos (SEI 2005) El anlisis y la gestin son una serie de pasos que ayudan a un equipo de software a comprender y manejar la incertidumbre (Pressman 2005) El enfoque de la administracin de riesgo es identificar posibles problemas en el proyecto y resolverlos antes de que puedan tener un impacto significativo en la fecha de entrega o el presupuesto. El elemento principal de la administracin del riesgo es el ajuste de los flujos de informacin adecuados, de tal forma que reporten con precisin y a tiempo los riesgo y problemas (Bruegge y Dutoit 2002) Cabe resaltar que la gestin de riesgo, es importante debido a que ayuda a evitar desastres, re-trabajo y sobre-trabajo, pero an mas importante, porque estimula la generacin de situaciones del tipo ganar-ganar. Una correcta gestin de riesgos posibilita, por tanto, el aprovechamiento ptimo de recursos y provoca, como consecuencia, el aumento de ganancias y la disminucin de prdidas. La ausencia de una apropiada gestin de riesgos conlleva a la imposibilidad de lograr el control efectivo de un proyecto derivando esto en la imposibilidad de realizar una correcta administracin del mismo (Rosenberg, et al., 1999) Reglas. Segn American Systems Corporation (ASC 2003), existen un conjunto de reglas bsicas relacionadas con la gestin de riesgos, las mismas se enumeran a continuacin: Regla 1. Los proyectos que no hacen gestin de riesgos se encuentran progresando a riesgo. Regla 2. La gestin de riesgos no es gratuita, es necesario comprometer recursos, establecer planes y procesos y disponer de reservas. Regla 3. Centralice las responsabilidades de gestin de riesgos porque la responsabilidad de administracin distribuida debe ser coordinada. Regla 4. Priorice los riesgos y concntrese en aquellos que sean mas crticos; a pesar de esto, todos los dems riesgos deberan contar con una estrategia de mitigacin. Regla 5. Los administradores de un proyecto son responsables por las acciones mientras que los administradores de los riesgos del proyecto son responsables por la identificacin y seguimiento de los riesgos. Regla 6. El proceso de gestin de riesgos debe definirse y seguirse de forma consistente en toda la organizacin. Todas las actividades deben ser tendientes a cumplimentar los requisitos de una poltica organizacional de gestin de riesgos.

38

Principios. Microsoft declar principios bsicos que se deben tener cuenta para cualquier proceso de la gestin de riesgo (Microsoft 2003): a. Agilidad.

La agilidad exige que los equipos de proyectos valoren ininterrumpidamente y administren de manera proactiva los riesgos durante todas las fases del ciclo de vida porque los continuos cambios en todas las facetas del proyecto implican, adems, cambios a nivel de los riesgos. Un enfoque proactivo permite que un equipo acepte los cambios y los transforme en una oportunidad. b. Potenciar la comunicacin. Los riesgos deberan discutirse de forma abierta, tanto dentro como fuera del equipo de proyecto. Todos los integrantes del equipo deben participar, en mayor o menor medida, de las diferentes tareas relacionadas con la gestin de riesgos. Los miembros de un equipo no deberan tener reservas de ningn tipo en comunicar sus opiniones con libertad para, de esta forma, evaluar con mayor precisin el estado del proyecto y tomar decisiones consensuadas. c. Aprender de todas las experiencias. Ya que el aprendizaje slo puede ayudar a mejorar los resultados, el conocimiento obtenido en un proyecto puede reducir la incertidumbre de la toma de decisiones en otros proyectos cuando la informacin es poco fiable. El anlisis directo de los resultados de proyectos anteriores fomenta el aprendizaje dentro del equipo mediante el intercambio de opiniones entre sus miembros. d. Participacin necesaria. La participacin activa en el proceso de gestin de riesgos es responsabilidad de todos los integrantes del equipo, an cuando la responsabilidad por la administracin de los riesgos deba ser centralizada. Asimismo, los diferentes miembros del equipo de proyecto reciben asignaciones de tareas especficas de las cuales son responsables. e. El riesgo es inherente en cualquier proyecto o proceso. Aunque un proyecto puede tener ms o menos riesgos que otro, no existe ningn proyecto que no se vea amenazado por algn riesgo. f. Proactividad.

La gestin de riesgos proactiva es la forma ms eficaz de hacer gestin de riesgos ya que posibilita: Anticiparse a los problemas en lugar de reaccionar ante ellos. Tratar la raz de un problema y no sus sntomas.

39

Reducir los tiempos de respuestas y minimizar el dao ocasionado por un problema en momentos de crisis. g. La identificacin de un riesgo es algo positivo. Para llevar a cabo una gestin de riesgos de forma efectiva es preciso comprender los riesgos a los que se enfrenta el equipo del proyecto. Cuando la diversidad de los retos y la magnitud de las prdidas potenciales son muy evidentes, las actividades relacionadas con la identificacin de riesgos pueden influir negativamente en la moral de los miembros del equipo, algunos de los cuales pueden, incluso, tener la impresin de que dicha tarea agrega mayor complejidad a la consecucin final del proyecto. En realidad, el proceso de identificacin de riesgos permite al equipo gestionar los riesgos de forma ms eficaz ya que posibilita el ponerlos de manifiesto y de este modo poder tratarlos. Esto implica considerar los riesgos como la nica forma de crear la oportunidad adecuada para conseguir los objetivos del proyecto. h. Valoracin continua. Los cambios continuos en los proyectos y en los entornos operativos obligan a los equipos a realizar valoraciones frecuentes del estado de los riesgos existentes y a valorar o a actualizar los planes para prevenir o actuar ante ellos. Se debe buscar, adems, y de forma constante, la posible aparicin de nuevos riesgos. Las actividades de gestin de riesgos deben integrarse en el ciclo de vida general del proyecto. i. Primero especificar y luego administrar: El punto de conjuncin entre la gestin de riesgos y la toma de decisiones lo constituye la incertidumbre. Las definiciones genricas de un riesgo no hacen desaparecer la incertidumbre y dan lugar a distintas interpretaciones del mismo. Las definiciones que no dejan lugar a dudas permiten: Asegurar que todos los participantes comprenden el riesgo de la misma forma. Comprender la causa o causas de los riesgos y la relacin con los problemas que puedan derivarse. Disponer de una base para realizar un anlisis formal y cuantitativo y planear los esfuerzos asociados a las acciones relacionadas con el proceso de administracin del riesgo. Aumentar la confianza que los patrocinadores tienen depositada en la capacidad del equipo. Las situaciones no deben juzgarse slo por el nmero de riesgos.

j.

A pesar de que los miembros del equipo y los patrocinadores suelen percibir los elementos de riesgo como algo negativo, los proyectos nunca deben juzgarse por el nmero de riesgos detectados. Es importante recordar que, un riesgo es slo una posibilidad, no la certeza de una prdida ni un resultado por debajo de lo esperado. Etapas. Existen distintas etapas segn los distintos autores pero las comunes a todos son las siguientes y como se muestra en la figura anterior:

40

a. Identificacin. La identificacin del riesgo ser la primera de las tareas a realizar durante la gestin de riesgos de un proyecto informtico (Snchez et al. 2003) La identificacin de riesgos es un intento sistemtico encaminado a especificar las amenazas al plan del proyecto. Esta fase es, probablemente, la ms importante entre todas aquellas que componen las actividades de la administracin de riesgos, ya que sin la correcta determinacin de los mismos, no es posible desarrollar e implementar anticipadamente respuestas apropiadas a los problemas que puedan surgir en el proyecto. La identificacin de riesgo requiere, fundamentalmente, una recopilacin de informacin acerca del proyecto informtico a desarrollar, as como su posterior clasificacin con el fin determinar los riesgos verdaderos (Snchez et al. 2003) Las entradas en la identificacin de riesgos son toda la informacin disponible acerca de riesgos generales y especficos del proyecto en las reas de negocios, tcnicas, organizativas y de entorno importantes. Otros aspectos adicionales son la experiencia del equipo, el enfoque organizativo actual ante los riesgos en forma de polticas, directrices, plantillas e informacin acerca del proyecto, incluido su estado actual y su historial (Microsoft 2003) Se debe poner hincapi que es vital la realizacin de reuniones de los integrantes del equipo del software, clientes y usuarios para recoger informacin sobre las percepciones que stos tienen acerca de los riesgos y las oportunidades. Un grave error que se comete en el desarrollo de software es que esta reunin solo se realiza al comienzo. La identificacin de riesgos puede realizarse segn un horario establecido (cada da, semana o mes), por objetivos (asociado a un plan de acontecimientos del proyecto) o activado por sucesos (forzado por sucesos destructivos en la empresa, la tecnologa, la organizacin o el entorno) (Microsoft 2003) Cuando ya se ha recogido la informacin necesaria del proyecto es imprescindible hacer una lista de comprobacin de elementos de riesgo que facilite la tarea de identificar y clasificar los riesgos de dicho proyecto en las siguientes subcategoras: Tamao del producto. Riesgos relacionados con el tamao global del software que construir o modificar. Impacto en el negocio. Estos riesgos se asocian con las restricciones que impone a gerencia o el mercado. Caractersticas del cliente. Riesgos que dependen de la sofisticacin del cliente y la habilidad del desarrollador para comunicarse con l en una forma oportuna. Definicin del proceso.

41

Riesgos provenientes del grado en el que se ha definido el proceso de software y en que le da seguimiento la organizacin que lo desarrolla. Entorno de desarrollo. Riesgos asociados con la disponibilidad y calidad de las herramientas que se usarn en la construccin del producto. Tecnologa que construir. Riesgos relacionados con la complejidad del sistema que se construir y la novedad de la tecnologa que est empaquetada en el sistema. Tamao y experiencia de plantilla del personal. Riesgos asociados con la experiencia global tcnica y en el proyecto de los ingenieros de software que harn el trabajo. El resultado de este proceso deber ser una larga lista de riesgos que podran presentarse y afectar al producto, al proceso o al negocio (Sommerville 2005) b. Anlisis. Durante este proceso, se considera por separado cada riesgo identificado; y se decide acerca de la probabilidad y la seriedad del mismo (Sommerville 2005) El anlisis de riesgos implica la conversin de los datos de riesgo en un formato que facilite la toma de decisiones (Microsoft 2003) Es necesario que el equipo de software realice una lista de los riesgos segn su prioridad, para poder tomarle atencin a aquellos riesgos que ocupan los primeros puestos, y determinar cul de ellos justifica la reserva de recursos para el planeamiento. El planificador del proyecto, junto con otros gestores y personal tcnico, realizan cuatro pasos en la proyeccin del riesgo (Pressman 2005): I. II. III. Establecimiento de una escala que refleje la posibilidad percibida de un riesgo. Delineado de las consecuencias del riesgo. Estimacin del impacto del riesgo en el proyecto y el producto.

IV. Tomar nota de la precisin global de la proyeccin del riesgo de modo que no haya mala interpretaciones. Existen dos aspectos importantes en la etapa de anlisis: Probabilidad de riesgo. La probabilidad de riesgo es una medida que calcula la probabilidad, de que la situacin descrita en el apartado de consecuencias de los riesgos de la declaracin de riesgos, llegue a producirse de verdad (Microsoft 2003)

42

La mayora de equipos de proyecto pueden expresar con palabras sus experiencias, interpretar los informes y proporcionar una amplia gama de expresiones de lenguaje natural para indicar rangos de probabilidad numricos. La primera tabla muestra un ejemplo de una divisin de tres valores para las probabilidades. La segunda tabla muestra una divisin de siete valores para las probabilidades. Impacto de riesgo. El impacto del riesgo calcula la gravedad de los efectos adversos, la magnitud de una prdida o el costo potencial de la oportunidad si el riesgo llega a producirse dentro del proyecto (Microsoft 2003). Cuando el impacto no se puede calcular en unidades monetarias, se puede alternar por un sistema de puntuacin de impacto que tenga las reas de proyecto adecuadas, como se describe en la siguiente tabla: Exposicin al riesgo. La exposicin al riesgo calcula la amenaza general que supone el riesgo combinando la informacin que expresa la probabilidad de una prdida real con informacin que indica la magnitud de la prdida potencial en un nico valor numrico (Microsoft 2003) La exposicin al riesgo se puede calcular de manera simple multiplicando el impacto con la probabilidad del riesgo, como lo establece Presuman (2005) en la siguiente frmula: ER= P x C donde P es la probabilidad de que ocurra un riesgo, y C, el costo al proyecto en caso de que el riesgo se convierta en problema. La exposicin al riesgo total para todos los riesgos puede ofrecer un medio con que ajustar la estimacin del costo final de un proyecto (Presuman 2005) La etapa de anlisis de riesgo permite obtener al equipo del proyecto una lista de prioridades de riesgos muy til para planear las actividades de riesgos. c. Planificacin. El proceso de planificacin de riesgos considera cada uno de los riesgos clave que han sido identificados; as como las estrategias para gestionarlos (Sommerville 2005) El principal objetivo de esta fase, es elaborar un plan para controlar los riesgos ms importantes identificados durante el anlisis de riesgos e integrarlo en los procesos de administracin estndar del proyecto para garantizar su realizacin. Segn Sommerville (2005) se pueden clasificar en tres categoras: I. Estrategias de prevencin.

Con estas estrategias la probabilidad de que el riesgo aparezca se reduce. II. Estrategias de minimizacin.

43

Siguiendo con estas estrategias se reducir el impacto del riesgo. III. Planes de contingencia.

Con estas estrategias se est preparado para lo peor y tener una estrategia para cada uso. Si el equipo desea desarrollar planes para reducir la exposicin de riesgo Microsoft (2003) recomienda: Concentrarse en los riesgos de mayor exposicin. Tratar la condicin para reducir la probabilidad. Buscar el origen de la causa en lugar de los sntomas. Tratar las consecuencias para minimizar el impacto. Determinar el origen de la causa y buscar situaciones similares en otras reas que puedan producirse por la misma causa. Tener en cuenta las dependencias e interacciones existentes entre los riesgos. Con la fase planeacin se obtiene formas de accin especficos. Las tareas para implementar estos planes deben integrarse en el planeamiento estndar del proyecto. Esto incluye realizar ajustes en los recursos reservados, la programacin y las caractersticas. El resultado debe ser un conjunto de acciones de riesgo que describen las tareas individuales que deben llevar a cabo los integrantes del equipo. Es aconsejable resumir los planes de administracin de riesgos en un solo documento. Sommerville (2005) remarca que es mejor usar una estrategia para evitar el riesgo. Si esto no es posible, utilizar una para reducir los efectos serios de los riesgos. d. Supervisin. Conforme avanza el proyecto se inician las actividades de supervisin de riesgo. El gestor de riesgo del proyecto supervisa los factores que pueden proporcionar un indicio de si el riesgo se est volviendo ms o menos probable y adems inspeccionar la efectividad de los pasos de reduccin del riesgo (Pressman 2005) Para Sommerville (2005) la supervisin de riesgos normalmente valora cada uno de los riesgos identificados para decidir si ste es ms o menos probable y si han cambiado sus efectos. La supervisin de los riesgos es esencial para la implementacin de un plan de acciones eficaz. Permite asegurar que las tareas asignadas que implementan medidas preventivas o planes de contingencia se realizan en el tiempo previsto dentro de las restricciones de recursos del proyecto. La principal actividad que realiza el equipo durante la supervisin de los riesgos consiste en supervisar las unidades de medicin y los puntos de activacin del riesgo para comprobar que las acciones de riesgo planeadas funcionan. La finalidad de la elaboracin de informes de estado de los riesgos consiste en comunicar los cambios en el estado del riesgo y progreso de los planes de mitigacin (Microsoft 2003)

44

METODOLOGAS PARA LA GESTIN DE RIESGO. Gestin del riesgo de Boehm. Boehm (1991) fija las bases para la gestin de riesgo en el software. La gestin de riesgo de Boehm cuenta con los siguientes pasos. a. Valoracin del riesgo.

Identificacin de riesgo. Produce listas de elementos del riesgo especficos para el proyecto que comprometen seriamente el xito del proyecto. Anlisis del riesgo. Determina la probabilidad e impacto a cada riesgo Priorizacin del riesgo. Produce una lista ordenada de elementos de riesgos identificados y analizados. b. Control del riesgo.

Planificacin de la gestin de riesgo. Ayuda a manejar cada elemento de los planes individuales de elementos de riesgos entre ellos y con respecto al plan general. Resolucin del riesgo. Implementa la planificacin de gestin del riesgo. Monitorizacin del riesgo. Consiste en controlar el proyecto en lo relativo a resolucin de riesgos, tomando las acciones correctoras cuando sea necesario. Gestin de riesgo de la SEI (Software Engineering Institute) Para la SEI (2005) las funciones de la gestin de riesgo son las siguientes: Proporcionar un entorno disciplinado para tomar decisiones de manera preactiva con el fin de controlar lo que puede ir mal. Determinar que riesgos son importantes con el fin de manejarlos. Implementar acciones para manejar los riesgos importantes. Identificacin.

a.

Busca y localiza riesgos antes de que se conviertan en problemas. b. Anlisis.

Procesa los datos sobre los riesgos para obtener informacin que ayude en la decisin.

45

c.

Planificacin.

Traduce informacin de riesgos en decisiones y acciones (ambas presentes y futuras) e implementa dichas acciones. d. Monitoreo.

Supervisa los indicadores y acciones tomados contra los riesgos. e. Control.

Corrige las desviaciones de las acciones contra los riesgos planeadas. f. Comunicacin.

Proporciona visibilidad y datos de realimentacin internos y externos al programa sobre actividades de riesgo actuales y emergentes. El SEI (2005) identifica la necesidad de un Equipo de Evaluacin de los Riesgos del Software, este equipo de contar con 1 a 5 integrantes. Uno de los miembros es el facilitador que se encarga de agilizar el proceso, ste debe ser alguien con experiencia y sin implicacin especial en el proceso de desarrollo. As mismo, toda organizacin dedicada a la construccin de software puede estar dentro de uno de los siguientes niveles de gestin de riesgo: a. Nivel 1: Gestin de crisis.

El riesgo es manejado luego de que ha transformado en un gran problema. b. Nivel 2: Reparar sobre la falla.

Se detecta y se reacciona al riesgo pero luego que este ha ocurrido. c. Nivel 3: Mitigacin del riesgo.

La gestin elabora un plan de contingencia que provee de elementos para cubrir el riesgo si este ocurre, pero no hace nada para eliminarlo anticipadamente d. Nivel 4: Preventivo.

La gestin implementa y se ejecuta un plan como parte de un proyecto de software para identificar riesgo y prevenir que se transforme en un problema. e. Nivel 5: Eliminacin

La gestin busca identificar y eliminar factores de manera que el riesgo no exista. Disciplina de administracin de riesgos de MSF (Microsoft Solutions Framework) La administracin de riesgos es una disciplina bsica dentro de Microsoft Solutions Framework (MSF). MSF reconoce que los cambios y la incertidumbre que stos generan

46

son aspectos inherentes del ciclo de vida de TI. La disciplina de administracin de riesgos de MSF prefiere tratar esta incertidumbre desde una perspectiva proactiva, realizando ininterrumpidamente valoraciones de riesgos que incidan en la toma de decisiones durante un ciclo de vida. Los riesgos se valoran, supervisan y administran ininterrumpidamente hasta que se resuelven o se convierten en problemas que deben solucionarse. El proceso de administracin de riesgos de MSF define los seis pasos lgicos que el equipo utiliza para administrar los riesgos actuales, planear y ejecutar las estrategias de administracin de riesgos y captar conocimientos para la empresa. Estos seis pasos se describen a continuacin: a. Identificacin de riesgos.

Los riesgos se identifican y ponen al descubierto para que todo el equipo sea consciente de que existe un problema en potencia. La identificacin de riesgos debe realizarse lo antes posible y repetirse con frecuencia a lo largo de todo el ciclo de vida del proyecto porque aporta informacin al proceso de administracin de riesgos. b. Anlisis de los riesgos.

Transforma las cifras y los datos de los riesgos detectados durante la fase de identificacin en informacin que el equipo puede utilizar para tomar decisiones relacionadas con la asignacin de prioridades. Al establecer la prioridad de los riesgos el equipo puede confirmar los recursos del proyecto para administrar los riesgos ms importantes. c. Planeamiento de riesgos.

Toma la informacin obtenida tras el anlisis de riesgos y la utiliza para trazar estrategias, planes y acciones. La programacin de riesgos garantiza que estos planes se aprueban y se incorporan en la infraestructura y el proceso de administracin diario del proyecto para confirmar que la administracin de riesgos forma parte de las actividades diarias del equipo. La programacin de riesgos es el punto de conexin explcito entre el planeamiento de riesgos y el planeamiento de proyectos. d. Seguimiento de riesgos.

Supervisa el estado de los riesgos y el progreso de sus planes de accin. El seguimiento de riesgos tambin incluye la supervisin de probabilidades, impactos, exposiciones y otras medidas de riesgo para los cambios que pudiesen alterar los planes de prioridades o de riesgos y las caractersticas, los recursos o la programacin del proyecto. El informe de los riesgos garantiza que el equipo, los patrocinadores y los accionistas estn al corriente del estado de los riesgos del proyecto y de los planes para administrarlos. e. Control de riesgos.

47

Es el proceso que ejecuta los planes de accin de riesgos y sus informes de estado asociados. El control de riesgos tambin incluye la iniciacin de las solicitudes de control de cambios del proyecto si los cambios en el estado o los planes de los riesgos pueden alterar las caractersticas, los recursos o la programacin del proyecto. f. Aprendizaje de riesgos.

Formaliza las lecciones aprendidas y los elementos y herramientas relevantes del proyecto y plasma todo esta informacin en un formato reutilizable para el equipo o la empresa. DISCUSIN

Segn las entrevistas realizadas a cada integrante del equipo se pudo verificar que stos demostraron: x x x x x Tener conocimiento sobre el concepto de riesgo. Conocer la nocin bsica de la administracin de riesgo, as como de las actividades de sta. Ser concientes de la importancia y lo vital de la administracin de riesgo para cualquier proyecto de software. Poseer un conocimiento pobre sobre las metodologas o herramientas que permiten la gestin de riesgo. No tener formacin formal en la gestin de riesgo.

Gestin de riesgo en el departamento de desarrollo de sistemas. A travs de la evaluacin realizada al equipo del Departamento se determin: x x x x x El Departamento no cuenta con ni una herramienta o metodologa para la gestin de riesgo. No se tiene ni un tipo de informacin escrita sobre el impacto y el tipo de riesgo no previsto. Existen problemas serios de riesgos en el desarrollo de software. El software desarrollado tuvo fallas despus de ser entregados. No existe ningn especialista en gestin de riesgos en el Departamento de Desarrollo de Sistemas.

48

Es as que segn los niveles de la gestin de riesgo, en las que se puede categorizar a una organizacin dedicada a la construccin de software, declarados por la SEI (2005); el Departamento tiene una gestin de Crisis, el nivel ms bajo, pues el riesgo es manejado cuando ya se ha transformado en problema

Propuesta de la gestin de riesgo del departamento de desarrollo de sistemas USAT

DESCRIPCIN. Luego de analizar la situacin actual del Departamento de Desarrollo de Sistemas con respecto a la gestin de riesgo; y verificar que no existe ni una metodologa ni herramienta que permita administrar riesgos; as mismo, despus de realizar una revisin exhaustiva sobre las herramientas disponibles para efectuar una actividad tan importante en el desarrollo de software; se opt por proponer la aplicacin de la disciplina de administracin de riesgos de MSF (Microsoft Solutions Framework). La razn principal por la cual se eligi esta disciplina es que se basa en el modelo de proceso ininterrumpido de administracin de riesgos de Software Engineering Institute (SEI) para evaluar el riesgo de los proyectos. La disciplina de administracin de riesgos de MSF ha interpretado este modelo teniendo en cuenta la amplia experiencia en el desarrollo de productos de Microsoft y la experiencia de proyectos de implementacin y de desarrollo de software de Microsoft Consulting Services (MCS) y de los colaboradores de Microsoft. Caractersticas. Las principales caractersticas de esta disciplina propuesta son las siguientes (Microsoft 2003): Carcter global que incluye todos los elementos de un proyecto: personas, procesos y elementos de tecnologa. Incorpora un proceso intuitivo, sistemtico y reproducible para la administracin de riesgos de los proyectos. se aplica ininterrumpidamente durante el ciclo de vida de los proyectos. Su tendencia es proactiva en lugar de reactiva. Fomenta el aprendizaje individual y colectivo. Es muy flexible y puede adaptarse a una gran variedad de anlisis de riesgos cuantitativos y cualitativos. Aplicacin. En esta parte de la investigacin se mostrar por cada etapa de la disciplina; los requisitos que el Departamento debe tener para la aplicacin, actividades y los resultados que debe obtener para que el Departamento aplique dicha disciplina; y por consiguiente pueda tener una herramienta para la administracin de riesgo.

49

Identificacin. a. Objetivo. La meta en la identificacin de riesgos es la elaboracin de una lista de los riesgos con los que el equipo deber enfrentarse. Esta lista debe ser lo ms extensa posible y deber cubrir todas las reas del proyecto. b. Requerimientos. Informacin disponible acerca de riesgos generales y especficos del proyecto en las reas de negocios, tcnicas, organizativas y de entorno importantes. Experiencia del equipo. Enfoque organizativo actual ante los riesgos en forma de polticas, directrices, plantillas e informacin acerca del proyecto, incluido su estado actual y su historial. c. Actividades. Crear una declaracin ambigua o una lista de riesgos que dan forma a los riesgos que se encontrar. Organizar sesiones de confrontacin de ideas para identificar los riesgos, stas deben llevarse a cabo peridicamente durante un proyecto. Se recomienda la participacin activa de todos los integrantes del equipo durante la identificacin de riesgos. Investigaciones adicionales o que se solicite ayuda a expertos en la materia para obtener ms informacin acerca de los riesgos del proyecto. Anlisis. a. Objetivo. Consiste en establecer las prioridades de los elementos de la lista de riesgos y determinar cul de ellos justifica la reserva de recursos para el planeamiento. b. Requerimientos. Recurrir a la experiencia e informacin conseguida de otras fuentes de importancia con relacin a las declaraciones de riesgo obtenidas durante la identificacin de riesgos. La informacin necesaria para transformar las declaraciones de riesgos en bruto en una lista maestra de riesgos con prioridades puede obtenerse de las polticas y directrices de riesgos de la organizacin, las bases de datos de riesgos del sector, las simulaciones, los modelos analticos, los administradores de unidades empresariales, as como expertos de dominio, entre otras fuentes. c. Actividades. Tomar las decisiones consensuadas por el equipo en dos de los componentes de riesgo: probabilidad e impacto. Estas cantidades se multiplican para calcular una mtrica denominada exposicin al riesgo. Planeamiento y programacin de riesgos.

50

a. Objetivo. Desarrollar un plan detallado para controlar los riesgos ms importantes identificados durante el anlisis de riesgos e integrarlo en los procesos de administracin estndar del proyecto para garantizar su realizacin. b. Requerimientos. La lista de riesgos ms importantes. Informacin de la base de conocimientos de la administracin de riesgos. Los planes y programas del proyecto. c. Actividades. Tomar las decisiones consensuadas por el equipo en dos de los componentes de riesgo: probabilidad e impacto. Estas cantidades se multiplican para calcular una mtrica denominada exposicin al riesgo. Seguimiento e informes de los riesgos. a. Objetivo. Consiste en supervisar los planes de accin (comprobar que los planes de contingencia y mitigacin se estn realizando), supervisar las unidades de medicin del proyecto asociadas al punto de activacin de un plan de contingencia e informar al equipo del proyecto que se han excedido los puntos de activacin del plan de contingencia, lo que indica que un plan de contingencia puede iniciarse. b. Requerimientos. Los formularios de accin de riesgos que contienen los planes de mitigacin y contingencia y que especifican las unidades de medicin y los valores de punto de activacin del proyecto que deben supervisarse. Los informes de estado del proyecto relevantes que se utilizan para realizar un seguimiento del progreso dentro de la infraestructura de administracin del proyecto.

c. Actividades. Durante el seguimiento de riesgos el equipo ejecuta las acciones del plan de mitigacin como una parte ms de la actividad general del equipo. El progreso hacia estos elementos de accin relacionados con los riesgos, as como cualquier cambio relevante de los valores de los puntos de activacin, se recopilan y emplean para crear informes de estado de cada riesgo. Control de riesgos. a. Objetivo.

51

El objetivo del control de riesgos es la ejecucin correcta de los planes de contingencia que el equipo del proyecto ha desarrollado para los riesgos ms importantes. b. Requerimientos. Formularios de accin de riesgo que describen con detalle las actividades que los miembros del equipo deben llevar a cabo. Informes de estado de riesgos que documentan los valores de las unidades de medicin del proyecto que indican que se ha excedido un valor de activacin. c. Actividades. Las actividades de control de riesgo deben utilizar los procesos estndar de administracin del proyecto para iniciar, supervisar y valorar el progreso durante el curso de accin planeado. Los detalles especficos de los planes de riesgo variarn en cada proyecto, pero debera utilizarse el proceso general para la elaboracin de informes de estado de las tareas. Es bsico identificar continuamente de los riesgos para detectar riesgos secundarios que puedan aparecer o amplificarse debido a la ejecucin del plan de contingencia. d. Resultado. El resultado del control de riesgos es el progreso de la documentacin del informe de estado estndar del proyecto hacia la realizacin del plan de contingencia. Para el equipo del proyecto tambin resulta til resumir las lecciones aprendidas (por ejemplo, lo que ha funcionado y lo que no) del plan de contingencia. Los cambios en el estado del riesgo que podran modificar la programacin, los recursos o las funciones del proyecto (por ejemplo, la ejecucin de un plan de contingencia) deben propiciar la creacin de una solicitud de control de cambios en los proyectos que cuentan con procesos formales de control de cambios. CONCLUSIONES La evaluacin al Departamento de Desarrollo de Sistemas arroj datos que reflejan un nivel grave con respecto a la a gestin de riesgo, pues no tienen ni una tcnica para realizar dicha tarea, ocasionando que despus de la entrega del software el cliente se queje de fallas. Se opt por proponer la aplicacin de la disciplina de administracin de riesgos de MSF (Microsoft Solutions Framework). La razn principal por la cual se eligi esta disciplina es que se basa en el modelo de proceso ininterrumpido de administracin de riesgos de Software Engineering Institute (SEI) para evaluar el riesgo de los proyectos. La disciplina de administracin de riesgos de MSF ha interpretado este modelo teniendo en cuenta la amplia experiencia en el desarrollo de productos de Microsoft y la experiencia de proyectos de implementacin y de desarrollo de software de Microsoft Consulting Services (MCS) y de los colaboradores de Microsoft. Si el Departamento decide aplicar dicha propuesta, a pesar que implica una ardua labor, los beneficios van a ser mayores pues el desarrollo de cualesquiera de los software caminaran hacia la obtencin del producto final de manera segura.

52

BIBLIOGRAFA
1. Bohem, Barry W. 1991. Software Risk Management. New York: IEEE Press. 2. Braude, Eric J. 2003. Ingeniera de Software. Una perspectiva orientada a objetos. Mxico, D. F.: Alfaomega. 3. Bruegge, Bernd y Dutoit, Allen H. 2003. Ingeniera de Software orientada a objetos. Naucalpan: Pearson Educacin. 4. Charette, Robert. 1989. Software Engineering Risk Anlisis and Management. New York: McGraw Hill. 5. Pressman, Roger S. 2005. Ingeniera del Software. Un enfoque prctico. Mxico, D. F.: McGraw Hill. 6. Robin, 2007) 7. Rosenberg, L., Hammer, T., Gallo, A. 1999. Continuous Risk Management at NASA. http://satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html. (accedido Noviembre 10, 2007) 8. Snchez G., Jos, Chalmeta R., Ricardo, Coltell S., scar, eds. 2003. Ingeniera de proyectos informticos: actividades y procedimientos. Castell de la Plana: Universitat Jaume. 9. Sommerville, Ian. 2005. Ingeniera del Software. Madrid: Pearson Education. 10. Williams, Ambrose Williams, Ambrose, Bentrem. 2005. A Roadmap of Risk Diagnostic Methods: Developing an Integrated View of Risk Identification and Analysis Techniques. http://www.sei.cmu.edu/publications/documents/04.reports/04tn002.html. Noviembre 11, 2007). (accedido Allison. 2003. Disciplina de Administracin (accedido de Riesgos. 10,

http://www.microsoft.com/latam/technet/articulos/200304/art02/

Noviembre

53

HACIA UN ESTNDAR DE MTRICAS DE CALIDAD EN APLICACIONES E-LEARNING3

RESUMEN El trabajo tiene como objetivo determinar un conjunto de mtricas que permitan medir la calidad en aplicaciones Web. Para ello se presentan diferentes propuestas de investigadores, con la finalidad de analizarlas y conocer si existe un estndar de mtricas de calidad Web. Finalmente, se seleccionan las adecuadas para ser utilizadas en aplicaciones e-learning. Palabras claves: mtricas de calidad Web, e-learning.

INTRODUCCIN

La calidad es una caracterstica esencial para el xito de una Web [1], pues desarrollar sistemas Web sin calidad puede provocar que la Web funcione con bajo rendimiento y cause fallos, amenazando gravemente la confianza del usuario en la Web [2]. En la actualidad, World Wide Web se encuentra inmerso en casi todas las actividades de la sociedad [3], incluyendo el sector educativo, entonces arriesgarse a desarrollar productos Web con fallas afectara exponencialmente al orden de la sociedad y al xito de las empresas. Lo ideal es, entonces, desarrollar sistemas Web con caractersticas que garanticen su calidad [4], lo cual es posible a travs de principios de medicin que evalen y aseguren la calidad [2]. El estudio de la calidad de productos y procesos de desarrollo para la Web es muy reciente, por lo cual no se dispone de mtodos de evaluacin estandarizados para este tipo de entorno [3]. Los investigadores proponen mtricas enfocadas en diferentes aspectos de la Web [1], muchas de las cuales han sido propuestas sin ningn tipo de rigor y orden, trayendo como consecuencia que su aplicacin sea difcil, riesgosa y la toma de decisiones en base a sus valores sea peligrosa [5]. Las diversas propuestas llevaron a [6] a realizar un estudio en el que confirmaron la existencia de diferencias y similitudes entre los variados modelos. Las distintas propuestas han conllevado tambin a innovaciones metodolgicas para el establecimiento de una serie de pautas de calidad Web [7], pero se sigue estando lejos de llegar a un estndar.

Mnica Yolanda Villavicencio Montoya

54

DEFINICIN DE CALIDAD Calidad es el cumplimiento de los requisitos de funcionalidad y desempeo explcitamente establecidos, de los estndares de desarrollo explcitamente documentados y de las caractersticas implcitas que se esperan de todo software desarrollado profesionalmente [8].

Mtricas de calidad en uso El estndar ISO 9126-4, define la calidad en uso en trminos de eficiencia, productividad, seguridad y satisfaccin, siendo relevantes para la investigacin solo dos de ellos (Tabla 1). El estndar presenta un conjunto de mtricas que permiten estimar cada caracterstica, junto con su mtodo de evaluacin y frmula [3].
Tabla 1: Tabla de mtricas propuestas en el estndar ISO 9126-4 Nombre de la mtrica Mtodo de evaluacin Mtricas relacionadas con la efectividad Efectividad de la tarea Test con usuarios Completitud de la tarea Test con usuarios Frecuencia de error Test con usuarios Mtricas relacionadas con la productividad Tiempo en llevar a cabo la Test con usuarios tarea Eficiencia de la tarea Test con usuarios Productividad econmica Test con usuarios Proporcin de tiempo Test con usuarios productivo Eficiencia relativa del Test con usuarios usuario (Fuente: Modificado de Paloma et al., 2004)

CALIDAD WEB

La alta calidad es el nico mecanismo que trae usuarios repetitivos a los sitios Web [5]. La calidad Web tiene asociada una serie de atributos que se pueden observar directa o indirectamente, dando, la medida de stos, un valor de estimacin de la calidad total del sitio Web. Aunque varios autores han presentado diferentes propuestas, hoy en da todava no existe un estndar sobre cules son esos atributos [3].

55

Atributos en Calidad Web

Olsina y sus colegas prepararon en 1999 un rbol de requisitos de calidad que identifica un conjunto de atributos tcnicos facilidad de uso, funcionabilidad, confiabilidad, eficiencia y facilidad de mantenimiento - que conducen a una Web de gran calidad [8]. Offut (2002) extiende estos atributos, agregando los siguientes [8]:

Seguridad. Una Web segura debe ser capaz de rechazar el acceso no autorizado e impedir un ataque malvolo. Disponibilidad. La medida del porcentaje del tiempo que una Web est disponible para usarla. Escalabilidad. El grado en que una Web puede manejar miles de usuarios y la capacidad de respuesta para no caer catastrficamente. Tiempo en el mercado. Desde el punto de vista de los negocios, generalmente la primera Web puesta en el mercado, capturar mayor cantidad de usuarios.

La calidad tambin se evala realizando una valoracin de la calidad del contenido; Tillman (2000) presenta un conjunto de criterios tiles para este propsito [8]:

El mbito y la profundidad del contenido se pueden determinar con facilidad para asegurar que satisfacen las necesidades del usuario? Los antecedentes y la jerarqua de los autores del contenido se pueden identificar fcilmente? Es posible determinar la precisin del contenido, la ltima actualizacin y lo que fue actualizado? El contenido y su ubicacin son estables (es decir, permanecern en la URL de referencia)?

Pressman aade las siguientes preguntas relacionadas con el contenido [8]:

El contenido es creble? El contenido es nico? (es decir, ofrece algn beneficio nico a quienes la usen) El contenido es valioso para la comunidad de usuarios a que se dirige? El contenido est bien organizado? Est en un ndice? Es fcilmente accesible?

Paloma et al. consideran que uno de los atributos ms importantes para medir la calidad de una aplicacin Web es la usabilidad. Constituye el atributo ms visible, porque

56

determina el grado de satisfaccin del usuario con respecto a la aplicacin Web [3]. La usabilidad, segn este autor se basa en los siguientes factores:

Facilidad de aprendizaje: la facilidad con la que nuevos usuarios pueden tener una interaccin efectiva con la Web. Flexibilidad: las distintas posibilidades con las que el usuario y el sistema pueden intercambiar informacin. Robustez: el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos. Se relaciona con la capacidad de observacin del usuario, de recuperacin de informacin y de ajuste de la tarea al usuario.

MTRICAS DE CALIDAD EN INGENIERA WEB

Un buen mecanismo para controlar la calidad de un producto de software (y de los sitios Web) es el uso de mtricas [5], ya que permiten medir la calidad de forma objetiva [3]. Desde los aos 1990, un amplio conjunto de mtricas han sido propuestas para medir atributos cuantificables de calidad Web. Sin embargo, algunas de estas no estn bien definidas ni validadas emprica ni tericamente, lo que hace poco fiable su uso [3] y puede confundir a usuarios interesados en lugar de ayudarlos [5]. Con el objetivo de clasificar las mtricas de una forma amplia, Calero et al. elaboraron el Modelo de Calidad Web (Web Quality Model, WQM), cuya ltima versin fue refinada en el ao 2005[5]. El Modelo de Calidad Web (Web Quality Model, WQM) Calero et al. propusieron un cubo, compuesto de tres aspectos a tener en cuenta en la evaluacin de la calidad de un sitio Web: caractersticas, procesos del ciclo de vida y aspectos de calidad, dentro de los que incluyeron 385 mtricas Web [5]. Dimensin Caractersticas Web En esta dimensin, se encuentran los tres aspectos clsicos de la Web: a. Navegacin: permite a los usuarios acceder fcilmente a la informacin que est buscando mientras se mueven por la Web. b. Contenido: formado por datos, programas y aplicaciones que proveen funcionalidades; y cuestiones de representacin y estructura. c. Presentacin: la manera en que el contenido y la navegacin son presentadas al usuario. Permite hacer la pgina ms fcil de usar. Dimensin Caractersticas de Calidad

57

Esta dimensin se describe segn el modelo Quint2, que presenta seis caractersticas bsicas, cada una con un conjunto de sub - caractersticas, que a la vez poseen un conjunto de atributos. La lista inferior muestra las caractersticas. 1. Funcionalidad: mide la existencia de un conjunto de funciones y sus propiedades especficas: Idoneidad: sus atributos miden la presencia e idoneidad de un conjunto de funciones para tareas especficas. Precisin: se refiere a la provisin y los resultados o efectos correctos. Interoperabilidad: mide la habilidad para interactuar con sistemas especficos. Seguridad: sus atributos miden la habilidad de prevenir acceso no autorizado, accidental o deliberado, a programas o datos. Trazabilidad: mide el esfuerzo necesario para verificar la correccin de procesamiento de datos en puntos requeridos. 2. Confiabilidad: sus atributos analizan la capacidad del software para mantener su nivel de rendimiento bajo determinadas condiciones despus de un perodo determinado de tiempo: Madurez: mide la frecuencia de fracasos por fallos en el software. Tolerencia a fallas: mide la habilidad para mantener un nivel especfico de rendimiento en caso de fallas. Recuperabilidad: mide la capacidad de volver a establecer su nivel de rendimiento y recuperar los datos directamente afectados en caso de un fracaso, y en el tiempo y el esfuerzo necesarios para ello. Disponibilidad: sus atributos miden la cantidad de tiempo que el producto est disponible para el usuario en el momento en que se necesita. Degradabilidad: mide el esfuerzo necesario para restablecer la funcionalidad esencial despus de una ruptura. 3. Usabilidad. Comprensibilidad: mide el esfuerzo de los usuarios para el reconocimiento del concepto lgico y su aplicabilidad. Habilidad para aprender: mide el esfuerzo de los usuarios para aprender su aplicacin. Operabilidad: el esfuerzo de los usuarios para la operacin y control de la Web. Explicitacin: atributos de software que tienen que ver con el producto de software con respecto a su situacin. Atractividad: mide la satisfaccin de deseos latentes y preferencias del usuario a travs de servicios, comportamiento y presentacin ms all de la demanda real. Personalizacin: va permitir reducir el esfuerzo necesario para su uso y aumentar la satisfaccin con el mismo. Claridad: de hacer al usuario consciente de las funciones que puede realizar. Ayuda: relacionada con la disponibilidad de instrucciones para el usuario sobre la forma de interactuar con la Web. Amigabilidad con el usuario: es decir, la satisfaccin del usuario.

58

4. Eficiencia. Consiste en la relacin entre el nivel de rendimiento del software y la cantidad de recursos utilizados: Tiempo de comportamiento: mide la respuesta y el tiempo de procesamiento y las tasas de rendimiento en el desempeo de la funcin de la Web. Recursos de comportamiento: mide la cantidad de recursos usados y la duracin de tal uso en el desempeo de su funcin.

5. Portabilidad. Es la habilidad del software de ser transformado de un entorno a otro: Adaptabilidad: la oportunidad de adaptacin del software a diferentes entornos sin la aplicacin de otras acciones o medios que los provistos para este fin. Instalabilidad: el esfuerzo necesario para instalar el software en un entorno especfico. Reemplazabilidad: la oportunidad y el esfuerzo de usar el software en el lugar de otro software especfico en el entorno de ese software. Co-existencia: la capacidad del software de coexistir con otro software independiente en un entorno comn compartiendo recursos comunes.

6. Mantenibilidad. Un conjunto de atributos que tienen que ver con el esfuerzo necesario para realizar modificaciones especficas: Analysability: mide el esfuerzo necesario para el diagnstico de las deficiencias o causas de fracasos, o para la determinacin de las partes a ser modificadas. Mutabilidad: mide los esfuerzos necesarios para la modificacin, supresin de fallas o cambios de entorno del software. Estabilidad: mide el riesgo de efectos inesperados de modificaciones. Testability: mide el esfuerzo necesario para la validacin del software modificado. Gestionabilidad: el esfuerzo necesario para establecer su estado de funcionamiento. Reusabilidad: potencial de reutilizacin completa o parcial en otro producto. Dimensin Procesos del Ciclo de vida Esta dimensin abarca procesos primarios y organizacionales. Dentro de los procesos primarios se encuentran el proceso de desarrollo, el proceso de operacin, y el proceso de mantenimiento. Como procesos organizacionales, se consideran el proceso de gestin del proyecto, y el proceso de gestin de programa de reuso. Medidas de reusabilidad Moraga et al. definieron dos dimensiones que afectan a la reusabilidad de los portlet4: comprensibilidad y portabilidad, y especificaron, para cada una, un
Un portlet es una miniaplicacin Web interactiva que es entregada a travs de una aplicacin Web [9]. Ejemplos de portlet son portlet para noticias, foros, correo, etc.
4

59

conjunto de atributos con sus respectivas medidas [4]. La dimensin Comprensibilidad presenta siete atributos, siendo importantes para la investigacin solo cuatro (Tabla 1). As mismo, la dimensin Portabilidad se subdivide en cinco dimensiones, siendo relevantes para la investigacin solo tres (Tabla 3).
Tabla 2: Medidas para los atributos de la dimensin comprensibilidad. Dimensin: COMPRENSIBILIDAD Dominio de la Atributo Medida medida Manuales El vendedor del portlet provee Booleano Usuario de usuario manuales de usuario. final El portlet especifica su Descripcin Booleano funcionalidad. El vendedor del portlet provee Administra- Documentacin Booleano documentacin adicional. dores del Lenguaje de Nmero de lenguajes en que la Nmero portal documentacin documentacin est escrita. natural (Fuente: Modificado de Moraga et al., 2005) Tabla 3: Medidas para los atributos de la dimensin portabilidad. Dimensin: Portabilidad Subdimensiones Customizability Usuario final Personalizacin Atributo Modo de edicin Complejidad del perfil del usuario Localizaciones Administradores del Instalabilidad Documentacin portal (Fuente: Modificado de Moraga et al., 2005) Medida El portlet soporta modos de edicin. Nmero de caractersticas del perfil del usuario que el portlet almacena. Nmero de localizaciones soportadas por el portlet Existe documentacin. Dominio de la medida Booleano Nmero natural Nmero natural Booleano

Dimensiones de portales Web que pueden afectar la satisfaccin del usuario Sampson y Manouselis definieron en el 2004 cuatro dimensiones relacionadas con la satisfaccin del usuario de un portal Web, de las cuales solo interesan tres [6]: a. Contenido del portal Web Satisfaccin de la organizacin del contenido, de modo que permita una bsqueda eficiente. Satisfaccin de la credibilidad del contenido Satisfaccin del uso del contenido, es decir, el uso de lenguaje apropiado y el uso de informacin acorde con la audiencia. Satisfaccin de integracin del contenido, es decir, los servicios relacionados con la integracin de fuentes externas de informacin y la provisin de links a recursos externos. 60

b. Personalizacin Satisfaccin de la personalizacin de navegacin, es decir el ajuste de mecanismos de navegacin y funciones de acuerdo a necesidades individuales. Satisfaccin de la personalizacin de informacin/contenido, de modo que se notifique al usuario sobre los nuevos contenidos importantes y se le provea de informacin adaptada a sus preferencias. Satisfaccin de la personalizacin de la interfaz, de modo que satisfaga las necesidades y preferencias del usuario y las propiedades de su equipo. c. Soporte a la comunidad Satisfaccin del soporte de comunicacin, es decir, de las herramientas y servicios relacionados con la comunicacin entre los miembros de una comunidad virtual. Satisfaccin del soporte de colaboracin, es decir, de las herramientas y servicios que permitan una eficiente y efectiva colaboracin entre los usuarios.
SCORM (Shareable Content Object Reference Model)

Es la coleccin, integracin y armonizacin de especificaciones y normas que dirigen la forma en que las aplicaciones e-learning deben ser creadas y entregadas a los estudiantes [10]. Considera las siguientes propiedades como requerimientos funcionales de alto nivel [11]:
Accesibilidad: La capacidad de localizar y acceder a componentes de enseanza de un lugar remoto y entregarlos a muchos otros lugares. Adaptabilidad: La capacidad para adaptar la enseanza a las necesidades individuales y organizacionales. Asequibilidad: La capacidad para aumentar la eficiencia y la productividad al reducir el tiempo y los costos implicados en la entrega de enseanza. Durabilidad: La capacidad para soportar la evolucin de la tecnologa y los cambios sin costoso rediseo, reconfiguracin o recodificacin. Interoperabilidad: La habilidad de tomar componentes de aprendizaje desarrollados en un lugar con un conjunto de herramientas o plataforma y utilizarlos en otro lugar con un conjunto diferente de herramientas o plataforma. Reusabilidad: La flexibilidad de incorporar componentes de aprendizaje en mltiples aplicaciones y contextos.

Las especificaciones se agrupan en una coleccin de "libros tcnicos", los cuales estn agrupados en tres temas principales: "Modelo de agregacin de contenido (Content

61

aggregation model / CAM)", "Entorno de tiempo de ejecucin (Run-time environment / RTE)" y "Secuencia y navegacin (Sequencing and navigation / SN)" [11].

a. Modelo de agregacin del contenido

Describe los tipos de contenido de los objetos utilizados en una agregacin de contenidos, la forma de empaquetar los objetos de contenido para proporcionar con xito el intercambio de un sistema a otro, la manera de describir los objetos mediante el uso de metadatos de contenido para permitir la bsqueda y el descubrimiento, y la forma de definir las normas para la secuenciacin de objetos de contenido para completar el diseo de la experiencia de aprendizaje. Un paquete de contenido SCORM puede representar un curso, leccin, mdulo o puede ser simplemente una coleccin de objetos relacionados con el contenido [11].
b. Entorno de tiempo de ejecucin

Describe los requisitos que se imponen para garantizar las condiciones que permitan la interoperabilidad de los contenidos a travs de diferentes LMSs (es decir, un lanzamiento del proceso de normalizacin de contenido, mtodos normalizados para la realizacin de la comunicacin entre el contenido y LMSs y modelo de datos normalizado de los elementos utilizados para introducir informacin acerca de la interaccin del alumno con el contenido). SCORM proporciona un medio para que los contenidos de aprendizaje sean interoperables a travs de mltiples LMSs independientemente de los instrumentos utilizados para crear el contenido [11].
c. Secuencia y navegacin

Describe la ramificacin y el flujo de las actividades de aprendizaje en trminos de un rbol de actividad, basado en los resultados de las interacciones de un alumno con los objetos de contenido y una estrategia de secuencia. Un rbol de actividad es una estructura conceptual de las actividades de aprendizaje gestionados por el LMS para cada alumno. En SCORM, una actividad de aprendizaje puede hacer referencia a objetos de contenido que se entreguen a los alumnos [11].
DISCUSIN Teniendo en cuenta que, por la finalidad para la que han sido creadas, las aplicaciones elearning dan prioridad a ciertos aspectos de la Web, se determinaron atributos particulares que van a permitir medir su calidad (Tabla 5). La organizacin de los mismos se bas en la jerarqua Dimensin - Atributos del modelo WQM, y los atributos seleccionados son: algunos pertenecientes a WQM, todos los empleados por SCORM, algunos considerados por Offut (Seguridad y Escalabilidad) y uno considerado por Paloma et al. (Flexibilidad, para la dimensin Usabilidad). En algunos casos, se sustituy simplemente el nombre de una dimensin de WQM por una de SCORM (Mantenibilidad por Durabilidad). As mismo se seleccionaron mtricas por cada dimensin, y se determin el dominio de la medida de

62

cada una. (Tabla 6). La definicin de estas se bas en las propuestas por WQM; adems, se utilizaron las preguntas planteadas por Tillman (2000) para complementar las mtricas de la dimensin Contenido, las mtricas de calidad en uso del estndar ISO9126-4 para completar las de la dimensin Confiabilidad y Usabilidad, las dimensiones concernientes a satisfaccin del usuario de Sampson y Manouselis (2004) para la dimensin Usabilidad, tambin; y finalmente, las medidas de reusabilidad de Moraga et al. (2005). Las dimensiones son las siguientes:

Tabla 4: Dimensiones y atributos de calidad para aplicaciones e-learning. DIMENSIN Contenido ATRIBUTOS DIMENSIN Usabilidad ATRIBUTOS

Secuencia Navegacin Funcionalidad

Asequibilidad

Comprensibilidad Facilidad de aprendizaje (Habilidad para aprender segn WQM) Operabilidad Personalizacin Ayuda Amigabilidad con el usuario Flexibilidad Tiempo de comportamiento Recursos de comportamiento Instalabilidad Co-existencia Mutabilidad
Estabilidad

Idoneidad Precisin

Portabilidad

Interoperabilidad

Confiabilidad

Madurez Tolerencia a fallas Disponibilidad Accesibilidad Escalabilidad

Durabilidad

Reusabilidad (Fuente: Elaboracin propia)

Tabla 5: Mtricas de calidad para aplicaciones e-learning.

DIMENSIN

MTRICAS

DOMINIO DE LA MEDIDA

63

Contenido

Credibilidad informacin

de

la

Booleano Nmero natural Nmero natural Escala: poca-normal-alta Escala: poca-normal-alta Escala: poca-normal-alta Booleano Nmero natural Nmero natural Booleano

Contador de imgenes Contador de pginas Complejidad de audio Complejidad de video Complejidad de animacin Informacin idnea Informacin actualizada Pginas reusadas Documentos reusados Preguntas frecuentes Soporte lenguajes para otros

Booleano Nmero natural Escala: poca-normal-alta Nmero natural Nmero natural Nmero natural Nmero natural Booleano

Nmero de componentes Web Complejidad de lectura Contador de elementos de bsqueda Total de Clips de Audio Total de Clips de video Total de animaciones Actualizacin del contenido

Identificacin de contenido actualizado Contenido estables y ubicacin

Booleano

Booleano

64

Total de documentos a bajar (.pdf, .doc) Contenido nico Contenido valioso Contenido organizado Contenido accesible fcilmente

Nmero natural

Booleano Booleano Booleano Booleano

Fcil identificacin de antecedentes y jerarqua de autores del contenido Booleano

Compacidad Nmero de IN LINKS Nmero de OUT LINLS Mapa de sitio Indicacin actual de posicin

Booleano Nmero natural Nmero natural Booleano Booleano Escala: mala-normal-buena Nmero natural Booleano Booleano Booleano Escala: mala-normal-buena Nmero natural Nmero natural Nmero natural

Secuencia y Navegacin

Calidad de la frase del link Contador redundantes de links

Errores en Links Secuencia de evaluacin Rpido acceso a pginas Funcionalidad Calidad de frases link Nmero de componentes Web Total de conos/botones Contador de interactivos elementos

65

Contador de elementos de bsqueda Total de Clips de Audio Total de Clips de video Total de animaciones Total de documentos a bajar (.pdf, .doc, etc.)

Nmero natural Nmero natural Nmero natural Nmero natural Nmero natural

Nivel de recuperacin de Escala: malo-normal-bueno informacin Nivel de recuperacin de personalizacin Nmero de mtodos Nmero de atributos Longitud de cdigo Forma de empaquetar los objetos Nmero de links rotos Errores ortogrficos Deficiencias o resultados inesperados Confiabilidad Compresin del mapa de navegacin Efectividad de la tarea Completitud de la tarea Frecuencia de error Usabilidad Efectividad de la tarea Completitud de la tarea Frecuencia de error Tiempo en llevar a cabo la tarea Eficiencia de la tarea Escala: malo-normal-bueno Nmero natural Nmero natural Nmero natural Descripcin Nmero natural Nmero natural Nmero natural Escala: poco-normal-alto Nmero flotante Nmero flotante Nmero flotante Nmero flotante Nmero flotante Nmero flotante Nmero flotante

66

Nmero de IN links Nmero de OUT links Nmero de links rotos Informacin actualizada Tabla de contenidos Mapa de sitio ndice Ayuda global FAQ Comentarios/Sugerencias Contador de errores ortogrficos Complejidad de lectura Contador de elementos de bsqueda Informacin de actualizaciones Lenguajes que soporta Satisfaccin con personalizacin de interfaz Satisfaccin con herramientas y servicios utilizados para comunicacin con tutores y compaeros Rpido acceso a pginas Complejidad de audio Complejidad de video Tiempo de descargas Duracin media de clips de audio Duracin media de video clips Peso de pgina

Nmero natural Nmero natural Nmero natural Booleano Booleano Booleano Booleano Booleano Booleano Booleano Nmero natural Escala: poca-normal-alta Nmero natural Booleano Descripcin Booleano

Booleano

Asequibilidad

Booleano Escala: poca-normal-alta Escala: poca-normal-alta Nmero flotante Nmero flotante Nmero flotante Nmero flotante

67

Uso de spam Complejidad de audio Complejidad de video Complejidad de animacin Tiempo de descargas Portabilidad Nmero de mtodos Nmero de atributos Nmero de componentes Web Caractersticas del perfil del usuario Documentacin Nmero de IN links Nmero de OUT links Durabilidad Nmero de elementos interactivos Interfaz de pgina Manuales de usuario Documentacin Reusabilidad

Booleano Escala: poca-normal-alta Escala: poca-normal-alta Escala: poca-normal-alta Nmero flotante Nmero natural Nmero natural Nmero natural Nmero natural Booleano Nmero natural Nmero natural Nmero natural Booleano Booleano Booleano

Descripcin de funcionalidad de componente

Descripcin

(Fuente: Elaboracin propia) CONCLUSIONES

No existe une estndar de mtricas de calidad Web, pues diversos investigadores han definido mtricas para medir la calidad en aplicaciones de este tipo, pero sus trabajos no se enfocan en los mismos aspectos de la Web.

68

Por ello, en la investigacin se realiz una seleccin de mtricas acordes con los objetivos de las aplicaciones e-learning, basndose en las propuestas de los autores citados en el trabajo. Emplear mtricas numerosas y muy especficas, como el modelo WQM, es inadecuado para medir algn producto de software. El tipo de aplicacin Web que se pretende medir, o los aspectos a los que se enfoca, son los determinantes en la seleccin de mtricas a utilizar.

BIBLIOGRAFA [1] CALERO C., RUIZ J., PIATTINI M., A Web Metrics Survey Using WQM [en lnea]. 4th International Conference, ICWE 2004 Munich, Germany [en lnea]. Julio 26-30, 2004 [fecha de consulta: 1 Octubre 2007]. Disponible en <http://alarcos.infcr.uclm.es/interfaces/spa/linesInv/CW.aspx> [2] PIATTINI M., GARCA F., Calidad en el desarrollo y mantenimiento del software. Mxico: Alfaomega Grupo Editor, 2003. [3] PALOMA M., MONTERO S., AEDO I., Ingeniera de la web y patrones de diseo. Mxico: Pearson Educacin, 2004. [4] MORAGA M., CALERO C., PAZ I., DAZ ., PIATTINI M., A Reusability Model for Portlets [en lnea]. 2005 [fecha de consulta: 1 Octubre 2007]. Disponible en <http://alarcos.inf-cr.uclm.es/interfaces/spa/linesInv/CW.aspx>

[5] CALERO C., RUIZ J., PIATTINI M., Classifying web metrics using the web quality model. Online Information Review [en lnea]. 2005, Vol. 29, N 3, pgs. 227-248 [fecha de consulta: 1 Octubre 2007]. Disponible en <http://alarcos.infcr.uclm.es/interfaces/spa/linesInv/CW.aspx> [6] MORAGA M., CALERO C., PIATTINI M. Comparing different quality models for portals [en lnea]. 2006 [fecha de consulta: 1 Octubre 2007]. Disponible en <http://alarcos.infcr.uclm.es/interfaces/spa/linesInv/CW.aspx> [7] Aguillo, I.F. Hacia un concepto documental de la sede web. En: El profesional de la informacin, 2007, 16 (1): 14. [8] PRESSMAN R., Ingeniera del software: un enfoque prctico. Mxico, DF: Mc GrawHill Interamericana, 2005. [9] BELLAS F. Standards for Second-Generation Portals. IEEE Computer Society [en lnea]. Marzo-abril 2004 [fecha de consulta: 01 Diciembre 2007] Disponible en: <http://www.tic.udc.es/~fbellas/publications/ic-march-april-2004.pdf>

69

[10] SCORM. Scorm for Dummies. <http://www.scorm.com/resources/scorm4dummies/Scorm%20for%20Dummies.htm> (1 Diciembre 2007) [11] ADVANCED DISTRIBUTED LEARNING. SCORM 2004 3rd Edition. Impact summary [en lnea]. 2006 [fecha de consulta: 1/12/2007]. Disponible en <www.ADLNet.org>

70

MEJORA DE PROCESOS DE SOFTWARE BAJO UN NUEVO CAMBIO ORGANIZACIONAL. CASO PERUANO DE XITO DE LA PRIMERA INSTITUCIN FINANCIERA EN ALCANZAR EL NIVEL 3 DE MADUREZ DEL CMMI5

RESUMEN El nuevo modelo CMMI brinda un marco con una estructura comn para todas las disciplinas: ingeniera de software, ingeniera de sistemas, desarrollo integrado de productos, adquisicin de productos, personas, y agrega una nueva forma de representacin adems de la conocida representacin por niveles. La nueva forma de representacin se llama Continua y est orientada a medir la mejora en los procesos de manera individual en vez de hacerlo de manera conjunta como la representacin por niveles (Software Engineer Institute, 2002). Con ello busco especificar qu es CMMI, cules es su estructura, cules son los niveles de capacidad y madurez, adems de brindar beneficios adicionales a los que presenta el Software Engineer Institute, 2002 como son: mejora del alineamiento del Software con la Estrategia de Negocio, reduccin en los costes y en las desviaciones en plazo de los Proyectos Software, mayor eficacia en la deteccin de errores a lo largo del ciclo de vida de los proyectos Software, reduciendo drsticamente el nmero de errores que afecta directamente a los clientes y usuarios, resultados ms predecibles en los proyectos, implementacin de tcnicas pro-activas de gestin, mitigando los riesgos que afectan a los proyectos, resultados ms predecibles en los proyectos, liberacin de tensiones, malentendidos y vacos de responsabilidad en Proyectos Software, disposicin de informacin de gestin til a la hora de tomar decisiones ya sean stas relacionadas con la Gestin de Proyectos Software, bien con la mejora continua del Proceso Software, mejorar el posicionamiento frente al mercado. Adems identificar las reas de proceso de CMMI en las cules las empresas deben de fijarse para un mayor logro competitivo a nivel de ingeniera de software. Por ltimo desarrollar el caso de xito del Banco de Crdito del Per, Institucin Financiera Peruana que alcanz el Nivel 3 de Madurez de CMMI y poner este caso como ejemplo para incentivar a las dems empresas a obtener un Nivel de Madurez igual o mayor al que dicha empresa alcanz y as ser competitivos con un respaldo de un Certificado Internacional de Calidad de sus procesos.

Palabras claves: SEI, CMMI, modelo, procesos, costes.

Meja Montao, Giuliana del Carmen

71

INTRODUCCIN El Tratado de Libre Comercio que posiblemente firmemos con Estados Unidos generar una mayor inversin al pas, lo que no significa una tarea fcil sino difcil de aprehender y poner en prctica. A medida que se generan nuevos cambios tecnolgicos, la globalizacin como tal exige nuevas formas de dirigir al mundo, entre ellas: el crecimiento del Producto Bruto Interno, el incremento en Exportaciones, inversin en infraestructura e industria del valor agregado que nos indica que vamos por buen camino, pero no podan faltar las Tecnologas de Informacin y Comunicacin, y la Industria del Desarrollo del Software que actualmente se preparan para afrontar este nuevo reto denominado Competitividad, la cual se origina en todos los pases del mundo para determinar bajo distintos enfoques cual es la empresa lder en el mundo en un sector determinado. Por ello es que surge el CMMI, como estndar mundial para la mejora de procesos de desarrollo de software y luego certificarlos e incluso por esta competitividad generada a nivel mundial es que esta acreditacin se ha convertido en requisito indispensable para la contratacin de servicios de Tecnologas de Informacin en muchos pases. En la actualidad Brasil, Chile, Argentina y Uruguay tienen ms de 20 empresas certificadas en un nivel CMMI, lo que facilita sus intercambios comerciales. En el Per estamos uniendo esfuerzos para mejorar nuestra posicin competitiva y as facilitar futuros compromisos con pases desarrollados, por ello es que pocas son las empresas que tienen la certificacin de CMMI actualmente y slo una ha obtenido el Nivel 3 de Madurez implementando modelos de calidad en su organizacin financiera convirtindose en lder del mercado, este logro involucr, para la organizacin, una inversin considerable y un cambio organizacional traumtico pero controlado que permiti continuar su mejora en sus procesos y sus visiones a alcanzar el Nivel 5 de Madurez en CMMI. Por lo tanto pretendo determinar cules son los beneficios que brinda el CMMI para que las organizaciones peruanas mejoren sus procesos de software teniendo como base el proceso de certificacin que tuvo una Institucin Financiera Peruana con Nivel 3 de CMMI y as adquirir certificaciones relevantes para ser ms competitivos en el mercado nacional y porqu no en el mercado internacional.

SOFTWARE ENGINEERING INSTITUTE (SEI) El Instituto de Ingeniera del Software de Estados Unidos (Software Engineering Institute, SEI) es un centro de investigacin y desarrollo perteneciente a la Universidad de Carnegie Mellon, fundado y financiado por el Departamento de Defensa de los Estados Unidos, a travs de la Oficina de la Subsecretara de Defensa para Adquisicin, Tecnologa y Logstica. La meta del Instituto es proporcionar a las organizaciones las pautas de actuacin necesarias para obtener mejoras observables en su proceso del software, de manera que desarrollen productos sin defectos respetando requerimientos, fechas y costos. Para ello se plantean cuatro objetivos: Acelerar la introduccin en las organizaciones de produccin de software de las prcticas y tcnicas de ingeniera del software ms eficaces y eficientes, identificando, evaluando y mejorando aquellas que se

72

consideren tiles. Mantener a largo plazo la competencia en ingeniera del software y en la gestin del cambio tecnolgico. Habilitar a organizaciones privadas y pblicas, trabajando con ellas, para que hagan mejoras en sus prcticas de ingeniera del software. Fomentar la adopcin y uso continuo de estndares de excelencia en prcticas de ingeniera del software.

SOFTWARE CAPABILITY MATURITY MODEL (SW-CMM) En el Modelo de Madurez de la Capacidad del Software del SEI (Software Capability Maturity Model, SW-CMM) se definen un conjunto de reas clave del proceso, que describen las funciones de ingeniera del software que deben llevarse a cabo para el desarrollo de una buena prctica, agrupadas en cinco niveles inclusivos. Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso del software en la organizacin. Mediante un amplio conjunto de mtricas se determina la calidad de cada una de las reas clave, obtenindose una visin precisa del rigor, la eficacia y la eficiencia de la metodologa de desarrollo de una organizacin productora de software. Cada una de las reas est organizada bajo cinco caractersticas comunes: compromiso de realizacin, capacidad para llevarla a cabo, actividades que hay que realizar, medicin y anlisis y verificacin de la implementacin. En cada caracterstica se especifican unas prcticas clave, que son normas, procedimientos y actividades cuya realizacin lleva a la consecucin de los objetivos del rea. En algunos casos se detallan subprcticas ms especficas, guas e interpretaciones de la prctica y, cuando procede, ejemplos y referencias cruzadas a otras prcticas.

NIVELES DE MADUREZ DE LA CAPACIDAD DEL SOFTWARE Los niveles en los que se agrupan las reas claves de proceso son inclusivos: para alcanzar uno es necesario haber alcanzado y mantener todos los anteriores:

Nivel Inicial Est caracterizado por una aproximacin intuitiva al proceso de desarrollo del software. El xito depende del esfuerzo individual. No se han definido procesos metodolgicos, o se han definido pero no se siguen. Es necesario realizar medidas de lnea base, es decir, medidas que servirn para estimar y planificar en el futuro. Asimismo, es el momento de hacer un esfuerzo de estructuracin y control en el proceso.

Nivel Repetible La madurez metodolgica de la organizacin permite estimar fiablemente el tamao funcional o fsico del sistema, as como recursos, esfuerzo, costos y calendario. Las

73

reas clave de proceso definidas en este nivel, cuyo estado se puede conocer mediante diversas mtricas, son las siguientes: Gestin de requisitos Planificacin del proyecto software Seguimiento y control del proyecto Gestin de la subcontratacin del software Aseguramiento de la calidad del software Gestin de la configuracin del software

Nivel Definido Se conoce la forma de construccin del sistema, el proceso del software de las actividades de gestin e ingeniera se documenta y se estandariza. Las actividades intermedias estn bien fijadas, y por tanto se pueden examinar y medir. Con ello es posible detectar tempranamente posibles problemas y aplicar una adecuada gestin del riesgo. Las reas clave de proceso definidas en este nivel son: Desarrollo y mejora de los procesos de la organizacin. Definicin de los procesos de la organizacin. Programa de formacin. Gestin integrada del software. Ingeniera de producto software. Coordinacin intergrupos. Revisin conjunta.

Nivel Gestionado Se aade la gestin a un proceso definido. Se usa realimentacin desde las primeras actividades del proyecto para seleccionar prioridades en las actividades actuales y conocer cmo se emplean los recursos. Los efectos de los cambios en una actividad se pueden seguir en otras. Se recopilan medidas detalladas del proceso del software y de la calidad del producto. En definitiva, se evala la efectividad de las actividades del proceso. Por ejemplo, se podra medir cunto se est produciendo para ser reutilizado, cunto se est reutilizando de proyectos anteriores, cmo y cundo son descubiertos los defectos y la relacin entre fechas de finalizacin de los mdulos y fechas previstas. Las reas clave definidas en este nivel son dos: Gestin cuantitativa del proyecto Gestin de calidad del software.

Nivel Optimizado Existe una mejora continua de los procesos. Las medidas de actividades se usan para mejorar el proceso, eliminando y aadiendo actividades y reorganizando su estructura

74

como respuesta a los resultados de las medidas. Las reas definidas para este nivel son: Prevencin de defectos. Gestin de cambios tecnolgicos Gestin de cambios en los procesos.

Adems del Modelo de Madurez de la Capacidad del Software existen el Modelo de Madurez de la Capacidad en la Adquisicin de Software (SA-CMM), y el Modelo de Madurez de la Capacidad de las Personas (P-CMM).

CAPABILITY MATURITY MODEL INTEGRATION (CMMI) El Capability Maturity Model Integration (en adelante CMMI) es una fusin de modelos de mejora de procesos para ingeniera de sistemas, ingeniera del software, desarrollo de productos integrados y adquisicin del software. Fue creado por el SEI con el objetivo de extender y combinar la gran cantidad de modelos creados por el SEI, entre otros, el Capability Maturity Model for Software (SW-CMM), el Systems Engineering Capability Model y el Integrated Product Development, y otras organizaciones a lo largo de los aos. El CMMI es uno de los modelos ms utilizados en la industria del software. Entre sus principales caractersticas tenemos: El disminuir o eliminar la redundancia en el trabajo. Aumentar la fiabilidad en la prediccin de costos. Aumenta el rehso de productos y procesos. Disminuir costos debido a travs de la evaluacin y mejora continua de los procesos. Adems proporciona objetivos cuantificables y una aproximacin al que hacer aunque no sea un precepto. As tambin, las valoraciones estn orientadas a determinar si se alcanza un determinado nivel de madurez en el proceso. Este modelo permite que las empresas dispongan de prcticas que pueden ser comparadas con las de otras compaas. CMMI mide el proceso de madurez en cinco niveles: nivel 1 inicial, nivel 2 gestionado, nivel 3 definido, nivel 4 gestionado cuantitativamente, nivel 5 optimizado.

REPRESENTACIONES CMMI Una representacin CMMI se debe entender como la forma en que vamos a trabajar con un modelo. CMMI posee dos representaciones: Staged (por etapas). Se refiere al modelo de madurez de una organizacin vista de forma global. Sus caractersticas principales son: Proporciona una secuencia de mejoras, empezando con una gestin de prcticas bsicas que progresan a travs de un conjunto predefinido y sucesivo de niveles, en los que de menor nivel sirven de base para los mayores. Permite la comparacin dentro de la organizacin y con otras

75

organizaciones a travs del uso de los niveles de madurez. Proporciona una fcil migracin desde SW-CMM a CMMI. Proporciona un esquema de medida simple que permite la comparacin entre organizaciones. Continuos (continua). Se refiere a la capacidad de un rea de Proceso de forma individual. Sus caractersticas principales son: Permite seleccionar el orden en que la mejora se llevara a cabo en lnea con los requerimientos de negocio y la necesidad de mitigar los riesgos identificados. Permite comparar entre empresas o dentro de una misma empresa, los resultados obtenidos por rea de proceso tras la adopcin del modelo. Proporciona una fcil migracin desde EIA/IS 731 (Electronic Industries Alliance Interim Standard) a CMMI. Ofrece una fcil comparacin entre la mejora de procesos del Internacional Organization for Standarization and International Electrothechnical Commission (ISO/IEC) 15504, dado que la organizacin de las reas de procesos es similar. El elegir una representacin u otra depende del juicio profesional y de los objetivos que se pretenden alcanzar. Independientemente de esto se debe tener claro que ambas representaciones han sido diseadas para proporcionar los mismos resultados.

NIVELES DE MADUREZ CMMI Los niveles en los que se agrupan las reas claves de proceso son inclusivos: para alcanzar uno es necesario haber alcanzado y mantener todos los anteriores:

Fig. 1. reas de proceso de CMMI por niveles

76

(Fuente: Nuez, 2007)

77

Nivel de Madurez 1: Inicial Nivel en el que se encuentran todas las empresas. Se trabaja fuerte pero de forma inefectiva, mucha actividad pero todo es til.

Nivel de Madurez 2: Gestionado Se introducen dos nuevos conceptos: Integracin del producto y Desarrollo de procesos y Gestin de los proveedores. Llegar al nivel 2 es la barrera ms grande de las organizaciones. El nivel de madurez 2 consiste en siete reas de proceso, que contribuirn a proyectar la eficacia de la gestin.

78

Fig. 2. Procesos del Nivel de Madurez 2 (Fuente: Raggio, s/f)

79

Fig. 3. Procesos del Nivel de Madurez 2 (Fuente: Raggio, s/f)

Nivel de Madurez 3 Definido Usa tus lecciones aprendidas, el conjunto de procesos estndares de la organizacin esta establecido y se mejora con el tiempo. Es un proceso en el que la organizacin entera participa en el proceso eficiente del proyecto software. Los procesos estn estandarizados, documentados e

80

institucionalizados con mayor rigurosidad. Se institucionaliza un proceso estndar de desarrollo de software que integra: los procesos de ingeniera de software, gerencia de proyectos de software, la organizacin tiene cimientos para futuros progresos, significativos y continuos. El debate acerca del valor de las mediciones y su utilidad contina abierto debido a la ausencia de una norma que fije cules son los pasos de un proyecto y cules los elementos a medir.

81

82

Fig. 4. reas claves del Proceso - Ingeniera (Fuente: Raggio, s/f)

83

Fig. 5. reas claves del Proceso Administracin de Proceso (Fuente: Raggio, s/f)

84

85

Fig. 6. reas claves del Proceso Administracin Proyectos (Fuente: Raggio, s/f)

Fig. 7. reas claves del Proceso Soporte (Fuente: Raggio, s/f)

Nivel de Madurez 4 Gestionado cuantitativamente Los proyectos son gestionados por los nmeros. Las decisiones organizacionales se toman por los nmeros. Los procesos, los servicios y la calidad del producto se miden por los nmeros. Proceso de refinamiento sucesivo (el paso al nivel 4 no es un cambio fcil). No se aaden metas genricas en el nivel 4 a partir del nivel 3. El nivel de madurez podra no probar el beneficio esperado. Lo que hace este nivel de madurez distinto son las dos reas de procesos: proceso organizacional del desarrollo y gestin de proyectos cuantitativa. Objetivos: entendimiento cuantitativo de la ejecucin de los procesos de la organizacin; proporcionar para la gestin cuantitativa de proyectos: datos de ejecucin de procesos, lneas base, modelos; necesidades: compromiso y la

86

participacin de la alta direccin, alto grado de experiencia, personal numeroso; es importante: el uso de Herramientas automatizadas para la recogida de datos, divisin del repositorio de medidas en capas, experiencia en la recogida de datos.

Fig. 8. Rendimiento de los Procesos en la Organizacin (Fuente: Raggio, s/f) - Lnea base de ejecucin de proceso: Resultados histricos logrados siguiendo un proceso. Uso: comparar ejecucin real vs. ejecucin esperada de procesos. - Modelo de ejecucin de procesos: Relaciones entre atributos de un proceso y sus productos de trabajo. Uso: estimar o predecir un valor crtico que no puede ser medido por el momento. - Medidas; deben proporcionar Rangos vs. datos puntuales, adems indican reas de debilidad a reforzar. Las medidas a considerar son: de proceso; esfuerzo, tamao, costo, planificacin; revisando la productividad en las fases del cv.; de producto; y fiabilidad, densidad de defectos.

Fig. 9. Gestin Cuantitativa de Proyectos (Fuente: Raggio, s/f)

Nivel de Madurez 5- En optimizacin

87

Crea lecciones aprendidas y las usa para ms lecciones aprendidas para crear ms lecciones aprendidas. Los procesos de mejora continan con proceso que cambian y adaptan para satisfacer los objetivos de negocio vigente y proyectado. Los procesos mejoran en base a un entendimiento cuantitativo de las causas de variacin inherente en los procesos. Las reas del Nivel 5 son: Innovacin y Despliegue Organizacional; y Anlisis y Resolucin de las Causas. Para satisfacer los objetivos del Nivel 5 se tienen que haber satisfecho los objetivos de los Niveles 2,3 y 4. Los objetivos del Nivel 5 son: Mejorar la calidad general de los procesos de la organizacin; Forma de alcanzarlo; Identificar las causas de la variacin; Determinar la raz de las causas de las condiciones identificadas; Hacer pruebas de las mejoras del proceso; Incorporar las mejoras y acciones correctivas en los procesos estndar de la organizacin.

Fig. 10. Innovacin y Despliegue Organizacional (Fuente: Raggio, s/f) Las propuestas de mejora de procesos y mejoras tecnolgicas estn incluidas en esta rea de proceso. Las etapas a seguir en esta rea de proceso son: Presentar las propuestas de mejora; Revisar y analizar las propuestas; Prueba piloto de las propuestas; Medir las mejoras para ver si son efectivas en las pruebas; Planear el despliegue de las mejoras; Desplegar las mejoras; Medir la eficacia de las mejoras a travs de la organizacin o proyecto.

88

Fig. 11. Anlisis y Resolucin de las Causas (Fuente: Raggio, s/f)

Las etapas a seguir en esta rea de proceso son: Buscar los defectos y problemas en la organizacin; Seleccionar los datos a analizar; Analizar las causas; Preparar propuestas para tratar los problemas; Implementar las propuestas; Evaluar los efectos de los cambios.

BENEFICIOS DEL MODELO CMMI

Reduccin de costos por: Estimaciones basadas en hechos. Reduccin de reprocesos. Acuerdos claros sobre el servicio y la funcionalidad del producto a entregar.

Aumento en la confiabilidad por: Reduccin consistente de errores. Cumplimiento consistente de fechas.

Mayor efectividad por: Visibilidad sobre el proceso y sobre el producto. Operar con estndares documentados. Personal entrenado.

89

Para obtener con xito dichos beneficios se necesita: Capacitaciones certificadas. Evaluaciones oficiales (informales y formales). Capacitacin general. Evaluaciones de terceros. Formulacin de planes de accin. Soporte a la ejecucin de planes de accin. Administracin del Cambio cultural.

EVALUACIN CMMI SCAMPI El Estndar CMMI usado como mtodo de evaluacin para la mejora de procesos, SCAMPI, es la evaluacin formal del Software Engineering Institute (SEI) para otorgar el nivel de maduracin a la compaa evaluada. Es realizada a travs de partners autorizados por el SEI. La evaluacin tiene una duracin de dos a tres semanas aproximadamente, por dos consultores del partner del SEI y facilitadores de la organizacin evaluada. La evaluacin es realizada a un grupo de proyectos de la organizacin evaluada (5 a 10 aproximadamente). Solo se otorga la certificacin en el nivel solicitado si se ha cumplido al 100% con todas las prcticas. Evaluacin basada en evidencias. Componentes Evaluados: - reas de Proceso. - Metas Especficas y Genricas.

Fig. 12. Evaluacin SCAMPI

90

(Fuente: Nuez, 2007)

Resultados de la evaluacin:

Fig. 13. Ejemplo de Evaluacin SCAMPI en Nivel 2 de CMMI (Fuente: Nuez, 2007) CASO DE XITO EN EL PER El Banco de Crdito del Per es la primera Institucin peruana en obtener una certificacin en Nivel de Madurez 3 del Modelo CMMI, a continuacin describiremos como fue dicha implementacin: El proyecto se inicio en Enero del 2003. Teniendo como objetivos: Mejorar la calidad de sus productos y procesos, Incrementar satisfaccin de clientes internos y externos. La meta del proyecto: Alcanzar el nivel de madurez CMMI 3 durante el segundo semestre del 2006. Optando como estrategias generales del proyecto: Equipo de procesos, Consultora y la Metodologa IDEAL. Dichas estrategias no fueron problema porque se utilizaron diversidad de factores que determinan el xito de un plan de mejora de procesos, en la organizacin se cuenta con modelos (CMMI) y una metodologa (IDEAL).Tambin durante la ejecucin surgen otros factores que conforman ese conjunto de factores principales para el xito del plan. Se buscaba romper los siguientes mitos con los que viven las organizaciones: No hay tiempo siempre hay tiempo para corregir las cosas que no hacemos bien, pero nunca hay tiempo suficiente para asegurarnos que hacemos las cosas bien la primera vez. Porqu hacer el trabajo ms complejo Antes, sin procesos, yo haca mi trabajo y lo haca bien pues era capaz de escribir software que funcionaba. Se requiere inversin la calidad no es gratis. Costo de conformidad + Costo de no conformidad = Calidad Los estndares van a limitar mi creatividad innovacin y capacidad de crear consistente y asegurada.

91

La metodologa IDEAL: es un modelo de mejora organizacional que sirve como mapa para iniciar, planificar e implementar acciones tendientes a mejorar los procesos. Se llama as por las 5 etapas previstas: Iniciar (Initiating) Diagnosticar (Diagnosing) Establecer (Establishing) Actuar (Acting) Aprender (Learning) Las fases de este enfoque son:

Tabla 1: Fases del modelo IDEAL I D Iniciar Diagnosticar Definir la base para un proceso exitoso de mejora. Identificar dnde est posicionada la Organizacin y a dnde quiere llegar. Planificar las acciones a ejecutar para alcanzar el estado deseado. Ejecutar el Plan. Aprender de la experiencia realizada y visualizar oportunidades de mejoras. Fuente: (Polo Tecnolgico Rosario, 2005)

Establecer

A L

Actuar Aprender

92

El Modelo IDEAL

Fase Iniciar Su propsito es establecer los fundamentos bsicos para garantizar y dar soporte a la iniciativa de mejoras de procesos. La alta direccin establece cules son los objetivos de la organizacin y de la mejora de procesos El apoyo de la alta direccin y de los gerentes en general es fundamental para el xito del programa de mejoramiento. Se garantiza la disponibilidad de recursos, la infraestructura y la priorizacin del proyecto de mejoramiento. Las actividades de esta fase determinan el xito o el fracaso del programa. Establecer el contacto: es el detonante de la iniciativa. Es importante conocer cules son las razones para mejorar e identificar los aspectos comerciales u organizacionales que se pretende asegurar. Establecer el patrocinio de la alta direccin: el apoyo de los distintos niveles de direccin es crtico, su ausencia o debilidad es una receta para fracasar. El apoyo debe ser claro, efectivo y constante. Establecer la infraestructura adecuada: contar con un mecanismo para dirigir e implementar el proyecto de mejora. Se debe capacitar a los distintos gerentes y personal de proyecto. Conocer CMMI es fundamental. Es aproximadamente el 5% del esfuerzo total del Proyecto

Fase Diagnosticar Su propsito es evaluar mediante un mtodo formal las fortalezas y debilidades del proceso actual utilizado en los proyectos. Los objetivos del programa se relacionan con las prcticas existentes y se determinan aquellas que no estn suficientemente desarrolladas. Generalmente esta fase es desarrollada con el asesoramiento de expertos en el modelo de referencia. Determinar el estado actual y el esperado: implica una evaluacin de los proyectos de la organizacin. Es equivalente a identificar el punto de partida y el punto de destino antes de hacer un viaje. CMMI sirve como un modelo de referencia para determinar el estado deseado que se pretende alcanzar. Plantear recomendaciones y documentar los resultados de la fase: un equipo experto identifica las debilidades y fortalezas de las prcticas actuales, en base a la informacin analizada durante la evaluacin. Sus recomendaciones sirven como entrada al plan de accin para la mejora. La salida es generalmente un informe de resultados. Es aproximadamente el 5% del esfuerzo total del Proyecto

Fase Establecer Su propsito es realizar la planificacin especfica de las mejoras que se desea alcanzar. Se desarrolla un plan de proyecto.

93

Se establece la estrategia. Se eligen prioridades para la accin, en base a recursos, necesidades urgentes, efectividad de la accin, impacto y otros. Establecer las prioridades: la mejor comprensin de las necesidades que se han ido identificando en los pasos previos, permite establecer la estrategia y los recursos necesarios para completar el trabajo. Se identifican a los recursos competentes que participarn en el proyecto de mejora. Elaboracin del Plan de Accin: las recomendaciones de la evaluacin se trasforman en un plan concreto que satisface las prioridades y necesidades de la organizacin. Habitualmente se consideran acciones de corto, mediano y largo plazo. El plan incluye calendarios de proyecto, tareas, hitos, puntos de decisin, recursos, responsabilidades, mtricas, mecanismos de seguimiento, riesgos con sus respectivas estrategias de mitigacin. Es aproximadamente el 5% del esfuerzo total del Proyecto

Fase Actuar El propsito es implementar la mejora de procesos llevando a cabo el plan de accin. Aqu se introducen o mejoran los procesos, se entrena a los respectivos niveles de personal, se miden los avances y beneficios logrados, se realizan proyectos pilotos, se implantan los procesos mejorados en los proyectos nuevos o existentes, se hacen mini evaluaciones para constatar la evolucin del plan y otros. Razonablemente, en una organizacin mediana se requieren entre 1 y 2 aos para moverse de un Nivel 1 a un Nivel 2-3. Desarrollar la solucin: implica la definicin e integracin de los procesos, herramientas, informacin, conocimiento y habilidades, tanto existentes como nuevas. Probar la solucin: una vez que las soluciones han sido diseadas, se necesita probarlas en proyectos pilotos antes de decidir institucionalizarlas en el resto de los proyectos. Refinar la solucin: cuando la solucin propuesta ha sido aplicada en un proyecto piloto, se puede refinar para reflejar el conocimiento, la experiencia y las lecciones aprendidas en el ensayo. Implementar la solucin: una vez que se ha decidido que se tiene una solucin aceptable, se procede a aplicarla a lo largo de la organizacin. Es aproximadamente el 80% del esfuerzo total del Proyecto Algunas de las actividades previstas para esta etapa son: La definicin y documentacin de procesos Adaptacin, desarrollo o adquisicin de herramientas de base, para dar soporte a los procesos y al manejo de la informacin (plantillas, software, guas) Comunicacin y Capacitacin a quienes utilizarn el proceso Implementacin de los procesos en un proyecto piloto Cursos Oficiales CMMI

Fase Aprender

94

El propsito es aprender de la experiencia del ciclo recin realizado y aumentar la habilidad de la organizacin para mejorar los procesos en forma continua. Se determinan los logros, el esfuerzo invertido, la manera en que las metas fueron satisfechas y la forma ms adecuada de implementar cambios en el futuro. Se utilizan las mediciones y registros acumulados durante la aplicacin de las etapas anteriores del ciclo. Analizar y validar los resultados: identificar el grado en que el esfuerzo invertido logr los propsitos deseados. Las lecciones se recolectan, se analizan, se resumen y se documentan. Se reexaminan las necesidades de la empresa identificadas en la fase de inicio para ver si fueron satisfechas. Revisar el enfoque seguido y proponer acciones futuras: se plantean y documentan recomendaciones que resultan del anlisis y la validacin. Se proponen pautas y acciones para el siguiente plan de mejora. Generalmente el final del primer ciclo coincide con las primeras etapas del ciclo siguiente. Se recomienda efectuar una nueva evaluacin para determinar las nuevas necesidades y fortalezas que servirn de entrada al nuevo plan de accin. Es aproximadamente el 5% del esfuerzo total del Proyecto

Fig. 15. Modelo de Diseo de Procesos en el Banco de Crdito (Fuente: Nuez, 2007)

Lecciones Aprendidas por el Banco de Crdito:

Leccin aprendida 1

95

El plan de implementacin debe ser dirigido por un gerente / Lder de proyecto de la propia organizacin. Factores: Compromiso. Comunicacin. Cultura. Leccin aprendida 2 El Consultor debe hablar y entender el idioma de los miembros de la organizacin. Factores: Comunicacin. Cultura. Idioma. Leccin aprendida 3 Emplear la infraestructura y herramientas actuales de la organizacin a favor de la implementacin de las prcticas de mejora de procesos. Factores: Involucrar. Reusabilidad. Leccin aprendida 4 Organizar paquetes (grupos / equipos) de mejoras, cambios y/o prcticas implementadas para un despliegue y difusin ordenado e integrado. Factores: Organizacin. Electividad. Leccin aprendida 5 La actividad de seguimiento al despliegue de las mejoras de los procesos debe ser el elemento ms importante luego de la etapa de definicin y desarrollo de los mismos. Factores: Institucionalizacin. Gestin del cambio.

96

Leccin aprendida 6 Las evaluaciones intermedias formales al proyecto dan una mayor visibilidad al mismo y renuevan las expectativas y compromisos de toda la organizacin. Factores: Visibilidad. Compromiso. Leccin aprendida 7 Tratar de hacer participar a la mayor parte de equipos de trabajo en evaluaciones parciales y/o preliminares que permitan revisar el avance del proyecto y promover la institucionalizacin de las mejoras. Factores: Institucionalizacin. Compromiso Leccin aprendida 8 Asociar los resultados de la ltima etapa del proyecto a los indicadores de desempeo del personal y gerencia de la organizacin. Factores: Compromiso.

97

Leccin aprendida 9 Desarrollar un plan de comunicacin que permita informar a la organizacin de las mejoras y del avance del proyecto. Factores: Comunicacin. Efectividad. ORGANIZACIONES CON CMMI EN EL MUNDO

Empresas que han participado en una evaluacin SCAMPI

Fig. 16. Empresas que han participado en una evaluacin SCAMPI (Fuente: Nuez, 2007)

98

Fig. 17. Empresas Latinoamericanas con Nivel en CMMI (Fuente: Nuez, 2007) CONCLUSIONES

CMMI surge como un modelo muy orientado hacia los procesos software. CMMI debe verse como punto de referencia para saber lo que se debe hacer. La adopcin de CMMI supone una ventaja competitiva para las empresas que prestan servicios de tecnologa frente a otras, dado que van a poder disponer de un modelo de madurez que actuar como medida comparativa de la calidad del servicio que prestan. Sin olvidar la mejora que supone para la empresa el hecho de considerar la mejora continua como parte integral de su operativa de sistemas y tecnologas de la informacin. El modelo CMMI y dems modelos, a pesar de tener sus propias definiciones y esquemas para afrontar los objetivos perseguidos, siguen un mismo patrn de comportamiento: Definir, establecer los fines y objetivos del proyecto; Medir, identificar el conjunto de rangos potenciales y establecer lneas bases para los distintos niveles; Analizar, evaluar los datos y la informacin, obtenida de los eventos. Para identificar patrones de comportamiento; Mejorar, Desarrollar, implementar y evaluar soluciones paliativas para las carencias detectadas. Controlar, asegurar que los problemas estn identificados y que los nuevos mtodos pueden ser aplicados. Para tener xito en una organizacin en un mercado sumamente competitivo como lo es el de hoy en da, se deben usar modelos y metodologas que mejoren la calidad de los procesos en la organizacin, para ello se tiene que contar con ayuda especializada de transferencia de conocimiento, consultora y aprender de otras

99

experiencias organizacionales. Adems de la correcta interpretacin del contexto del negocio y la creatividad e innovacin del Departamento encargado del proyecto dentro de la organizacin. BIBLIOGRAFA
1. Libros o monografas DOLADO COSN, JOS JAVIER. Medicin para la gestin en la ingeniera del software. Madrid. Ra-Ma. 2000. 2. Publicaciones peridicas Revista PC WORLD. Editorial Planeta. Lima, (06, 2007, N 12). 3. Comunicaciones, ponencias y conferencias NEZ F., Alfonso. La mejora en la productividad del software y la decisin de generar un cambio organizacional para lograrlo - Caso exitoso de la primera institucin financiera del Per en alcanzar CMMI nivel 3 . Ponencia presentada en el XV Congreso de Estudiantes de Ingeniera de Sistemas y Computacin. Trujillo. Del 06 al 10 de Agosto del 2007. 4. Sitios web CENTRO DE CALIDAD EN TECNOLOGAS DE LA INFORMACIN, Polo Tecnolgico Rosario El Modelo IDEAL para implementar CMMI. 2005. <http://rosario.sadio.org.ar/descargas/JAI1/JAI1..El.modelo.IDEAL.para.implementar.CMMI.(Silvia.Di.Mnaco.y.Silvio.Vitali).ppt> (15 de octubre de 2007) LPEZ PREZ, Carmelo. Modelo de Madurez de la Capacidad del Software. 2004. <http://www.cii-murcia.es/informas/ene05/articulos/CMM.pdf> (01 de octubre de 2007). RAGGIO, Juan. DESARROLLO DE PROCESOS DE GESTIN DE SERVICIOS DE EXPLOTACIN SIGUIENDO EL MODELO CMMI. s/f <http://is.ls.fi.upm.es/doctorado/Trabajos20042005/Raggio.pdf> (10 de octubre de 2007) RODRIGUEZ, Patricia; ALONSO, Josefina; SNCHEZ, Jos. Cul es la madurez que necesitaran los procesos para el desarrollo de sistemas de software crtico? 2005. <http://www.ati.es/IMG/pdf/PatriciaRodriguezNum2Vol1.pdf> (08 de octubre de 2007) SEQUERA, Gelvis; BUSTAMANTE, Juan; VIVAS, Kenny. CMMI. Planificacin del Proyecto. 2005 <http://carolina.terna.net/ingsw3/datos/CMMI_PlanificacionProyecto.ppt> (20 de octubre de 2007)

100

Pruebas de navegabilidad e interfaz de usuario de la WebApp de la USAT

RESUMEN

En el presente artculo, se describe la investigacin respecto a las pruebas de navegabilidad e interfaz de usuario aplicadas a la WebApp de la Universidad Catlica Santo Toribio de Mogrovejo. Dichas pruebas se realizaron con la finalidad de saber si es que esta WebApp satisface completamente estas pruebas, centrndonos en la funcionalidad que sta debe de poseer, para que de esta manera se garantice la calidad de la misma.

Para la realizacin de estas pruebas, se requiri del empleo de distintas herramientas de software, como lo son LINKVIEWER 3.1 y XENU LINK SLEUTH. La primera de estas fue empleada, con la finalidad de proporcionar de manera grfica (forma de rbol) la estructura que posee la WebApp de la USAT, dando a conocer cuales son los vnculos tanto internos como externos que se consideran en ella. La otra herramienta empleada, se us con la finalidad de verificar la funcionalidad de todos los enlaces o vnculos que se encuentran en la WebApp en cuestin. En este caso, la funcionalidad es el punto clave a considerar, pues mediante ella, se garantiza la calidad o no de una WebApp

Palabras claves: WebApp, Funcionalidad, Validacin, Calidad, Navegabilidad.

INTRODUCCIN

El presente trabajo de investigacin se basa principalmente en aplicar algunas de las pruebas de las aplicaciones Web, como lo son las pruebas de navegabilidad y de interfaz de usuario.

Ramrez Chirinos, Javier

101

Estas pruebas, principalmente giran en torno a los usuarios, pues son ellos quienes tienen el control, ya que si ellos no tienen la confianza suficiente en la aplicacin o les parece muy tedioso el acceso a ella, simplemente no querrn emplearla y se habr realizado un trabajo sin xito.

Hoy en da, las aplicacin Web o tambin llamadas WebApps, estn siendo muy usadas, por lo que las interfaces que se le presenten a los usuarios son puntos clave en esas aplicaciones (Ramos y Rivagorda, 2004,).

Por ello, en estas pruebas, es necesario tener en cuenta, el formato de la aplicacin, la apariencia o esttica que es percibida por los usuarios y la facilidad de uso de la misma por parte de ellos. De ello depende la buena comunicacin y/o empleo de la aplicacin por parte del usuario.

Las pruebas de navegabilidad guardan relacin con la anterior, bsicamente stas se centran en garantizar que todos los mecanismos que permiten al usuario de la aplicacin Web sean funcionales (Pressman, 2005). Es decir, aqu se debe de evaluar minuciosamente la aplicacin, para que, de esta manera podamos asegurarnos de que no existan errores en ella. De lo contrario, tendremos una aplicacin con errores y de una calidad pobre que puede tener un serio impacto sobre el negocio (Cortazar, 2001).

Las pruebas antes mencionadas son la base de este trabajo, las cuales fueron aplicadas a la WebApp de la USAT, cabe mencionar que, slo se evalu la parte esttica de esta la WebApp, es decir, la que es presentada a usuarios generales, es decir los que no tienen ningn tipo de acceso privilegiado (alumno, docente, egresado, etc.), por ello, estos mdulos mencionados no fueron tomados en cuenta ni mucho menos evaluados en este trabajo.

ESTADO DEL ARTE

De acuerdo al presente tema de investigacin, algunos de los estudios realizados, referidos a las aplicaciones Web, y a las pruebas de estas, tenemos a: Gamboa F (2001), quien en su estudio denominado Diseo y evaluacin de aplicaciones interactivas ergonmicas, establece una metodologa para la especificacin de interfaces, basadas en las tareas del usuario. Dicha metodologa, consta de MAD (modelo analtico de descripcin de tareas orientado a la especificacin de interfaces), SSI (Especificacin semntica de la interfaz). De este trabajo, se concluy que, a pesar de su importancia, el

102

diseo de las interfaces de usuario, es aun poco tratado, adems que, las interfaces, no slo involucran el aspecto visual esttico, sino que, adems es un proceso iterativo e incremental.

Por otro lado, Lpez A (2004), en su tesis denominada Gisweb: Reingeniera para la implementacin de un Web Feature Service, realiz la implementacin de una aplicacin Web, denominada WisGeb, la cual fue sometida a diversas pruebas, las cuales estuvieron a cargo de un grupo de personas; estas fueron quienes evaluaron su funcionamiento, proporcionando crticas constructivas, acerca de cmo hacer ms robusta dicha aplicacin, seguidamente, se elabor un conjunto de consultas para probar la funcionalidad de la aplicacin Web. Esta aplicacin, pas con xito las pruebas realizadas, y su desempeo fue mejor al esperado, logrndose objetivos como el de desarrollar una interfaz grfica para usuarios que conocen el tema de WFS.

Covella G (2005), en su tesis llamada Medicin y Evaluacin de Calidad en Uso de Aplicaciones Web, propone un enfoque para medir y evaluar la calidad en uso, es decir, la calidad percibida por los usuarios en contextos reales de uso, de productos software para la Web. Dicha propuesta, es de carcter sistemtico y disciplinado, encuadrada por un marco de medicin y evaluacin. Dicho enfoque fue aplicado a un caso de estudio, el cual se realiz con la participacin de usuarios reales de una aplicacin para E - learning. Para ello se emple la metodologa WebQEM, diseada para evaluacin de calidad de productos Web. Del mismo modo, Olsina L (1999), propone una metodologa cuantitativa para la evaluacin y comparacin de la calidad de sitios Web, la cual pretende realizar un aporte al proponer un enfoque sistemtico, disciplinado y cuantitativo que se adecue a la evaluacin, comparacin y anlisis de calidad de artefactos Web ms o menos complejos. Para mayor entendimiento de dicho enfoque, se utilizaron 2 casos de estudio para sitios Web, uno es sobre museos tpicos en la Web y el otro es sobre los sitios Web de comercio electrnico.

APLICACIONES WEB.

Al hablar de Aplicaciones Web, o tambin llamadas WebApps, debemos, referirnos necesariamente a lo que es Internet, y la manera de cmo es que se implementan en este medio, ya que, este es nico camino por el que se puede tener acceso a dichas aplicaciones de manera remota.

103

Sabemos que, Internet nace aproximadamente a partir de los aos 70. Naci gracias al auspicio de DARPA, la Agencia de Proyectos Avanzados para la Defensa de los Estados Unidos, la cual, inicio un programa de investigacin de tcnicas y tecnologas para unir diversas redes de conmutacin de paquetes, permitiendo as a los ordenadores conectados a estas redes comunicarse entre s de forma fcil y transparente (Mateu, 2004). A partir de esto, naci el protocolo de comunicaciones de datos IP o tambin llamado Internet Protocol, y con ello, se expandi el uso de las redes, del mismo nacieron los primeros proveedores de Internet.

A mediados de los noventa se inici el boom de Internet. En esa poca el nmero de proveedores de acceso privado se dispar, permitiendo a millones de personas acceder a Internet, que a partir de ese momento ya se empez a conocer como la Red de Redes (Mateu, 2004). Es por ello que, hoy en da, la mayora de las personas tiene acceso a Internet y a los contenidos que ofrece, por lo que, algunas empresas ya han empleado Internet para poder mantener una mejor relacin con sus clientes, as como tambin ofrecer sus productos o servicios a travs de Internet, todo esto de manera dinmica, dejndose muy de lado la informacin esttica que normalmente brindan algunas Web.

Aqu es donde encajan las WebApps, las cuales consisten principalmente en un sistema, al cual acceden distintos usuarios a un servidor Web, ya sea a travs de Internet o de una intranet para el caso de algunas organizaciones. Adems, estas aplicaciones generalmente estn integradas con distintas bases de datos.

Las WebApps, poseen caractersticas comunes, a continuacin tenemos algunas:

- Intensidad de Red: Esta caracterstica est referida a que, necesariamente, las WebApps, residen un red, la cual puede ser: Internet, una Intranet, para el caso de algunas organizaciones o una Extranet, la cual consiste en la interconexin de dos o ms Intranets; pero para todos los casos mencionados, las WebApps deben de satisfacer las necesidades de sus usuarios. - Concurrencia: Caracterstica referida a que, en un momento dado, pueden acceder uno o mas usuarios a la WebApp (Pressman, 2005) - Carga impredecible: Esta caracterstica est muy relacionada con la anterior; esta se refiere a que en nmero de usuarios puede variar con respecto al tiempo, el cual puede aumentar de manera considerable, pero del mimo modo, el numero de usuarios puede verse mermado.

104

- Disponibilidad: La WebApp, debe de estar siempre disponible a los usuarios, pues estos, con frecuencia, demandan acceso sobre una base de 24/7/365 (Pressman, 2005). - Gobernada por datos: Pues, mayormente, las WebApp presentan mucha informacin al usuario, la cual puede estar de manera escrita (texto), de manera grfica, o mediante audio o video. - Evolucin continua: Esta caracterstica est referida al constante cambo que tienen las WebApps en el tiempo, pero especficamente el contenido que ofrecen estas, pues, se debe de tener en cuenta que es lo que ser mostrado al usuario, para que, de esta manera se garantice la calidad de la WebApp. - Seguridad: Las WebApps, deben de implementar medidas de seguridad respecto a contenido confidencial, infraestructura de la WebApp y ofrecer modos seguros de transmisin de datos (Pressman, 2005) - Esttica: La esttica es un punto importante a tomar en cuenta en la elaboracin de WebApps, para que, el usuario se sienta cmodo emplendola ARQUITECTURA DE LAS WEBAPPS

Las WebApps, generalmente, estn formadas o distribuidas en 3 componentes, los cuales son: el navegador, el cual presenta la internas al usuario; la aplicacin, que realiza las operaciones necesarias segn las acciones llevadas a cabo; y la base de datos, donde la informacin relacionada con la aplicacin se hace persistente. Esta distribucin se conoce como el modelo o arquitectura de tres capas. (Castejn, 2004)

Figura N 01: Estructura de una aplicacin Web Fuente: Castejn, 2004

105

De acuerdo a la arquitectura de 3 niveles o capas, mencionada anteriormente, tenemos: 1. Nivel de presentacin: En este nivel se encuentra, la interfaz de usuario, la cual depende directamente de la accin que realice el usuario. 2. Nivel de negocio: En este nivel se realiza todo el procesamiento necesario para atender a las peticiones del usuario. 3. Nivel de administracin de datos: En este nivel, se hacer persistente toda la informacin, se suministra y almacena informacin para el nivel de negocio. PRUEBAS DE WEBAPPS

A las aplicaciones Web, o llamadas tambin WebApps, se les somete a diversas pruebas con la intencin de encontrar posibles errores y corregirlos, para que luego se ponga a disposicin del usuario una aplicacin de calidad. Las pruebas a las que son sometidas las WebApps, estn referidas a nivel de contenido, funcin, facilidad de uso, navegacin, desempeo y seguridad (Pressman, 2005). A continuacin, se definen cada una de las pruebas:

Pruebas a nivel de contenido Pruebas centradas a encontrar errores en la informacin que se le presenta al usuario, estas pruebas buscan aquellos errores tanto sintcticos como semnticos que se hallan podido cometer en la elaboracin o preparacin del contenido para la webApp. Este tipo de pruebas, es de gran ayuda, para el caso de los errores sintcticos, el empleo de verificadores ortogrficos automatizados. Para el caso de la evaluacin semntica, se deben de plantear interrogantes que se enfoquen en averiguar si la informacin que se presenta al usuario es precisa, concisa, de fcil entendimiento, si se ha empleado de manera adecuada las referencias, si se respetan los derechos de autor, etc.

Pruebas a nivel de interfaz de usuario Las pruebas a nivel de interfaz de usuario se da en 3 etapas durante el proceso de Ingeniera Web (Pressman. 2005). Estas 3 etapas son: la etapa de la formulacin y anlisis de requisitos, en ella, se debe de evaluar muy a detalle el modelo de las interfaces, se debe de tener en cuenta si es que estas satisfacen los requisitos solicitados por el cliente, luego; durante la etapa del diseo, se realiza la misma tarea, la de revisin, con la finalidad de garantizar la calida de las interfaces.

106

Estas pruebas se centran en descubrir errores especficos de la interfaz, como por ejemplo errores en la ejecucin de un vnculo o en el ingreso de datos de un formulario especfico, as como tambin errores en la que, la interfaz implementa la semntica de navegacin o el despliegue de contenido.

La finalidad de estas pruebas es asegurar que las interfaces, est correctamente diseadas, teniendo en cuenta las reglas de diseo, as como tambin esttica y, que el contenido que se le presenta al usuario no posea error alguno; adems es necesario dar a conocer que los mecanismos de cada interfaz son evaluados como unidad, para que luego, como conjunto, sean probadas en uno o carios ambientes para que se asegure su compatibilidad. Estas pruebas toman en cuenta distintos puntos de la WebApp, a continuacin, algunos de ellos:

- Vnculos: El Ingeniero Web, debe de tener en cuenta, que al realizar una WebApp, de los vnculos que se incluyan en ella, deben de aparecer en un listado, para que, luego cada uno de ellos sea probado, con la finalidad de garantizar que todos ellos funcionen de manera correcta. - Formatos: Para el caso de formularios, se debe de tener en cuenta que, las etiquetas, identifican adecuadamente al campo al que estn referidos, se da a conocer cuales son los campos que son obligatorios, si estos poseen un ancho adecuado, adems se debe de tener en cuenta, que, si dado el caso, el usuario, no selecciona una opcin, la aplicacin toma un valor por defecto, y si se ingresa datos de manera errnea, la aplicacin es capaz de mostrar mensajes de error o no. - HTML dinmico: Tambin llamado DHTML, se debe tener en cuenta que, si en las pginas que forman parte de la WebApp se emple este, deben de ser probadas, con la finalidad de ver si es que en realidad, funciona de manera correcta. - Ventanas pop up: Llamadas tambin ventanas emergentes. Si en la WebApp, se ha hecho uso de ellas, se debe de tener en cuenta que, posean un tamao adecuado, de manera que no cubra por completo la interfaz al usuario, estas ventanas, deben de conservar el mismo estilo de diseo de la WebApp. - Cookies: Las cookies consisten en el almacenamiento de un fragmento de informacin en el disco duro de un usuario, esto con la finalidad de conseguir informacin acerca de los hbitos de los usuarios. Si en la WebApp, se ha hecho uso de estas, se deben de evaluar para garantiza que hayan sido construidas

107

adecuadamente, y ver si en realidad, cumple cabalmente la funcin para la cual fue construida. Aqu tambin se consideran las pruebas de facilidad de uso, las cuales generalmente se realizan tomando como referencia a los usuarios. Estas pruebas evalan el grado en el cual los usuarios pueden actuar interactivamente con la WebApp (Pressman, 2005).

En estas pruebas, se consideran aspectos como: la interactividad, referida a que, si para el usuario, son fciles de entender y/o usar los mens, etc.; la legibilidad, es decir, si lo que se le presenta al usuario en forma textual est escrito de manera adecuada y comprensible; si la esttica que ha sido empleada, hace sentir cmodo al usuario cuando emplea la WebApp. Y tambin si la WebApp, hace uso ptimo del tamao y resolucin de la pantalla (Pressman, 2005).

Pruebas a nivel de Componentes Llamadas tambin pruebas de funcin, se enfocan en un conjunto de pruebas que intentan descubrir errores en las funciones de la WebApp (Pressman, 2005). Estas pruebas, emplean los casos de prueba, con la finalidad de encontrar posibles errores, algunos de dichos casos, estn referidos a los formularios, los cuales, en estos se pretende saber cmo es que funcionarn una vez que es usuario selecciona una opcin, as como tambin si los campos que son mostrados estn validados de acuerdo al tipo de dato que admiten, as como tambin la longitud de ese dato. Pero tambin se emplean las pruebas que son llamadas de error forzado (Pressman, 2005), estas ultimas se refieren a ingresar datos incorrecto en la aplicacin de manera intencionada, con la finalidad de ver cmo es que responde esta aplicacin antes dichos datos ingresados.

Pruebas a nivel de Navegacin Este tipo de pruebas estn orientadas a garantizar que todas las opciones o rutas que se le ofrecen al usuario en la WebApp, estn correctamente elaboradas y funcionan perfectamente. As como tambin validar que cada unidad semntica de navegacin (USN) pueda ser alcanzada por la categora de usuario adecuada (Pressman, 2005).

Segn Splaine y Jaskiel, quienes son citados por Pressman, afirman que los mecanismos a probar aqu, son los siguientes:

108

- Vnculos de navegacin: Se prueban, tanto los vnculos internos a la WebApp, como los que son ajenos ella para garantizar su funcionalidad. - Redirigir: Consiste en que, si el usuario elije un vnculo que a sido removido o eliminado, sea informado de la situacin y automticamente sea redirigido a otra pgina, por ejemplo la pgina principal de la WebApp (Pressman, 2005). - Bookmarks: Se debe de asegurar que, el usuario al crear el Bookmark de la WebApp, se pueda extraer un ttulo para ella. - Mapa del sitio: En este punto, del mismo modo, se prueban los vnculos para garantizar su funcionalidad. - Motores de bsqueda internos: Generalmente, esta es caracterstica de algunas WebApps complejas, y se refieren a que, de acuerdo a algunas palabras claves, el usuario puede realizar bsquedas internas dentro de dicha WebApp. Pruebas a nivel de Configuracin: Estas pruebas se realizan con la finalidad de garantizar que el manejo que hagan los usuarios de la WebApp sea el mismo para todos, tratando de reducir el nmero de errores o inconvenientes que puedan surgir en particular, como es el caso de empleo de distintos navegadores, sistema operativo, etc.

Por el lado del servidor, en el se instala la WebApp, con la finalidad de comprobar si en realidad la soporta sin incurrir en errores, si es compatible con el sistema operativo del servidor, si las medidas de seguridad del sistema, permiten el acceso a los usuarios sin inconvenientes y adems para detectar posibles errores que se encuentren y repararlos inmediatamente, etc.

Mientras que por el lado de los usuarios, se evala la WebApp para comprobar su compatibilidad con los destinos de los usuarios, es decir, de acuerdo a la PC desde la que se conecten ellos, comprobar caractersticas de hardware, sistema operativo, software de navegacin, conectividad, etc. El lo que respecta a hardware, se comprueba compatibilidad de memoria, almacenamiento, etc.; respecto a sistemas operativos, pueden ser Linux, Macintosh, Microsoft Windows, etc.; de acuerdo a software de navegacin, pueden ser: Internet Explorer, Mozilla/Netscape, etc. y con respecto a la conectividad: Cable, DSL, mdem, etc. (Pressman, 2005)

109

Pruebas a nivel de Seguridad La seguridad es fundamental en las WebApps, generalmente se tiene mayor preocupacin por la parte del lado del usuario, pues generalmente, los llamados hackers, realizan maliciosamente ciertas acciones que ponen en peligro la WebApp, as como tambin pueden tener acceso a informacin no autorizada, por ejemplo a los cookies, de esta manera roban informacin de los usuarios, violando su privacidad y tomando sus identidades. De otro lado, se debe de garantizar seguridad en la transmisin o comunicacin de datos entre el servidor y usuario, estando seguro de que nadie ms puede interferir en esa situacin. Otro aspecto importante que se toma en cuenta en la seguridad, es que existen ciertas aplicaciones, creadas maliciosamente, con la finalidad de engaar al usuario, estas aplicaciones toman la apariencia de una determinada webApp, engaando de esta manera al usuario, estando este ltimo expuesto al robo de se sus contraseas, datos de tarjetas de crdito, etc.

Por estas y otras razones, se deben de implementar en el servidor, elementos de seguridad como: los cortafuegos, los cuales con utilizados para poder controlar la comunicacin, permitindola o no de acuerdo a las polticas de seguridad que se hayan establecido. Estos garantizan que el envo de datos lleg a una fuente legtima (Pressman, 2005); la autentificacin, la cual se refiere a la verificacin de usuarios, tanto del lado del usuario como del lado del servidor, de manera que, la comunicacin entre estos elementos se realice siempre y cuando ambas partes hayan sido autentificadas; el encriptado, que consiste en la proteccin de ciertos datos o informacin, mediante una codificacin, gracias a ella, personas no autorizadas, no podrn tener acceso a ella. El encriptado se fortalece empleando certificados digitales que permiten al cliente verificar el destino al cual se transmiten los datos (Pressman, 2005); y por ltimo, la autorizacin, la cual consiste en que, solo personas autorizadas podrn acceder a la WebApp por cualquiera de las 2 partes. Dicho acceso se da mediante el empleo de cdigos de autorizacin (Pressman, 2005).

Pruebas a nivel de Desempeo Las pruebas de desempeo, se realizan con la finalidad de hallar cuales son los problemas por los que la WebApp hace de manera lenta las tareas que debe de realizar. Los problemas por los que se pueden dar, pueden ser, por falta de recursos en el servidor como ancho de banda de red inapropiado, capacidades inadecuadas de bases de datos, defectuosas o dbiles capacidades del sistema operativo, funcionalidad WebApp mal diseada y otros conflictos de hardware o software pueden conducir a un pobre desempeo cliente servidor (Pressman, 2005).

110

Las pruebas de este tipo, pueden ser: pruebas de carga, las cuales tienen como propsito el de determinar cmo es que la WebApp responder a diversas situaciones en las que el acceso a ella por parte de los usuarios es relativamente alto.

La frmula por la que se calcula dicha situacin es la siguiente:

P = N xT x D
Donde: P indica la cantidad de informacin que es procesada en un instante dado. N es el nmero de usuarios concurrentes. T es el nmero de transacciones en lnea por usuario por unidad de tiempo. D es la carga de datos procesada por el servidor por transaccin.

Tambin tenemos las pruebas de tensin, las cuales se refieren a evaluar la WebApp en situaciones donde el acceso de usuarios es demasiado alto, estas pruebas buscan determinar que pasa con el servidor en estas situaciones, es decir si el servidor se desconecta cuando rebasa su capacidad, si muestra al usuario mensajes de no disponibilidad, si los datos se ven afectados por causa de dicho rebasamiento, si el sistema falla por causa de esto, que tiempo se demorar en recuperarse, etc. Las pruebas de tensin, tambin son llamadas pruebas pico/ rebote (Pressman, 2005) DISCUSIN

La realizacin de las pruebas a la WebApp de la USAT, a nivel de navegabilidad e interfaz de usuario, se realiz con el empleo de distintas herramientas de software, como LINKVIEWER 3.1 y XENU LINK SLEUTH.

XENU LINK SLEUTH, se us en este caso con la finalidad de verificar si en realidad todos los links de la WebApp de la USAT, funcionan de manera correcta. Se us este software, para verificar si en realidad, todos los links que posee la WebApp, funcionan, o si entre ellos existe algn o algunos enlaces rotos. Este software, mientras va verificando todos y cada una de los links, es capaz de proporcionar reportes de todos las pginas que fueron escaneadas.

LINKVIEWER 3.1, se us con la finalidad de proporcionar, respecto a la WebApp de la USAT, la estructura en forma de rbol que esta posee, dando a conocer cuales son los

111

links internos y externos que posee esta WebApp. Este software, es considerado un analizador de Webs. En el que se obtienen mapas grficos de un determinado sitio Web.

Para el caso de la interfaz de usuario, con XENU LINK SLEUTH, se obtuvo el listado de la totalidad de enlaces que posee la WebApp de la USAT, en dicho listado, se resalta la diferencia entre los que son funcionales, as como los que no son funcionales (enlaces rotos).

Los enlaces no funcionales (error code 404: no found) o tambin llamados enlaces rotos, encontrados en la WebApp de la USAT, suman un nmero de 26 enlaces, los cuales son dados a conocer en el anexo N 01

En el caso de los enlaces movidos permanentemente (status code 301: object permanently moved), fueron hallados 13 enlaces. Los cuales son mostrados en el anexo N 02.

Por ltimo, para el caso de los enlaces movidos temporalmente (status code: 302: object temporarily moved), se encontraron 31 enlaces, los cuales son dados a conocer en el anexo N 03

A manera de resumen, se presenta la siguiente tabla, donde se muestra el nmero de enlaces encontrados, de acuerdo al estado en el que se encuentran:

Tabla N 01: Nmero de enlaces encontrados de acuerdo al estado en el que se encuentran Enlaces Cantidad Enlaces rotos (Error code 404) 26 Enlaces permanentemente movidos(Error code 404) Enlaces temporalmente movidos(Error code 404) Total Fuente: Elaboracin propia 13 31 70

Para el caso de las pruebas de navegabilidad, se utiliz el Software LINKVIEWER 3.1, el que nos brinda, de manera grfica (en forma de rbol), toda la distribucin de la WebApp de la USAT, siendo esta la siguiente:

112

Figura N 02: Estructura en rbol de la WebApp de la USAT.

En la figura N 02, se muestra la distribucin de vnculos que existen en la pgina principal de la USAT, como vemos, existen enlaces sombreados de rojo, los cuales indican los enlaces rotos que se encuentran en la pgina principal del a USAT. Siguiendo con la distribucin de vnculos de la pgina principal, tenemos que, del vnculo Biblioteca USAT, se desprende una serie de vnculos que se relacionan de manera indirecta o secundaria con la pgina principal. Dichos vnculos son mostrados en la figura N 03

Figura N 03: Estructura en rbol del vnculo Biblioteca USAT.

Al igual que el caso anterior, del vnculo USAT, que se refiere a proyeccin social, se desprenden 3 vnculos, los cuales son mostrados en la figura N 04.

113

Figura N 04: Estructura en rbol del vnculo Proyeccin Social.

114

De la pgina principal, se desprende el vnculo de Postgrado, el cual a su vez, contiene a otros 3 ms, los cuales son mostrados en la figura N 05

Figura N 05: Estructura en rbol del vnculo Postgrado.

Del mismo modo que los casos anteriores, tenemos al vnculo denominado Bienvenidos al Instituto Mayorga, en este vnculo se encuentran otros 5 ms, los cuales son dados a conocer en la figura N 06.

Figura N 06: Estructura en rbol del vnculo Bienvenidos al Instituto Mayorga.

115

De la pgina principal, se desprende el vnculo referido a publicaciones, dicho vnculo, en el software utilizado, tambin tomo el nombre de USAT, en el cual existen 3 vnculos ms que se relacionan de manera secundaria con la pgina principal, los cuales son mostrados en la figura N 07.

Figura N 07: Estructura en rbol del vnculo Publicaciones.

Del vnculo denominado Carreras, nacen otros 3 vnculos ms, los cuales son mostrados en la figura N 08.

Figura N 08: Estructura en rbol del vnculo Carreras.

116

Del mismo modo, en el vnculo denominado Campus Virtual, se desprende una serie de 6 vnculos, entre ellos, notamos uno sombreados de color rojo, el cual es un vnculo externo a la WebApp, como se muestra en la figura N 09.

Figura N 09: Estructura en rbol del vnculo Campus Virtual.

Al igual que un caso de los anteriores, el vnculo de Investigacin, adopt el nombre de USAT, el cual se relaciona de manera directa con otros 3 vnculos ms, como se muestra en la figura N 10.

Figura N 10: Estructura en rbol del vnculo Investigacin.

117

De igual manera, notamos que el vnculo denominado Servicios, se relaciona de manera directa con otros 3, como se da a conocer en la figura N 11.

Figura N 11: Estructura en rbol del vnculo Servicios.

Del vnculo denominado Noticias USAT 2007, se desprende un par de vnculos, los cuales son mostrados en la figura N 12.

Figura N 12: Estructura en rbol del vnculo Noticias USAT 2007.

118

Por ltimo, tenemos al vnculo denominado Admisin, este vnculo se relaciona de manera directa con otros 3 vnculos mas, como de detalla en la figura N 12.

Figura N 13: Estructura en rbol del vnculo Admisin.

119

CONCLUSIONES

De acuerdo al trabajo elaborado, se llega a las siguientes conclusiones:

Si bien, las aplicaciones Web, tienen por finalidad hacer que el usuario se sienta cmodo emplendolas siendo estas de fcil manejo, es indispensable que, antes de poner en funcionamiento o implementar una aplicacin de este tipo, se realicen distintas pruebas que garanticen la calidad que debe de poseer, siendo esta una aplicacin confiable y segura para los usuarios.

La realizacin de todas las pruebas a una aplicacin Web, es indispensable, en todos los sentidos, pues estas ayudan a ofrecer una aplicacin que se desempea ptimamente, siendo el usuario y la empresa que la gestiona, los ms beneficiados, ya que si se implementa una aplicacin Web, que funcionalmente no es buena, no tendr mayor aceptacin por los usuarios.

Respecto a la evaluacin realizada a la WebApp de la USAT, como vemos, se ha encontrado un nmero regular de enlaces rotos, los cuales llevan al usuario a un sitio Web que no existe. Errores como estos, deben de ser solucionados, para que, tanto a nivel de navegabilidad e interfaz de usuario, se garantice el buen funcionamiento de esta aplicacin.

Como recomendaciones finales, se debe de tener en cuenta, ms que nada a los enlaces rotos que posee la WebApp de la USAT, descritos en este trabajo, para que sean corregidos en esta aplicacin, todo esto, para que la aplicacin Web, vista desde la parte esttica funcionalmente sea ptima a todos los usuarios que puedan visitarla, de esta manera, la empresa, en este caso la universidad se ver en parte beneficiada.

120

BIBLIOGRAFA

Castejn G, Juan 2004. Arquitectura y diseo de sistemas Web modernos.

Cortazar R; Perallos A and Vzquez I. 2001 Desarrollo de una Metodologa de Validacin de Aplicaciones Internet. Bilbao

Daz M. Paloma. 2005. Ingeniera de la Web y Patrones de Diseo. Madrid - Pearson. Educacin.

Gamboa R, F. 2001. Diseo y evaluacin de aplicaciones interactivas ergonmicas. Mxico.

Guerrero L. 2003. Modelando Interfaces para Aplicaciones Web. Chile

Guillermo COVELLA, G. 2005. Medicin y Evaluacin de Calidad en Uso de Aplicaciones Web. Argentina. Tesis de Doctor Ciencias. Universidad Nacional de la Plata. Argentina. 274pp.

Lafuente, G and Olsina, L. 2001. Catalogando Mtricas Web. Argentina.

Lpez A, A. 2004. Gisweb: Reingeniera para la implementacin de un Web Feature Service. Mexico.

Mateu, Carles. 2004. Desarrollo de Aplicaciones Web. Barcelona

Mndez Pozo, G. 2001. Construccin de Aplicaciones Web con UML. Mxico.

Olsina, Lus. 1999. Metodologa Cuantitativa para la Evaluacin y Comparacin de la Calidad de Sitios Web. Argentina

121

Pressman, Roger. 2005. Ingeniera del software: Enfoque Prctico. Mxico: McGraw Hill Interamericana.

Pressman, Roger. 2002. Ingeniera del software: Enfoque Prctico. Mxico: McGraw Hill Interamericana.

Ramos A. Benjamn. Rivagorda. 2004. G. Arturo. Avances en criptologa y seguridad de la informacin. Madrid - Daz de Santos

Gonzles, C. Evaluacin de calidad Web: Mtodos, tcnicas y uso de mtricas de usabilidad.

122

ANEXOS

Anexo N 01 Listado de enlaces rotos de la WebApp de la USAT (error code: 404)

1. http://cervantesvirtual.com/portal/Platero/

http://www.cervantesvirtual.com/portal/Platero/
2. http://usuarios.lycos.es/deuntiron/

http://www.tripod.lycos.es/error/404.phtml
3. http://www.grupobuho.com/gbsite/modules.php?op=modload&name=Publications&file=in

dex&secid=3 http://www.grupobuho.es/blog/gbsite/modules.php?op=modload&name=Publications &file=index&secid=3

4. http://www.um.es/~depmide/mur2000/competen.doc

http://www.um.es/depmide/mur2000/competen.doc
5. http://www.usat.edu.pe/biblioteca_/linksbiblioteca.htm

http://www.usat.edu.pe/biblioteca_/images/cabecera.jpg http://site.ebrary.com/lib/usatsp
6. http://www.usat.edu.pe/carreras1/educacion/area_cientifica.htm

http://www.tdx.cesca.es/index_tdx.html http://www.comie.org.mx/revista.htm http://revista.iimec.ucr.ac.cr/index1.htm http://www.huascaran.edu.pe/investigadores/sitios_investigacion.htm http://www.upnqueretaro.edu.mx/biblioteca/InvestigacionEducativa/indice.htm http://www.idrc.ca/socdev/pub/pizarro/pizarro.html http://www.campus-oei.org/revista/deloslectores/054Ancizar.PDF http://www.mty.itesm.mx/dhcs/hiper-textos/num2gomez.html http://www.reduc.cl/aula/genfoque.pdf http://csociales.uchile.cl/publicaciones/enfoques/02/edu13.htm http://www.universia.edu.pe/contenidos/formacion/bibliotecas/digital_bib.zhtml http://descartes.cnice.mecd.es/Bach_HCS_2/inferencia_estadistica/index_inferencia. htm http://www.huascaran.edu.pe/investigadores/encuesta_nacional.htm http://www.huascaran.edu.pe/investigadores/conocimientos_educacion.htm

123

7. http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm

http://www.bne.es/esp/bidigital.htm http://www.bibliele.com/cilht.htm http://www.ih.csic.es/departamentos/medieval/fmh/ http://www.weblaopera.com/libretos/libretos.htm http://www.arrakis.es/~trazeg/index.html http://www.geocities.com/Athens/Forum/6413/leyendas/leyendas.html http://www.tele-vicio.com/scripts/70/ficcion/index.asp?tipo=cuentos

Anexo N 02 Listado de enlaces permanentemente movidos (Status code: 301)

1. http://www.macromedia.com/go/getflashplayer

Redirigido a:

http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Ver sion=ShockwaveFlash 2. http://olam.ed.asu.edu/epaa/v10n13.html Redirigido a: http://epaa.asu.edu/epaa/v10n13.html

3. http://miarroba.com/foros/ver.php?foroid=787948

Redirigido a: dex&secid=3 Redirigido a:

http://ignoria.mforos.com/

4. http://www.grupobuho.com/gbsite/modules.php?op=modload&name=Publications&file=in

http://www.grupobuho.es/blog/gbsite/modules.php?op=modload&name= Publications&file=index&secid=3 5. http://www.itacab.org/crystal-andino Redirigido a: http://www.itacab.org/crystal-andino/

6. http://www.clarin.com.ar/pbda/

Redirigido a:

http://www.clarin.com/pbda/

7. http://www.uni-mainz.de/~lustig/texte/antologia/antologi.htm

Redirigido a:

http://www.staff.uni-mainz.de/lustig/texte/antologia/antologi.htm

8. http://www.intratext.com/ESL

Redirigido a:

http://www.intratext.com/ESL/

9. http://www.cinefantastico.com/terroruniversal/ficcion

124

Redirigido a:

http://www.cinefantastico.com/terroruniversal/ficcion/

10.http://www.gutenberg.net/

Redirigido a:

http://www.gutenberg.org/

11.http://www.loscuentos.net/

Redirigido a:

http://www4.loscuentos.net/

12.http://www.gutenberg.org/

Redirigido a:

http://www.gutenberg.org/wiki/Main_Page

13.http://www.iespana.es/gramaticas/

Redirigido a:

http://gramaticas.iespana.es/ Anexo N 03

Listado de enlaces temporalmente movidos (Status code: 302)

1. http://www.elcomercioperu.com.pe/ Redirigido a: http://www.elcomercio.com.pe/ Vinculado de la pgina: http://www.usat.edu.pe/usat2007.htm 2. http://www.usat.edu.pe/english Redirigido a: http://www.usat.edu.pe/english/ Vinculado de la pgina: http://www.usat.edu.pe/usat2007.htm 3. http://www.usat.edu.pe/campusvirtual Redirigido a: http://www.usat.edu.pe/campusvirtual/ Vinculado de las pginas: http://www.usat.edu.pe/usat2007.htm http://www.usat.edu.pe/avances/agrocadenas/ http://www.usat.edu.pe/avances/agrocadenas/Convenio.html 4. http://www.usat.edu.pe/im Redirigido a: http://www.usat.edu.pe/im/ Vinculado de la pgina: http://www.usat.edu.pe/usat2007.htm 5. http://www.usat.edu.pe/avances/agrocadenas Redirigido a: http://www.usat.edu.pe/avances/agrocadenas/ Vinculado de la pgina:

125

http://www.usat.edu.pe/postgrado/detalle.htm 6. http://www.elcomercio.com.pe/ Redirigido a: http://www.elcomercio.com.pe/online/ Vinculado de la pgina: http://www.elcomercioperu.com.pe/ 7. http://www.elcomercio.com.pe/online/ Redirigido a: http://www.elcomercio.com.pe/ediciononline/ Vinculado de la pgina: http://www.elcomercio.com.pe/ 8. http://www.usat.edu.pe/turismo Redirigido a: http://www.usat.edu.pe/turismo/ Vinculado de la pgina: http://www.usat.edu.pe/postgrado/detalle.htm 9. http://www.usat.edu.pe/admision/inscripcion2006_2 Redirigido a: http://www.usat.edu.pe/admision/inscripcion2006_2/ Vinculado de la pgina: http://www.usat.edu.pe/admision/examen.htm 10. http://www.um.es/~depmide/mur2000/competen.doc Redirigido a: http://www.um.es/depmide/mur2000/competen.doc Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/area_cientifica.htm 11. http://www.sepyc.gob.mx/IVcongreso/IVcongreso.html http://guide.opendns.com/?url=www.sepyc.gob.mx%2FIVcongreso%2FIVcon Redirigido a: greso.html&servfail Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/area_cientifica.htm 12. http://search.ebscohost.com/ Redirigido a: http://search.ebscohost.com/Login.aspx?lp=login.asp&ref=&authtype=ip,uid Vinculado de las pginas: http://www.usat.edu.pe/biblioteca_/linksbiblioteca.htm http://www.usat.edu.pe/biblioteca_/index.html 13. http://www.georgetown.edu/labyrinth/library/latin/latin-lib.html http://www8.georgetown.edu/departments/medieval/labyrinth/library/latin/latin Redirigido a: -lib.html Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm

126

14. http://laurencio.webz.cz/mongolxel/toli/ulger/ Redirigido a: http://i.wz.cz/404.html Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 15. http://prodigi.bl.uk/gutenbg/default.asp Redirigido a: http://www.bl.uk/treasures/gutenberg/homepage.html Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 16. http://webs.demasiado.com/papiro/Egipto2.html Redirigido a: http://club.telepolis.com/error/error_telepolis.htm Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 17. http://cervantesvirtual.com/bib_voces/bibvoces.shtml Redirigido a: http://www.cervantesvirtual.com/bib_voces/bibvoces.shtml Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 18. http://ensayo.rom.uga.edu/antologia/ Redirigido a: http://www.ensayistas.org/oldensayo.html Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 19. http://redie.ens.uabc.mx/ Redirigido a: http://redie.uabc.mx/index.html Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/area_cientifica.htm 20. http://www.le-chateau.ilias.com/ Redirigido a: http://guide.opendns.com/?url=www.le-chateau.ilias.com Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 21. http://www.ciberoteca.com/ Redirigido a: http://www.ciberoteca.com/homecas.asp Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 22. http://www.cinefania.com/ficcion/

127

Redirigido a:

http://www.cinefantastico.com/terroruniversal/ficcion

Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 23. http://www.wordtheque.com/owawt/new_wordtheque.wcom_literature.literaturea_page?lang=ES&letter=A&source= search&page=1 http://www.logoslibrary.eu/pls/wordtc/new_wordtheque.wcom_literature.literat Redirigido a: urea_page?lang=ES&letter=A&source=search&page=1 Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 24. http://escolar.com/cgi-bin/php4/download.php Redirigido a: http://www.escolar.com/index11.php Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 25. http://phcuentos.chuynet.com/ Redirigido a: http://guide.opendns.com/?url=phcuentos.chuynet.com Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 26. http://xoomer.virgilio.it/caballero.ilustrado/ Redirigido a: http://xoomer.alice.it/caballero.ilustrado/ Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 27. http://cervantesvirtual.com/ Redirigido a: http://www.cervantesvirtual.com/index.jsp Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 28. http://usuarios.lycos.es/deuntiron/ Redirigido a: http://www.tripod.lycos.es/error/404.phtml Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 29. http://cervantesvirtual.com/portal/Platero/ Redirigido a: http://www.cervantesvirtual.com/portal/Platero/ Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm 30. http://redie.uabc.mx/index.html

128

Redirigido a:

http://redie.uabc.mx/vol9no2/contenido-contenido.html

Vinculado de la pgina: http://redie.ens.uabc.mx/ 31. http://ensayo.rom.uga.edu/index-sp.html Redirigido a: http://www.ensayistas.org/oldensayo.html Vinculado de la pgina: http://www.usat.edu.pe/carreras1/educacion/bibliotecapublica.htm

129

MEJORAS PARA LA ADAPTACIN DE REQUISITOS EN LA WEB6

INTRODUCCIN En los ltimos aos ha ganado reconocimiento la importancia de la ingeniera de requisitos y los riesgos en que se incurren si sta es realizada en forma incompleta o incorrecta. El tratamiento de requisitos es el proceso mediante el cual se especifican y validan los servicios que debe proporcionar el sistema as como las restricciones sobre las que se deber operar. Consiste en un proceso iterativo y cooperativo de anlisis del problema, documentando los resultados en una variedad de formatos y probando la exactitud del conocimiento adquirido. La importancia de esta fase es esencial puesto que los errores ms comunes y ms costosos de reparar, as como los que ms tiempo consumen se deben a una inadecuada ingeniera de requisitos. Actividades propias de esta rea, como la captura de requisitos del usuario, la especificacin de requisitos o la validacin de los mismos, son algunas de las consideradas ms crticas en el desarrollo y la produccin del software. Estas actividades tienen por objetivo la determinacin de las necesidades del sistema, la adquisicin por parte del equipo de desarrollo de la informacin necesaria para desarrollar un producto de calidad y en definitiva, la comunicacin inicial entre el grupo de expertos y los clientes y usuarios. La ingeniera de requisitos es un tema complejo y crucial para el xito de todo el proyecto de ingeniera del software. Las aplicaciones en el entorno de la web no son una excepcin. Sin embargo, las propuestas metodolgicas para el desarrollo de aplicaciones web contemplan el tema de ingeniera de requisitos con distinto grado de profundidad y proponen el uso de diferentes tcnicas. Este proyecto de investigacin tiene como fin dar a conocer de qu manera se puede mejorar el proceso e requisitos para la web, basndose en metodologas propuestas por un estudio realizado anteriormente

Faya Nishiyama, Nelly Victoria

130

ANTECEDENTES DE LA INVESTIGACION De temas similares al presente trabajo de investigacin no existen, existe bibliografa referente a ingeniera de requisitos, a la obtencin de los requisitos y tambin sobre ingeniera web. Se tomarn en cuenta aquella bibliografa que tenga mucho que ver con la obtencin de requisitos y sobre las webs y las WebApps MARCO TERICO INGENIERA DE REQUISITOS Generalmente la Ingeniera de Requisitos es un tema muy amplio y complejo, pero para el desarrollo de este presente trabajo de investigacin hablaremos brevemente de este tema, recopilando solo la informacin necesaria para el trabajo de investigacin. 1.1.- Breve Descripcin Bsicamente se puede definir a la Ingeniera de Requisitos como el proceso de establecimiento de los servicios que debe proporcionar un sistema, as como tambin las restricciones con la que debe operar; se encarga de comprender las necesidades de los clientes, saber que es lo quieren para el software claro tambin hay mucha probabilidad que estas necesidades o requisitos cambien durante todo el proyecto. El IEEE define a la Ingeniera de Requisitos como:el proceso de estudio de las necesidades de los usuarios con el objeto de llegar a una definicin del sistema (hardware y software) y como el proceso de estudio y refinamiento del sistema. La Ingeniera de Requisitos debe adaptarse a las necesidades del proceso, el proyecto, el producto y las personas que realizan el trabajo, es una accin de la Ingeniera de Software que comienza durante la actividad de comunicacin y contina en la actividad de modelado. Es primordial que el equipo de software haga un esfuerzo real para poder entender los requisitos de un problema antes de intentar resolverlo 1.2.- Definicin de Requisito Un requisito es una condicin o aptitud necesaria para resolver un problema o alcanzar un objetivo. El IEEE define a los requisitos como una condicin que debe proporcionar un sistema o algunos de sus subsistemas para poder satisfacer un contrato, norma, especificacin, o cualquier otra condicin impuesta formalmente a travs de un documento. Existen dos tipos de requisitos primordiales: a) Funcionales, describen los servicios o funciones del sistema b) No funcionales, describen las restricciones del sistema o del proceso de desarrollo (prestaciones, interfaces, atributos de calidad, entre otros).

131

Para poder comenzar con toda la recopilacin de los requisito es necesario que se empiece por los participantes del proyecto (gerentes, clientes, usuarios finales), donde se definen las necesidades del negocio, adems se describen los escenarios de los usuarios, se definen las caractersticas y funciones, y por ltimo se identifica todas las restricciones del proyecto. 1.3.- Tareas Bsicas de la Ingeniera de Requisitos Resumiendo la funcin de la Ingeniera de Requisitos se dice que proporciona el mecanismo mas adecuado para poder entender lo que el cliente desea, evaluar la factibilidad, negociar una solucin razonable, especificar la solucin sin ambigedades, validar la especificacin y administrar los requisitos conforme stos se transforman en un sistema operacional. Las tareas bsicas son: a) Inicio: Se recomienda reunirse con los clientes para poder definir la idea del software y poder programar una serie de reuniones para realizar cambios si as fuera necesario. Esta tarea tiene como objetivo establecer una comprensin bsica del problema, las personas que quieren la solucin y sobretodo crear un buen lazo de comunicacin entre el cliente y el desarrollador. b) Obtencin: Se necesita saber los objetivos del sistema, que es lo que se debe lograr, de que manera, cuales son las necesidades y como se utilizar este sistema; pero toda esta informacin es exacta si se tiene en cuenta que los requisitos estn bien definidos, que no sean requisitos innecesarios, los clientes deben saber cuales son las capacidades y limitaciones de un ambiente de computo, los requisitos deben ser bastante descriptivos porque no existe una funcin que sea obvia. Es muy importante tener en cuenta que los requisitos son muy cambiantes a lo largo del desarrollo del software. c) Elaboracin: Se enfoca en el desarrollo de un modelo tcnico refinado de las funciones, caractersticas y restricciones del software; es una accin de modelado del anlisis que se compone de una serie de tareas de modelado y refinamiento. La elaboracin se conduce mediante la creacin y refinamiento de escenarios del usuario que describen la forma en la que el usuario final interactuarn con el sistema. Despus de haber aplicado la elaboracin se define el dominio de la informacin, las funciones y comportamiento del problema. d) Negociacin: Es muy comn que los clientes sugieran o exijan ms de lo que se puede lograr, por ello es necesario negociar los requisitos que se puede agregar y cuales no. Para ello es necesario que los clientes y usuarios finales deban realizar una lista con los requisitos que tienen en mente para despus ordenndolos por prioridad y analizar los riesgos que pueden traer cada requisito. Despus de haber realizado todo lo anteriormente dicho los requisitos se eliminan, combinan o modifican de forma que cada parte (clientes, usuarios finales) tengan cierto grado de satisfaccin. e) Especificacin: es el producto del trabajo final que genera todo el proceso de la Ingeniera de Requisitos. Esta sirve como base para las actividades 132

siguientes, es necesario ser flexible al momento que se desarrolla una especificacin. Bsicamente una especificacin describe la funcin y el desempeo de un sistema basado en una computadora y las restricciones que existen en su desarrollo. f) Validacin: Permite examinar la especificacin para asegurar que todos los requisitos de software se han establecido de manera precisa. El mecanismo primordial es la revisin tcnica formal, todos los miembros del equipo examinan la especificacin y buscan posibles errores. Pulen reas que requieran clarificacin, agregan informacin, solucionan posibles conflictos entre los requisitos. g) Gestin de Requisitos: se define como un conjunto de actividades que ayudan al equipo del proyecto identificar, controlar y rastrear los requisitos y cambio a stos en cualquier momento mientras se desarrolla el proyecto. La gestin de requisitos se inicia con la identificacin de los requisitos, una vez identificados se realizan una serie de tablas de rastreabilidad, entre las tablas ms usadas tenemos: o Tabla de rastreabilidad de las caractersticas, muestran la manera en que los requisitos se relacionan con las caractersticas del sistema. o Tabla de rastreabilidad de la fuente, identifica la fuente de cada requisito. o Tabla de rastreabilidad de dependencia, indica la forma en que los requisitos estn relacionados entre s. o Tabla de la rastreabilidad del subsistema, establece categoras entre los requisitos de acuerdo con el subsistema que gobierna. o Tabla de la rastreabilidad de la interfaz, muestra la forma en que los requisitos se relacionan con las interfaces del sistema. 1.4.-Proceso de Requisitos Es un conjunto estructurado de actividades que sirven para derivar, validar y mantener los requisitos de un sistema (hardware, software o hardware + software) el equipo de software se ve obligado a trabajar dentro de las restricciones que impone cada situacin. Se pueden dar diferentes variaciones en el proceso, ya sea segn la naturaleza del proyecto (dirigido a mercado, a medida), o segn la naturaleza de la aplicacin (riesgo, recursos, incertidumbre, sistemas empotrados). Los posibles problemas en el proceso son si: El proceso de requisitos es excesivamente largo y costoso. Los implicados en el proceso se quejan de falta de tiempo y otros recursos. Se reciben quejas acerca de la inteligibilidad del documento de requisitos.

133

Los implementadores se quejan del trabajo perdido por culpa de errores en los requisitos. Los usuarios no utilizan muchas de las capacidades del sistema. En cuanto el producto se entrega, se recibe una inmensa cantidad de solicitudes de cambios. Lleva demasiado tiempo alcanzar un acuerdo cuando se proponen cambios a los requisitos. 1.4.1.- Identificacin de mltiples puntos de vista Debido a la gran diversidad de clientes, los requisitos se analizaran desde diferentes puntos de vista. Por ejemplo, los gerentes de negocios estn interesados en un grupo de caractersticas, los usuarios finales pueden desear caractersticas con las que estn familiarizados. Los ingenieros de software quizs estn interesados en funciones que del el soporte de la infraestructura y caractersticas ms accesible. Como paso final se debe categorizar toda la informacin de tal manera que permita a los encargados de tomar las decisiones elegir un conjunto de requisitos para que el sistema sea consistente de manera interna. 1.4.2.- Formulacin de Preguntas Iniciales Para tener una obtencin de requisitos eficiente, es necesario realizar preguntas como: Qu est detrs de la solicitud de este trabajo?, Quin usar la solucin?, Cul ser el beneficio econmico de una solucin exitosa?, Existe otra fuente para la solucin requerida? Despus de haber realizado estas preguntas se pobra identificar el beneficio medible de una implementacin exitosa y las posibles alternativas posibles para poder personalizar el desarrollo del software, debido a que los requisitos pueden ir cambiando a lo largo de la duracin del proyecto. 1.4.3.- Obtencin o Captura de Requisitos Se refiere a la captura y descubrimiento de los requisitos. Es una actividad ms humana que tcnica. Se identifica a los interesados (stakeholders) y se establecen las primeras relaciones entre ellos y el equipo de desarrollo. Es la actividad mediante la que el equipo de desarrollo de un sistema de software extrae, de cualquier fuente de informacin disponible, las necesidades que debe cubrir dicho sistema (Escalona, 2006). El proceso de captura de requisitos puede resultar complejo, principalmente si el entorno de trabajo es desconocido para el equipo de analistas, y depende mucho de las personas que participen en l. Por la complejidad que todo esto puede implicar, la Ingeniera de Requisitos ha trabajado desde hace aos en desarrollar tcnicas que permitan hacer este proceso de una forma ms eficiente y precisa. Han sido utilizadas para esta actividad en el proceso de desarrollo de todo tipo de software. 134

a) Entrevistas: Resultan una tcnica muy aceptada dentro de la Ingeniera de Requisitos y su uso est ampliamente extendido. Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solucin buscada. A travs de esta tcnica el equipo de trabajo se acerca al problema de una forma natural. Existen muchos tipos de entrevistas y son muchos los autores que han trabajado en definir su estructura y dar guas para su correcta realizacin. Bsicamente, la estructura de la entrevista abarca tres pasos: identificacin de los entrevistados, preparacin de la entrevista, realizacin de la entrevista y documentacin de los resultados (protocolo de la entrevista). A pesar de que las entrevistas son esenciales en el proceso de la captura de requisitos y con su aplicacin el equipo de desarrollo puede obtener una amplia visin del trabajo y las necesidades del usuario, es necesario destacar que no es una tcnica sencilla de aplicar. Requiere que el entrevistador sea experimentado y tenga capacidad para elegir bien a los entrevistados y obtener de ellos toda la informacin posible en un perodo de tiempo siempre limitado. Aqu desempea un papel fundamental la preparacin de la entrevista. b) Tormenta de ideas: Es tambin una tcnica de reuniones en grupo cuyo objetivo es que los participantes muestren sus ideas de forma libre. Consiste en la mera acumulacin de ideas y/o informacin sin evaluar las mismas. El grupo de personas que participa en estas reuniones no debe ser muy numeroso (mximo 10 personas), una de ellas debe asumir el rol de moderador de la sesin, pero sin carcter de controlador. Como tcnica de captura de requisitos es sencilla de usar y de aplicar, puesto que no requiere tanto trabajo en grupo como ste. Adems suele ofrecer una visin general de las necesidades del sistema, pero normalmente no sirve para obtener detalles concretos del mismo, por lo que suele aplicarse en los primeros encuentros. c) Reuniones: Para realizar una reunin productiva es necesario tener en cuenta detalles como: las reuniones deben estar dirigidas por alguno de los asistentes al cual se le denomina moderador y su funcin es dirigir la reunin, se deben de establecer reglas para la preparacin y la participacin, se sugiere organizar la agenda para que se pueda cubrir con todos los puntos importantes, es importante utilizar un mecanismo de definicin (el uso de hojas de trabajo, grficos, foro virtual, entre otros). La meta de la realizacin de reuniones es poder identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto de requisitos de solucin preliminares que conduzca al cumplimiento del objetivo principal. La meta de la reunin es permitir que cada asistente haga una lista de objetos que son parte de su entorno, que objetos utiliza para su trabajo, entre otros, aparte se preparan listas de las restricciones que tendr el sistema (costo, tamao, reglas de negocio) adems de los criterios de rendimiento como la velocidad del proceso. Cuando se inicia una reunin para poder recopilar los documentos, se debe determinar cual es la necesidad y la justificacin para el nuevo producto todos los miembros asistentes a la reunin deben estar de acuerdo en que la necesidad del producto se debe justificar. Para tener una lista con todos los 135

requisitos necesarios se debe debatir las listas propuestas, ya sea por medio de una votacin o un foro virtual; una vez elaborado las listas combinadas de todas las reas se debe comenzar a depurar o agregar requisitos para reflejar de manera apropiada el producto que se requiere. El objetivo de esta etapa es desarrollar una lista consensada en el rea de cada tpico (objetos, servicios, restricciones y rendimiento. d) JAD (Joint Application Development / Desarrollo Conjunto de Aplicaciones): Esta tcnica resulta una alternativa a las entrevistas. Es una prctica de grupo que se desarrolla durante varios das y en la que participan analistas, usuarios, administradores del sistema y clientes. Est basada en cuatro principios fundamentales dinmica de grupo, el uso de ayudas visuales para mejorar la comunicacin, mantener un proceso organizado y racional y una filosofa de documentacin WYSIWYG (What You See Is What You Get, lo que ve es lo que obtiene), es decir, durante la entrevista se trabajar sobre lo que se generar (Escalona y Koch 2006). Tras una fase de preparacin del JAD al caso concreto, el equipo de trabajo se rene en varias sesiones. En cada una de ellas se establecen los requisitos de alto nivel a trabajar, el mbito del problema y la documentacin. Durante la sesin se discute en grupo sobre estos temas llegndose a una serie de conclusiones que se documentan. En cada sesin se van concretando ms las necesidades del sistema. Esta tcnica presenta una serie de ventajas frente a las entrevistas tradicionales ya que ahorra tiempo al evitar que las opiniones de los clientes se tengan que contrastar por separado. Pero requiere un grupo de participantes bien integrados y organizados. e) Casos de Uso: Aunque inicialmente se desarrollaron como tcnica para la definicin de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como tcnica para la captura de requisitos. Los casos de uso permiten mostrar el contorno (actores) y el alcance (requisitos funcionales expresados como casos de uso) de un sistema. Un caso de uso describe la secuencia de interacciones que se producen entre el sistema y los actores del mismo para realizar una determinada funcin. Los actores son elementos externos (personas, otros sistemas, etc.) que interactan con el sistema como si de una caja negra se tratase. Un actor puede participar en varios casos de uso y un caso de uso puede interactuar con varios actores. La ventaja esencial de los casos de uso es que resultan muy fciles de entender para el usuario o cliente, sin embargo carecen de la precisin necesaria si no se acompaan con una informacin textual o detallada con otra tcnica como pueden ser los diagramas de actividades (UML, 2001).

Otras tcnicas de obtencin o captura de requisitos: Preliminares: Utilizar preguntas libres de contexto. Reunin de de Reflexin (Brainstorming): Seleccionar un grupo variado de participantes. Eliminar crticas, juicios y evaluaciones mientras los participantes sugieren ideas. Producir muchas ideas. Recogerlas todas por escrito. Otro da, en otra sesin, se evalan las ideas (se puntan). 136

Observacin y anlisis de tareas: Un observador estudia a los futuros usuarios en su entorno de trabajo. A veces se utiliza el video. Anota todo aquello que es susceptible de mejora. Posteriormente, genera una serie de requisitos tentativos. Prototipado: tiles cuando la incertidumbre es total acerca del futuro sistema. Hay dos tipos principales: evolutivo y de usar y tirar.

1.4.4.- Anlisis de Requisitos Consiste en detectar y resolver conflictos entre requisitos. Se precisan los lmites del sistema y la interaccin con su entorno. Se trasladan los requisitos de usuario a requisitos del software. En el anlisis de requisitos se realizan tres tareas fundamentales: 1. Clasificacin: En funcionales vs. no funcionales (Capacidades vs. Restricciones). Por prioridades. Por coste de implementacin. Por niveles (alto nivel, bajo nivel). Segn su volatilidad/estabilidad. Si son requisitos sobre el proceso o sobre el producto. 2. Modelizacin Conceptual: Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interaccin, de objetos, etc. La meta es entender mejor el problema, ms que iniciar el diseo de la solucin (idealmente). El tipo de modelo elegido depende de la naturaleza del problema, la experiencia del modelizador, y de la disponibilidad de herramientas. Por decreto el cliente impone una notacin. 3. Negociacin: En todo proceso de Ingeniera de Requisitos intervienen distintos individuos con distintos y, a veces, enfrentados intereses. Estos conflictos entre requisitos se descubren durante el anlisis. El conflicto no es rechazable, pues los conflictos son fuente de nuevos requisitos.

137

Los conflictos nunca se deben resolver por decreto, sino mediante un proceso de negociacin. 1.4.5.- Gestin de Requisitos Consiste en gestionar los cambios a los requisitos. Asegura la consistencia ente los requisitos y el sistema construido (o en construccin). Consume grandes cantidades de tiempo y esfuerzo. Durante el proceso de software la compresin del problema por parte de los stakeholders esta cambiando constantemente. Estos requerimientos deben entonces evolucionar para reflejar esta experiencia con un sistema, descubren nuevas necesidades y prioridades: Los sistemas grandes tienen una comunidad de usuarios diversos donde los usuarios tienen diferentes requerimientos y prioridades. Los clientes del sistema imponen requerimientos debido a las restricciones organizacionales y de presupuesto. Estos pueden estar en conflicto con los requerimientos de los usuarios finales y puede tener que aadirse nuevas caractersticas de apoyo al usuario, pus el sistema debe de cumplir con sus objetivos. El entorno de negocios y tcnico del sistema cambia despus de haberse instalado, puede ser necesario de que interactu con otros sistemas, las prioridades de un negocio pueden cambiar y puede haber una nueva reglamentacin y medidas que deben ser implementadas por el sistema (Sommerville, 2005). La Gestin de Requisitos es necesaria porque los requisitos son voltiles, el entorno fsico y el entorno organizacional cambian, y la propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios. Segn Sommerville define a la gestin de requisitos como: el proceso de comprender y controlar los cambios en los requerimientos del sistema. El proceso de gestin de requisitos debe empezar cuando existe una versin preliminar de un documento de requisitos, pero se recomienda empezar a planificar como gestionar los requisitos que cambian durante el proceso de obtencin. 1.4.6.- Negociacin de Requisitos El objetivo de la negociacin de requisitos es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones. Segn Pressman las mejores negociaciones son aquellas que buscan un resultado de tipo ganar ganar, para realizar de manera ms rpida la negociacin con el cliente se recomienda utilizar las siguientes actividades definidas: 1. Identificacin de los interesados clave en el sistema 2. Determinacin de las condiciones ganadoras de los interesados 3. Negociacin de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar- ganar, lo cual se 138

convierte en el criterio clave para continuar con las siguientes actividades de la Ingeniera de Software. 1.4.7.- Validacin de requisitos El objetivo de la validacin de requisitos es descubrir problemas en el documento de requisitos antes de comprometer recursos a su implementacin. Como resultado de esta validacin se produce una lnea-base (baseline). El documento debe revisarse para descubrir omisiones, conflictos, ambigedades, y comprobar la calidad del documento y su grado de adhesin a estndares. Lnea Base.- En el contexto de la Ingeniera de Requisitos, una lnea base es un conjunto de requisitos que han sido formalmente aceptados por todas las personas implicadas en el proyecto. Una vez que se establece una lnea base, futuros cambios a tales requisitos slo podrn realizarse por medio de un proceso formal de gestin y aprobacin de cambios. Revisiones (Reviews).- Es la frmula ms empleada para validacin. Un grupo de personas (incluyendo usuarios) se ocupan de revisar el documento de requisitos. Consta de tres fases: 1. Bsqueda de problemas. 2. Reunin. 3. Acuerdos. Como gua para identificar problemas habituales, se pueden utilizar listas de comprobacin (checklists). Existen checklists adaptadas a distintos tipos de sistemas. Una checklist debera girar alrededor de los 24 atributos de calidad que debera poseer una ERS. Otros mtodos de validacin: Prototipado: Permite descubrir con rapidez si el usuario se encuentra satisfecho, o no, con los requisitos (Uso de escenarios/casos de uso) Validacin de modelos: Cuando los requisitos se expresan por medio de modelos (de objetos, DFDs, etc.) Validacin de su testabilidad: El equipo de pruebas debe revisar los requisitos. INGENIERA WEB Las pginas web son interfaz de usuario, la programacin HTML es programacin, y las aplicaciones desplegadas en el navegador son sistemas de software que pueden beneficiarse de los principios bsicos de la ingeniera de software. 2.1.- Definicin 139

La Ingeniera de la Web hace referencia a las metodologas, tcnicas y herramientas que se utilizan en el desarrollo de Aplicaciones Web complejas y de gran dimensin en las que se apoya la evaluacin, diseo, desarrollo, implementacin y evolucin de dichas aplicaciones. El desarrollo de Aplicaciones Web posee determinadas caractersticas que lo hacen diferente del desarrollo de aplicaciones o software tradicional y sistemas de informacin. La Ingeniera de la Web es multidisciplinar y aglutina contribuciones de diferentes reas: arquitectura de la informacin, Ingeniera de hipermedia/hipertexto, Ingeniera de Requisitos, diseo de interfaz de usuario, usabilidad, diseo grfico y de presentacin, diseo y anlisis de sistemas, Ingeniera De Software, Ingeniera de Datos, indexado y recuperacin de informacin, testeo, modelado y simulacin, despliegue de aplicaciones, operacin de sistemas y gestin de proyectos. 2.2.- Formulacin de Sistemas Basados en Web Comienza con la identificacin de las necesidades del negocio, se mueve hacia una descripcin de los objetivos de las WebApp define grandes caractersticas y funciones y realiza la recopilacin de requisitos que conducen al desarrollo de un modelo de anlisis. La formulacin permite que los clientes y el equipo de ingeniera web establezcan un conjunto comn de metas objetivos para la construccin de la WebApp. El anlisis identifica los requisitos funcionales, de comportamiento y de datos de la WebApp.La formulacin se enfoca sobre el gran cuadro: en las necesidades y objetivos del negocio y en la informacin relacional (Pressman, 2006); sin embargo, virtualmente es imposible mantener este grado de abstraccin. a) Preguntas de Formulacin.- Los autores recomiendan hacer las siguientes preguntas: Cul es la principal motivacin para realizar la WebApp? Cules son los objetivos que debe satisfacer la WebApp? Quin usar la WebApp?

La respuesta para cada pregunta debe ser tan brevemente como sea posible. Las preguntas de formulacin tienen como objetico acotar la intencin global de la WebApp. b) Comunicacin entre los Actores.- Se recomienda no emplear informacin recopilada de pocas personas como base para la formulacin el anlisis. Es muy recomendable tener la opinin de ms de dos personas. Para esta comunicacin es necesario tener en cuenta los siguientes mecanismos: 1. Grupo Muestral Tradicional.- Tiene como propsito discutir la WebApp que se desarrollar y se podr comprender mejor los requisitos del sistema.

140

2. Grupo Muestral Electrnico.- Denominado tambin un debate electrnico que va dirigido a un grupo de usuarios finales con este mecanismo es posible recopilar ms informacin en un periodo ms corto. 3. Entrevistas Interativas.- Va dirigida a usuarios representativos donde se solicitan respuestas a las preguntas especificas. Estas se analizan y aprovechan para afinar una entrevista posterior. 4. Entrevistas de Exploracin.- Est basada en Web y ligada a una o ms aplicaciones web con usuarios similares a los que usarn la WebApp que se desarrollar. c) Anlisis de la informacin Recopilada Tiene como objetivo desarrollar listas de objetos de contenido, operaciones que se aplican a los objetos de contenido dentro de una transaccin de usuario. Segn Fucella y Pizzolato: Se crea un paquete de cartas para los objetos de contenido, las operaciones aplicadas a los objetos de contenido, las funciones Webapp y otros requisitos no funcionales. Se barajan las cartas luego se distribuyen a las personas representativas de cada categora de usuario. Luego se solicita a los usuarios que describan cada agrupamiento y las razones por las que son importantes para ellos, despus de haber realizada este ejercicio el equipo de ingeniera web busca agrupamientos comunes entre las diferentes clases de usuarios (Pressman, 2006). d) Conflictos de gestin de proyecto para una ingeniera Web El trabajo que debe realizarse sigue siendo el mismo sin importar si una WebApp es subcontratada, desarrollada en casa o distribuida entre proveedor externo. Si se cambian los requisitos de comunicacin, la distribucin de actividades tcnicas, el grado de interaccin entre clientes y desarrolladores, y una diversidad de otros conflictos importantes. e) Planeacin de una Aplicacin Web Los proveedores que se especializan en el desarrollo de sistemas y aplicaciones basados en una Web. El cliente pide un precio fijo para desarrollar la WebApp de uno o ms proveedores. Para esta planeacin se deben tener en cuenta criterios como: 1. Inicio del Proyecto: para comenzar con el proyecto se debe tener en cuenta acciones como: Realizar una lista con los accionistas internos donde se definen y revisan las metas globales. Desarrollar internamente un diseo aproximado de la aplicacin web. Elaborar un programa aproximado que incluya las fechas finales de entrega sino tambin fechas clave Crear una lista de responsables para la organizacin interna, aborda que informacin, contactos y otros recursos se requieren de ambas organizaciones.

141

Identificar el grado de supervisin de la organizacin contratante.

2. Seleccin entre los subcontratistas candidatos: con la finalidad de elegir desarrolladores web candidatos. 3. Valoracin de la validez de las cotizaciones y la confiabilidad de las estimaciones: algunos proveedores incorporarn mrgenes de seguridad sustanciales en cotizaciones para un proyecto 4. Comprensin del grado de gestin del proyecto que puede esperar o realizar: es proporcional al tamao de la aplicacin web 5. Evaluacin: el programa para el desarrollo debe tener una dosificacin muy precisa, aqu se debe reconocer la fecha de finalizacin. 6. Gestin del mbito: permite que el equipo de desarrollo congele el mbito para un incremento de manera que se puede crear una liberacin operativa de la aplicacin web. MEJORAS DE REQUISITOS PARA LA WEB El desarrollo de sistemas web agrupa una serie de caractersticas que lo hacen diferente del desarrollo de otros sistemas (Koch, 2001). Por un lado, hay que tener en cuenta que roles muy diferentes de desarrolladores participan en el proceso: analistas, clientes, usuarios, diseadores grficos, expertos en multimedia y seguridad, etc. Por otro lado, la existencia en estos sistemas de una importante estructura de navegacin obliga a un desarrollo preciso de este aspecto que garantice que el usuario no se pierde en el espacio navegacional del sistema (Olsina, 1999). Estas ideas unidas al hecho que los sistemas web suelen tratar con mltiples medios y es esencial que ofrezcan una interfaz adecuada en cada momento, obligan a que estos aspectos propios de la web deban ser tratados de una forma especial en el proceso de desarrollo. Estas caractersticas especiales tambin hay que tenerlas en cuenta en la fase de especificacin de requisitos (Escalona, 2002). Por ello, la mayora de las propuestas estudiadas ofrecen diferentes clasificaciones de los requisitos. Sin embargo, la terminologa usada no es siempre la misma. Para facilitar la comprensin de las propuestas, antes de presentarlas, presentamos una clasificacin de requisitos relevantes en sistemas web. Requisitos de datos, tambin denominados requisitos de contenido, requisitos conceptuales o requisitos de almacenamiento de informacin. stos requisitos responden a la pregunta de qu informacin debe almacenar y administrar el sistema. Requisitos de interfaz (al usuario), tambin llamados en algunas propuestas requisitos de interaccin o de usuario. Responden a la pregunta de cmo va a interactuar el usuario con el sistema. Requisitos navegacionales, recogen las necesidades de navegacin del usuario. 142

Requisitos de personalizacin, describen cmo debe adaptarse el sistema en funcin de qu usuario interacte con l y de la descripcin actual de dicho usuario. Requisitos transaccionales o funcionales internos, recogen qu debe hacer el sistema de forma interna, sin incluir aspectos de interfaz o interaccin. Tambin son conocidos en el ambiente web como requisitos de servicios. Requisitos no funcionales, son por ejemplo los requisitos de portabilidad, de reutilizacin, de entorno de desarrollo, de usabilidad, de disponibilidad, etc.

Son muchos los autores que han propuesto tcnicas y modelos para el desarrollo de este tipo de sistemas, pero como se ha comentado, estas propuestas se centran principalmente en las ltimas fases del proceso de desarrollo. En este apartado se van a presentar aquellas tcnicas que incluyen el proceso de definicin de requisitos dentro del ciclo de vida. Alguna de las propuestas que describimos cubra la captura y definicin de requisitos desde sus primeras propuestas. Otras, como se vern, la han incluido en revisiones a sus trabajos iniciales. El criterio que se ha seguido para presentar las propuestas es el cronolgico, desde la primera publicacin que incluye tratamiento de requisitos. Ello nos permitir en la comparativa evaluar la evolucin de las propuestas para requisitos. a) WSDM: Web Site Design Method (Mtodo de Diseo de Sitio Web), es una propuesta para el desarrollo de sitios web, en la que el sistema se define en base a los grupos de usuarios. Esta propuesta recopila los requisitos para una web teniendo en cuenta dos cosas: 1. Clasificacin de usuarios: en este paso se deben identificar y clasificar a los usuarios que van a hacer uso del sistema. Para ello, WSDM propone el estudio del entorno de la organizacin donde se vaya a implantar el sistema y los procesos que se vayan a generar, describiendo las relaciones entre usuarios y actividades que realizan estos usuarios. Para la representacin grfica de estas relaciones WSDM propone una especie de mapas de conceptos de roles y actividades. 2. Descripcin de los grupos de usuarios: en esta segunda etapa se describen con ms detalles los grupos de usuarios detectados en la etapa anterior. Para ello, se debe elaborar un diccionario de datos, en principio con formato libre, en el que indican los requisitos de almacenamiento de informacin, requisitos funcionales y de seguridad para cada grupo de usuarios b) SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology (Metodologa de Diseo de Hipermedios de comunicacin), presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. Para ello, propone el uso de escenarios. El proceso de definicin de requisitos parte de la realizacin de un diagrama de contexto tal y como se propone en diagramas de flujos de datos. 143

c) RNA: Relationship-Navegational Analysis (Anlisis de Relacin de Navegacin), plantea una secuencia de pasos centrndose fundamentalmente en el flujo de trabajo de anlisis. El proceso de trabajo que presenta RNA se basa en la realizacin de las siguientes fases: 1. Fase 1- Anlisis del entorno: El propsito de esta fase es el de estudiar las caractersticas de la audiencia. Consiste en determinar y clasificar a los usuarios finales de la aplicacin en grupos segn sus perfiles. 2. Fase 2- Elementos de inters: En esta fase se listan todos los elementos de inters de la aplicacin. Por elementos de inters se entienden los documentos, las pantallas que se van a requerir, la informacin, etc. 3. Fase 3- Anlisis del conocimiento: Esta fase consiste en desarrollar un esquema que represente a la aplicacin. Para ello RNA propone identificar los objetos, los procesos y las operaciones que se van a poder realizar en la aplicacin, as como las relaciones que se producen entre estos elementos. 4. Fase 4- Anlisis de la navegacin: En esta fase el esquema obtenido en la fase anterior es enriquecido con las posibilidades de navegacin dentro de la aplicacin. 5. Fase 5- Implementacin del anlisis: Una vez obtenido el esquema final en el que ya se encuentran incluidos los aspectos de navegacin, se pasa el esquema a un lenguaje entendible por la mquina. DISCUSIN Despus de haber investigado sobre la ingeniera de requisitos, el proceso de obtencin de requisitos, la ingeniera web y su obtencin de requisitos; se obtuvo que ambas ingenieras cuentas con tcnicas similares para recopilar su informacin necesaria sin embargo, la ingeniera web tiene una forma de recopilar la informacin de manera ms dinmica que la ingeniera de requisitos. Con lo que respecta a las metodologas que el proyecto de investigacin esta basado, en general se refieren a simplificar la obtencin de requisitos, a clasificar sus usuarios y a utilizar otras herramientas de discusin aparte de las reuniones, mejorando en el tiempo de recopilacin y en la eficiencia del proceso en s.

144

CONCLUSIONES La ingeniera de requisitos es la etapa clave para el desarrollo de un software. Para todos los sistemas web existen diversas maneras de como adaptar los requisitos, mediante este trabajo de investigacin se tratar de mejorar las tcnicas existentes trayendo beneficios quizs en reducir el tiempo de aplicacin o que algunas tcnicas de adaptacin sean ms eficientes Al final de este trabajo de investigacin la obtencin de requisitos tanto para un sistema como para una aplicacin web son casi similares y existen varias tcnicas de recoleccin de datos que se utilizan en ambas ingenieras.

Existen diversas formas y tcnicas de obtener los requisitos, desde entrevistas, foros virtuales, casos de uso, tormentas de ideas, entre muchos ms. En lo que respecta mejoras de requisitos para las web solo se han nombrado 3 metodologas basados en una investigacin realizada y como se puede ver existen tareas o actividades que permiten que la recopilacin de requisitos para una web sea mucho mas corto el tiempo y su recopilacin sea ms eficiente.

145

ESTUDIO COMPARATIVO Y PROPUESTA METODOLOGICA PARA LA INTERFACES EVALUACIN DE LA CALIDAD DE DISEO DE INTERFACES GRAFICAS DE USUARIO7

RESUMEN

El presente trabajo de Investigacin se desarroll ante el problema que surge al no aplicar metodologas para la Evaluacin de la Calidad de Interfaces Grficas de Usuario, tratando de enfocar las necesidades del usuario y la interaccin que este tiene con el sistema.

Ante los diversos problemas de interaccin Hombre Mquina, surge la necesidad de investigar metodologas para la Evaluacin de la Calidad de Interfaces Grficas de Usuario. Seguidamente se compar dichas metodologas para determinar la que mas se ajusta a la hora de disear Interfaces Grficas de Usuario.

Finalmente

se propone mecanismos metodolgicos para la buena calidad de las

Interfaces Grficas, llevando consigo el contexto de usabilidad.

PALABRAS CLAVES: Calidad, Interfaces Grficas de Usuario, Metodologas, usabilidad.

Bejarano Ramrez Zully

146

INTRODUCCIN
Si bien el contar con un sistema informtico ayuda a mejorar los procesos, pues las Interfaces Grficas tambin lo han hecho, de manera tal que ha influido en la industria del hardware y software. Pues, el diseo de Interfaz Grfica, es til para el usuario ya que a travs de ellas podr interactuar y ver informacin que pueda serle de inters, por otro lado tambin proporcionar las herramientas para tomar acciones necesarias como respuesta al sistema. Es por ello, que se torna necesario tener Metodologas de Evaluacin que permitan que las Interfaces Grficas sean de buena calidad. Al hacer uso de las diversas metodologas, se tendr como respuesta la usabilidad del sistema, as como la buena apreciacin del Usuario. En resumen, una buena interfaz grfica de usuario requiere simplicidad y funcionalidad y de las diversas metodologas para la evaluacin de las mismas. Por otro lado, aunque el diseo grfico tiene una presencia implcita, debe ser considerado como parte fundamental en el xito o el fracaso de la interfaz, porque a travs de sta se refuerzan notablemente las ideas y/o conceptos en los contenidos.

1.1.

DEFINICIN DE INTERFAZ GRFICA DE USUARIO: Se entiende por interfaz de usuario el entorno visual, que un usuario dispone para poder interactuar con las funciones de un sistema. La interfaz de usuario es algo ms que software, por la que se incluyen las interacciones que el usuario tiene con el producto, en la cual sus aspectos se dirigen en un mbito visible o superficial de un sistema, as se tiene en: Los dispositivos de E/S de datos Informacin presentada el usuario extraer ciertos aspectos relevantes. El feddback presentado al usuario El comportamiento del sistema La documentacin y sistemas de ayuda en la utilizacin del sistema

147

Figura N 01: Modelos de Interfaz Fuente: CATALAN, Macos. (2003).

1.2.

ANLISIS Y DISEO DE LA INTERFAZ DE USUARIO

1.2.1.

Modelos de Anlisis y Diseo de Interfaz: Modelo de Usuario: Establece el perfil de los usuarios finales del sistema. Se debe comenzar por la compresin de quienes son los usuarios de destino, y que perfiles se encuentra cada usuario, Modelo de Diseo: Incorpora datos, arquitectura, interfaz y representaciones procedimentales del software. La especificacin de requisito establece ciertas restricciones que ayudan a definir el usuario del sistema, pero el diseo de interfaz solo puede ser incidental en relacin con el modelo del diseo. Modelo Mental del Usuario: es la percepcin, imagen del sistema, que los usuarios finales llevan en la mente. Es lo que el usuario se imagina o percibe de lo que se trata el sistema. Modelo de Implementacin: combina la manifestacin externa del sistema, es decir la apariencia de la interfaz y toda la informacin de ayuda, en este modelo, lo que se trata de especificar es la descripcin que se hace tanto en el

148

funcionamiento como en el mecanismo de interaccin que existe con el sistema.

1.3. Segn

DEFINICIN DE CALIDAD ISO 900(ISO, 1987), asocia la calidad con la certeza de que el producto a

desarrollar o producir satisfar los requisitos establecidos. En ISO 8402 (ISO, 1994), define la calidad como la totalidad de las caractersticas de una entidad que afectarn a su habilidad para satisfacer las necesidades establecidas e implcitas. Dentro de esta lnea, se mueve la propuesta de ISO 9126(ISO, 1991) en la cual se describen las caractersticas que permiten describir la calidad de un producto software como: Funcionalidad, Usabilidad, Fiabilidad, Manteneabilidad y Portabilidad. 1.4. DEFINICIN DE USABILIDAD

Segn ISO 9241-11(ISO, 1996), la define como el instante en el cual un producto puede ser utilizado por usuarios especficos para alcanzar metas especificas con efectividad, eficiencia y satisfaccin en un contexto de uso especifico. En este contexto se define tres posibles valores: efectividad, eficiencia y satisfaccin. Los parmetros para definir la usabilidad, son: aprendizaje, eficiencia, necesidad de recordar, errores, satisfaccin. Medicin de la Usabilidad:

Efectividad El glosario Usability First define como El modo de ayudar al usuario a lograr ciertas metas de forma rpida y sin errores, satisfacindole plenamente. Se trata, en suma, de medir el xito de funcionamiento del sistema. En consecuencia, las variables utilizadas para su medicin siempre son de tipo cuantitativo.

Eficiencia Mide cuan rpido y preciso un usuario puede realizar las tareas del sistema. Se debe realizar un anlisis de tareas para favorecer el desarrollo de aquellas tareas ms frecuentes e importantes. La forma ms habitual de medir la eficiencia de una interfaz es preguntarle directamente al usuario.

149

Satisfaccin Aceptacin del sistema por parte de los usuarios, es decir la actitud positiva de los usuarios hacia la utilizacin del producto. La medicin de la satisfaccin del usuario puede realizarse de muchas formas. Bien puede hacerse preguntando directamente al usuario si recomendara la interfaz o si trabajar con ella le ha resultado satisfactorio, bien puede elaborarse una pequea encuesta.

1.5.

METODOLOGAS DE EVALUACIN DE CALIDAD DE INTERFACES

El siguiente cuadro, hace referencia a las metodologas para la evaluacin de la calidad de interfaces. (FUENTE: ELABORACION PROPIA)

150

METODOLOGAS DE EVALUACIN DE INTERFACES GRFICAS DE USUARIO

MTODOS DE EVALUACIN PREVIOS A LA DISTRIBUCIN

MTODOS DE EVALUACIN DURANTE LA VIDA ACTIVA DEL PRODUCTO

REVISIONES DE EXPERTOS

TEST DE USABILIDAD

TEST DE LABORATORIO

Evaluacin Heurstica

Tests Rebajados

Seguimiento de la Activacin del

ENCUESTAS

Seguimiento y/o ayuda telefnica u on

Revisin por Recomendacio

Tests Exploracin
ENTREVISTAS

Comunicacin de Problemas

Grupos de Noticias

Inspeccin de la

Tests de Campo

Informaciones al Usuario

Simulaciones de Usuario Juicio

Tests de Validacin

Tests Destructivos

Tests Competitivo

151

1.6.

MTODOS DE EVALUACIN PREVIOS A LA DISTRIBUCIN COMERCIAL DE LA INTERFAZ (FORMATIVE EVALUATION)

1.6.1.1.

Revisiones de expertos (expert reviews o predictive evaluations)

Esta metodologa consiste en la revisin del sistema por parte de un experto en usabilidad, sin que medie el usuario. En consecuencia, depende de la disponibilidad de esos expertos en la plantilla del proyecto o bien en forma de consultores externos. Evaluacin Heurstica: Esta metodologa tiene como objetivo determinar los errores ms comunes en el diseo de interfaces ms que determinar en qu grado cumple la herramienta tal o cual funcionalidad. En este sentido, es de mayor utilidad realizar este tipo de evaluacin en etapas iniciales del diseo. Revisin por Recomendaciones Previas: Las recomendaciones son reglas e interpretaciones detalladas que deben seguirse a la hora de crear interfaces, y definen sus elementos, su apariencia o su comportamiento Inspeccin de la consistencia (consistency inspection):Los expertos verifican peridicamente la consistencia de una familia de interfaces, en especial en lo referente a la terminologa, color, composicin y distribucin de elementos de presentacin, formatos de importacin y exportacin de datos, o las formas de ayuda al usuario sin olvidar que los conceptos no relacionados deben ser mostrados de forma inequvoca. Por lo tanto, esta metodologa dispone de objetivos explcitamente determinados. Simulaciones de usuario (cognitive walkthrough o pluralistic walkthrough): Los expertos simulan ser usuarios finales de la interfaz ejecutando y recorriendo las funciones ms usuales del sistema, paso a paso y mediante unas lneas de actuacin que pretenden imitar las del usuario final. En consecuencia, se intenta vaticinar el comportamiento del usuario frente a la interfaz y predecir los errores que pueden encontrarse.

152

Juicio formal (formal usability inspection): Metodologa de diagnstico y sin objetivos establecidos basada en que los expertos se renen bajo la moderacin de uno de ellos para discutir acerca de la interfaz tras haberla estudiado de forma individual.

1.6.1.2.

Tests de usabilidad (usability testing or engineering o observing and monitoring usage)

Tests rebajados (discount usability engineering)

Son aproximaciones muy rpidas a las interfaces, rompiendo as barreras para los usuarios inexpertos. Consiste en que los evaluadores van enseando muy rpidamente la interfaz a los usuarios, sin detenerse a responder preguntar de estos ltimos, ya que este tipo de tests busca evaluar las reacciones inmediatas de los usuarios para saber si, a grandes rasgos, la interfaz les resulta llamativa. Tests de exploracin (exploratory tests)

Son aquellos en los que el evaluador, a modo de interfaz, va enseando al usuario las pantallas del producto a medida que ste elige una u otra opcin de accin o navegacin. Tests de campo (assessment tests)

Es el tipo de metodologa ms extendida dentro de este campo, aunque necesita, como mnimo, un producto medianamente desarrollado. Estos tests son los que se realizan en entornos lo ms realistas posibles y en los que la monitorizacin del usuario es ms importante. Tests de validacin (validation tests o acceptance tests)

En proyectos que necesiten de un largo desarrollo e implantacin, es habitual que, tanto el usuario o cliente como el desarrollador, fijen objetivos medibles de satisfaccin del funcionamiento de la interfaz. En consecuencia, un test de aceptacin del producto debera ser acordado entre vendedor y cliente antes de la implantacin definitiva del sistema como paso previo a su adquisicin o bien que sea el cliente quien evale el

153

producto de cara a su compra, sin que tenga la empresa productora nada que ver dentro del proceso evaluador. Tests destructivos

Los tests destructivos son empleados, principalmente, por la industria del ocio informtico. Se propone a los usuarios el vencer a la mquina y encontrar errores de programacin. La gran ventaja que tiene este tipo de test es la facilidad con la que se encuentran usuarios dispuestos a realizarlo por el elemento ldico de la experiencia. Tests competitivos (comparison tests)

Los tests competitivos son aquellos que comparan diversas versiones de la interfaz, la interfaz con productos similares de compaas rivales e, incluso, la interfaz con la ayuda humana. Tienen como objetivo el conocer qu diseos son los ms tiles y discernir sus ventajas y desventajas. Se realizan en cualquier momento del diseo del sistema.

1.6.1.3.

Tests

de

laboratorio

(laboratory

testing

formal

evaluation) Este tipo de metodologa puede considerarse hermana de la anterior. La diferencia radica en que, en este caso, existe un control mucho ms frreo sobre el entorno del experimento, siendo una metodologa de diagnstico pero con objetivos explcitamente marcados. La importancia de los llamados tests de laboratorio estriba en que el evaluador puede controlar y manipular un conjunto de factores asociados al producto y estudiar el efecto en varios aspectos de la actuacin de los usuarios. 1.6.1.4. Encuestas (surveys)

Las encuestas son herramientas de diagnstico, pero que tienen los objetivos perfectamente estipulados. Confeccionar encuestas es una forma habitual y relativamente poco costosa de acompaar otros modos de evaluacin.

154

1.6.1.5.

Entrevistas y discusiones con usuarios (interviews and focusgroup discussions)

Este tipo de metodologas son herramientas de diagnstico, pero que tienen los objetivos perfectamente estipulados, y es uno de los ms utilizados por las empresas desarrolladoras de software. En una entrevista, el evaluador puede preguntar a los usuarios sobre su comportamiento con la interfaz e, incluso, las mejoras que pueden producirse. 1.7. MTODOS DE EVALUACIN DURANTE LA VIDA ACTIVA DEL PRODUCTO (SUMMATIVE EVALUATION) 1.7.1. Seguimiento de la actuacin del usuario (continuous userperformance data logging) El mayor beneficio que puede dar esta forma de evaluar es el conocimiento de la actuacin real y diaria del usuario, yendo directamente a solucionar aquellas dificultades ms habituales y aumentando as la tasa de usuarios satisfechos. En cualquier caso, este seguimiento debe ser respetuoso con la privacidad del usuario. 1.7.2. Seguimiento y/o ayuda telefnica u online (online or telephone consultants) Este tipo de evaluacin puede proporcionar una atencin personalizada al usuario final. Es decir, puede servir en ambos sentidos: el desarrollador puede tener una idea de los aspectos a mejorar y el usuario puede sentirse ms arropado por la compaa tras el producto. Muchas compaas ofrecen este servicio por va telefnica y chat para facilitar la comunicacin inmediata con el usuario, y es la metodologa ms integrada en la asistencia o mantenimiento al usuario. 1.7.3. Comunicacin de problemas (online suggestion box or trouble reporting) El correo electrnico o cualquier otro sistema de comunicacin pueden ser empleado por los usuarios para mandar mensajes a los desarrolladores de la interfaz, expresando sus opiniones, problemas y sugerencias.

155

1.7.4. Grupos de noticias (online bulletin board or newsgroup) Este sistema ofrece, usualmente, una lista de encabezamientos que pueden ayudar al usuario en la bsqueda a la solucin de sus problemas. Adems, el gestor del grupo de noticias puede concretar que solucin es la ms consultada o adecuar el rigor de la solucin ofrecida y, de paso, saber las demandas de los usuarios y, evidentemente, su evaluacin de la interfaz. 1.7.5. Informaciones al usuario -en forma de boletines o FAQs- y encuentros (user newsletters and conferences) Los boletines donde se ofrecen noticias acerca de las nuevas potencialidades de la interfaz, sugerencias para un mejor funcionamiento, demandas de ayuda o informes de implantacin del producto pueden aumentar la satisfaccin del usuario y la sensacin de pertenencia a esta comunidad. En otro sentido, tambin es positivo favorecer los encuentros personales va reuniones de trabajo para que los usuarios puedan intercambiar impresiones acerca del producto y promover mejoras. Por todo ello, si la compaa desarrolladora de la interfaz est alerta, el feedback surgido de estas vas de comunicacin puede aportar datos valiosos para su evaluacin.

1.8.

COMPARACIN DE LAS METODOLOGAS

156

METODOLOGA DE EVALUACIN PREVIAS A LA DISTRIBUCIN: REVISIONES DE EXPERTOS

Evaluacin Heurstica

Revisin por recomendaciones

Inspeccin de Consistencia

Simulaciones de Usuario

Juicio Formal

Objetivo: Determinar errores comunes en el diseo de Interfaces. Referencias Consistencia Posibilidad de Atajos FeedBack

Objetivo: Dar reglas e Interpretaciones detalladas para crear Interfaces. Referencias rea Fsica rea Sintctica rea Semntica Forma de Evaluar Se evala un conjunto de tems a modo de checkboxes

Objetivo: Verificar la consistencia de una familia de interfaces. Referencias Terminologa Color Composicin Distribucin de elementos de presuncin Formatos de importacin de datos

Objetivo: Intentar vaticinar el comportamiento del usuario frente a la interfaz y predecir errores que puedan encontrarse. Referencias Demos Manuales Tutoriales Recibir Informacin que recibirn los usuarios finales.

Objetivo: Discutir acerca de la Interfaz. Referencias Lluvia de ideas Tipo de Metodologa: Metodologa de diagnostico y sin objetivos establecidos Forma de Evaluar

DIFERENCIAS

Informativo Disear Dilogos de Finalizacin de Procesos Prevenir y Gestionar

157

Errores Apoyar controles Internos Minimizar la sobrecarga de la Memoria del Usuario. Forma de Evaluar Se evala un conjunto de listas breves de elementos Forma de estudio Conversacin con los diseadores de manera personal

modo de checkboxes indicando si se cumple o no.

importacin de datos Formatos de exportacin de datos. Formatos de ayuda al usuario.

Realizacin Llevado a cabo la simulacin con socilogos, usuarios finales y desarrolladores.

Debatir problemas encontrados en la lluvia de ideas. Detallar la localizacin de problemas y ofrecer una solucin. Forma de estudio Reunin de expertos

Forma de estudio Conversacin con los diseadores de manera impersonal

Forma de Evaluar Se evala aspectos grficos y semnticos, estudia las metforas visibles, realiza un medicin a travs de WYSIWIS y WYWITYS. Forma de estudio Trabajo individual luego en equipo

Forma de Evaluar Se simula ser usuarios finales de la interfaz ejecutando y recorriendo las funciones ms usuales del sistema. Forma de estudio

bajo la moderacin de uno de ellos. Informe Final Descripcin de problemas Detallar la

Se realiza en equipo, donde estarn los expertos, socilogos, etc.

localizacin de problemas Ofrecer solucin a los problemas Reflejar el estado de la cuestin de la interfaz en lo relativo

158

a la usabilidad.

Tipo de Metodologa: Metodologa de comparacin y objetivos explcitamente estipulados.

Tipo de Metodologa: Metodologa de comparacin y objetivos explcitamente estipulados

Tipo de Metodologa: Metodologa de diagnostico y objetivos explcitamente determinados

Tipo de Metodologa: Metodologa de diagnostico y con objetivos explcitamente determinados

Tipo de Metodologa: Metodologa de diagnostico

SIMILITUDES

Inspeccin Inspeccin a la consistencia. Realizacin Llevado a cabo por expertos Informe Final Lista de problemas de usabilidad en la que se detallan:

Realizacin Llevado a cabo por expertos Informe Final Lista de problemas de usabilidad en la que se detallan: Frecuencia Impacto para el usuario Inspeccin Realizacin Inspeccin a la Consistencia Realizacin Llevado a cabo por expertos Informe Final Descripcin de problemas Llevado a cabo por expertos Informe Final Evaluacin de las Interfaces Descripcin de problemas Detallar Problemas Ofrecer Soluciones Realizacin Llevado a cabo por expertos

159

que se detallan: Frecuencia Impacto para el usuario Persistencia Comentario de la importancia del problema

usuario Persistencia Comentario de la importancia del problema

problemas Detallar la localizacin de problemas. Ofrecer soluciones

FUENTE: Elaboracin Propia

METODOLOGA DE EVALUACIN PREVIAS A LA DISTRIBUCIN: REVISIONES DE EXPERTOS: TEST DE USABILIDAD

160

T. Rebajadas

T. Exploracin

T. Campo

T. Validacin

T. Destructivos

T. Competitivos

Evaluacin Busca evaluar reacciones inmediatas de los usuarios, para saber si las interfaces les resultan llamativas.

Evaluacin Se pretende evaluar conceptos preliminares de diseo y conocer el modelo mental del usuario acerca del producto.

Evaluacin Se pretende evaluar conceptos concretos del producto.

Evaluacin Se pretende evaluar el tiempo de aprendizaje, velocidad de funcionamiento, tasa de errores de los usuarios inducidos a un mal funcionamiento de la interfaz, satisfaccin subjetiva de la interfaz.

Evaluacin Se pretende evaluar errores de programacin.

Evaluacin Comparar con otras interfaces de otras compaas y determinar que diseos son las mas tiles.

Interaccin con el Usuario Facilidad de interactuar con el usuario, dado por la experiencia que cuentan.

DIFERENCIAS

Interaccin con el Usuario

Interaccin con el Usuario

Interaccin con el Usuario

Interaccin con el Usuario

Interaccin con el Usuario

161

el Usuario Los evaluadores van enseando rpidamente la interfaz SIMILITUDES

Usuario El evaluador va enseando las pantallas del producto, a medida que se elige una u otra opcin de accin o navegacin

el Usuario El usuario interviene en la evaluacin.

el Usuario Interaccin directa con el usuario.

Usuario Interaccin directa con el usuario.

FUENTE: Elaboracin Propia

162

METODOLOGA DE EVALUACIN PREVIOS A LA DISTRIBUCIN

Revisiones de Expertos

Test de Usabilidad

Test de Laboratorio

Entrevistas

Quin lo revisa? Revisin del sistema por parte de un experto en usabilidad Tipo de Metodologa Metodologa de comparacin y objetivos explcitamente estipulados

Bsqueda Busca diferencias entre las interfaces, comparndolas y buscndola fallos.

Bsqueda Busca controlar y manipular un conjunto de factores asociados al producto y estudiar los efectos en la actuacin de los usuarios.

Bsqueda Busca identificar posibles reas que necesitan un anlisis mas pormenorizado y determinar errores del sistema

DIFERENCIAS

163

Bsqueda Busca conocer diferencias y opiniones conduciendo la discusin para aportar soluciones

Resultado Su resultado es un informe que expresa problemas identificados y/o recomendaciones del cambio

Quin lo revisa? Revisin del sistema por parte de evaluadores y usuarios.

Quin lo revisa? Revisin del sistema por parte de evaluadores y usuarios

Quin lo revisa? Revisin a travs de preguntas que los evaluadores realizan a los usuarios

Resultado Su resultado es describir y priorizar los problemas e intentar ser cuantitativos.

Resultado Su resultado es describir el propsito que se estableci y una lista de problemas con recomendaciones.

Tipo de Metodologa Herramienta de diagnostico con objetivos perfectamente estipulados

SIMILITUD

164

recomendaciones. Tipo de Metodologa Metodologa de diagnostico con objetivos detallados Tipo de Metodologa Metodologa de diagnostico con objetivos detallados

FUENTE: Elaboracin Propia

165

Mtodos de Evaluacin Durante la Vida Activa del Producto

Informaciones al Seguimiento de la actuacin del usuario Seguimiento y/o ayuda telefnica u online Comunicacin de problemas Grupos de noticias usuario en forma de boletines o FAQs y encuentros

Objetivo: Recopilacin de datos sobre el uso de la interfaz. Herramientas: El comportamiento del usuario La velocidad de

Objetivo: Dar una atencin personalizada al usuario final del sistema. Herramientas: Telfono Chat Uso de los Datos: Los datos se hacen llegar a los diseadores y desarrolladores en forma de listado

Objetivo Envo de mensajes a los desarrolladores de la interfaz, expresando sus opiniones, problemas y sugerencias Herramientas: Correo Electrnico Otros sistemas de comunicacin

Objetivo Ofrecer un sistema de grupos de noticias para que puedan recibir y responder preguntas de los usuarios Herramientas: Grupos de Noticias Uso de los Datos: una lista de encabezamientos que pueden ayudar al

Objetivo Crear una sensacin de comunidad entre usuarios de una misma interfaz; los cuales pueden estar en zonas geogrficas similares o distintas Herramientas: Boletines Encuentros

DIFERENCIAS

procedimiento La tasa de errores o el feedback con el sistema

166

sistema

forma de listado detallado de los problemas ms comunes, para que estos pasen a estudiarlos ms concretamente. Dificultades: Disponer de personal con la perspectiva necesaria, para no solo responder va telefnica o va chat a las consultas de los usuarios, sino que su trabajo es bsico de cara a la evaluacin del sistema.

Uso de los Datos: Con los datos obtenidos se le enva un mensaje de respuesta al usuario contestando a tus dudas.

usuario en la bsqueda a la solucin de sus problemas

Uso de los Datos: Se crean boletines y generar encuentros donde se ofrecen noticias acerca de las potencialidades de la interfaz, sugerencias para un mejor funcionamiento, e informes de implantar del producto.

Uso de los Datos: Los datos que son recogidos pueden servir para mejorar o adecuar los sistemas de ayuda, nuevas funcionalidades o atajos

167

Interaccin: El usuario con el sistema. Beneficio: Brinda conocimiento de la actuacin real y diaria del usuario,

Interaccin: El usuario con el sistema. Beneficio: Brinda conocimiento de la actuacin real y diaria del usuario, solucionando aquellas dificultades ms habituales; logrando una atencin personalizada del usuario final.

Interaccin: El usuario con el sistema. Beneficio: Permite la comunicacin entre los desarrolladores y el usuario a travs mensajes (Envo Respuesta) del usuario para as lograr una solucin al problema de

Interaccin: El usuario con el sistema. Beneficio: Brinda conocimientos sobre que noticias puede concretar, que solucin es la ms consultada, adecuar el rigor de la solucin ofrecida y saber las demandas de los usuarios.

Interaccin: El usuario con el sistema. Beneficio: Brinda conocimientos necesario para mantener una comunicacin sincera con el usuario y puedan intercambiar impresiones acerca del producto y promover mejoras

SIMILITUDES

solucionando aquellas dificultades ms habituales y aumentando as la tasa de usuarios satisfechos

FUENTE: Elaboracin Propia

168

COMPARACIN DE AMBAS METODOLOGA DE EVALUACIN DE CALIDAD DE INTERFACES

Mtodos de evaluacin previos a la distribucin comercial de la interfaz

Mtodos de evaluacin durante la vida activa del producto

Objetivo: Mejorar la interfaz lo mximo posible antes de su distribucin comercia

Objetivo: Diagnosticas las posibles fallas del sistema una ves comercializado

Formas de valoracin: Las revisiones de expertos Los tests de usabilidad

Formas de Valoracin: Seguimiento de la actuacin del usuario. Seguimiento y/o ayuda telefnica u online. y Comunicacin de problemas. Grupos de noticias. Informaciones al usuario -en forma de boletines o FAQs- y encuentros.

DIFERENCIAS

Los tests de laboratorio Encuestas, entrevistas

discusiones con usuarios.

Resultado Su resultado es un informe que expresa problemas identificados

Resultado Sus resultados al son brindar como

soporte

usuario

169

y/o algunas

recomendaciones

formas

de

evaluacin

del

SIMILITUD

del cambio

sistema para que se sienta satisfecho y servir para los desarrolladores del producto como plataforma para realizar mejoras del mismo.

FUENTE: Elaboracin Propia

1.9.

DISCUSION

Se propone para la evaluacin previa de las interfaces de un sistema; lo siguiente: Evaluacin Heurstica: Es importante dado que tiene como objetivo determinar los errores ms comunes en el diseo de interfaces ms que determinar en qu grado cumple la herramienta tal o cual funcionalidad. En este sentido, es de mayor utilidad realizar este tipo de evaluacin en etapas iniciales del diseo.

Inspeccin de la consistencia: se va ha verificar peridicamente la consistencia de una familia de interfaces, en especial en lo referente a la terminologa, color, composicin y distribucin de elementos de presentacin, formatos de importacin y exportacin de datos, o las formas de ayuda al usuario sin olvidar que los conceptos no relacionados deben ser mostrados de forma inequvoca. Este tipo de evaluacin se centra en los aspectos visibles de la interfaz.

Encuestas: Son herramientas de diagnstico, Confeccionar encuestas es una forma habitual y relativamente poco costosa de acompaar otros modos de evaluacin. Normalmente, la capacidad de respuesta que tiene una encuesta -puede hacerse a un gran nmero de personas sin un aumento excesivo de coste. La encuesta puede servir para preguntar a los usuarios sus impresiones sobre cualquier aspecto de la interfaz.

170

Tests de validacin: son test realizados entre los usuarios o clientes con los desarrolladores, antes de la implantacin definitiva del sistema como paso previo a su adquisicin o bien que sea el cliente quien evale el producto de cara a su compra, sin que tenga la empresa productora nada que ver dentro del proceso evaluador. El objetivo del test de aceptacin no es encontrar errores al sistema, sino corroborar la adecuacin del diseo a los requisitos del cliente.

A todo ello, se podra, conceptualizar, esta propuesta a travs del siguiente cuadro, en el que da a entender

Inspeccin de la Consistencia

Evaluacin Heurstica

Encuesta

Test de Validacin

MODELO DE DISTRIBUCION DE INTERFACES GRAFICAS PREVIAS A LA DISTRIBUCION FUENTE: Elaboracin Propia

171

Una vez determinada la estructura posible a aplicarse para la evaluacin de las interfaces graficas de los sistemas previo a su distribucin; ahora se propondr una forma de evaluar dichos sistemas durante la vida activa del mismo (Despus de su distribucin)

Como se haba referido todo sistema (interfaz) requiere de constante atencin por parte de los desarrolladores y dems equipo involucrado en su diseo, realizacin y mantenimiento. Asimismo es necesario que puedan contribuir a una mejora constante del producto y aumentar en consecuencia el nivel de servicio

Muchas de las metodologas existentes para este tipo de evaluacin no cumplen con toda su funcionalidad o no se obtienen los resultados requeridos.

Para ellos se propone las siguientes metodologas de evaluacin:

Seguimiento de la actuacin del usuario: La propia interfaz va ha recopila los datos sobre su uso; tanto el comportamiento del usuario la velocidad de procedimiento, la tasa de errores o el feedback con el sistema- debe ser recogido por el producto bajo la interfaz para que luego pueda ser interpretado por el desarrollador del mismo para mejorar el sistema. Los datos recogidos pueden servir para mejorar o adecuar los sistemas de ayuda, nuevas funcionalidades o atajos. Sin estos datos los encargados de ofrecer el mantenimiento del sistema tienen muy difcil el saber dnde el sistema puede ser mejorado o en qu procedimientos tiene el usuario ms problemas. El mayor beneficio que puede dar esta forma de evaluar es el conocimiento de la actuacin real y diaria del usuario, yendo directamente a solucionar aquellas dificultades ms habituales y aumentando as la tasa de usuarios satisfechos.

172

Grupos de noticias: Algunos usuarios pueden tener dudas sobre el funcionamiento de un determinado aspecto de la interfaz o quizs pueden querer localizar a alguien que tenga experiencia en el uso del producto. En este sentido, si no tienen a nadie concreto en mente, el correo electrnico puede no serles de utilidad. As, algunos sistemas ofrecen grupos de noticias para recibir y responder preguntas de los usuarios. Este sistema ofrece, usualmente, una lista de encabezamientos que pueden ayudar al usuario en la bsqueda a la solucin de sus problemas. Adems, el gestor del grupo de noticias puede concretar que solucin es la ms consultada o adecuar el rigor de la solucin ofrecida y, de paso, saber las demandas de los usuarios y, evidentemente, su evaluacin de la interfaz.

Informaciones al usuario: Metodologa utilizada cuando se da la situacin de que los usuarios de una misma interfaz estn geogrficamente muy distanciados es positivo que los desarrolladores de un producto creen una sensacin de comunidad. En este sentido, los boletines donde se ofrecen noticias acerca de las nuevas potencialidades de la interfaz, sugerencias para un mejor funcionamiento, demandas de ayuda o informes de implantacin del producto pueden aumentar la satisfaccin del usuario y la sensacin de pertenencia a esta comunidad. As, es necesario mantener una comunicacin sincera con el usuario; comunicndole cundo se podrn atajar los diversos problemas encontrados o, si es el caso, la imposibilidad de hacerles frente diseccionndoles incluso a algn sistema que s pueda ofrecerles lo que desean en un momento determinado.

173

De lo dicho en esta metodologa se podra resumir en este grfico:

Seguimiento de la Actividad del Usuario

Informe de Usuarios

Grupo de Noticias

MODELO DE DISTRIBUCION DE INTERFACES GRAFICAS POSTERIOR A LA DISTRIBUCION COMERCIAL DEL SISTEMA FUENTE: Elaboracin Propia

CONCLUSIONES

174

A travs de las metodologas analizadas, se ha podido hacer sus comparaciones respectivas, dando como resultado que algunas de ellas son muy redundantes para la evaluacin de una interfaz grfica. La evaluacin de la calidad de interfaces es muy importante, dado que a travs de ellas, el usuario puede tener una visin del sistema que requiere y as, poder determinar si el sistema esta cumpliendo con lo solicitado El diseo de interfaces requiere de tiempo, y dedicacin, adems se necesita establecer los requerimientos que el usuario solicite, siendo la interfaz la mejor entendible. Para la evaluacin de la calidad de interfaces se tuvo en cuenta la usabilidad ya que a travs de ella, es que se puede evaluar.

BIBLIOGRAFA PIATTINI, Mario & GARCIA, Feliz. (2003). Calidad en el desarrollo y Mantenimiento de Software. 1 Edicin. Editorial Alfa Omega. Mxico. PRESSMAN, Roger. (2005). Ingeniera de software: Un enfoque prctico. 6 Edicin. Editorial Mc Graw Hill. Mxico. BRAUDE, Eric. (2003). Ingeniera de software, una perspectiva orientada a objetos. 1 Edicin. Editorial Alfa Omega. Mxico. SOMMERVILLE, Ian. (2005). Ingeniera de software. 7 Edicin. Editorial Pearson Adisson Wesley. Espaa. DOLADO, Javier & FERNANDEZ, Luis. (2000). Medicin para la gestin en la Ingeniera de Software. 1 Edicin. Editorial Ra Ma. Espaa. KENDALL, Kenneth && KENDALL, Julie. (2005). Sistemas.MOLINA, Pedro. (2003). Especificacin de Interfaz de Usuario. Consultado el 15/09/07 a las 10:30 p.m. [En Lnea]: http://www.dsic.upv.es/~pjmolina/papers/TesisPjmolina.pdf CATALAN, Macos. Metodologas de Evaluacin de Interfaces Grficas de Usuario. Consultado el 15/09/07 a las 10:30 p.m. [En Lnea]: http://eprints.rclis.org/archive/00004718/01/Metodologias_de_evaluaci%C3 %B3n_de_interfaces_graficas_de_usuario.pdf Anlisis y Diseo de

175

JIMENEZ, Francisco. (2006). Tutorial: Diseo de una Interfaz Grfica. Consultado el 11/10/07 a las 8:30 p.m. [En Lnea]: http://www.uag.mx/66/Ante.htm

MOLINA, Pedro. (2003). Especificacin de Interfaz de Usuario. Consultado el 2/12/07 a las 8:30 a.m. [En Lnea]: http://www.dsic.upv.es/~pjmolina/papers/TesisPjmolina.pdf

Laboratorio DEI. Universidad Carlos III de Madrid. . Consultado el 8/12/07 a las 8:30 p.m. [En Lnea]: http://dei.inf.uc3m.es/docencia/p_s_ciclo/dsh/teoria/t2.pdf

MERLINO, H. Patrn de Diseo de Vistas Adaptables. . Consultado el 8/12/07 a las 8:30 p.m. [En Lnea]: http://www.itba.edu.ar/capis/rtis/rtis8/rtis-8-2-30-35.pdf

UNIVERSIDAD DE CASTILLA LA MANCHA. Patrones de Diseo. . Consultado el 11/12/07 a las 9:30 a.m. [En Lnea]: Usability First Glossary (disponible en http://www.usabilityfirst.com/glossary/

MARCOS, Mari. Pautas para el Diseo y Evaluacin de Interfaces de Usuario. . Consultado el 11/12/07 a las 10:30 p.m. [En Lnea]: http://www.mcmarcos.com/pdf/2004_pautas-iula.pdf

176

Marcos Mora, Mari Carmen (2004) Pautas para el diseo y la evaluacin de interfaces de usuario [en lnea]. En: Rovira, Cristfol, Codina, et al. Informacin y documentacin digital. Barcelona: IULA, Documenta Universitaria. http://www.mcmarcos.com/pdf/2004_pautas-iula.pdf

Jimnez Ordez, Francisco (2006) Diseo de una Interfaz grfica. Tutorial [en lnea]. Mxico: Universidad Autnoma de Guadalajara. http://www.uag.mx/66/Ante.htm

177

PROPUESTA METODOLGICA PARA UNA BUENA PRCTICA EN LA INGENIERA DE REQUERIMIENTOS8

RESUMEN

En el siguiente trabajo, se ha tenido como objetivo la planeacin de una nueva metodologa, que servir de apoyo y para una buena prctica en la ingeniera de requerimientos, la que permitir, en este caso, a los iniciadores de los proyectos de software, elegir entre tantas opciones, y sistematizar su forma de trabajar con los requerimientos.

Palabras Claves: Requerimientos, metodologas, ingeniera, planeacin.

INTRODUCCION

En el mundo del la Ingeniera de software, cuando se han realizado toda una serie de planificaciones, metodologas, mtricas, pruebas, etc., y al final no se obtiene el xito que se planea al inicio de todo proceso de software, es que, en algunos casos claro, no se a tenido una buena recoleccin de los requisitos.

En el siguiente trabajo, se ha tenido como objetivo la planeacin de una nueva metodologa, que servir de apoyo y para una buena prctica en la ingeniera de requerimientos, la que permitir, en este caso, a los iniciadores de los proyectos de software, elegir entre tantas opciones, y sistematizar su forma de trabajar con los requerimientos.

Guzmn Alvarado Cristhyan

178

En la primera parte, se ver el diseo del plan de la investigacin que se ha optado para el desarrollo del proyecto, posteriormente hablaremos en forma breve de la ingeniera de software, su situacin en el mundo; luego, en el captulo 3, los conceptos de la ingeniera de requerimientos; en el capitulo 4, se har el desarrollo de la nueva metodologa, basadas en Pressman (2005), Escalona y Koch (2002), Bez y Barba (2001) y Sommerville (2005), haciendo comparaciones, definiendo las etapas.

Esto que implica? Pues bien, que hagamos, en primera instancia, la planeacin de los requerimientos, segn Pressman (2005), Schach (2006) y Lawrence (2002), que va a necesitar el software. La Ingeniera de Requisitos consiste en esto. En la bsqueda de esas formas que permitan a los ingenieros realizar una buena practica para el desarrollo en cuanto se refiere al reconocimiento de los requisitos del software.

ANTECEDENTES DE LA INVESTIGACIN

En La ingeniera de requerimientos y su importancia en el desarrollo de proyectos de software de Michael Arias Chaves (2006), nos menciona en una de sus conclusiones en sus artculos Es muy importante mencionar que el poder formular una especificacin de requerimientos completa y consistente, es un paso muy importante para evitar cometer errores en la definicin de los requerimientos, ya que los mismos pueden resultar muy caros de corregir una vez desarrollado el sistema.

En Metodologa DoRCU para la Ingeniera de Requerimientos de M. Griselda Bez, Silvia I. Barba Brunner (2001), en una de sus conclusiones los esfuerzos se concentraron en la bsqueda de tcnicas, mtodos y herramientas que pudieran ser aplicados durante el proceso de definicin de requerimientos para arribar a una etapa de diseo exitosa, dejando de lado la obtencin de una metodologa capaz de adaptarse a cualquier tipo de sistema y paradigma, brindando un marco de trabajo referencial, independiente del mtodo a aplicar.

En un proyecto, Ingeniera de Requisitos en Aplicaciones para la Web Un estudio comparativo, de Mara Jos Escalona y Nora Koch (2002), llega a esta conclusin referida al tema Como resultado de este estudio podemos afirmar que an hay mucho potencial de investigacin en el campo de ingeniera de requisitos para aplicaciones para

179

el entorno web. Si se compara este trabajo con otros estudios comparativos de propuestas de la web (Koch, 1999, Barry & Lang, 2001 y Escalona, Mejas & Torres, 2002), se pueden observar que la gran mayora de las metodologas que existen estn centradas en el diseo de sistemas web en comparacin con las que contemplan la especificacin de requisitos.

Todos llegan a la importancia que tienen la recoleccin de la Ingeniera de Requisitos, y una buena prctica que aun falta por explotar.

MUNDO DE LA IS

El proceso de ingeniera de software se define como un conjunto de etapas, las cuales parcialmente ordenadas para obtener un producto de software de calidad. El proceso de desarrollo de software es aquel en que las necesidades de o de los usuarios son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo. En forma concreta, se define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo.

La naturaleza del software, tambin es cambiante, y por ente los requerimientos de los usuarios para su software, son tambin ms necesarios para los mismos.

Segn Pressman (2005) existen grandes categoras del software de computadora que presentan retos continuos para los ingenieros:

Software de sistemas. Software de aplicacin Software cientfico o de ingeniera Software emportado Software de lnea de productos Aplicaciones basadas en Web Software de Inteligencia Artificial.

Esto ha permitido, que un ingeniero de software, este apto para trabajar en cualquiera de estos sistemas, originando nuevos retos, como as menciona Pressman (2005):

180

Computacin ubicua Alimentacin de la red Fuente abierta La nueva economa.

Segn, Fernndez (2000), la investigacin y el desarrollo de tcnicas y mtodos de ingeniera del software son constantes y suelen suponer interesantes avances en la resolucin de problemas de desarrollo de software. Sin embargo, es habitual que en la prctica diaria profesional no se incluya prcticamente ninguna de las recomendaciones ms elementales de la ingeniera del software. En efecto, es habitual que el desarrollo de software se parezca ms al descontrol del cuento de si los programadores fueran albailes...

INGENIERA DE REQUERIMIENTOS

La ingeniera de requerimientos, trata de los principios, mtodos, tcnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemtica y repetible. Un requerimiento define que es lo que debe hacer el sistema y bajo que restricciones (o condiciones) va a operar, segn Lavariega (2005). Un requerimiento es simplemente una declaracin abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restriccin de ste, segn expresa Sommerville (2005). En el proceso de desarrollo de un sistema, sea o no para la Web, el equipo de desarrollo se enfrenta al problema de la identificacin de requisitos. Esta es una realidad, segn exponen Escalona y Koch (2002), y Lavariega (2005). Segn este ltimo, los problemas comunes de los requerimientos: Los requerimientos no reflejan las necesidades reales de los clientes del sistema. Los requerimientos son inconsistentes y/o incompletos. Es muy costoso el hacer cambios a los requerimientos despus de que han sido acordados. Hay malos-entendidos entre clientes, analistas y desarrolladores.

Segn se expresa en Arias (2006), es importante no perder de vista que un requerimiento debe ser:

181

Especificado por escrito: Como todo contrato o acuerdo entre dos partes. Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces cmo se sabe si se cumpli con l o no? 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.

METODOLOGAS EXISTENTES DE LA INGENIERA DE REQUERIMIENTOS Revisando varias metodologas, las que a su vez, presentan una serie de actividades en las cuales se realizan para hacer la prctica de la ingeniera de requerimientos.

Figura 1: Esquema de la metodologa DoRCU (Fuente: Baz y Barba, 2001).

La mayora de las metodologas, como las de DoRCU, de Baz y Barba (2001) (ver imagen 1), as como Pressman (2005), Sommerville (2005), y Escalona y Koch (2002), expresan una seria de pasos que orientan, en la ingeniera de requisitos. Algunas actividades, tambin las realizan una que otra metodologa, cumplen bsicamente las mismas tareas, usan casi las mismas herramientas, las cuales permiten reunir informacin

182

de los requerimientos, ya sean funcionales o no funcionales, y recabar estos, para planificar la etapa del desarrollo del software. En la siguiente tabla, se hace una comparacin de las metodologas que se exponen en el proyecto, con las actividades que se realizan en cada uno de las etapas, y las tareas que se realizan en cada una de las mismas. (ver tabla 01). A continuacin se expone la tabla comparativa que se est mencionando en prrafos anteriores: Tabla 01: Comparacin de metodologas y actividades. (Elaboracin propia) Actividad Inicio Elicitacin Obtencin Elaboracin Negociacin Especificacin Validacin Documentacin Administracin Pressman (2005) Sommerville (2005) Escalona y Koch (2002) Baz y Barba (2001)

DEFINICIN DE LA PROPUESTA Basndonos en las propuestas mencionadas, vamos a definir las etapas o funciones de la metodologa propuesta: Inicio, Obtencin de los requerimientos cliente/usuario. Anlisis de los requerimientos. Especificacin y definicin de los requerimientos. Validacin de los requerimientos Certificacin y documentacin de los requerimientos.

183

CONCEPTUALIZANDO PASOS DE LA PROPUESTA. INICIO, OBTENCION DE LOS REQUERIMIENTOS CLIENTE/USUARIO Aqu, se realizaran las siguientes actividades: Formalizar equipos multidisciplinados, aptos para solucionar problemas, de cliente/usuario, capaces de determinar requerimientos, de cualquier tipo. Buscar hechos, involucrando el problema, y declarar el contexto del mismo. Clasificar requerimientos, obteniendo los objetivos, necesidades, tanto del cliente como del usuario. Evaluar y racionalizar, examinar las coherencias en la informacin, en subetapas previas. Otorgar prioridad. Ya habiendo obtenido los requerimientos, darles un orden de prioridad. Integrar, pudindose validar la consistencia con respecto a las metas organizacionales. Documentar esta etapa, como primer avance de lo que se est realizando.

ANLISIS DE LOS REQUERIMIENTOS Reducir ambigedades, con lo obtenido en la etapa anterior, se deben tratar a los efectos de llevarlos a una notacin que permita reducir la ambigedad del lenguaje usuario. Traducir a lenguaje tcnico. Ya con menos ambigedades, tratar a los efectos, y llevarlos a un lenguaje ms tcnico. Plantear modelo lgico, Se transforma en una estructura preliminar, as, usando otras tcnicas, representar el modelo que nos permita establecer el vinculo con las otras etapas. Documentar la etapa.

ESPECIFICACIN Y DEFINICIN DE LOS REQUERIMIENTOS Determinar tipo de requerimiento, determinando unvocamente a cual de ellos pertenece el que se est tratando. Elegir la herramienta de especificacin acorde al tipo de requerimiento; seleccionando la herramienta de representacin acorde a dicho tipo y al tipo de especificacin que se desea realizar. Documentar la etapa; confeccionando el documento representativo de la etapa tomando como base a los modelos formales o semiformales que se han elaborado al realizar la especificacin de los requerimientos.

VALIDACIN DE LOS REQUERIMIENTOS Validar de acuerdo a la herramienta seleccionada, representando el requerimiento sobre la base de la eleccin realizada en la etapa anterior Terminar con la validacin. Documentar el estado de esta etapa

184

CERTIFICACION Y DOCUMENTACIN DE LOS REQUERIMIENTOS. Seleccionar las fuentes de informacin, para validar el documento. Elegir el modelo del documento, que mejor se aplica al modelo. Elegir la herramienta de documentacin. Documentar siguiendo estndares. Generar el documento, procediendo a la aprobacin del documento.

BENEFICIOS DE LA PROPUESTA Va a permitir definir los requerimientos desde varios puntos de vista, de acuerdo a los grupos que se han formado. Segn los objetivos de la empresa, ser beneficioso la clasificacin de los requerimientos. Va a permitir reducir ambigedades. Documentacin en cada etapa. Se puede elegir cualquier tipo de herramienta, siempre y cuando se pueda utilizar para cumplir con los objetivos del mismo.

LIMITACIONES Como toda metodologa, no se pueden seguir siempre todos los pasos indicados, puesto que todo software no necesariamente es igual, o similar a otro, en cuanto a el tipo de requerimiento. Dado el caso de que ninguno de los conocidos satisfaga las necesidades de documentacin del analista de requerimientos, se deber proceder a disear aquel que mejor se ajuste a sus necesidades. En caso de existir dificultades para su empleo, volver a la sub-etapa anterior para realizar una nueva seleccin o, incluso, a la primera ya que la dificultad de representacin puede obedecer al intento de usar una herramienta para un requerimiento cuyo tipo ha sido mal definido, por lo cual se selecciona una inaplicable al caso.

CONCLUSIONES Y RECOMENDACIONES Se pudo dar a conocer los pasos necesarios de una nueva metodologa, tomando como referencia el conjunto de metodologas que han sido revisadas y comparadas. La ingeniera de requerimientos, es el punto inicial de todo proceso de software; de ah depende el xito de todo proyecto de software. Los requerimientos, sern evaluados de acuerdo a los objetivos de toda empresa, y las funciones que necesita el usuario/cliente. Se recomienda seguir revisando este campo, hay mucho todava por hacer hay muchos proyectos en las que se siguen proponiendo metodologas, sin embargo, todava este sigue siendo un campo en que no hay una etapa fija, para solucionar esta fase tan importante.

185

BIBLIOGRAFA

ARIAS, M. 2006. La ingeniera de requerimientos y su importancia en el desarrollo de proyectos de software. Revista Intercedes. Universidad de Costa Rica BEZ, M. Y BARBA, S. 2001. Metodologa DoRCU para la Ingeniera de Requerimientos. Instituto Superior Politcnico "Jos Antonio Echeverra", La Habana, CU. Facultad de Ciencia y Tecnologa, Universidad Autnoma de Entre Ros, AR BRAUDE, E. 2003. Ingeniera de Software. Una perspectiva orientada a Objetos. Ed. 1. Mxico, DF.: Alfaomega Grupo Editor. BRUEGGE, B. Y DUTOIT, A. 2002. Ingeniera de Software orientado a objetos. Ed. 1. Mxico: Pearson Educacin DURN AMADOR. 2000. Un entorno metodolgico de Ingeniera de Requisitos para Sistemas de Informacin. Universidad de Sevilla: Departamento de Lenguajes y Sistemas Informticos. [En lnea]: http://www.lsi.us.es/~amador/publicaciones/tesis.pdf.zip DURN AMADOR Y BENNDEZ BEATRIZ. 2000. Metodologa para la Elicitacin de Requisitos de Sistemas Software. Universidad de Sevilla: Facultad de Informtica y Estadstica. [En lnea]: http://www.lsi.us.es/~informes/lsi-2000-10.pdf ESCALONA, M. Y KOCH, N. 2002. Ingeniera de Requisitos en Aplicaciones para la Web Un estudio comparativo. Departamento de Lenguajes y Sistemas Informticos. Escuela Tcnica Superior de Ingeniera Informtica. Universidad de Sevilla FERNNDEZ, LUIS. 2000. El futuro de la Ingeniera del software o cundo ser el software un producto de ingeniera?. Universidad Europea de Madrid. [En lnea]: http://www.ati.es/novatica/2000/145/luifer-145.pdf GOMEZ GERZON Y TOVAR EDMUNDO. 2004. Aplicaciones Web: Requisitos de calidad, hacia una taxonoma general. Universidad Politcnica de Madrid: facultad de ingeniera. Madrid. [En lnea] http://is.ls.fi.upm.es/doctorado/Trabajos20032004/ggomezNFR.pdf LAWRENCE, S. 2002. Ingeniera de Software: teora y prctica. Ed. 1. Buenos Aires: Pearson Educacin

186

LAVARIEGA, JUAN. 2005. Ingeniera de Requerimientos. Introduccin a la Ingeniera de Requerimientos. [En lnea]: http://copernico.mty.itesm.mx/~jlavarie/Clases/AnalisisReqSw/Ch1_ReqEngSomm_jc.pdf PERDRIX, F., PIQUE, E., CAL, J., CASTELLS, P., PULIDO, E., RICO, M., GRANOLLERS, T., LORS, J., GONZLES, M. Y BADIA, J. Uso de escenarios aplicados a la ingeniera de los requisitos para la creacin de una hemeroteca digital. NETS. [En lnea]: http://nets.ii.uam.es/neptuno/publications/neptuno-escenarios-interaccion04.pdf PRESSMAN, R. 2005. Ingeniera de Software Enfoque Prctico. Ed. 6. Mxico, DF: Mc Graw-Hill Interamericana SERRANO RICO, ARIEL E. 2003. Estructura Bsica para la formalizacin de una metodologa del Modelo de Madurez de Capacidad en la Ingeniera de Requisitos. Unidad Docente de Ingeniera del Software: UPM: Madrid [En lnea]: http://is.ls.fi.upm.es/doctorado/Trabajos20032004/Ariel_Serrano_Resumen(Esp).pdf SCHACH, S. 2006. Ingeniera de software clsica y orientada a objetos. Ed. 6. Mxico DF: Mc Graw-Hill Interamericana SOMERVILLE, L. 2005. Ingeniera de Software. Pearson Education: 7 Ed. Madrid. UCHITEL, S. S.F. Introduccin a la Ingeniera de requerimientos. [En lnea]: http://www2.dc.uba.ar/materias/isoft1/is1-2007_1/recursos/Teoricas/02a-RE_QueYPorque.pdf WEITZENDFELD, A. 2005. Ingeniera de Software Orientada a Objetos con UML, Java e Internet. Ed. 1. Mxico DF.: International Thomson Editores

187

EVALUACIN DE DIFERENTES ALGORITMOS DE ENCRIPTACIN PARA BRINDAR SEGURIDAD A LA BASE DE DATOS DE UN SISTEMA DE MATRCULA9

RESUMEN

La presente investigacin tiene como objetivo evaluar los diferentes algoritmos de encriptacin que brinden la seguridad necesaria a la base de datos de un sistema de matrcula. Para ello, se tuvo como base las caractersticas usadas por el Instituto Nacional de Estndares y Tecnologa (NIST) que son para la comparacin de un estndar de cifrado avanzado y las tres dimensiones clsicas de seguridad como son la confidencialidad, integridad y disponibilidad. Especficamente se tomaron las caractersticas de sistema de matrcula de la I.E.P. Santo Toribio de Mogrovejo y las caractersticas generales de su base de datos, para proponer en ella la implementacin del mejor algoritmo de encriptacin seleccionado. Palabras claves: Algoritmo de encriptacin, Seguridad, Base de datos, Sistema de matrcula.

INTRODUCCIN

Generalmente los usuarios finales no se fijan en la seguridad cuando hacen uso de un sistema, ya que, muchas veces ignoran los aspectos relacionados con ello y estn corriendo un alto riesgo al ser vulnerables a accesos de usuarios no autorizados como piratas informticos que intentan acceder a los sistemas por deporte, aquellos empleados disgustados que intentan penetrar por venganza o individuos deshonestos que intentan penetrar para obtener ganancias personales ilcitas. Algunas instituciones educativas tambin estn corriendo el mismo riesgo al pasar desapercibido el aspecto de seguridad, sobre todo en sus sistemas de matrculas. Sin embargo, se le debe dar mucha importancia, pues todo sistema es susceptible de ser

Montoya Vergara, Evelyn

188

atacado y las consecuencias son peores si se trata de robo o prdida de informacin de las personas.

Debido a esto, la Ingeniera de Software nos brinda algoritmos de encriptacin para obtener la confiabilidad en las bases de datos de dichos sistemas y es as que surge la interrogante Los algoritmos de encriptacin brindan la seguridad necesaria a las bases de datos de los sistemas de matrculas de instituciones educativas? Es por ello, que en este proyecto se pretenden evaluar diferentes algoritmos de encriptacin que brinden esa seguridad, adems se determinarn las caractersticas generales en cuanto al proceso de matrcula de la I.E.P. Santo Toribio de Mogrovejo, las caractersticas generales de la base de datos de dicho sistema y por ltimo se seleccionar el algoritmo de encriptacin que cumplir con el objetivo en caso de implementarse en la base de datos.

Todo ello, porque debemos saber que la seguridad del software es una actividad de aseguramiento de la calidad del software que se enfoca en la identificacin y evaluacin de los peligros potenciales que pueden afectar negativamente al software y provocar una falla de todo el sistema [1]. Entonces con lo dicho, podemos darnos cuenta que al aplicar un algoritmo de encriptacin en un software, no slo se estar brindando seguridad sino tambin calidad al sistema.

CRIPTOGRAFA Definicin Segn el Diccionario de la Real Academia, Criptografa es el arte de escribir con clave secreta o de un modo enigmtico. En griego, cryptos significa secreto, oculto. Por tanto, la criptografa estudia los mtodos para codificar un mensaje de tal modo que slo su destinatario legtimo consiga interpretarlo [2].

La Criptografa se ocupa del diseo de procedimientos para cifrar, es decir, para enmascarar una determinada informacin de carcter confidencial [3].

La ciencia y el arte de manipular mensajes para hacerlos seguros se llama criptografa [4].

189

La criptografa es aquella rama inicial de las Matemticas y en la actualidad tambin de la Informtica y la Telemtica, que hace uso de mtodos y tcnicas con el objeto principal de cifrar, y por tanto proteger, un mensaje o archivo por medio de un algoritmo, usando una o ms claves [5].

Por lo tanto, se puede decir que la criptografa es una forma de proteger la informacin a travs de herramientas de cifrado. Clasificacin a) Criptografa Clsica.Tambin llamada Criptografa de clave secreta; se ocupa nicamente de la confidencialidad. Dentro de ella aparecen 2 procedimientos de cifrado bsicos que se han ido repitiendo en pocas posteriores hasta llegar a nuestros das. Tales son los procedimientos de sustitucin y transposicin [3]:

- Sustitucin: establece una correspondencia entre las letras del alfabeto en el que est escrito el mensaje original y los elementos de otro conjunto, que puede ser el mismo o distinto al alfabeto. De esta forma, cada letra del texto claro se sustituye por su smbolo correspondiente en la elaboracin del criptograma. Ejemplos: Cifrado de Csar, Cifrado de Vigenre, Cifrado de Beaufort y el Cifrado Vernam.

- Transposicin: consiste en barajar los smbolos del mensaje original colocndolos en un orden distinto, de manera que el criptograma contenga los mismos elementos del texto claro, pero colocados de tal forma que resulten incomprensibles.

b) Criptografa de hoy.Basada en el concepto de comunicaciones seguras, se ocupa de la confidencialidad, autenticidad y disponibilidad de los datos. En los criptosistemas modernos, la cifra en bits est orientada a todos los caracteres ASCII o ANSI, usan por lo general una operacin algebraica en Zn, un cuerpo finito, sin que necesariamente este mdulo deba corresponder con el nmero de elementos del alfabeto o cdigo usado. Su fortaleza se basa en la imposibilidad computacional de descubrir una clave secreta nica, en tanto que el algoritmo de cifra es (o al menos debera ser) pblico [5].

190

Aparecen dos mtodos en la criptografa de hoy, ver Tabla 1:

Tabla N 1: Mtodos de cifra moderna CIFRADO EN BLOQUE Ventajas Desventajas

Alta difusin de los elementos en el - Baja velocidad de cifrado al tener que criptograma. leer antes el bloque completo. Inmune: imposible introducir bloques - Propenso a errores de cifra. Un error extraos sin detectarlo. se propagar a todo el bloque. CIFRADO EN FLUJO Ventajas Desventajas

Alta velocidad de cifra al no tener en - Baja difusin de elementos en el cuenta otros elementos. criptograma. Resistente a errores. La cifra es - Vulnerable. Pueden alterarse los independiente en cada elemento. elementos por separado. Fuente: (Rami, 2006).

ALGORITMOS DE ENCRIPTACIN Definicin Codificadores de bloques sobre los que iteran operaciones como sustitucin, transposicin, suma/producto modular y transformaciones lineales [5].

Se puede decir, que un algoritmo de encriptacin es un medio de transformacin de la informacin con el objetivo de protegerla hasta que llegue a su destinatario. Tipos a) RSA.Segn Pons [6], este algoritmo es el ms popular y utilizado de los algoritmos asimtricos. Fue inventado en 1978 por Rivest, Shamir y Adlman que dan nombre al algoritmo. Patentaron el algoritmo y cuando alcanz popularidad fundaron una empresa, RSA Data Security Inc., para la explotacin comercial. Para su implementacin y comercializacin se deben pagar derechos a esta empresa. Fuera de los EE.UU. slo est permita la utilizacin del algoritmo con claves menores o iguales a 512 bits.

191

El algoritmo utiliza las siguientes claves: - Como pblicas dos nmeros grandes elegidos por un programa: e y n. - Como privada un nmero grande d, consecuencia de los anteriores. El clculo de estas claves se realiza en secreto en la mquina depositaria de la privada. Este proceso tiene mucha importancia para la posterior seguridad del sistema. El proceso es el siguiente: 1. Se buscan dos nmero grandes (entre 100 y 300 dgitos) y primos: p y q. 2. Se calcula f = (p-1) * (q-1) y n = p * q. 3. Se busca e como un nmero sin mltiplos comunes a f. 4. Se calcula d = e-1 mod f. (mod = resto de la divisin de enteros). 5. Se hace pblicas las claves n y e, se guarda d como clave privada y se destruyen p, q y f.

Mediante prueba y ensayo es muy difcil calcular d ya que es un nmero de 512 bits o ms. Por tanto, este algoritmos es difcil de romper, aunque en agosto de 1999 la empresa RSA Inc. consigui romper un RSA con clave de 512 bits, necesitando para ello, 5.2 meses y 292 ordenadores entre computadoras y estaciones de trabajo.

Actualmente el RSA est muy extendido como algoritmo asimtrico, es el ms rpido y sencillo de los existentes. Sin embargo, en comparacin con el algoritmo de clave secreta DES, en cuanto a software DES es como mnimo 100 veces ms rpido que el RSA y en cuanto a hardware es entre 1000 y 10 000 veces ms rpido [3].

b) DES.El estndar de cifrado de datos, DES (Data Encryption Standard), lo desarroll IBM a principios de la dcada de los setenta y lo aprob el Bur Nacional de Estndares, hoy Instituto Nacional de Estndares para Tecnologa (NIST), en 1997 [4].

Utilizar claves de 56 bits hace que DES sea vulnerable a un ataque de fuerza bruta. Una mejora bien conocida se llama DES triple, que en realidad utiliza dos claves, extendiendo la longitud total de la clave a 112 bits.

192

Segn Maiwald [7], el DES es un cifrado en bloque que funciona sobre un bloque de 64 bits del texto original a la vez. Existen 16 rondas de encriptacin en el DES con una subclave diferente utilizada en cada ronda, despus la clave pasa a travs de su propio algoritmo para derivar las 16 subclaves.

Existen cuatro modos de operacin para el DES: - Libro de cdigo electrnico: esta es la encriptacin en bloque bsica, donde el texto y la clave estn combinados para formar el texto cifrado. En este caso una entrada idntica produce una salida idntica. - Encadenamiento de bloques cifrados: en este modo, cada bloque es encriptado como un libro de cdigo electrnico, pero se agrega un tercer factor, derivado de la entrada anterior. En este caso, una entrada idntica (texto original) no produce una salida idntica. - Retroalimentacin del cifrado: este modo utiliza texto cifrado y previamente generado como entrada para el DES. La salida se combina entonces con el texto original para producir un nuevo texto cifrado. - Retroalimentacin de salida: este modo es semejante al de la retroalimentacin del cifrado pero utiliza la salida del DES y no texto cifrado encadenado. En la Fig. 1, se puede observar el esquema general de este algoritmo simtrico.

193

Fig. 1: Esquema general del algoritmo DES. (Fuente: Snchez ,1999)

c) IDEA.Propuesto por Lai, Massey y Murphy en el Eurocrypt 91 denominado IDEA (Internacional Data Encription Algorithm). Tanto los datos en claro como los datos cifrados estn compuestos por bloques de 64 bits, mientras que la clave consta de 128 bits. El cifrado se basa en el concepto de mezclar operaciones aritmticas de grupos algebraicos diferentes. El algoritmo consiste en 8 vueltas de encriptacin idnticas seguidas de una transformacin de salida [3].

194

Este algoritmo presenta, a primera vista, diferencias notables con el DES que le hacen ms atractivo: a) El espacio de claves es mucho ms grande: 2128 = 3.4 x 1038. b) Todas las operaciones son algebraicas, sin cajas S de oscura justificacin filosfica. c) No hay operaciones a nivel de bit, facilitando su programacin en alto nivel. d) Es ms eficiente que los algoritmos de tipo Feistel, porque a cada vuelta se modifican todos los bits del bloque y no solamente la mitad. e) Se puede utilizar todos los modos de operacin definidos para el DES. En cuanto a su seguridad, el ataque por fuerza bruta resulta impracticable, ya que sera necesario probar 1038 claves, cantidad imposible de manejar an. Es necesario saber que este algoritmo es libre de restricciones y permisos nacionales y es de libre distribucin por Internet, lo cual ha hecho que sea muy popular fuera de Estados Unidos [6].

d) RIJNDAEL.Con el fin de reemplazar a DES, NIST dio a conocer una competencia para el estndar de encriptacin avanzado (AES, Advanced Encryption Standard) en 1997. A fines de 2000, NIST anunci que dos criptgrafos de Blgica, Joan Daemen y Vincent Rijmen, haban ganado la competencia con su algoritmo Rijndael. El algoritmo fue elegido sobre la base de su fortaleza, as como por su conveniencia para redes de alta velocidad y por su implementacin en hardware [7]. Rijndael es un cifrado en bloque que utiliza claves y bloques de 128, 192 o 256 bits. Estas longitudes de clave hacen que los ataques por medio de la fuerza bruta sean inverosmiles. El algoritmo se compone de 10 a 14 rondas o series, dependiendo del tamao del bloque de texto original y de las dimensiones de la clave. La clave usada en el algoritmo es similarmente mostrada como un arreglo rectangular de bytes de 4 filas, el nmero de columnas de la clave est determinado por Nk y es igual al tamao de la clave dividido por 32. Algunas veces la clave es presentada como un arreglo lineal de palabras de 4 bytes. En este caso, las palabras estn distribuidas dentro de cada columna [8]. En cuanto a su proceso de encriptacin, este est compuesto de tres pasos: - Una transformacin AddRoundKey. - Nr 1 vueltas. - Una vuelta final. Y su proceso de desencriptacin consiste en la aplicacin de las transformaciones del algoritmo de encriptacin en orden inverso para obtener el texto plano.

195

ENCRIPTACIN EN BASE DE DATOS La seguridad de las bases de datos debe considerar que ninguna persona o grupo de personas deben ser capaces de leer, escribir, destruir o modificar datos directamente de una manera no autorizada. As mismo, debe ser imposible para cualquier persona o grupo de personas inferir el valor de cualquier objeto dato por manipulacin directa o computacional. Los mecanismos de seguridad no deben degradar el desempeo de las operaciones bsicas de la base de datos y no debe producirse un aumento grande en el almacenamiento de datos. Sin olvidar que el costo computacional debe ser razonable [9]. Por lo tanto, el algoritmo de encriptacin a usar en una base de datos, debe ser tericamente seguro o requerir un trabajo extremadamente alto para romperlo. La encriptacin y desencriptacin deben ser suficientemente rpidas para no degradar el desempeo del sistema, y los datos encriptados no deben ocupar ms espacio que los datos desencriptados. Existen diferentes maneras de encriptar la base de datos: a) Se puede configurar la base de datos para permitir que slo determinadas tablas sean encriptadas, en lugar de toda la base de datos. Tenemos tablas encriptadas, si cada parte de la tabla est cifrada cuando se escribe en el disco, y se descifra cuando se lee en el disco. Este proceso es invisible a las solicitudes. Sin embargo, puede haber un ligero impacto negativo en el rendimiento en la lectura de, o escribiendo a, tablas encriptadas. Encriptar o desencriptar las tablas existentes puede tardar bastante tiempo, dependiendo del tamao de la tabla [10]. b) La encriptacin puede estar orientada a registros, es decir, debe ser posible la encriptacin y desencriptacin sobre un solo registro sin considerar una posicin fsica o lgica en la base de datos; esta propiedad es requerida para que, en el caso de que un registro cambie de posicin, no se tenga que desencriptar n-1 registros para desencriptar el registro n. Adems el registro encriptado es una funcin individual de los valores de todos los campos y en los cuales cada campo separado es encriptado/desencriptado por llaves separadas [9]. c) Encriptar el registro como un todo, sin separaciones entre campo y campo. Con una sola llave de encriptacin/desencriptacin que ser elegida por el propietario o administrador de la base de datos [9]. Siguiendo el estudio de Capetillo y Gmez [9] es necesario saber que la encriptacin debe soportar la lgica del enfoque del subesquema para bases de datos. En un sistema de bases de datos, el DBMS (sistema manejador de bases de datos) es la primera lnea de defensa de nuestra informacin. El DBMS presenta a un usuario solo los campos que ha solicitado y, sobre todo, solo a los que tiene acceso. El sistema de encriptacin debe impedir que si un atacante obtiene partes del registro ilegtimamente, este pueda usarlos. Es necesario que un registro encriptado no sea un conjunto de campos encriptados individualmente. Un registro encriptado debe ser un valor nico encriptado en funcin de

196

todos los campos. Esto previene dos cosas: la comparacin de patrones y la substitucin de valores encriptados. El esquema de encriptacin debe ser flexible, estimando cualquier combinacin de privilegios. Idealmente debe ser posible otorgar a cada usuario privilegios por cada campo, as como poder detectar y rechazar registros que hayan sido creados o modificados bajo una falsa llave de encriptacin. El DBMS no debe ser forzado por el sistema de encriptacin a guardar copias duplicadas de objetos de datos. Por ltimo, los registros probablemente sern construidos sobre un periodo de tiempo, por lo que debe ser posible recuperar informacin de registros parcialmente completos.

DISCUSIN

Paso 1 Primero ser necesario elegir entre el tipo de encriptacin simtrica y asimtrica para poder seleccionar un algoritmo.

Segn el estudio realizado por Aladdin [11] nos dice que aunque la encriptacin asimtrica proporciona mayor funcionalidad, an hay muchas aplicaciones en las que la encriptacin simtrica es la mejor solucin y trabaja con seguridad de manera ms eficiente, adems nos dice que este ltimo tipo de encriptacin es mucho menos costosa de aplicar. Con el fin de demostrar lo dicho se presenta la Tabla N 2.

Tabla N 2: Comparacin de los principales aspectos de los dos tipos de encriptacin

197

Aspectos

Encriptacin Simtrica

Encriptacin Asimtrica

Funcionalidad

Permite la seguridad en los Permite la comunicacin entornos donde la eficiente entre dos partes en encriptacin simtrica un ambiente cerrado. simplemente no funciona o es ms difcil de aplicar. Clculos increblemente rpidos, ya que las operaciones relativamente simples utilizadas son ejecutadas de manera muy eficiente. Clculos lentos, usando operaciones pesadas y complejas basadas en la dificultad de resolver problemas numrico-tericos.

Eficiencia computacional

Tamao de clave

Usa una clave de 128 bits, la Emplea tamaos de clave de cual es considerada muy al menos 1000 bits para lograr segura. suficiente seguridad duradera. Realiza algoritmos simples que requieren relativamente poco costo de hardware. Implementa algoritmos complejos y de mucho tiempo que necesitan de un hardware ms poderoso.

Hardware

Seguridad

No existe diferencia. La seguridad se basada en la fuerza del algoritmo y el tamao de su clave. Existen buenos algoritmos para ambos tipos.

Fuente: (Traducida de Aladdin, 2000).

Como se necesita un algoritmo de encriptacin que brinde seguridad a la base de datos, se puede decir que dara lo mismo usar uno del tipo simtrico o asimtrico, pero observando otros aspectos como la funcionalidad, la eficiencia y el hardware, se puede claramente optar por un algoritmo simtrico.

Paso 2 Ahora se debe elegir el mejor algoritmo simtrico que sea capaz de brindar seguridad a una base de datos y como en esta investigacin han sido objeto de estudio los algoritmos DES, IDEA y Rijndael (nuevo AES), se har la evaluacin entre los tres.

198

Las caractersticas para la comparacin en principio sern las usadas por el Instituto Nacional de Estndares y Tecnologa (NIST) que son para la comparacin de un estndar de cifrado avanzado. Estas son: 1. Ser pblico. 2. Ser un algoritmo de cifrado en bloque simtrico. 3. Estar diseado de manera que se pueda aumentar la longitud de clave segn las necesidades. 4. Ser implementable tanto en hardware como en software. 5. Estar o bien a) disponible gratuitamente, o bien b) disponible bajo trminos consistentes con la poltica de patentes del Instituto Nacional Americano de Estndares (American National Standards Institute, ANSI). 6. Los algoritmos que cumplan con los requisitos arriba citados sern juzgados de acuerdo con los siguientes factores: o Seguridad. o Eficiencia computacional. o Requisitos de memoria. o Adecuacin hardware y software. o Simplicidad de diseo. o Flexibilidad y requisitos de licencia. Para lograr la evaluacin, se cre la Tabla N 3:

Tabla N 3: Evaluacin de algoritmos de encriptacin.

199

Caractersticas Espacio de claves Longitud de clave Tamao de bloque Nmero de rondas Tiempo en romperlo Vulnerable Desencriptado Confidencialidad Integridad Disponibilidad Fuente: (Creacin propia).

DES 255 56 bits 64 bits 16 40 horas S Inverso S S Rpido

IDEA 2128 128 bits 64 bits 8 264 aos No Inverso S S Rpido

RIJNDAEL (AES) 2128 a ms 128 a ms siendo 256 bits el estndar 128, 192 y 256 bits Flexible Ms de 264 aos No Inverso S S Muy rpido

Se obtiene como el mejor al algoritmo Rijndael o nuevo AES por cumplir sofisticadamente con todas las caractersticas del cuadro de evaluacin. En caso de que este algoritmo sea implementado en la base de datos de la I.E.P Santo Toribio de Mogrovejo se deber optar por configurarlo de tal manera que la encriptacin de cada registro de las tablas sea como un todo y no campo por campo, con el fin de prevenir la comparacin de patrones y la substitucin valores de encriptados.

Para completar la seguridad de esa base el algoritmo trabajar segn los accesos de tipos de usuarios, que seran los de la Tabla N 4:

200

Tabla N 4: Permisos a la BD de la institucin. Tipo de Usuario Director Administradora Secretaria Docentes rea de sistemas Permisos en BD Lectura de todas las tablas Lectura de todas las tablas Lectura/Escritura a todas las tablas. Lectura/Escritura a algunas tablas. Acceso completo de administracin.

Fuente: (Creacin propia).

Junto con el algoritmo Rijndael ser necesario usar un protocolo de autenticacin. Pues el usuario de un sistema criptogrfico ha de tener presente que la robustez del algoritmo de cifrado no es el elemento definitivo en la seguridad; hay otros aspectos a tener en cuenta, principalmente la utilizacin del algoritmo y los protocolos con que se usa [3]. Segn Manuel J. Lucena [12], el protocolo Secure Sockets Layer (SSL): permite establecer conexiones seguras a travs de Internet, de forma sencilla y transparente. La idea consiste en interponer una fase de codificacin de los mensajes antes de enviarlos por la red. Una vez que se ha establecido la comunicacin, cuando una aplicacin quiere enviar informacin a otra computadora, la capa SSL la recoge y la codifica, para luego enviarla a su destino a travs de la red. Anlogamente, el mdulo SSL del otro ordenador se encarga de decodificar los mensajes y se los pasa como texto plano a la aplicacin destino.

Una comunicacin SSL consta fundamentalmente de dos fases: Fase de saludo (handshaking).- consiste bsicamente en una identificacin mutua de los interlocutores, para la cual se emplean habitualmente los certificados X.509; tras el intercambio de claves pblicas, los dos sistemas escogen una clave de sesin, de tipo simtrico. Fase de comunicacin: en esta fase se produce el autntico intercambio de informacin, que se codifica mediante la clave de sesin acordada en la fase de saludo. Cada sesin SSL lleva asociado un identificador nico que evita la posibilidad de que un atacante escuche la red y repita exactamente lo mismo que ha odo, an sin saber lo que significa, para engaar a uno de los interlocutores.

201

Las ventajas de este protocolo son evidentes: confidencialidad y autenticacin, caractersticas que son necesarias para enviar la informacin a travs de Internet o en el caso de que se trabaje en una red.

El sistema de matrcula de la I.E.P. Santo Toribio de Mogrovejo presenta seguridad slo al momento de acceder a el, ya que, se deber ingresar el usuario y contrasea, para que aparezca el Nombre y cargo de la persona que accede. Despus de llenar los datos correctamente, el usuario deber hacer clic en el botn ingresar, y entonces el sistema le dar la bienvenida y mostrar las aplicaciones. En caso de que el usuario no se encuentre registrado en la BD o llene errneamente los datos, el sistema emitir un mensaje de error, en donde slo le permitir dos intentos de ingresos fallidos, ya que al trmino se proceder a cerrar la aplicacin.

En la Fig. 2 se presenta el modelo lgico de la base de datos utilizada por el sistema de matrcula desarrollado para la I.E.P. Santo Toribio de Mogrovejo.

202

ESTUDIANTE USUARIO
# cod_estud * nombres * Apellido paterno * Apellido materno * sexo * fnacimiento # Nombreusuario * contrasea * Codigoresponsable * nombre * Cargo

INSTITUCIN EDUCATIVA
# Cod_modular * Nombre

* Telfono

MATRCULA

RESPONSABLE
# cod_resp * nombres * Apellidos

* Direccion Cod_mat # * Ao_lectivo *Recuperacin_pedag * Cod_estud

PROYECTO
#Cod_proyecto

SECCIN
# cod_sec * nombre

DOCENTE
# dni * Nombres

NOTAS
# cod_curso # cod_mat * TrimestreI

GRADO
# cod_grado

* app_paterno * app_materno * Direccin

CURSO
# cod_cur * nombre

ASIGNACIN
# Cod_asig * dni

Fig. 2: Modelo Lgico de la base de datos de la I.E.P Santo Toribio de Mogrovejo. (Fuente: Creacin propia)

203

Se puede decir que no existe un modelo conveniente de base de datos en el cual se pueda aplicar un determinado algoritmo de encriptacin, sin embargo, teniendo en base este modelo, se elegirn las tablas que debern ser encriptadas por cuestiones de seguridad de la institucin. Siendo el algoritmo Rijndael el mejor para este objetivo la encriptacin de estas tablas deber ser registro por registro. La tablas se muestran en la Fig. 3, 4, 5 y 6. Tabla de Estudiantes

Fig. 3: Tabla de estudiantes en Access (Fuente: Creacin propia)

Tabla de Docentes

Fig. 4: Tabla de docentes en Access (Fuente: Creacin propia)

Tabla de Matrculas

Fig. 5: Tabla de matrculas en Access (Fuente: Creacin propia)

204

Tabla de Usuarios

Fig. 6: Tabla de usuarios en Access (Fuente: Creacin propia)

Si se usara el algoritmo Rijndael para la encriptacin del registro nmero dos de la tabla de Usuario, el que tiene por Nombre de usuario a Claudia, el registro encriptado obtenido sera la Tabla N 5:

Tabla N 5: Registro encriptado Nombreusuario I4OHaL8hS5F3 GF13hpwk2A== contrasea hSG7vvIoydA = Codigoresponsable Nombre Cargo HFtnxCp3V Amu4c0tL/ doCg==

Uw4pojEUW49h0tYB I4OHaL8hS5Fnx 1gfPR4vrrJLdpEnD tGNTx1AITTxuU Al5ViI/fDstar39n 8=

Fuente: (Creacin propia).

Este ejemplo se hizo de manera externa al sistema, pero en el caso de que el algoritmo sea implementado en la base de datos, est automticamente deber ser capaz de encriptar y desencriptar los registros seleccionados y trabajar de manera normal en el sistema de matrcula.

CONCLUSIONES - Los algoritmos de encriptacin brindarn la seguridad necesaria a las bases de datos de los sistemas de matrculas de instituciones educativas, pues la funcionalidad de todo sistema ser mayor cuanto ms niveles de confianza se ofrezcan a la seguridad de la informacin valiosa que estos manipulan.

205

- La correcta evaluacin de los algoritmos de encriptacin se debe regir de las caractersticas usadas por el Instituto Nacional de Estndares y Tecnologa (NIST) que son para la comparacin de un estndar de cifrado avanzado y por las tres dimensiones clsicas de seguridad como son la confidencialidad, integridad y disponibilidad. - En esta investigacin se seleccion como mejor algoritmo de encriptacin para la base de datos a Rijndael o nuevo AES por ser del tipo simtrico y por cumplir sofisticadamente con las caractersticas de la evaluacin a comparacin con los algoritmos DES e IDEA. - Al hacer que el algoritmo de encriptacin trabaje con los accesos de tipos de usuarios creados para la base de datos y con el protocolo SSL, se brindar an mayor seguridad al sistema. - En caso de hacerse la implementacin del mejor algoritmo seleccionado en esta investigacin, los mecanismos de seguridad que proporcione no deber degradar el desempeo de las operaciones bsicas del sistema de matrcula y tampoco deber producir un aumento grande en el almacenamiento de los datos. - Se propone la implementacin del algoritmo de encriptacin simtrico Rijndael, no slo para brindarle seguridad a la base de datos del sistema de la institucin sino que tambin para obtener una mejor calidad.

BIBLIOGRAFA

1. PRESSMAN R., Ingeniera del software. Un enfoque prctico. Adaptado por Ince D. Mxico: Mc Graw-Hill Interamericana, 2005. 2. COUTINHO, S. C. Nmeros enteros y criptografa RSA. Lima: Hozlo S.R.L, 2003. 3. FSTER et al., Tcnicas Criptogrficas de proteccin de datos. Mxico: Alfaomega Grupo Editor, S.A., 2001. 4. LEN-GARCA A., Redes de comunicacin: conceptos fundamentales y arquitecturas bsicas. Espaa: Mc Graw-Hill Interamericana, 2002. 5. RAMI J., Libro Electrnico de Seguridad Informtica y Criptografa. Espaa: Universidad Politcnica de Madrid, v. 4.1, 2006. 6. PONS, M. Criptologa. Escuela Universitaria Politcnica de Matar. <http://www.geocities.com/escandalo_mexicano/Criptologia_by_Manuel_Pons.zip> (2 de noviembre de 2007). 7. MAIWALD, E. Fundamentos de seguridad en redes. Mxico, DF: Mc Graw-Hill Interamericana, 2005.

8. JCOME, G; VELASCO, J., LPEZ, J. Implementacin en hardware del algoritmo Rijndael. Colombia: Universidad del Valle. <http://www.iberchip.org/iberchip2004/articles/109-3-JAIMEVELASCO-VELASCO4RIJNDAEL.PDF> (11 de noviembre de 2007).

206

9. CAPETILLO, M., GMEZ, R. Encripcin de Bases de Datos. Mxico: Instituto Tecnolgico de Estudios Superiores de Monterrey, 2002. 10. SYBASE IANYWHERE. 2007. Understanding Encryption and Transport-Layer Securit. iAnywhere Solutions, Inc. < http://www.ianywhere.com/datasheets/sqlany_10.html> (20 de noviembre de 2007). 11. Aladdin. 2000. The Enduring value of Symmetric Encryption. <http://www.aladdin.com/blog/pdf/WP-SymmetricEncryption.pdf> (29 de noviembre de 2007). 12. Lucena, M. Criptografa y Seguridad en Computadores. Espaa: Universidad de Jan, 1999.

ANEXOS

En el caso de realizarse la implementacin de los algoritmos, el modo de evaluarlos sera segn su rendimiento y su coste. Segn Molero et al. (2004), Para medir el rendimiento, consideremos dos computadores X e Y, los cuales tardan Tx y Ty unidades de tiempo, respectivamente, en ejecutar un programa. Si Tx = Ty diremos que el rendimiento de ambas mquinas es igual o equivalente, ya que en ambas obtenemos el mismo tiempo de ejecucin.

Si por el contrario, Tx < Ty, quiere decir que el computador X tarda menos tiempo en ejecutar el programa. Esta relacin nos permite afirmar que X es ms rpido que Y. Sin embargo, si el objetivo es cuantificar esta relacin y decir que X es tantas veces ms rpido que Y. El valor numrico al que nos estamos refiriendo recibe el nombre de aceleracin (speedup) y se puede calcular como la relacin entre el tiempo de ejecucin ms grande y el ms pequeo: Aceleracin = Ty / Tx Por lo tanto, la aceleracin representa el incremento de rendimiento de una mquina respecto de la otra. La manera de expresar esta aceleracin en palabras adquiere mltiples formas; si se desea expresar en trminos de porcentajes, es decir, X es un n % ms rpido que Y, en cuyo caso la relacin anterior se expresa: Aceleracin = Ty / Tx = 1 + (n/100)

De acuerdo con estas frmulas, se puede obtener el algoritmo de encriptacin que logre la ejecucin del sistema de matrculas en menos tiempo.

Por otro lado, para medir el coste, la comparacin de los precios entre computadores se puede llevar a cabo de la misma manera que la empleada para el rendimiento. Por ejemplo, si los costes de los computadores X e Y son Cx y Cy, respectivamente, el incremento (o tambin aceleracin) del coste de una opcin respecto de la otra se puede expresar dividiendo el coste ms elevado entre el ms bajo. Si suponemos que Cx > Cy, entonces se puede escribir: Incremento = Cx / Cy = 1 + (n/100)

207

En consecuencia, esta expresin permite decir que X es tantas veces ms caro que Y, o que X es un n % ms caro que Y.

Para el caso que deseemos la relacin entre prestaciones y coste, las frmulas sern: RENDIMIENTO x COSTE x RENDIMIENTO y COSTE y 1 Tx x COSTE x 1 Ty x COSTE y

Segn esto el algoritmo de encriptacin que obtenga el valor ms elevado ser el mejor.

208

DESARROLLO DE UN SISTEMA WEB DE MATRICULAS10

Resumen: El siguiente trabajo se aplicara en la rama de desarrollo de software de la disciplina de ingeniera de software, para lo que se har un sistema de matriculas similar (hasta cierto punto) con el actual usado por la universidad, el trabajo es bastante limitado por los recursos humanos usados y de conocimiento por parte del desarrollador, flaquea en puntos como el diseo de la interfaz y uso la metodologa de extreme programming. El trabajo realizado har uso de herramientas libres debido a la restriccin econmica de compra de licencias para uso de herramientas privativas adems de la seguridad y gran uso que tienen dichas herramientas, lo cual ayuda en el conocimiento y aprendizaje que pueden tener los programadores de la misma.

Palabras Clave: software, desarrollo de software, Ingeniera de software , Extreme programing.

10

Posada Linares Jorge Lus

209

1.-Introduccin:

En la actualidad la Web se ha vuelto de uso generalizado tanto por personas naturales como por empresas, debido a su gran capacidad de difusin, gracias a esto las organizaciones de todo tipo se han visto cada vez mas obligadas a adoptar sistemas va Web para mantenerse actualizadas y a la vanguardia del medio, tanto empresas gubernamentales, educativas y comerciales han ido adoptando este tipo de sistemas para una mayor difusin de sus productos y servicios, pero la Web en las ultimas dcadas ha empezado a enrumbarse hacia la mejora y automatizacin de diversos procesos que hacen mas gil. En Per muchas empresas han tomado estos tipos de sistemas, siendo las organizaciones gubernamentales las que han tomado mas provecho de estos, pero otro tipo de organizaciones tales como las educativas han ido avanzando con el uso de estas tecnologas. La web se ha vuelto un medio imprescindible para el mejor provecho de los recursos empresariales de una organizacin por lo que es necesarioo que todo estudiante del area de informatica tenga conocimientos solidos en el desarrollo de este tipo de aplicaciones y aplicando los conceptos de la ingenieria de software para desarrollar una aplicacin optima. 1.1.- Tecnologas Orientadas a Objetos: En la programacin tradicional estructurada como se conoce, se trata de separar los datos del programa de las funciones que los manipulan. El programa o aplicacin completa consiste de mltiples datos y mltiples funciones que actan sobre las mismas. Esta forma de programar tiene dos problemas principales. El primer problema es obligar a un programador a pensar como maquina en lugar de lo opuesto. El segundo problema es que toda la informacin presente es conocida y potencialmente utilizada por todas las funciones del programa y si se hiciera algn cambio en la estructura de alguno de los datos (se consideran todos como globales) habra que modificar todas la funciones del programa para que puedan utilizar este nuevo tipo de datos.

210

1.2.-Programacin Orientadas a Objetos: El software orientado a objetos tiene ciertas cualidades que ayudan a mejorar la robustez y funcionalidad de las aplicaciones, estas son necesarias para poder considerar una aplicacin como orientada a objetos. 1.2.1.- Abstraccin: Esta es una de las consideraciones mas importantes para tratar el problema de la complejidad del software es decir, la idea bsica de abstraccin nos dice que todo lenguaje o aplicacin orientada a objetos debe tener capacidad de trabajar con tipos de dato de alto nivel, que sea mas fcil de comprender para el programador y que refleje de mejor manera la realidad, entonces nos podramos preguntar porque no programar con 1 y 0 en lugar de con lenguajes de programacin? la abstraccin es la que responde a esta pregunta, para poder reflejar de mejor manera la realidad lo que har que cualquier programador pueda entender un programa y estos sean mantenidos y codificados de manera mas rpida. 1.2.2.- modularidad: Esta propiedad de los sistemas orientados a objetos es aquella que nos permite dividir al sistema en sus componentes separados. La orientacin a objetos al trabajar con un nivel de abstraccin mayor al tradicional en su mayora reduce el numero final de mdulos , funciones y objetos que las funciones que se habran utilizado de la manera tradicional de esta manera haciendo el sistema mas comprensible para otros programadores y mas fcil de trabajar haciendo que cada uno tenga menos componentes a la vez por los que preocuparse, reduciendo la complejidad de la aplicacin. 1.2.3.- Extensibilidad: La extensibilidad nos permite hacer cambios en el sistema de manera modular afectando en lo ms mnimo posible al resto del sistema. Con la orientacin a objetos los cambios se dan a 2 niveles : modificacin externa e interna de los objetos. Los cambios internos

211

afectan principalmente al propio objeto mientras que los cambios externos a los objetos afectaran de mayor forma al resto del sistema.

1.2.4.- Reutilizacin: La reutilizacin nos permite reducir el tiempo de diseo y codificacin de una aplicacin ya que se utilizaran componentes y objetos ya existentes lo que nos permite reducir el cdigo, al hacer eso adems reducimos la complejidad de la aplicacin afectando a todas las otras propiedades y adems aumentando la probabilidad de que el cdigo sea correcto. 1.3.- Modelo del proceso: Define un orden para llevar a cabo los distintos aspectos del proceso. El modelo se puede definir como un grupo de estrategias, actividades, mtodos y tareas que se organizan para lograr un conjunto de metas y objetivos. El modelo de proceso contempla cosas como la planeacion, autoridad, prediccin, evaluacin y rastreabilidad. La planeacion involucra definir como se llevarn acabo las diversas etapas del proceso sin limitarse a aspectos de desarrollo sino tambin organizacionales, evaluativos, correctivos, etc. La autoridad define como se puede influir a las personas para que se llegue a donde se quiere, se debe tener un lder que sepa controlar al equipo de desarrollo de manera adecuada. La prediccin trata de ver a donde se quiere llegar y los obstculos que se pueden presentar. La evaluacin describe donde se encuentra el proyecto actualmente y que tal correcto esta siendo este, adems tambin existen tipos de evaluacin orientadas al resultado es decir a la aplicacin que medirn que tal correctamente esta cumpliendo esta con los objetivos planteados.

212

La rastrabilidad har que se pueda saber como se logro un objetivo en particular. En particular el proceso es considerado como un grupo de personas, estructuras organizacionales, reglas, polticas, actividades, componentes de software, metodologas y herramientas usadas o creadas para desarrollar, ofrecer un servicio o extender un producto de software, es decir la forma en que la empresa u organizacin realiza sus diversos proyectos de generacin de software

1.3.1- Modelo del proceso segn tipo de software: . Un mito de la ingeniera del software es que todo tipo de proceso es valido para cualquier tipo de proyecto de software, el modelo del proceso depende mucho del proyecto que se esta llevando es por eso que podemos clasificarlos en los siguientes tipos 1.3.1.1- Primer Proyecto de su tipo: En este tipo de proyectos se va a crear la mayora del software desde 0, aunque obviamente se pueden aprovechar componentes genricos para su desarrollo. Por se la primera vez que se crea este tipo de software se requiere mas tiempo para analizar el dominio del problema para que de esta manera este pueda servir para futuros proyectos de este tipo. En este tipo de proyectos la incertidumbre crea riesgos adicionales cuya revisin y correccin deberan ser contempladas en el modelo de proceso. 1.3.1.2- Segundo Proyecto de su tipo: En este caso generalmente se busca agregar una nueva funcionalidad a un proyecto ya conocido. El desarrollador tpicamente tiende a excederse agregando demasiada funcionalidad comparada al proyecto anterior (featuritis). El sistema se vuelve mucho ms grande que el original significando retrasos en el sistema. 1.3.1.3- Variacin de un proyecto: Donde se va a extender un sistema ya existente. Esto puede involucrar introducir componentes de software reutilizable como un marco(Framework),crear nuevos

213

componentes o simplemente extender la aplicacin mediante nueva funcionalidad. Dependiendo de la estrategia en particular, el modelo de proceso debe variar. 1.3.2- Modelos de proyecto: 1.3.2.1- Cascada: Data de los aos 60 y 70, este modelo define como una secuencia de actividades seguidas en orden donde la estrategia principal es definir y seguir el progreso de desarrollo de software hacia puntos de revisin bien definidos. El desarrollo de software implica una secuencia de actividades a realizarse y cuyo seguimiento era verificar que cada actividad haya sido completada. La ejecucin del modelo es muy lineal por lo que es sencillo de utilizar. Sus principales problemas son (yourdon, 1992) : Los documentos a entregar rigen el proceso de software Toma demasiado tiempo ver resultados Depende de requisitos estables correctos Hace difcil rastrear los requisitos iniciales y el cdigo final Retrasa la deteccin de errores hasta el final No promueve rehso del software No promueve el uso de prototipos No se practica de manera formal

1.3.2.1- Espiral: El modelo de espiral es una modificacin del modelo cascada desarrollado durante los 80. El modelo de espiral se basa en una estrategia para reducir el riesgo, al contrario del modelo de cascada que es regido por documentos. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. Cada ciclo comienza con la identificacin de los objetivos para una parte del producto, formas alternativas de lograr el objetivo. 1.4.- EL lenguaje php: PHP fue originalmente diseado en Perl, seguidos por la escritura de un grupo de CGI binarios escritos en el lenguaje C por el programador dans-canadiense Rasmus Lerdorf

214

en el ao 1994 para mostrar su currculum vitae y guardar ciertos datos, como la cantidad de trfico que su pgina web reciba. PHP 3.2.4.3 Dos programadores israeles del Technion, Zeev Suraski y Andi Gutmans, reescribieron el analizador sintctico (parser en ingls) en el ao 1997 y crearon la base del PHP3, cambiando el nombre del lenguaje a la forma actual. Inmediatamente comenzaron experimentaciones pblicas de PHP3 y fue publicado oficialmente en junio del 1998. Para 1999, Suraski y Gutmans reescribieron el cdigo de PHP, produciendo lo que hoy se conoce como Zend Engine o motor Zend, un portmanteau de los nombres de ambos, Zeev y Andi. Tambin fundaron Zend Technologies en Ramat Gan, Israel. PHP 4 En mayo de 2000 PHP 4 fue lanzado bajo el poder del motor Zend Engine 1.0. La ltima versin de PHP 4 disponible en febrero de 2007 es la 4.4.7. Php.net anuncio el da 13 de Julio de 2007 que la versin 4 de PHP qued discontinuada. PHP 5 El 13 de julio de 2004, fue lanzado PHP 5, utilizando el motor Zend Engine II (o Zend Engine 2). La versin ms reciente de PHP es la 5.2.4 (30 de agosto de 2007), que incluye todas las ventajas que provee el nuevo Zend Engine 2 como:

Soporte slido y REAL para Programacin Orientada a Objetos ( o OOP) con PHP Data Objects. Mejoras de rendimiento. Mejor soporte para MySQL con extensin completamente reescrita. Mejor soporte a XML ( XPath, DOM... ). Soporte nativo para SQLite. Soporte integrado para SOAP. Iteradores de datos. Excepciones de errores.

PHP 6

215

Est previsto el lanzamiento en breve de la rama 6 de PHP, cuando se lance esta nueva versin, quedarn solo dos ramas activas en desarrollo (PHP 5 y 6) pues se ha comunicado que PHP 4 ha sido discontinuado desde el 13 de Julio de 2007. Las diferencias que encontraremos frente a PHP 5.* son: Soportar Unicode Limpieza de funcionalidades obsoletas como register_globals, safe_mode... PECL Mejoras en orientacin a objetos.

9.3.-Ventajas: Es un lenguaje multiplataforma. Capacidad de conexin con la mayora de los manejadores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL Leer y manipular datos desde diversas fuentes, incluyendo datos que pueden ingresar los usuarios desde formularios HTML. Capacidad de expandir su potencial utilizando la enorme cantidad de mdulos (llamados ext's o extensiones). Posee una amplia documentacin en su pgina oficial ([1]), entre la cual se destaca que todas las funciones del sistema estn explicadas y ejemplificadas en un nico archivo de ayuda. Es libre, por lo que se presenta como una alternativa de fcil acceso para todos. Permite las tcnicas de Programacin Orientada a Objetos. Permite crear los formularios para la web. Biblioteca nativa de funciones sumamente amplia e incluida No requiere definicin de tipos de variables ni manejo detallado del bajo nivel.

216

Bibliografa: Jess Vegas.2002. Departamento de Informtica de la Universidad de Valladolid [Recurso Web]. http://www.infor.uva.es Weitzenfeld Alfredo(2002) Ingeniera de software orientada a objetos. ITAM. Kendall & Kendall (1997)Anlisis y diseo de sistemas. Prentice Hall Hispanoamericana. Mxico DF- Mxico. Pressman, R. (2002). Ingeniera del Software un Enfoque Prctico. (Quinta Edicin). Mc.Graw Hill Interamericana: Espaa. Wang, P. (2000). Java con programacin orientada a objetos y aplicaciones en la WWW. International Thomson Editores: Mxico.

217