:

:6

;

.*.&(& >(?! @#>

Todo el proceso del RUP se encuentra disponible permanentemente en la Web, dado que desde el principio, uno de los objetivos del RUP era que ste estuviera disponible de manera fcil a todo el grupo de trabajo cuando fuera necesario. Este enfoque Web lo diferencia de otras alternativas metodolgicas queUML: Unified Modeling Language / Lenguaje Unificado de Modelamiento 5 USPM: Unified Software Process Model / Modelo de Procesos de Software Unificado4

21

:

8

!/.>.*.&(& -%#' ($.A-

El RUP es un modelo flexible y dinmico que permite la fcil integracin con la variedad de herramientas de diseo de software existentes. Asimismo, por las mismas caractersticas, es posible integrar el modelo de RUP a nuevos diseos y programas.

:

9

!&,*( .&(& "

*#B.>.*.&(&

Por la naturaleza modular y electrnica del RUP, este puede ser configurado y acomodado para que cumpla con las necesidades y objetivos de la mayora de organizaciones. He aqu otra caracterstica funcional que lo hace

:

:

*

#- #C!*,$.A-

Rational sabe que el RUP siempre estar en continuo proceso de revisin, por tanto realiza iteraciones en el proceso de ingeniera de software y como resultado se comprometen en sacar al menos dos actualizaciones del modelo por ao6, de este modo todos los que interacten con el modelo siempre tendrn la

6

The Rational Edge, Enero 2001. What is the Rational Unified Process? 22

:8El RUP tiene dos dimensiones, como se observa en el grfico presentado a continuacin.

Figura 1: Arquitect ura del RUP

En la grfica de la arquitectura del RUP se observan dos ejes o dimensiones. El eje horizontal representa el tiempo, y muestra los aspectos del ciclo de vida del proceso, a medida que ocurren. Esta dimensin representa el aspecto dinmico y siempre cambiante del proceso. Se expresa en trminos de fases, iteraciones y metas. El eje vertical, a su vez representa las disciplinas, que agrupa lgicamente a las actividades por su naturaleza. Esta dimensin representa el aspecto esttico del proceso, y cmo se expresa en trminos de componentes, disciplinas, actividades, flujos de trabajo,23

:9

Figura 2: Fases del RUP Grfica Recursos vs. Tiempo

El ciclo de vida de un software que siga el RUP est dividido en proceso cuatro fases, cada una de las cuales termina en una meta. Es decir, cada fase es el tiempo que transcurre entre dos metas. Al final de cada fase, se efectan procesos de control y evaluacin para determinar si los objetivos de la fase fueron alcanzados. A saber, las cuatro fases son Concepcin, Elaboracin, Construccin y generalment siempre son diferentes. Existen plantillas para este fin. e Grficamente, un ejemplo de la planeacin de un proyecto de software podra ser: Un recorrido completo a travs de todas las fases equivale a un ciclo de desarrollo. Cada ciclo de desarrollo debe tener como resultado la generacin de software. Un producto podr continuar con su siguiente generacin, recorriendo de nuevo un ciclo de desarrollo completo, a no ser que el producto haya alcanzado ya sus fines y se considere muerto. Los siguientes ciclos de desarrollo son llamados ciclos de evolucin. Cada vez que se cumple un ciclo de evolucin,24

A continuacin se explicar brevemente cada una de las fases del RUP:

:96

(/#

! $# )$.A-

Esta fase es la de ms importancia para proyectos nuevos que para evolucin de proyectos anteriores. En esta fase lo fundamental es establecer los objetivos del proyecto y hacer que todas las entidades relacionadas con el mismo Establecer el alcance del proyecto y sus posibles marcos de accin. Se debe especificar claramente lo que va a ser el producto y lo que no. Identificar los casos de uso crticos para el sistema. Analizar y exhibir al menos una arquitectura candidata para el desarrollo del sistema. Estimar el cronograma y costo del proyecto en su totalidad. Estimar los riesgos potenciales.

Preparar el entorno para la realizacin del proyecto. La meta de esta fase es llamada Objetivos del ciclo de vida y bsicamente evala cada uno de los objetivos frente a las personas o entidades relacionadas con la coordinacin y administracin del proyecto de software.

:9

(/#

*(>! ($.A-

El principal objetivo de esta fase es tener un fundamento de la arquitectura del sistema para proveer una base estable para la mayor parte del diseo e implementacin en la fase de construccin. La estabilidad de la arquitectura es evaluada a travs de uno o ms prototipos de las arquitecturas. Los puntos clave Asegurar que la arquitectura, requerimientos y planeacin son lo suficientemente estables, y los riesgos son evaluados de tal manera que se pueda determinar el costo y cronograma de todo el25

Tener en cuenta todos los riesgos significativos de la arquitectura. Producir un prototipo evolutivo de los componentes de Demostrar que la arquitectura escogida soportar requerimientos del sistema, dentro de un plazo de tiempo y un costo los

Establecer un entorno de soporte. La meta de esta fase es llamada Arquitectura del ciclo de vida y bsicamente mide la estabilidad de la visin, los requerimientos y la

razonable.

:9

(/#

!-/% ,$$ .A-

Retomando la metfora de la empresa manufacturera vs. empresa de software, tenemos que el nfasis de esta fase est en administrar los recursos de la produccin y controlar las operaciones de planta para optimizar la calidad, los costos y el itinerario. El objetivo principal es clarificar los requerimientos pendientes y completar el desarrollo del sistema basado en la arquitectura Minimizar los costos de desarrollo gracias a la optimizacin de recursos. Lograr la mejor calidad como sea pragmticamente posible. Llegar al desarrollo de versiones tiles (alfa, beta, etc.) Completar el anlisis, diseo, desarrollo y pruebas de toda la funcionalidad requerida. Desarrollar de manera iterativa un proyecto que est listo para hacer la migracin a la comunidad de usuarios.

Decidir si el software, los sitios y los usuarios estn listos para Igualmente, esta fase tiene su meta, denominada Capacidad inicial de operacin, la cual determina si el producto est listo para ser lanzado en un entorno de pruebas beta.

26

:98

(/#

( /.$.A-

La etapa final del ciclo de desarrollo de software se enfoca en que el software est listo y disponible para sus usuarios, con todos sus objetivos claramente logrados. Esta fase puede necesitar de varias iteraciones para su cumplimiento completo, por ejemplo, el afinamiento del software mediante sugerencias y comentarios de los usuarios finales. Los objetivos especficos de esta fase varan de proyecto a proyecto, pero Realizar las pruebas beta para validar el nuevo sistema con las expectativas de los usuarios. Realizar pruebas beta en paralelo con el antiguo sistema que va a reemplazar. Tener bases de datos en operacin. Entrenamiento de los usuarios y mantenedores. Asignar labores de ingeniera de soporte. Realizar y activar tareas de soporte de errores. Acordar con los auditores y miembros directivos del proyecto que el desarrollo fue realizado satisfactoriamente y que sus La meta de esta fase es el Lanzamiento del producto y en l se evala el nivel de satisfaccin de los usuarios, as como los gastos reales vs. los gastos propuestos.

27

:: @

Figura 3: Ciclo de Ing. De SW en el RUP

En el RUP, se tiene un ciclo de de software objetivo ingeniera cuyo es desarrollar o mejorar un proceso. Este proceso est organizado en una agrupacin de disciplinas las cuales a su vez estn definidas por flujogramas de trabajo. Una disciplina es una coleccin de actividades relacionadas con reas de importancia similar dentro de un proyecto. La manera de agrupar en disciplinas, es para facilitar el trabajo a quienes tienen fuertes races en el proceso de desarrollo en cascada. Tenemos entonces las siguientes

28

::6

!*(&! *

#'!$.!

Esta disciplina se lleva a cabo con el fin de entender la estructura y dinmica de la organizacin en el cual se va a realizar el sistema. Se deben entender igualmente los problemas en la organizacin e identificar el potencial de mejoras. En esta etapa tambin se debe asegurar que los clientes, desarrolladores y usuarios, compartan un entendimiento sobre la visin y objetivos de la

::

#D,./.%!/

En esta disciplina se debe acordar con aquellos involucrados en la gestin del proyecto lo que el sistema har, es decir, delimitar el alcance del proyecto. Igualmente se debe proveer a los desarrolladores con un mejor entendimiento de los requerimientos del sistema. Todo esto ayuda a establecer una base en el

::

-E*././ "

./#F!

El propsito de la disciplina de anlisis y diseo, es transformar los requerimientos en un diseo del futuro sistema, y as evolucionar hacia una arquitectura robusta del mismo. Tambin en esta disciplina se harn labores para adaptar el diseo y que iguale el entorno de la aplicacin, especficamente

::8

0)*#0#-%($.A-

La implementacin es la disciplina que se encarga del proceso de construccin y elaboracin de cdigo. En ella se debe definir la organizacin del cdigo, e implantar los diferentes subsistemas en capas. Igualmente, se deben implementar (cdigo fuente, clases y objetos como componentes del sistema

binarios, etc.). Estos componentes se deben probar en esta disciplina como unidades, y finalmente, se debern integrar los resultados producidos por diferentes individuos o equipos en un sistema completamente ejecutable. Es importante diferenciar que las pruebas en esta disciplina son hechas a las

::9

,#>(/

Como su nombre lo indica, la disciplina de pruebas se encarga de realizar bsquedas y validaciones a los defectos en la calidad del software, junto con su documentacin apropiada. En esta disciplina se debe igualmente validar que todos los objetivos hechos en las especificaciones y requerimientos sean tangibles y estn completamente implementados, hecho mediante demostracin concreta del proyecto de software. Es importante contar con la auditora de los clientes

:::

#/)*.#',#

Esta disciplina garantiza que el software est disponible para los usuarios finales. Este despliegue puede darse de cualquier manera que sea adecuada al entorno de la organizacin, tales como una instalacin personalizada, o un paquete de instalacin (MSI7, RPM8, etc.) o que las personas puedan acceder libremente a travs de Internet. Es claro que esta disciplina tiene su cima

7 8

MSI: Microsoft Installer Package / Paquete de instalacin de Microsoft

RPM: Redhat Package Manager / Administrador de paquetes de Redhat 30

::G

&0.-./% ($.A- $(0>.!/ " $!-4.', ($.A-

Segn el CMM9 del SEI10, sta disciplina controla los cambios y mantiene la integridad de los artefactos de un proyecto. Para la administracin de cambios y configuracin se debe a tomar en cuenta y cuales elementos sern se eventualmente sujetos realizados y configuracin cambios, posteriormente

deber restringir los cambios solo a esos elementos, auditar los cambios finalmente definir y administrar las configuracines de esos de trabajo. Este control es elementos. Esta disciplina es esencial para controlar los numerosos artefactos resultantes de un proyecto y su equipo sumamente til para evitar la confusin y

::H

&0.-./% ($.A- * ) !"#$ %!administracin y un marco de trabajo para lineamiento de planeacin, enfoca ms administracin de

Un intento del RUP para facilitar la tarea de coordinacin del proyecto es esta disciplina. En ella, da se el administrar proyectos de software se mediante reclutamiento, ejecucin y administracin y en el control de riesgo que en la presupuesto y personal.

::I

-%! !

El objetivo de esta disciplina son las actividades necesarias para configurar el proceso de desarrollo de disciplina se un proyecto. Describe soporte de proporcionar encarga las actividades del proyecto. un entorno necesarias requeridas Esta parael

que soporte a todo el proyecto, por tanto est9

CMM: Capability Maturity Model Software Engineering Institute 31

1 0 SEI:

:GEl Rational Unified Process tiene ciertos elementos o bsicos conceptos clave que es importante sealar. En grfica a continuacin se muestra un la diagrama de flujo de dichos elementos.

Figura 4: Flujograma de elementos del RUP

Se hablar un poco ms sobre los distintos elementos a continuacin.

32

:G6

./$.)*.-(/

Como se mencionaba anteriormente, una disciplina es una coleccin de actividades relacionadas con reas de importancia similar dentro de un proyecto. La manera de agrupar en disciplinas, facilita el trabajo a quienes tienen fuertes

:G

! $# )%!/ -

Son las definiciones clave de un proceso (tales como iteracin, riesgo, fases, etc.). Generalmente van junto con las disciplinas para su mejor entendimiento.

:G

!*#/

Es uno de los conceptos ms importantes, y tal vez el ms cntrico de todo el proceso. Un rol define el comportamiento y responsabilidades de un individuo o equipo de trabajo en un proyecto. Es importante distinguir que un rol no es un individuo, ms individuos o bien, describe personas deberan cmo comportarse los en la

organizacin, y sus responsabilidades. Es decir, dentro de un proyecto es comn que una sola persona desempee diferentes roles. Dentro del RUP existen muchos tipos de rol predeterminados. Las macro categoras que los Analistas Desarrolladores Probadores (o testers) Administradores Roles varios (ej. Escritor tcnico, diseador grfico, administrador

33

:G8

$%.C.&(/

Una actividad es una unidad de trabajo definida que cierto individuo que realice un rol podra tener que hacer. Una actividad tiene un propsito claro, generalmente expresado en generar o actualizar un artefacto. especfica una actividad, ms ptimo es el resultado. Al igual que en sea otros elementos RUP, cada actividad debe tener un perodo de ingeniera, otro ejecucin y finalmente uno de evaluacin. Ejemplos de actividades predeterminadas son asignar prioridad a los casos de uso, describir distribucin, o documentar clases. Cada actividad puede tener relacionada una gua de trabajo que presenta las tcnicas y diferentes pasos sugeridos para llevar a la ejecucin cierta unidad de trabajo.

:G9

%#4($%!/

Una actividad puede tener artefactos de entrada o de salida. Un artefacto es el resultado del trabajo de un proceso: los roles usan los artefactos como insumos para realizar actividades o como productos de su proceso. Los artefactos son responsabilidad de un solo rol y dan la idea que cada pedazo de informacin en el proceso es responsabilidad de solo una persona. Un artefacto puede tomar diferentes formas, como por ejemplo un modelo (modelo de casos de uso, modelo de diseo, modelo de anlisis e implementacin), un elemento del modelo (caso de uso, clase de diseo), un documento (visin, lista de riesgos, glosario, caso de negocio o documento de arquitectura del software), cdigo fuente o ejecutables (como componentes). Al igual que las actividades, los artefactos tienen guas de trabajo que definen un derrotero para indicar cmo desarrollar y evaluar los artefactos. Estas guas de trabajo tienen a su vez ciertos puntos de control que permiten un mayor control y acercamiento a los objetivos de los mismos. Para cada artefacto el RUP presenta plantillas para usar en diferentes formatos (Word,34

provee modelos para los reportes, puesto que algunos artefactos pueden tener como salida alguno de ellos.

:G:

*,?! % (>(?!

Un flujo de trabajo es una secuencia prctica de actividades que tienen como fin algn resultado que puede ser medido u observado. En un flujograma de trabajo se pueden observar de manera clara y grfica las interacciones entre el UML, un diagrama de secuencias, o un diagrama de colaboracin, un o diagrama de actividades. estandarizar, el RUP usa el diagrama de Para actividades para cada disciplina.

35

:H

7

Figura 5: Mejores prcticas

Para profundizar el conocimiento y el marco terico sobre el RUP, se tocar un tema de mucha importancia en el mundo actual de la ingeniera de software. El RUP ha demostrado que cumple con algunas de las llamadas mejores prcticas en la industria de software, prcticas que con el tiempo y uso han

:H6

#/( !* *! %# (%.C!

Todos los proyectos tienen cierto riesgo involucrado. El enfoque tradicional de cascada en el cual cada paso se ejecuta por completo antes de entrar en el conlleva a descubrir los riesgos solamente hasta muy entrado el de ciclo un desarrollo de software, tiempo en el cual arreglar los errores de diseo un es proceso tedioso y costoso. Con el RUP, donde por definicin se proceso iterativo de desarrollo y con marcas de control en cada paso, es ms fcil mitigar estos riesgos y arreglarlos oportunamente.36

:H

&0.-./% ($.A- #D,./.%!/

Administrar un requisito, o cualquier condicin que el sistema deba cumplir es importante para organizar, documentar y corroborar

las

especificaciones del sistema. Es de suma importancia para mantener un acuerdo entre los clientes y los gestores del proyecto. Pudiera parecer que este proceso es simple, pero en realidad es ms complejo de lo que parece. El RUP permite mantener un establecimiento de requisitos de manera clara y concisa, junto con

:H

%.*.3($.A$!0)- #-%#/ !

( D,.%#$ %, (/

) !

El RUP tiene la capacidad de usar componentes en su modelado. Un componente es un grupo coherente de cdigo con interfaces y comportamientos bien definidos que proporcionan fuerte encapsulacin de sus contenidos. La principal ventaja de usar arquitectura por componentes es que tienden a reducir el tamao y complejidad de la solucin, y por tanto sta ser ms robusta y

:H8

!*(0.#-%! C./,(*

El uso de un modelo visual, tal como el UML, permite usar notaciones de diseo ricas y claras para capturar el diseo de software. El UML proporciona un ms alto nivel de abstraccin sobre el problema, manteniendo la sintaxis y la semntica. De esta manera, mejora la comunicacin dentro del equipo de desarrollo y presenta una manera de interpretacin sin ambigedades. Otras de sus ventajas son el tener la posibilidad de comparar diferentes alternativas a bajo costo, el formar una base para la implementacin y finalmente, capturar los requerimientos de manera precisa.37

:H9

! % !* $(*.&(& )# 0( #-%# -

Dentro del RUP se controla constantemente la calidad. Ya sea al final de una fase, o al terminar las actividades de una disciplina, o al finalizar artefacto. No importa el un estado de maduracin del proyecto, el RUP verificar ordena su calidad. Esto se diferencia de otros aproximaciones a la ingeniera de software que tienen en cuenta el control de calidad solo hasta muy entrado el ciclo de vida del proyecto de software.

:H:

&0.-./% ($.A- *!/ $(0>.!/

Es muy importante en cualquier proyecto de desarrollo de software el estar en capacidad de manejar los cambios. En proyectos de corto alcance puede no parecer tan necesario, pero en otros de mayor alcance, donde hay varios equipos de desarrolladores trabajando de manera asincrnica, la necesidad puede parecer apremiante. Sin un control establecido, el proyecto de desarrollo fcilmente una correcta administracin y manejo de los cambios, diferentes equipos de trabajo, iteraciones y lanzamientos en el proyecto.

versiones,

38

G

Siguiendo como patrn el RUP, tenemos que la unidad organizacional primaria en el desarrollo de todo proyecto, es la segmentarizacin por fases. Como se explicaba anteriormente, en cada una de las fases se deben seguir ciertos requerimientos y actividades, y al final de cada una de ellas, establecer una evaluacin con el fn de saber si los requerimientos de cada fase fueron alcanzados. As pues, iniciemos la exploracin dentro de cada una de las fases del

G6Siendo este proyecto uno nuevo, es claro que se le debe hacer especial nfasis a esta fase. Inicialmente, y con el fin de entender la estructura y la dinmica de la organizacin en la que se va a trabajar en el futuro, se decidi hacer el modelado del negocio como primer paso.

G66

!*(&! *

#'!$.!

Con el fin de compartir una visin holstica del negocio y de sus procesos con los clientes, el primer paso en la fase inicial del ciclo de ingeniera de software sugerido por el RUP fue este.

39

Figura 6: Modelamiento del Negocio

Observamos que dentro del segmento del negocio que se va a trabajar, existen dos procesos principales, Vender Productos en Lnea y Gestionar Pedidos, los cuales usan diferentes mdulos. Dentro del primero, Vender Productos en Lnea, se observa que su objetivo es tomar los pedidos del cliente, y como resultado, genera un pedido u rden. Usa los mdulos de administracin y pedido, y como entrada, el inventario en bodega y el mdulo de catlogo. Este proceso es claramente el ms importante dentro del proceso a mejorar, y gracias40

G6

*$( $# J $ !! ' (0( " 0( $! ($$ .A-

Para el RUP (al igual que la mayora de procesos organizados), determinar el alcance y el marco de accin de un proyecto es un paso vital y es imprescindible tenerlo en cuenta con el fin de realizar un proceso maduro y confiable con visin acertada a futuro. Por ello, se realiz el alcance del proyecto dentro de unos mrgenes temporales y materiales. Toda la informacin de esta actividad, fue plasmada en los numerales 2, 3 y 4 del presente proyecto de grado. Adems, y granular la planeacin de recursos del en un anexo est el llamado documento de Plan de Iteraciones, en el cual se ver de manera detallada

G6

#D,./.%!/ " $(/!/ ,/! $ +%.$!/

Es importante en esta primera fase, identificar los requisitos y casos de uso crticos para tener un entendimiento macro del sistema. Bsicamente estos seran los requisitos y casos de uso ms bsicos y globales que se pudieran tener a un nivel alto.

Figura 7: Requisitos Crticos

Tenemos como requisito funcional global realizar una aplicacin web interactiva que les permita a los clientes web de la compaa revisar el catlogo completo a travs de Internet, navegar por los productos, conocer los detalles y especificaciones completas de los mismos, agregar estos productos a una orden, y realizar el pedido cuando la orden est completa. El sistema deber enviar un

formato de XML para el departamento de pedidos, para que el pedido realizado sea actualizado correctamente en la base de datos de la empresa. Se logran identificar en principio tres grandes requisitos: Implementar seguridad, hacer pedidos en lnea y administrar el sistema. Para Implementar Seguridad, tenemos que el sistema deber contar con un esquema de seguridad que permita sesiones de usuarios recurrentes y la validacin de cada usuario En el requisito Hacer pedidos en lnea, se tiene que el usuario deber poder ver navegar por el catlogo de productos de la empresa. y deber Igualmente, y administrar su pedido (agregar productos, finalmente podr hacer su pedido a la compaa. ver Por ltimo, en Administrar el Sistema, se enuncia que el sistema podr ser administrado por un usuario de tipo administrador, el cual podr administrar usuarios, productos, lneas, y pedidos. Teniendo ya los requisitos crticos a nivel global, se puede crear una idea ms clara sobre el desarrollo de software en el proyecto que se pretende llevar a cabo, y sirve como punto de partida hacia un modelo de casos de uso ms detallado junto con sus respectivos requisitos. Tambin con estos requisitos, se puede sacar al menos una arquitectura candidata para el desarrollo del sistema,

G68 D,.%#$ %, ( $( &.&(%( /( !* *! * /./%#0(

.-.$.(*

) ( (

#*

Para empezar con el desarrollo del sistema, se debe tener una idea sobre la arquitectura a utilizar. Una primera aproximacin a la arquitectura sera utilizando el modelo de dos capas, una para servidor de aplicaciones que maneje la lgica del negocio y presentacin, y otra para el servidor de bases de datos. Se usara GNU/Linux como sistema operativo para ambos servidores, mySQL como manejador de bases de datos, Apache como servidor web y PHP como lenguaje de programacin. Se realiz un diagrama de distribucin donde se enumerar42

Figura 8: Arquitect ura inicial con GNU/Linux

G69 -%! ! !4%5( #

*

) !$# /!

-'#-.# +(

En la etapa inicial es muy importante saber igualmente cul es el entorno en el cual todo el proceso de ingeniera de software estar soportado. Como el RUP est fuertemente basado en UML, existen varias alternativas en el mercado, siendo las dos ms reconocidas la Rational Rose Enterprise

1 1 Rational

Rose Enterprise: http://www.rational.com/rose / Architect Proffessional: http://www.sparxsyste ms.com.au/ 43

1 2 Enterprise

Por qu es importante escoger una herramienta CASE para modelar el UML? A medida que los sistemas se construyen hoy en da son ms y ms complejos, las herramientas CASE para UML ofrecen muchos beneficios para aquellos involucrados con un proyecto. Las herramientas CASE nos permiten aplicar la metodologa formal orientada a objetos y abstraerla del cdigo a un nivel donde el diseo y la arquitectura sean ms fciles de entender y modificar. () El modelo acta como un plano y guiar finalmente la construccin del sistema13. Es importante tambin hacer uso de una arquitectura que proporcione un correcto entorno para el proyecto, para la debida administracin del proyecto y la elaboracin del mismo con menor complejidad. Existen varios factores a evaluar en la eleccin de una herramienta rendimiento, facilidad de manejo, soporte a travs del proyecto, de capacidad rendir informes y documentacin, entre otros. Estos factores varan de proyecto a proyecto, rendimiento y acoplamiento con el proyecto en Caracterstica Rose Soporte de UML 1.4 Soporte y posibilidades de expansin Diagramas de anlisis y diseo Soporte para la creacin automatizada de cdigo Estimacin Riesgos Reportes Concurrencia Ingeniera de Requisitos Documentacin para Pruebas S Excelente Todos, asistentes Muy completa (a Normal excepcin .NET) No No Limitado S terceros Limitado S S S Muy completos S (C++, de VB, Java y C#) y ac evaluaremos su EA S Normal con Todos

Con software de S

1 3 Dr.

Jie Zhao, Comparison of UML Modelling Tools, 2002. 44

Facilidad de manejo Precio

Fcil U$5024.oo

Muy fcil U$144.oo

Tabla 1: Comparacin entre Rational Rose y Enterprise Architect

En la Tabla 1, se resaltan las caractersticas en las que cada paquete se ajusta ms a las necesidades del proyecto. Como podemos ver, ambos paquetes CASE tienen soporte para UML completo, de manera que cualquiera de los dos sera una herramienta til para el modelado. Con respecto a los diagramas, Rose se lleva la delantera dado que adems de presentar la posibilidad de crear diagramas como el Enterprise Architect, proporciona asistentes automticos que hacen la tarea ms fcil. Rose tambin se lleva la delantera al Architect en la creacin automatizada de cdigo, puesto que genera cdigo mediante plantillas ya includas para muchos ms lenguajes de programacin que su contendor, a excepcin de .NET. Rose, junto con Architect, soportan manejo de sesiones concurrentes, desarrollo del proyecto para que el simultneamente. Rational Rose cuenta con el soporte de la corporacin IBM, y est dentro de una completa suite de productos especializados en ingeniera de software, por tanto se puede integrar con otros programas adicionales para aumentar la capacidad. Enterprise Architect, es producto de una compaa relativamente nueva y poco conocida, especializada en su producto. Enterprise Architect proporciona de por s una amplia funcionalidad en cuanto a manejo de requisitos se refiere. Rose, por su parte, no proporciona soporte nativo para esta funcionalidad y requiere de otro paquete de la suite de Rational para tenerlo. En la parte de administracin y gestin del proyecto, Enterprise Architect toma la delantera puesto que contiene soporte nativo para el proceso de estimacin, mediante tcnicas de UCP14. Rose no proporciona mtodos de estimacin nativos. Tambin el Architect se lleva el podio en cuanto a gestin de riesgos, aunque no sea tan impresionante esta funcionalidad, est1 4 UCP:

importante

en

el

equipo completo pueda trabajar

Use Case Points, o Puntos de Casos de 45

Uso

Enterprise Architect de nuevo se lleva el premio en el aspecto de documentacin. Aunque ambos soportan la web, el Enterprise Architect proporciona un mdulo completo de documentacin, flexible y con una impecable salida en varios formatos de documentacin y grficas. El Rose por otra parte, necesita de SoDa para tener documentacin. Igualmente, el Architect proporciona soporte nativo para el manejo de pruebas, mientras que el Rose necesita de software adicional para lograrlo. En cuanto a precio, el Enterprise Architect se lleva con creces el mejor puesto. cuantioso Sus U$149 del representan Rational apenas que una se pequea vende a fraccin un precio del de precio Rose,

aproximadamente U$5,000. Concluyendo, optamos por elegir al Enterprise Architect, de Sparx Systems, puesto que es una completa herramienta para el modelado en UML y que soporta al proyecto durante todo su ciclo. Adems, soporta funcionalidades muy importantes para el proyecto en curso, como son estimacin, ingeniera de requisitos y gestin de riesgos. Proporciona adems muy buenas capacidades de documentacin, facilidad de manejo y aunque el Rose pueda expandirse y complementarse con ms software adicional, el Enterprise Architect es lo apropiado para nuestro proyecto. Y, su relacin precio

G6:

*( %# ($.! #/ -

Con el fin de planear, administrar y gestionar los procesos que llevarn al desarrollo y terminacin del proyecto, es importante contar con un Plan de Iteraciones detallado. Dicho plan, es un conjunto de actividades y tareas con recursos asignados, que son necesarias para realizar cada iteracin. En el Anexo

46

G6G

#/%.A- .#/'!/

Los riesgos son elementos que implican incertidumbre y prdida, y estn presentes en todos los proyectos de Ingeniera de Software15. Estos involucran modificaciones tanto en las decisiones como en las acciones, y es importante identificarlos a su gran mayora y clasificar los ms importantes con el fin de tratar de minimizarlos y elaborar estrategias proactivas y planes de contingencia reactivos para ellos. As pues, se cre una lista de comprobacin de riesgos en la Tabla 2 con aquellos que se juzgaron de mayor consideracin, tomando como base la lista de riesgos de software de la Universidad de Guadalajara, con sus diferentes el ms crtico, se categorizaron los riesgos. Igualmente, probabilidad que determinado riesgo ocurriera. Riesgo Riesgos por Tamao Inseguridad en la estimacin del tamao Tamao en nmero de programas, archivos y transacciones calculado errneamente. Tamao de la Base de Datos creada o usada por el SW insuficiente. Nmero de usuarios del SW superiores. Cambios imprevistos a los requisitos Poca reutilizacin del SW Riesgos por Impacto en el Negocio Incidencia sobre el ingreso de la compaa Fecha de entrega insuficiente Sistemas interoperables con el SW creado 3 4 1 40 70 10 4 4 2 50 50 70 2 30 3 3 70 40 Peso (W) P(r) %.

se tom en cuenta la

15

Curso de Ingeniera de Software (Universidad de Guadalajara): Mdulos 10 y 11, Gestin de Riesgos 47

Usuario final incompetente para usar el SW Cantidad y calidad de la documentacin insuficiente Limitaciones gubernamentales en la creacin del SW Retraso posible con sobrecostos para la empresa Defectos posibles con sobrecostos para la empresa Riesgos por el Cliente No ha trabajado con el cliente anteriormente El cliente no tiene la suficiente idea formal de lo que quiere El cliente no participa en reuniones formales para definir el mbito del SW El cliente no establece una comunicacin fluida con el desarrollador El cliente no participa en las revisiones Es muy sofisticado tcnicamente el rea del producto El cliente no est dispuesto a dejar hacer el trabajo al desarrollador El cliente no entiende el proceso del SW Riesgos por el Proceso No hay claridad sobre el proceso de SW en la organizacin desarrolladora No tiene madurez sobre el desarrollo de SW No est capacitada en procesos de SW No se hacen RTFs documentadas No hay mtodos especficos para el anlisis del SW No hay un mtodo especfico para el diseo de datos y arquitectnico48

4 4 1 2 3

70 60 20 40 50

2 3 4 4 5 3 4 2 2 3 4 2 4 3

70 60 80 70 60 50 30 20 30 20 10 30 20 40

No

se

han

definido y

empleado reglas

3 3 4 4

30 70 20 30

especficas para la documentacin del cdigo No se emplean mtodos especficos para el diseo de casos de prueba No No se se emplean herramientas emplean mtricas de CASE calidad en y diferentes etapas del proyecto productividad en el proyecto Riesgos por la Tecnologa Es muy nueva para su organizacin la 3 4 40 40 tecnologa a construir Los requisitos demandan nuevos mtodos de anlisis, diseo o pruebas Riesgos por el Entorno de Desarrollo No se cuenta con una herramienta de gestin de proyectos de SW No existen herramientas de anlisis y diseo adecuadas para el SW a crear No hay disponibles compiladores o 2 40 generadores de cdigo apropiados para el SW a crear. No existen herramientas de pruebas 4 4 4 60 20 10 adecuadas para el SW a crear No existen expertos disponibles para aclarar dudas sobre las herramientas No es adecuada la ayuda en lnea de esas herramientas Riesgos por el Personal No disponemos de la mejor gente El personal no tiene todos los conocimientos adecuados No se ha asignado el personal para toda la duracin del proyecto49

3 4

20 10

2 4 4

30 50 30

Tabla 2: Lista de riesgos en el proyecto

Se tiene entonces un completo compendio sobre los riesgos en el actual proyecto. Ahora determinamos cules son los riesgos ms importantes que se deben tener en consideracin, puesto que es muy dispendioso en recursos tanto de tiempo como de dinero hacer estudios y planes de RSGR (Reduccin, Supervisin y Gestin de Riesgos) a cada uno de ellos. Para saber cules son los riesgos ms importantes, definimos la siguiente funcin: Si W * P(r ) 2.8 Es un riesgo importante!

En la tabla, se resaltaron los riesgos ms importantes, que a saber, son: El cliente no participa en reuniones formales para definir el mbito del software El cliente no participa en las revisiones Fecha de entrega insuficiente Usuario final incompetente para usar el software El cliente no establece una comunicacin fluida con el desarrollador Se observa que los riesgos ms importantes tienen que ver con las categoras de Riesgos por el Cliente y Riesgos por el Impacto en el Negocio. Con estos riesgos ya identificados, el paso a seguir sera realizar un plan con el fn de evitar que ocurran tales riesgos o de mitigar el impacto de los mismos en el proyecto. Si se quisiera evaluar ms profundamente el tema de los riesgos, se pudiera plantear la ejecucin de una matriz costo beneficio, con el fin de saber si se justifica hacer planes RSGR. A grandes rasgos, en nuestro caso se identific que los principales problemas pueden surgir por la falta de comunicacin con el cliente, el tiempo, y la capacidad del usuario final. Como estrategias se podran sugerir: Mejorar la comunicacin con el cliente

50

Conscientizar al cliente de la importancia de su actuacin activa dentro del proceso de desarrollo de software y los inconvenientes que surgiran por la falta de su apoyo. Realizar un nuevo cronograma con mejores tcnicas de estimacin, o contratar ms personal capacitado. Generar manuales ms didcticos e informativos, y realizar talleres de capacitacin ms extensos a los usuarios finales. Crear ayuda interactiva en el software con el fn de hacerlo ms Como vemos, la gestin de riesgos es una herramienta sumamente til y con resultados contundentes a la hora de realizar un proyecto de desarrollo de software. Es claro que el tiempo invertido en la gestin de riesgos, genera como resultados la identificacin, mitigacin y hasta posible erradicacin de potenciales que como resultado, una prdida sumamente mayor de traeran dinero, tiempo y good will al

51

GEl objetivo en esta fase es tener establecida una arquitectura del sistema con los requisitos establecidos para proveer una fase estable y continuar con el anlisis, diseo y construccin del proyecto. En esta fase se debe terminar y refinar el proceso de ingeniera de requisitos, y se empieza la labor de anlisis y

G

6

-'#-.# +(

#D,./.%!/

En esta fase, los requisitos deben estar lo ms depurados posible y completos. Estos, deben ser unidos a los casos de uso y junto a estos ltimos formarn el punto de contacto y aceptacin entre el equipo desarrollador y el usuario final. Al terminarlos, se genera el Documento de especificacin de requisitos, el cual est en el Anexo F del presente documento. Gracias a dicho documento, se logr tener una mejor visin y comprensin de lo que es necesario para realizar el sistema, as como tambin se pudo enmarcar y limitar de manera clara el sistema y proveer una base para estimar el costo y factores tcnicos de futuras iteraciones, que sern incorporadas en el

52

G

!*!

(/!/

/!

Segn el RUP, el modelo de casos de uso debe estar al menos completo en un 80% al terminar esta fase, con todos los casos de uso y actores identificados, junto con la mayora de descripcines de los mismos casos de uso. En el Anexo D del presente documento, se encontrar el modelo completo de los casos de uso, al La Tabla 3 enuncia los casos de manera abreviada:

Nmero1.1. 1.2. 1.3. 1.4. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. Cambiar clave Recuperar clave

Caso de UsoAutorizarse en el sistema (login)

CategoraEsencial Deseable Esencial Esencial Esencial Esencial Esencial Esencial Esencial Esencial Deseable Deseable Esencial Esencial Esencial Esencial Esencial Esencial Esencial

Registrarse en el sistema Agregar Elementos al Pedido Calcular Precio del Pedido Cambiar Cantidades del Pedido Efectuar Pedido Eliminar Elementos del Pedido Ingresar datos del Pedido Mostrar Resumen del Pedido Ver Detalles Producto Ver Pedido Agregar Categora Agregar Producto Agregar Usuario Eliminar Categora Eliminar Producto Modificar Categora53

Nmero3.7. 3.8. 3.9.

Caso de UsoModificar Producto Modificar Usuario Ver Pedidos

CategoraEsencial Esencial Esencial

Tabla 3: Lista de Casos de uso

54

G

!*!

(%!/

El modelo de datos se encarga de describir las representaciones fsicas y lgicas de los datos persistentes usados por la aplicacin, es decir, las relaciones, estructura, eventos y procedimientos de las bases de datos y sus respectivos representacin. Para presente ver el modelo completo, favor remitirse al Anexo E del

Figura 9: Modelo Entidad - Relacin

55

G

8

.(' (0(

*(/#/

El modelo de datos y el diagrama de clases van fuertemente relacionados el uno con el otro. Dado que en la creacin de uno, inherentemente sale el otro. tanto, se observan las diferentes y las relaciones con sus respectivas clases tablas.

Figura 10: Diagrama de Clases

*(/#

(%#'! +(public Class Propuesto.Versin 1.0.Fase 1.0.

Tipo: Estado:

Paquete :

Diagrama de Clases

Creado el 14/08/2003. Modificado el 03/09/2003. Detalles Clase para manejar las categoras Trazabili dad Enlace de asociacin desde la clase Categora Enlace de asociacin desde la clase Cat egora Atributos Atributo cdigo nombre descripcin categoraPadre Tipo private: int private: string private: string private: int Notas

Tabla 4: Clase Categora Atributos

Mtodo agregar () eliminar (int) Editar (int) Listar ()

Tipo Public: void Public: void Public: void public: void

Notas param: cdigoProducto [ int - in ] param: cdigoProducto [ int - in ]

Tabla 5: Clase Categora Mtodos

*(/#

! 4.', ($.Apublic Class Propuesto.Versin 1.0.Fase 1.0. Diagrama de Clases Creado el 14/08/2003. Modificado el 15/10/2003.

Tipo: Estado: Paquete :

Maneja todas las variables y procesos de la configuracin Trazabili dad Enlace de asociacin a la clase Pedido Enlace de asociacin a la clase57

Atributo hostBD usuarioBD passwordBD directorioPgina directorioPlantillas directorioImagenes

Tipo private: string private: string private: string private: string private: string private: string

Notas

Tabla 6: Clase Configuracin - Atributos

*(/#

-K !0) (public Class Propuesto.Versin 1.0.Fase 1.0. Diagrama de Clases Creado el 14/08/2003. Modificado el 03/09/2003.

Tipo: Estado: Paquete :

Tiene incluida toda la funcionalidad de las ordenes de compra realizadas. Trazabili dad Enlace de asociacin desde la clase Producto Enlace de asociacin desde la clase Atributo cdigo compradoPor fecha comentarios estado total Tipo private: int private: string private: date private: string private: int private: intTabla 7: Clase Orden_Compra - Atributos

Notas

- Mtodo detalles (int) listar ()

Tipo public: void public: void

Notas param: cdigoOrden [ int - in ]

Tabla 8: Clase Orden_Compra Mtodos 58

*(/#

#&.&!public Class Propuesto.Versin 1.0.Fase 1.0. Diagrama de Clases Creado el 14/08/2003. Modificado el 15/10/2003.

Tipo: Estado: Paquete :

Toda la funcionalidad del pedido, es decir, de la canasta de compras. Trazabili dad Enlace de asociacin a la clase Producto Enlace de asociacin desde la clase Configuracin Atributo elementos total Tipo private: array private: intTabla 9: Clase Pedido - Atributos

Notas

Mtodo agregar (int, int)

Tipo public: void

Notas param: cantidad [ int - in ] param: cdigoProducto [ int - in ]

cantidad (int, int)

public: void

param: cantidad [ int - in ] param: cdigoProducto [ int - in ]

eliminar (int) limpiar () contar () recalcular () ver () completarPedido () hacerPedido ()

public: void public: void public: void public: void public: void public: void public: void

param: cdigoProducto [ int - in ]

Tabla 10: Clase Pedido Mtodos

59

*(/#

!&,$%!public Class Propuesto.Versin 1.0.Fase 1.0. Diagrama de Clases Creado el 14/08/2003. Modificado el 15/10/2003.

Tipo: Estado: Paquete :

Clase para manejar los productos. Trazabili dad Enlace de asociacin a la clase Categora Enlace de asociacin a la clase Orden_Compra Enlace de asociacin desde la clase Pedido Atributo cdigo nombre descripcin precio especial palabrasClave foto Tipo private: int private: string private: string private: int private: int private: string private: stringTabla 11: Clase Producto - Atributos

Notas

Mtodo agregar () eliminar (int) editar (int) listar () ver ()

Tipo public: void public: void public: void public: void public: void

Notas param: cdigoProducto [ int - in ] param: cdigoProducto [ int - in ]

Tabla 12: Clase Producto Mtodos

*(/#

/,( .!public Class Propuesto.Versin 1.0.Fase 1.0.60

Tipo: Estado:

Paquete :

Diagrama de Clases

Creado el 14/08/2003. Modificado el 15/10/2003. Detalles Clase para manejar las categoras Trazabili dad Enlace de asociacin a la clase Orden_Compra Enlace de asociacin desde la clase Configuracin Atributo username nombre apellido email telfono direccin privilegios Tipo private: string private: string private: string private: string private: string private: string private: int Notas

Tabla 13: Clase Usuario - Atributos

Mtodo agregar () eliminar (string) Editar (string) listar () reinicializarClave (string) registrar () cambiarClave ()

Tipo public: void public: void public: void public: void public: void public: void public: void boolean

Notas param: username [ string - in ] param: username [ string - in ]

param: username [ string - in ]

param: username [ string - in ] param: username [ string - in ]

verificarPrivilegios () public:

Tabla 14: Clase Usuario - Mtodos

61

G

9

/%.0($.A- " 02% .$(/

Determinar o predecir con gran precisin el tamao y duracin de un proyecto de ingeniera de software puede significar en una gran reduccin de incertidumbre en la etapa inicial de planeacin, llevando as a mantener unas cifras econmicas y de tiempo precisas, permitindole a la gerencia del proyecto no incurrir en sobrecostos y mantenerse dentro de un cronograma. Hay varias alternativas en cuanto a la estimacin, segn Roger Pressman: Para realizar estimaciones seguras de costos y esfuerzos, se Dejar la estimacin para ms adelante, obviamente se puede realizar una estimacin al cien por cien fiable despus de haber terminado el proyecto. Basar las estimaciones en proyectos similares ya terminados. Utilizar tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto.

Desarrollar un modelo emprico para el clculo de costos y esfuerzos En nuestro caso, las primeras dos alternativas quedan descartadas, puesto que uno de los objetivos del presente trabajo de investigacin es la estimacin temprana y precisa, no se puede dejar para etapas ms avanzadas la tarea de la estimacin. Tampoco ha habido proyectos similares ya terminados en los cuales se pueda basar una estimacin precisa. Por tanto, quedamos con las alternativas de desarrollar un modelo emprico de estimacin, o utilizar tcnicas de descomposicin funcional sencillas. Se decidi hacer uso de tcnicas de estimacin basadas en descomposicin COCOMO (Estimacin por PF17 o SLOCs1 8) Estimacin por UCP (Puntos de Casos de Uso)Roger L. Ingeniera del Software: Un enfoque

1 6 PRESMAN,

prctico1 7 PF:

Puntos de Funcin (Source Lines Of Code): Lneas de cdigo fuente

1 8 SLOCs

Se eligi la estimacin por UCP puesto que en el presente proyecto los casos de uso son uno de los pilares bsicos y el medio de comunicacin principal entre el cliente y la gerencia del proyecto. Adems, a diferencia de COCOMO, usar el mtodo de UCP permite realizar una estimacin confiable en las primeras etapas del proyecto, solamente haciendo uso de los casos de uso, sin entrar a profundizar en la construccin y elaboracin del proyecto, como lo necesita la estimacin por SLOCs o PF. Estimar por UCP trae muchas ventajas. Adems de la ya mencionada de la capacidad para una estimacin temprana, este mtodo toma en cuenta los factores de complejidad tcnica y de complejidad del entorno del proyecto, para computar de manera realista la duracin del proyecto. Cmo funciona? Resumiendo, a cada caso de uso y a cada actor se le asigna determinada complejidad. Luego, se le asigna un peso o valor en una escala a los diferentes componentes de la complejidad tanto tcnica como del entorno, para obtener los diferentes factores independientes en la ecuacin. Luego, mediante una prueba piloto en algn caso de uso o por la experiencia previa, se obtiene el nmero total de horas por UCP nico. Finalmente, en una ecuacin se calcula el nmero total de horas de desarrollo del proyecto. Horas por UCP nico Modelo de Casos de Uso, con su complejidad determinada (tanto para casos como para actores) Peso en la escala de factores de complejidad tcnica Peso en la escala de factores de complejidad del entorno

Para la obtencin del clculo de Horas por UCP, se realiz una prueba piloto en el desarrollo de un solo mdulo del proyecto, en nuestro caso, el de administracin y se tomaron las mtricas de tiempo, as como el resultado de los UCP de dicho mdulo. Partiendo de la ecuacin bsica de clculo de las horas totales de un proyecto, tenemos que:

HorasTotales = UCP * HorasPorUCP63

HorasTotales UCP = HorasPorUCP

Por tanto, en el mdulo de administracin que tard cerca de 100 horas en completar (HorasTotales), con un valor de UCP de 32, se tiene:

100 HorasPorUCP = 32 3.0Entonces, es claro que el valor de HorasPorUCP en nuestro proyecto, es de 3.0, lo cual va a proporcionar una entrada muy precisa a la ecuacin de clculo de la estimacin por UCP, y servir en proyectos futuros que tengan un modelado de casos de uso a un nivel similar. En este caso, el modelado por casos de uso se llev a un nivel explcito y granular, casi al de funciones CRUD (Crear, Recuperar, Actualizar y Eliminar). Observemos la manera como se calcul la estimacin para el proyecto en tem Fecha de Estimacin Numero de Casos de Uso Puntos de Casos de Uso Unicos (UUCP) Complejidad Tecnica (TCF) Complejidad del Entorno (ECF) Puntos de Casos de Uso (UUCP * TCF * ECF) = UCP Horas por UUCP (HRS) Horas Totales (HRS * UCP)Tabla 15: Estimacin por puntos de casos de uso (UCP)

Valor 15-Ago-2003 22 125.00 0.92 0.71 81.00 3.00 243.00

Se observa que la cantidad de horas para el desarrollo del proyecto, es de 243 horas en total. Es decir, el resultado de la estimacin por puntos de casos de uso, dio como resultado que se estima que para el desarrollo y construccin del proyecto se tomarn 243 horas. Observemos cmo se obtuvieron los valores de

($%! #/ Metrica TCF01

!0)*#?.&(&

2$ -.$(Peso 2,0064

Descripcin Sistema Distribuido

Valor 2,00

TCF 4,00

TCF02 TCF03 TCF04 TCF05 TCF06 TCF07 TCF08 TCF09 TCF010 TCF011 TCF012 TCF013

Tiempo

de

respuesta

1,00 1,00

3,00 2,00 3,00 2,00 1,00 3,00 4,00 3,00 1,00 2,00 0,00 0,00 Total:

3,00 2,00 3,00 2,00 1,00 3,00 8,00 3,00 1,00 2,00 0,00 0,00 32.00

(rendimiento) Eficiencia del usuario final (en linea) Procesamiento interno complejo 1,00 El cdigo debe ser reutilizable Fcil de instalar Fcil de usar Portable Fcil de cambiar Concurrente Incluir capacidades de seguridad especiales Acceso directo a SW de terceros 1,00 Necesidad de especial entrenamiento 1,00 1,00 1,00 1,00 2,00 1,00 1,00 1,00

Tabla 16: Componentes del factor de complejidad tcnica

Factor Valor TCF sin ajustar (UTV) Peso del TCF (TWF) Constante del TCF (TC) Factor de Complejidad Tcnica (TCF) = TC + (UTV * TWF)Tabla 17: Clculo del factor de complejidad tcnica (TCF)

Valor 32.00 0.01 0.60 0.92

($%! #/ Metrica ECF01 ECF02 ECF03 ECF04

!0)*#?.&(& *

-%! -!Peso 1,50 1,00 1,00 0,00 Valor 4,00 3,00 3,00 4,00 ECF 6,00 3,00 3,00 0,00

Descripcin Conoce el RUP Experiencia con la aplicacin Experiencia con el modelo POO Capacidades del analista lder65

ECF05 ECF06 ECF07 ECF08

Motivacin Requisitos estables Trabajadores de medio tiempo Dificultad en el lenguaje de programacin

1,00 2,00 -1,00 -1,00

5,00 4,00 1,00 1,00 Total:

5,00 8,00 -1,00 -1,00 23.00

Tabla 18: Componentes del factor de complejidad del entorno

Factor Valor del ECF sin ajustar (UEV) Peso del ECF (EWF) Constante del ECF (EC) Factor de Complejidad del Entorno (ECF) = EC + (UEV * EWF)Tabla 19: Clculo del factor de complejidad del entorno (ECF)

Valor 23.00 -0.03 1.40 0.71

!0)*#?.&(& ) !

$(/! ,/! L-.$!de uso. La

En la siguiente tabla se estim la complejidad de cada caso complejidad sigue una escala as: Sencillo = 5.0 Mediana = 10.0

Difcil = 15.0 Esta complejidad se calcula mediante el nmero de escenarios o pasos por cada caso de uso. Tambin se podra calcular mediante el nmero de clases o de tablas con las que se relaciona el caso de uso. Mdulo Administracin Administracin Administracin Administracin Administracin Administracin Nombre Ver Pedidos Modificar Usuario Agregar Usuario Eliminar Producto Modificar Producto Agregar Producto66

Tipo UseCase UseCase UseCase UseCase UseCase UseCase

Complej. 5.0 5.0 10.0 5.0 5.0 5.0

Mdulo Administracin Administracin Administracin Pedidos Pedidos Pedidos Pedidos Pedidos Pedidos Pedidos Pedidos Pedidos Seguridad Seguridad Seguridad Seguridad

Nombre Eliminar Categora Modificar Categora Agregar Categora Efectuar Pedido Ingresar datos del Pedido Mostrar Resumen del Pedido Eliminar Elementos del Pedido Calcular Precio del Pedido Agregar Elementos al Pedido Ver Pedido Ver Detalles Producto Registrarse en el sistema Recuperar clave Cambiar clave

Tipo UseCase UseCase UseCase UseCase UseCase UseCase UseCase UseCase UseCase UseCase UseCase UseCase UseCase UseCase

Complej. 5.0 5.0 5.0 15.0 5.0 5.0 5.0 5.0 5.0 5.0 5.0 5.0 5.0 5.0 5.0 5.0

Cambiar Cantidades del Pedido UseCase

Autorizarse en el sistema (login) UseCase

Tabla 20: Complejidad por caso de uso

G

:

D,.%#$ %, (

#/( !**!

Con el fin de tener la arquitectura de desarrollo ideal para el desarrollo del trabajo, se han de evaluar las alternativas viables, ms all de la inicialmente, donde se evalen su beneficios y desventajas tcnicas, administrativas y econmicas. Como se haba mencionado anteriormente, se llevar a cabo la realizacin bajo el modelo de n-capas o n-tier, lo que significa bsicamente un modelo de n- capas, consiste en construir diferentes capas dentro de la aplicacin con el fin que cada capa sea especializada en su tarea. Segn NTier Inc., un modelo por67

Si un sistema va a ser descrito como N-Tier, deber cumplir con las siguientes reglas: Cada capa deber poder existir en un independiente. Cada capa solo deber intercambiar informacin con las capas inmediatamente superior e inferior Cada capa podr ser intercambiable1 9 sistema fsicamente

Por tanto, nuestra arquitectura tendr un modelo por capas, as:

(( -%# 4(3 )

#/#-%($.A-

Recibe los datos enviados por el servidor y los analiza de manera tal que sean entendibles por el ser humano. En este caso la interfaz la proporciona un navegador que analiza el contenido de pginas HTML, XML, o DHTML, es decir, un navegador compatible con los estndares de HTML v.4.0. En conclusin, el usuario final puede hacer uso de cualquiera de los navegadores modernos, tales como Internet Explorer 4.x

(( )

A'.$(

#/#-%($.A- " *

#'!$.!

Manipula y modifica los datos enviados por la capa inferior de acceso a los datos y transforma de acuerdo a las reglas del negocio, generando el cdigo HTML o XML y la enva a la interfaz de presentacin mediante HTTP. Como alternativas Entorno Sun: JSP, con Enterprise Java Beans Entorno Microsoft: ASP.NET, con COM+ Entorno PHP: PHP, con XML

En la siguiente tabla comparativa se podrn apreciar las caractersticas de cada una de las alternativas, y la alternativa con caractersticas ms

1 9 N-TIER

INC., Client/Server and the N-Tier Model of Distributed Computing 68

ser resaltada. Dicha tabla fue tomada de phpPatterns, en su artculo Presenting with PHP: putting N-Tier Online20. Caracterstica Multiplataforma IDE grfico Madurez Fuertemente ligado a su productos Funcionalidad para la web Facilidad de integracin con diferentes tecnologas (ej. Competencia) Facilidad de despliegue Facilidad de aprendizaje S Difcil S Normal S Fcil Fcil Muy fcil Microsoft S Excelente S familia de Si Sun S Bueno S Algo PHP S Regular S No

Relativamen Normal te fcil Normal Normal No compatible

Compatibilidad con productos anteriores Compatible Velocidad de desarrollo Suporte y actualizacin Cantidad de mtodos y funciones aptos para utilizar Orientado a objetos Hardware especial Benchmarks de desempeo Aceptacin en el mercado Costo de acuerdo al presupuesto Normal Excelente Normal S S Excelente Alta Alto

muy Compatible Rpido Bueno Muchos S No Excelente Normal Libre

Normal Bueno Muchos S S Normal Alta Alto/Medio

Tabla 21: Comparacin entre tecnologas Microsoft, Sun y PHP

De la anterior tabla, se pueden extraer varias Para las conclusiones. necesidades de la empresa, las alternativas que ms se acercaron fueron Sun y20

phpPatterns():

Presenting

with 69

PHP:

putting

N-Tier

Online.

http://www.phppatterns.com/index.php/article/articleview/9/1/3/

PHP. Como se va a seguir el modelo de n-capas, es importante para el desarrollo del proyecto que se elija una opcin que pueda ser multiplataforma y tenga libertad para interactuar con otros sistemas que no siempre estn dentro de su familia de productos. Por ello, y por su elevado costo, la alternativa de la tecnologa Microsoft fue descartada desde el inicio, aunque proporcione un soporte y servicio al cliente excelente. Por tanto, los dos contendores directos son las tecnologas Sun y PHP. Este ltimo proporciona algunas ventajas frente a su competidor que est siendo ampliamente utilizado en el mercado. Algunos factores que entran a modificar la decisin, son la facilidad de aprendizaje y la velocidad de desarrollo de pequeos proyectos PHP, dado enfocados hacia la web utilizando queste est especializado en eso, Internet. Por

ello tambin existen muchas funciones en PHP especializadas y que pueden ser muy tiles al momento de desarrollar, evitando trabajo no necesario. Aunque PHP no sea respaldado por una entidad reconocida a nivel internacional, es un software en continua evolucin por un equipo de trabajo de muy buena calidad y poco a poco est siendo utilizado y reconocido en el mundo. Tal vez el factor ms decisivo a la hora de elegir luego de conocer los anteriores puntos, fue el precio. Como se explic anteriormente, la tecnologa Microsoft es la ms cara de todas, seguida por la Sun y finalmente, PHP que prcticamente no tiene costo (salvo el del soporte y mantenimiento). Aunque se puedan llevar a cabo soluciones de mediano y bajo costo con Sun (Tomcat, Jboss, etc.), estas no aseguran por completo la correcta operatividad e interconexin con los sistemas, y obviamente, se perdera el soporte. Por tanto, se eligi la alternativa de utilizar PHP con XML en esta capa del

(( )

$$# /! ( *!/

(%!/

Recibe las peticiones del nivel superior, ingresa a las diferentes fuentes de datos y devuelve los valores en formato accesible. Se tiene: JDBC ODBC70

Libreras de abstraccin de acceso a datos, nativas de PHP Teniendo en cuenta que se opt por el entorno PHP en la anterior capa, no tiene mucho sentido elegir JDBC como capa de acceso de datos. Por tanto, se tienen ODBC y las libreras nativas de PHP como alternativas. Aunque PHP tiene soporte completo para ODBC, igualmente tiene una cantidad importante de libreras nativas de acceso a los datos, que proporcionan ms velocidad. Por ello, se eligi la alternativa de utilizar las libreras de abstraccin de acceso a datos

(( )

(%!/

Los datos fsicos almacenados en repositorios. Vara desde archivos planos, bases de datos relacionales o repositorios de XML. Como alternativas: Microsoft SQL Server 2000 IBM DB2/Informix Oracle9i Database mySQL Bloor Research realiz una investigacin para IBM con el fin de una comparacin exhaustiva de las grandes compaas en el mercado de las bases de datos. Ellos especifican que una base de datos debe ser evaluada segn su tecnologa, as: Especficamente, se deben evaluar en la tecnologa subyacente los factores de disponibilidad, facilidad de uso, interoperatividad, escalabilidad y seguridad2 1 En esta capa, los requisitos de la aplicacin no son exhaustivos, simplemente requieren de un RDBMS que sea compatible con el estndar ANSI SQL, que tenga buen rendimiento, y que tenga una excelente tasa costobeneficio. Por ello, se realiz una comparacin bsica entre los servidores anteriormente enunciados. Se concluy, que comparativamente las bases de datos comerciales (SQL Server, Oracle9i y DB2) son excelentes y tienen una

2 1 IBM:

Bloor Research Databases: An evaluation & comparison. 71

2001

Microsoft SQL Server. Siendo notables los anteriores productos, notable tambin es el precio, siendo U$3,500.oo el ms econmico de todos. Estando el proyecto enfocado a la pequea y mediana empresa, los precios se salen del presupuesto y se est en la necesidad de elegir una alternativa ms econmica, en este caso, mySQL server comercial con valor de U$495,oo con soporte incluido por un ao. Es claro que por estar en una arquitectura de capas, donde cada una es independiente de la otra, y estar basada en el estndar ANSI SQL, esta base de datos podr ser migrada sin problemas a una ms robusta en caso de ser

Tenemos entonces una arquitectura basada mayormente en tecnologas de cdigo abierto, y grficamente es:

Figura 11: Esquema n-tier sobre arquitectura GNU/Linux 72

G

G

#C./.A- ( *(

#/%.A-

.#/'!/

En esta etapa inicial es importante realizar una revisin a la gestin de riesgos con fin de implantar nuevas medidas y estrategias, en caso de el necesarias ser evaluar los nuevos riesgos que hayan surgido debido arquitectura de desarrollo elegida. y De acuerdo con la poltica de gestin de riesgos establecida anteriormente, se verific que las estrategias estn siendo desarrolladas y en stas se efectivas. Adicionalmente, se realiz un que realidad hicieran especficamente sobre la nueva tecnologa a utilizar. Riesgos especficos de la arquitectura No se obtenga soporte sobre la tecnologa empleada No haya personal capacitado para 5 4 insuficiente e 3 5 35 10 20 5 administrar/mantener la tecnologa La tecnologa ser obsoleta La base de datos ser inadecuada El hardware no soportar la arquitecturaTabla 22: Riesgos especficos de la arquitectura

anlisis de riesgos Peso 4 P(r) 30

Aunque ningn factor sobrepase el valor que se estableci crtico como punto lmite, se debe poner especial nfasis en el riesgo que versa sobre que no haya personal capacitado para administrar/mantener la tecnologa. De esto desprende, que la empresa debe buscar asesora externa, o realizar capacitaciones internas sobre la nueva tecnologa a implantar.

G

H

.(' (0(

#$ ,#-$.(73

De los diagramas de interaccin existentes (secuencia y colaboracin), se opt por seleccionar el diagrama de secuencia como preferido, puesto que demuestra claramente a travs del tiempo la interaccin entre los diferentes componentes del sistema. Veamos pues el diagrama de secuencia del mdulo ms

74

Figura 12: Diagrama de Secuencia - Mdulo de pedidos 75

El diagrama tambin se puede apreciar en forma de tabla, como se muestra a continuacin: Cod 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Mensaje verCatlogo listar() listarProductos verDetallesProducto ver() mostrarDetallesProduc to agregarProductoAPedi do agregar(int, int) recalcular() confirmarAgregarProd ucto hacerPedido verificarPrivilegios() completarPedido() recalcular() confirmarPedido hacerPedido() ver() mostrarDetallesPedido cambiarPedido cantidad(int, int) Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Interfaz de catlogo Desde Hacia Interfaz de catlogo

Tabla 23: Diagrama de Secuencia Mdulo Pedidos

76

G

En la etapa de construccin se pasa del desarrollo y construccin de la propiedad intelectual producto de fases anteriores, hacia la elaboracin y construccin de productos utilizables en versiones alfa o beta. Es vital que al terminar esta fase se haya completado el anlisis, diseo, desarrollo y pruebas de toda la funcionalidad requerida. Dentro de la ideologa del RUP, se trat de hacer un balance en minimizar el tiempo de desarrollo con una buena calidad en el producto, buscando maneras de minimizar los costos de desarrollo, es decir, evitar el trabajo innecesario mediante la reutilizacin de cdigo (una de las Fue importante en esta fase rectificar y clarificar tanto los requisitos como el diseo que fueron necesarios, desarrollar o implementar los subsistemas o componentes, e integrarlos. Dicha integracin se realiz en el llamado modelo operacional, el cual representa una composicin fsica de la implementacin en trminos fuente y Durante la etapa de la construccin se hizo uso de un sistema de manejo de versiones llamado CVS (Concurrent Versin Set) con motivos de seguridad, organizacin y adems para proporcionar documentacin detallada de todos los de subsistemas y elementos (directorios, archivos, cdigo

77

G

6

#C./.A- ( *( #/%.0($.A- " 02% .$(/

Se llev un registro preciso de tiempo en la implementacin de cada caso de uso durante esta fase, con el fin de verificar qu tan diferente fue la realidad a lo planeado durante el paso de estimacin. En la siguiente tabla observaremos Mdulo Administracin Pedidos Seguridad Total Horas Estimadas 96 105 39 240 Horas Reales 96 127 42 269 Horas Diferencia 0 22 3 29 % de Diferencia 0% 20.9523% 7.6923% 12.0833 %

Tabla 24: Comparacin tiempo estimado vs. tiempo real

Se nota que hubo un 12.083% de diferencia con relacin al tiempo estimado, es decir, hubo un retraso del 12.083% en el tiempo de implementacin del proyecto. Aunque en la actividad de estimacin se hizo una prueba piloto con un mdulo con el fin de establecer un precedente, el resultado obtenido demuestra que la diferencia de tiempos fue mayor en el mdulo de mayor proporcin de integracin, que fue el mdulo de pedidos. Aunque la estimacin no fue perfecta, lejos de pensar que es inservible, los datos y resultados obtenidos sirven para perfeccionar la misma estimacin con el fin que sea ms certera y

G

*( -

,#>(/

Una vez realizada la primera versin alfa, es necesario realizar un plan de pruebas con el fin de evaluar contra el criterio de aceptacin con suficiente amplitud y profundidad, la implementacin y ejecucin de la aplicacin desarrollada, almacenando la informacin necesaria para diagnosticar y resolver78

identificar adicionalmente potenciales riesgos en los que el proyecto pueda caer, desde las primeras fases del desarrollo del mismo. El plan de pruebas que se realiz incluye diferentes tipos de riesgos dentro de los cuales hay varios tipos de pruebas que fueron ejecutadas por el grupo de desarrollo e integracin, o por terceras partes ajenas al proceso de construccin. Este plan de pruebas es basado en algunas pruebas sugeridas por

.#/'!1

, -$.!-(*.&(&

Este riesgo abarca los posibles problemas relacionados con la misma funcionalidad del sistema. Para probar este riesgo y sus posibles problemas, se

Prueba de FuncionalidadFue utilizada con el fin de validar que la unidad examinada funcione como se espera, es decir, que trabaje conforme a los casos de uso, requisitos, servicios, etc. Cada unidad examinada puede ser desde un mtodo o funcin, hasta un

Prueba de SeguridadSe verific que la informacin solo puede ser accedida por aquellos actores que en realidad tienen los privilegios y credenciales para hacerlo.

Prueba de VolmenEste examen prob la capacidad del sistema de recibir/devolver cantidades de informacin muy grandes o vacas. Se usaron consultas que devolvieran grandes cantidades de informacin, o informacin que fuera difcil para el motor

79

.#/'!1

/(>.*.&(&

Implica que la unidad a ser examinada cumpla con las caractersticas propias de una correcta interfaz al usuario. Es decir, evala la esttica, la consistencia de la interfaz, la documentacin, etc. Se efectu la llamada prueba

Prueba de UsabilidadSe examinaron factores tales como la esttica, la documentacin, la ayuda en lnea, la facilidad de comunicacin con el humano, la consistencia, y dems factores que permitan que la aplicacin sea amigable al usuario.

.#/'!1

! 4.(>.*.&(& -

Como su nombre lo indica, las pruebas realizadas para identificar problemas de este tipo busca que la aplicacin sea confiable en distintos niveles, es decir, busca la robustez de la misma. Las pruebas ms importantes en este

Prueba de IntegridadSe enfoca a la robustez de la unidad a examinar. Busca que tal unidad sea resistente a fallos, y evala factores tcnicos como uso de recursos y que la aplicacin est de acuerdo con los estndares del lenguaje.

Prueba de EstructuraEn el caso de las aplicaciones enfocadas a la web, esta prueba examin que todo el sistema sea completamente navegable, sin enlaces muertos, con congruencia en el diseo de navegacin, el contenido correcto sea mostrado, y que no hayan pginas inaccesibles (llamadas islas o hurfanas). En este caso, se80

LinkChecker, el cual fue de gran ayuda para encontrar problemas de tipo estructurales en la aplicacin web.

Prueba de AdversinBusca evaluar como se desempe el sistema en situaciones extremas y adversas, tales como sobrecarga de procesador, servicios no disponibles, falta de memoria, fallas en la comunicacin, y falta de cualquier tipo de recurso que sea necesario. Ms que para corregir situaciones, este tipo de prueba se realiza con el fin de identificar cmo funciona el sistema en condiciones anormales, para as poder sacar los debidos planes de contingencia y de mitigacin de riesgos, con su debido presupuesto para el futuro. Para estas pruebas, se hizo uso del software de pruebas automticas OpenSTA, el cual sirvi para simular el comportamiento de clientes y as sobrecargar la aplicacin, para finalmente dar los resultados

.#/'!1

#-&.0.#-%!

Las pruebas en este mbito se realizan con el fin de evaluar las caractersticas relacionadas con el rendimiento de un determinado sistema. Tales caractersticas pueden ser de tiempo de respuesta, confiabilidad operacional, y

Prueba de CargaVara la cantidad de entradas de operacin normal al sistema (nmero de consultas, usuarios, etc.) manteniendo constante la configuracin. Se us la aplicacin de pruebas automticas OpenSTA para este tipo de pruebas.

Prueba de Perfiles de FuncionamientoVara las configuracines del sistema, mientras las entradas de operacin normal del sistema permanecen constante. Se observa el comportamiento de la aplicacin bajo estos cambios.81

Pruebas de Comparacin (benchmarking)Compara los valores mesurables de la unidad a probar, con los de una unidad estndar ya conocida.

.#/'!1

( %#-.0.#-%! " -

!! )

%#

Finalmente estas ltimas pruebas, se aseguran que la unidad a ser examinada cumpla caractersticas propias de una correcta configuracin e instalacin.

Pruebas de ConfiguracinSe pretendi evaluar y asegurar que el sistema funcionara en diferentes configuraciones tanto de software como de hardware.

Pruebas de InstalacinSe busc probar cmo era la instalacin de la aplicacin en diferentes configuraciones tanto de software como de hardware. Se utiliza para identificar posibles errores y realizar planes de contingencia y mitigacin.

G

(/!/

,#>(

Por definicin, un caso de prueba es la definicin formal de un conjunto especfico de entradas, condiciones de ejecucin y resultados esperados, identificados con el fin de evaluar determinado aspecto de un elemento dentro de un proyecto. Se efectuaron casos de prueba para la realizacin de los tests propuestos en el plan de pruebas ya mencionado. Algunos de estos casos de

82

G

8

#) %# !

! #/

Una vez efectuados los casos de prueba para llevar a cabo el plan de pruebas, en caso tal que hayan casos de prueba cuya ejecucin haya dejado como resultado que no pasa el criterio de aceptacin los resultados esperados, se debe emitir un reporte de errores en el cual estarn plasmados de manera clara y concisa los errores y los problemas que debern ser solucionados con el fin que los elementos evaluados logren pasar los criterios de aceptacin definidos. Algunos ejemplos de documentos de reporte de errores, estn en el

G

9

.%# .!/

C(*,($.A-

Luego de las anteriores actividades, se llega a la meta de la fase de construccin, en la que se plantearon los criterios de evaluacin y en caso de ser positivos, se contina con la fase de transicin. A saber, los criterios de evaluacin que se realizaron fueron: Est el producto lo suficientemente maduro y listo para su lanzamiento hacia los usuarios finales? Estn los usuarios finales listos para aceptar el proyecto? Contina siendo aceptable el presupuesto luego de terminar esta fase? En caso tal que alguna de estas preguntas o criterios de evaluacin fuera negativa, el paso a la fase de transicin tendra que ser pospuesto y los artefactos relacionados con el criterio de evaluacin, identificados y corregidos.

83

G8

En la fase de transicin se asegura que la aplicacin est disponible para los usuarios finales. Tambin se hacen los cambios menores basndose ms que todo en la retroalimentacin de los usuarios beta y/o usuarios finales. Se dice cambios menores (configuracin, instalacin y usabilidad), porque los grandes cambios estructurales debieron haber sido corregidos en la fase anterior. Para

G86

,#>(/ >#%( " $(( $.%($.A)

Actualmente, en el desarrollo del proyecto se est en esta ltima fase obligatoria para el RUP, donde los usuarios finales estn llevando a cabo las pruebas beta y comparando la nueva aplicacin con la manera antigua de realizar los procesos. En paralelo, se est haciendo una induccin al rea administrativa que estar usando el software, de manera tal que se adapten al uso de la nueva aplicacin, e igualmente recibir la retroalimentacin de estos usuarios para

G8

#C./.A- (*

*( %# ($.! #/ -

Una vez en la fase de transicin, es importante revisar el Plan de Iteraciones con el fin de analizar los criterios de evaluacin particulares a cada iteracin, as como para la ratificacin del plan de la siguiente iteracin. El historial presente84

de

estas

revisiones

puede

ser

visto

en

el

Anexo

G

del

G8

.%# .!/

C(*,($.A-

Para terminar la ltima fase del ciclo del RUP, y por ende la iteracin, es necesario responder a unas preguntas o criterios de evaluacin con el fn de saber si los objetivos fueron alcanzados y si es necesario o no realizar otro ciclo del RUP. Los criterios de evaluacin en este caso son: Est(n) satisfecho(s) el (los) usuario(s)? El presupuesto real vs. el presupuesto planeado sigue siendo aceptable? Nuevamente, en caso que alguno de respondido de manera negativa, implicara involucrados en esta fase para los criterios de evaluacin sea una revisin a los artefactos causas de la falla, y

identificar las Una vez terminado el ciclo del RUP, se tendra una aplicacin o modelo de implementacin muy bien documentado, maduro, y de calidad, y si es necesario realizar cambios adicionales al mismo, se realizara otro nuevo ciclo o iteracin, donde se hara nfasis a la solucin del problema, funcionalidad adicional o al

85