Ingenieria de Software - Procesos

Procesos de ingeniera de software Software engineering processes

Hctor Arturo Flrez Fernndez*

Fecha de recepcin: 5 de abril de 2009Fecha de aceptacin: 15 de mayo de 2009

Resumen

Existen diferentes procesos en el tema ingeniera de software, que tienen como objetivo presentar diferentes tcnicas que consisten en la com-binacin de procedimientos que permiten guiar el diseo y el desarrollo de sistemas de software a un producto final de cali-dad. Algunos de esos procesos son: modelo secuencial, mode-lo en espiral, modelo win win, rational unified process (RUP), extreme programming (XP), mtodo delphi, mtrica versin 3, modelo de madurez de capacidad (CMM), proceso personal de software (PSP) y proceso en equipo de software (TSP).

Palabras clave: Ingeniera de Software, RUP (Rational Unified Process), XP (eXtreme Programming), CMM (Capability Matu-rity Model), PSP (Personal Software Process), TSP (Team Soft-ware Process).

* Ingeniero Electrnico de la Universidad El Bosque de Bogot, Ingeniero de Sistemas de la Universidad El Bosque de Bogot, Especialista en Alta Gerencia de la Universidad Militar Nueva Granada de Bogot, magster en Ciencias de Informacin y las Comunicaciones de la Universidad Distrital Francisco Jos de Caldas. Docente Investigador Funda-cin Universitaria Konrad Lorenz, docente Universidad Distrital Francisco Jos de Caldas. Adscrito al grupo de inves-tigacin Promente de la Fundacin Universitaria Konrad Lorenz. Correo electrnico: [email protected].

VINCULOS SPT 2010.indd 26 12/10/10 11:01

HcTor arTuro Flrez Fernndez

l o sE N E R O - J U N I O D E 2 0 0 9 V O L U M E N 6 N M E R O 1

ucnv

2727

Modelo lineal secuencial

Tambin llamado ciclo de vida clsico o modelo en cascada, sugiere un enfo-que1 sistemtico, secuencial para el desa-

Abstract There are different processes in software engineering, that

have the goal presenting different techniques that consist in the combination of processors that allow the guide in the de-sign and development of software systems to a final product whit quality. Some of these processes are sequential model, spiral model, win win model, rational unified process (RUP), extreme programming (XP) delphi method, metric version 3, capability maturity model (CMM), personal software process (PSP) and team software process (TSP)

Key words: Software Engineering, RUP (Rational Unified Process), XP (eXtreme Programming), CMM (Capability Ma-turity Model), PSP (Personal Software Process), TSP (Team Software Process)

rrollo del software que empieza con el esta-blecimiento de requisitos y pasa a las fases de anlisis, diseo, codificacin, pruebas y mantenimiento[1].

1 El modelo original propuesto por Winston Royce haca provisiones para ciclos de realimentacin, la gran mayora lo aplica como si fuera estrictamente lineal.

Figura 1. El ciclo de vida del modelo lineal secuencial [3]

Ingeniera y modelado de sistemas e informacin

Establece los requisitos para todos los ele-mentos del sistema y le asigna al software

algn subgrupo de estos requisitos. Tenien-do en cuenta el sistema como tal y la empre-sa desde los puntos de vista estratgico y de negocio.


procesos de ingeniera de soFTWare

2828

I + D I N V E S T I G A C I N Y D E S A R R O L L O

Anlisis de los requisitos del software

En esta parte el ingeniero intenta compren-der la naturaleza de los programas que han de construirse, as como el dominio de la aplicacin.

Diseo

En esta fase se traducen los requisitos a una representacin que pueda ser evalua-da previamente antes de empezar la fase de codificacin.

Generacin de cdigo

Se traduce lo diseado en la fase anterior a un lenguaje que pueda ser procesado por la mquina.

Pruebas

Cuando el cdigo se ha generado es el mo-mento de empezar a realizar las pruebas del programa, centrado en los procesos lgicos internos y en los procesos externos funciona-les para asegurar que las entradas producen los resultados requeridos.

Mantenimiento

El software puede necesitar cambios, debido a varias razones: errores, el entorno o mejo-ras sugeridas por el cliente.

Debilidades del modelo en cascada

Nada est hecho hasta que todo est terminado.

Se pueden presentar problemas debido a falta de informacin en la fase de levan-tamiento de requisitos.

El progreso ordenado no es realista: du-rante el proceso de desarrollo pueden

cambiar las variables de entorno del usuario que pueden afectar de mane-ra potencial y los requisitos planteados inicialmente.

La eliminacin de fallas suele ser extre-madamente difcil durante las ltimas etapas de prueba del sistema.

Modelo en espiral

El modelo espiral, propuesto originalmente por B. Boehm, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo en cascada [1], aadiendo un nuevo elemento: el anlisis de riesgo [2]. El modelo, representado mediante la espiral de la figura 2, define cuatro actividades principales:

Planificacin. Determinacin de objeti-vos, alternativas y restricciones.

Anlisis de riesgo. Anlisis de alter-nativas e identificacin/resolucin de riesgos.

Ingeniera. Desarrollo del producto del siguiente nivel.

Evaluacin del cliente. Valorizacin de los resultados de la ingeniera.

Durante la primera vuelta alrededor de la es-piral se definen los objetivos, las alternati-

Figura 2. Modelo espiral [2]




ucnv

2929

vas y las restricciones, y se analizan e iden-tifican los riesgos. Si el anlisis de riesgo indica que hay una incertidumbre en los re-quisitos, se puede usar la creacin de proto-tipos en el cuadrante de ingeniera para dar asistencia, tanto al encargado de desarrollo como al cliente. ste evala el trabajo de in-geniera (cuadrante de evaluacin de clien-te) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la si-guiente fase de planificacin y de anlisis de riesgo; en cada bucle alrededor de la espiral, la culminacin del anlisis de riesgo resulta en una decisin de seguir o no seguir.

Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versio-nes del software, cada vez ms completa y, al final, al propio sistema operacional.

Actualmente, el paradigma del modelo en es-piral para la ingeniera de software es el en-foque ms realista para el desarrollo de soft-ware y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de soft-ware, puesto que le permite al desarrollador y al cliente entender y reaccionar conforme a los riesgos en cada nivel evolutivo. De igual forma, utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de prototipos [2].

Modelo en espiral (win-win)

El modelo en espiral tratado anteriormente sugiere una actividad del marco de trabajo que aborda la comunicacin con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal, el desarrollador simplemente le pregunta al cliente lo que necesita y el cliente proporcio-

na detalles suficientes para continuar. Des-graciadamente, esto raramente ocurre. En realidad, el cliente y el desarrollador entran en un proceso de negociacin, en el cual el cliente puede ser preguntado para sopesar la funcionalidad, el rendimiento y otros pro-ductos o caractersticas del sistema frente al coste y al tiempo de comercializacin.

Las mejores negociaciones se esfuerzan en obtener gana-gana. Esto es, el cliente gana obteniendo el producto o sistema que satisfa-ce la mayor parte de sus necesidades y el de-sarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista.

El modelo en espiral win-win define un con-junto de actividades de negociacin al prin-cipio de cada paso alrededor de la espiral. Adems del nfasis realizado en la negocia-cin inicial, el modelo en espiral win-win in-troduce tres hitos en el proceso, llamados puntos de fijacin, que ayudan a establecer la completitud de un ciclo alrededor de la es-piral y proporcionan hitos de decisin antes de continuar el proyecto de software.

En esencia, los puntos de fijacin representan tres visiones diferentes del progreso mien-tras que el proyecto recorre la espiral. El pri-mer punto de fijacin, llamado objetivos del ciclo de vida, define un conjunto de objeti-vos para cada actividad principal de inge-niera de software. El segundo punto de fija-cin, llamado arquitectura del ciclo de vida, establece los objetivos que se deben conocer, mientras que se define la arquitectura del software y el sistema. La capacidad operati-va inicial es el tercer punto de fijacin y re-presenta un conjunto de objetivos asociados a la preparacin del software para la instala-cin y distribucin [1].

RUP (Rational Unified Process)

RUP (Rational Unified Process) es una me-todologa que permite construir software



3030


en tiempo y precio justos. RUP utiliza UML (Unified Modeling Language), para especifi-car, visualizar, construir y documentar siste-mas de software. Tambin representa un con-junto de las mejores prcticas de ingeniera que han probado ser exitosas en el modelo de sistemas, reduciendo la complejidad y el diseo de los procesos [7].

Un proceso de Ingeniera de Software re-quiere herramientas que apoyen todas las actividades del ciclo de vida de los sistemas. Como respuesta a ello Rational Software Corp. pone a disposicin herramientas que estn diseadas para hacer ms eficiente la aplicacin de metodologas como el RUP, de esa forma se permite la creacin de un am-biente de desarrollo ptimo. El conjunto de herramientas de Rational est basado en seis principios fundamentales para el desarrollo de software, denominadas las seis mejores prcticas que son: administracin de los re-querimientos, desarrollar en forma iterativa, modelar visualmente, pruebas continuas, ar-quitecturas basadas en componentes y con-trol de cambios [7].

Administrar los requerimientos

El desafo de administrar los requerimientos de un sistema de software es que son dinmi-cos, es decir, pueden cambiar durante la vida de un proyecto. Identificar los verdaderos re-querimientos de un sistema es delicado, de-bido a que hay que satisfacer objetivos eco-nmicos y tcnicos en un proceso continuo.

Desarrollar software iterativamente

El enfoque iterativo facilita la implementa-cin de nuevos cambios tcticos de reque-rimientos y caractersticas del cronograma. Con este enfoque se fortalece tempranamen-te la identificacin de los riesgos del proyec-to, cuando an es posible atacarlos y reac-

cionar a tiempo y eficientemente. De cada iteracin debe resultar una nueva versin ejecutable para verificar claramente que to-dos los productos generados actan en for-ma predecible y repetible [6].

Las iteraciones que se deben realizar en la elaboracin de un proyecto se describen en la siguiente figura.

Modelar software visualmente

Hacer modelos es importante, porque ayu-da al equipo de desarrollo a visualizar, es-pecificar, construir y documentar la estruc-tura y comportamiento de la arquitectura de un sistema de software. Si, adems, se utili-za un lenguaje de modelacin estndar, los distintos miembros del equipo de desarrollo pueden comunicar sus decisiones sin ambi-gedades. Las herramientas de modelacin visual facilitan la administracin de los mo-delos. Permiten presentar el modelo en dis-tintos niveles, ocultando los detalles. En re-sumen, mejora la capacidad del equipo para administrar la complejidad del software. [7]

Verificar continuamente la calidad del software

Encontrar y reparar un problema de software despus de la implementacin, puede resul-

Figura 3. Desarrollo interactivo




ucnv

3131

tar demasiado costoso. Por esta razn es im-portante evaluar continuamente la calidad de un sistema con respecto a su funcionali-dad, confiabilidad y performance. La activi-dad fundamental que involucra esta prcti-ca es la revisin, la cual permite encontrar las fallas antes de la puesta en produccin de un sistema. Si, adems se utiliza la prctica de desarrollar software iterativamente, se est revisando la versin en cada iteracin, lo-grando as un proceso de evaluacin conti-nuo y cuantitativo [7].

Utilizar arquitecturas basadas en componentes

El desarrollo basado en componentes es un enfoque importante de arquitectura de soft-ware, porque permite la reutilizacin o adap-tacin de componentes existentes de mi-les de fuentes comercialmente disponibles. Un componente de software se puede defi-nir como una pieza no trivial de software, un mdulo, un paquete o un subsistema que completa una funcin clara [7].

Controlar los cambios del software

Normalmente, un proyecto de sistemas, im-plica mltiples desarrolladores organizados en diferentes equipos de trabajo. Posible-mente, estos equipos de trabajo se encuen-tran en diferentes sitios, trabajando en con-junto y en mltiples iteraciones, para lograr nuevas versiones, productos y plataformas. Coordinar las actividades y los productos que van generando los desarrolladores im-plica establecer procesos repetibles para ad-ministrar los cambios al software y otros ar-tefactos del desarrollo. Esta coordinacin permite una mejor asignacin de los recur-sos, basada en las prioridades y en los ries-gos del proyecto y administrar activamente los cambios a travs de las iteraciones [7].

Fases para el diseo y desarrollo

Existen cuatro fases en los procesos RUP: ini-cio, elaboracin, construccin y transicin. Estas fases representan el nfasis de las acti-vidades dentro de cada iteracin [5].

Figura 4. Fases de RUP [5]



3232


Inicio

En esta fase, la meta de las iteraciones es ayu-dar al equipo de proyecto a decidir cules se-rn los objetivos verdaderos del proyecto [5].

Elaboracin

En esta fase se establece una comprensin firme del problema que se solucionar, se es-tablece la fundacin arquitectnica del soft-ware, se apoya un plan detallado de itera-ciones subsecuentes se refina el proceso y se elimina los altos riesgos. Las iteraciones pro-ducidas en esta fase estn, en el promedio, perceptiblemente menos disponible que las producciones en la fase de inicio. Cada ite-racin debe agregar nuevas caractersticas al cuerpo del software [5].

Construccin

Las iteraciones en la fase de la construccin no son muy diferentes de las iteraciones de la fase de la elaboracin. Cada iteracin agrega caractersticas al software. Durante esta fase, se espera que las descripciones del caso del uso se estabilizarn hasta cierto punto, sin embargo, en muchos dominios del proyecto continuarn cambiando a travs del curso de la vida del proyecto [5].

Transicin

En esta fase, las iteraciones continan agre-gando caractersticas al software. Sin embar-go, esas caractersticas agregan a un sistema que los usuarios estn utilizando activamen-te. Los artefactos producidos en esta fase son los mismos que los producidos en la fase de construccin. El equipo simplemente mejora el sistema hacia los objetivos que fueron fija-dos en el final de la fase del inicio [5].

Extreme Programing (XP)

Es una de las metodologas de desarrollo de software ms exitosas en la actualidad, uti-lizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es te-ner como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.Caractersticas de XP, la metodologa se basa en:

Pruebas unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantndonos en algo hacia el futuro, podamos hacer prue-bas de las fallas que pudieran ocurrir. Es como si nos adelantramos a obtener los posibles errores.

Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos estndares, siendo ms flexi-ble al cambio.

Programacin en pares: una particulari-dad de esta metodologa es que propone la programacin en pares, la cual consis-te en que dos desarrolladores participen en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la ac-cin que el otro no est haciendo en ese momento. Es como el chofer y el copilo-to: mientras uno conduce, el otro consul-ta el mapa.

El desarrollo bajo XP tiene caractersticas que lo distinguen claramente de otras metodologas: Los diseadores y programadores se co-

munican efectivamente con el cliente y entre ellos mismos.

Los diseos del software se mantienen sencillos y libres de complejidad o pre-tensiones excesivas.

Se obtiene retroalimentacin de usuarios y clientes desde el primer da, gracias a las ba-




ucnv

3333

teras de pruebas El software es liberado en entregas frecuentes tan pronto como sea po-sible. Los cambios se implementan rpida-mente tal y como fueron sugeridos. Las me-tas en caractersticas, tiempos y costos son reajustadas permanentemente en funcin del avance real obtenido.

Con estas caractersticas no es sorprenden-te que XP sea la metodologa ms apropiada para un entorno caracterizado por requeri-mientos cambiantes, originados por un mer-cado fluctuante y los propios avances de la tecnologa y los negocios.

Cambio de paradigma

El cliente tpico de servicios de desarrollo de software y pginas Web tiene mucha dificul-tad para ofrecer desde el inicio informacin precisa y detallada del sistema que necesi-ta. Esto es normal y la explicacin radica en muchos factores, entre los principales, la fal-ta de prototipos y las sucesivas oportunida-des para mejorar el sistema que el cliente en-cuentra mientras ste va tomando un forma ms tangible.

El desarrollo de un entregable de caractersti-cas fijas a un costo fijo crea ms problemas de los que pretende solucionar. A pesar de ser el paradigma comercial ms usado en la ac-tualidad, es un modelo que desperdicia de-masiadas oportunidades de entregar como resultado un software no slo ms til, sino tambin mejor diseado y ms fcil de man-tener. Adems, la dificultad natural en esta-blecer las caractersticas exactas de un pro-ducto que inicialmente es slo un concepto que genera diferencias, muchas veces insal-vables entre clientes y desarrolladores que originan la ruptura de las relaciones comer-ciales, casi siempre, ni bien el proyecto es fi-nalmente entregado y en casos incluso antes. La solucin radica en un manejo ms eficien-

te de los cambios en los requerimientos y un fuerte enfoque en las pruebas de aceptacin de cada etapa.

Gestin de cambios

El cliente est en el pleno derecho de hacer cuantos cambios necesite al proyecto, si con ello consigue un mejor resultado final. Para lograr esto, desarrolladores y clientes deben trabajar en conjunto y muy de cerca desde el primer da y las metas en trminos de carac-tersticas, tiempos y costos deben ser reajus-tadas permanentemente.

Un desarrollador nunca debe eliminar carac-tersticas con el afn de disminuir tiempos o costos sin la aprobacin del cliente. Un clien-te no puede esperar cambiar reiteradamen-te los requerimientos de un sistema si ya los ha probado y aceptado sin incurrir en gastos adicionales.

Gestin de costos

XP crea transparencia y un clima de agili-dad en la relacin entre desarrolladores y clientes. El costo de hora/hombre por cada tipo de recurso es conocido y acordado des-de el principio. Un proyecto de varios meses es dividido en pequeos proyectos de po-cas semanas de duracin y las metas y cro-nogramas se van ajustando en tiempo real, de acuerdo con el nivel de avance y las difi-cultades reales que ofrece el proyecto acepta-das en forma conjunta por desarrolladores y clientes.

El hecho de tener que aceptar resultados de poca calidad o que no solucionan realmente los problemas de las organizaciones perjudi-ca enormemente a los clientes. De igual for-ma, tener que enfrentar una gran cantidad de cambios y ajustes y regresar a etapas ya rea-lizadas por cambios en los requerimientos o



3434


los criterios de aceptacin perjudica enorme-mente a los desarrolladores, si es que no van a recibir una compensacin econmica por el esfuerzo adicional requerido.

Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probable-mente, est ocurriendo un problema que se debe corregir. El trabajo extra desmotiva al equipo. Los proyectos que requieren traba-jo extra para intentar cumplir con los plazos suelen ser entregados con retraso. En lugar de esto, se puede realizar el juego de la pla-nificacin para cambiar el mbito del proyec-to o la fecha de entrega.

Metodo Delphi

El mtodo Delphi consiste en una serie de interrogaciones repetidas, usualmente por medio de cuestionarios a un grupo de indi-viduos, cuyas opiniones o juicios son de in-ters. Despus de un interrogatorio inicial a cada individuo, cada subsiguiente interroga-torio es acompaado por informacin consi-derando las respuestas precedentes, usual-mente presentadas annimamente. De esta manera, el individuo es alentado a recon-siderar, de ser apropiado, o cambiar su res-puesta previa a la luz de las respuestas de otros miembros del grupo. Despus de dos o tres vueltas, la posicin del grupo es deter-minada por promedio [10]

Generalidades

El mtodo Delphi es una tcnica para la re-solucin de problemas, toma de decisiones y predicciones de escenarios desarrollado por la corporacin Rand de la inteligencia mili-tar de los Estados Unidos. Fue desarrollado durante la Guerra Fra y, al parecer, toma su nombre de la localizacin del mtico orculo griego, Delfos.

Este mtodo hace uso de un panel de ex-pertos que de forma asincrnica no se re-nen, intercambian opiniones a travs de co-rreo electrnico u otro medio impersonal, son seleccionados en funcin de las reas de conocimiento requeridas por el proble-ma. Lo anterior implica la nocin de que in-dividuos bien informados, haciendo uso de su experiencia e introspeccin, estn mejor equipados para predecir el futuro que las aproximaciones tericas o la extrapolacin de tendencias [11]. Este mtodo asume que a travs de repetidos cuestionarios, los exper-tos se acercarn a un punto en comn que ser la mejor respuesta, lo cual es definido por indicadores estadsticos.

Etapas del proceso

Este mtodo incluye las siguientes etapas [12]: Formacin de un equipo para asumir y

monitorear un tema especfico. Seleccin de uno o ms paneles para par-

ticipar en el ejercicio. Frecuentemente, los panelistas son expertos en el rea por ser investigada.

Desarrollo del primer cuestionario Delphi.

Prueba del cuestionario para asegurar el uso de palabras correctas, es decir, por ejemplo, para evitar divagar o caer en ambigedades.

Transmisin del primer cuestionario a los panelistas.

Anlisis de la primera serie de respuestas. Preparacin del segundo cuestionario

Delphi y sus posibles pruebas. Transmisin de la segunda ronda de

cuestionarios a los panelistas. Anlisis de la segunda ronda de respues-

tas. Los pasos del 7 al 9 son repetidos hasta tanto se alcance la estabilidad ne-cesaria en los resultados.




ucnv

3535

Preparacin de un reporte por el equipo de anlisis para presentar las conclusio-nes del ejercicio.

Mtrica versin 3

Estructura de Mtrica versin 3

Ha tomado como referencia el modelo de ci-clo de vida propuesto en la norma ISO 12207, distinguiendo procesos principales (plani-ficacin, desarrollo y mantenimiento) e in-terfaces (gestin de proyectos, aseguramien-to de la calidad, seguridad y gestin de la configuracin), cuyo objetivo es dar sopor-te al proceso en los aspectos organizativos. Ha sido concebida para abarcar el desarro-llo completo de sistemas de informacin, sea cual sea su complejidad y magnitud, me-diante un enfoque orientado al proceso.

La metodologa descompone cada uno de los procesos en actividades y stas, a su vez, en tareas. Para cada tarea se describe su con-tenido haciendo referencia a sus principa-les acciones, productos, tcnicas, prcticas y participantes.

Procesos principales de Mtrica 3

Los procesos de la estructura principal de Mtrica 3 son los siguientes: Planificacin de sistemas de informacin. Desarrollo de sistemas de informacin. Mantenimiento de sistemas de

informacin.

Proceso de planificacin de sistemas de informacin

Su objetivo es proporcionar un marco estra-tgico de referencia para los sistemas de in-formacin de un determinado mbito de la organizacin. La perspectiva del plan debe ser estratgica y operativa, no tecnolgica.

En este proceso participan, por un lado, los responsables de los procesos de la organiza-cin con una visin estratgica y, por otro, los profesionales de ingeniera de software [14].

Como productos finales del proceso se obtienen: - Catlogo de requisitos de PSI.

Arquitectura de informacin, que se compo-ne de: Modelo de informacin. Modelo de sistemas de informacin. Arquitectura tecnolgica. Plan de Proyectos. Plan de mantenimiento del PSI.

Proceso de desarrollo de sistemas de informacin

Contiene todas las actividades y tareas que se deben llevar a cabo para desarrollar un siste-ma, cubriendo desde el anlisis de requisitos hasta la instalacin del software. Este proce-so es el ms importante de los identificados en el ciclo de vida de un sistema y se relacio-na con todos los dems.

Se ha subdivido en cinco procesos: 1. Estudio de Viabilidad del Sistema (EVS).

El propsito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solucin a corto plazo. Los resultados del EVS cons-tituirn la base para tomar la decisin de seguir adelante o abandonar.

2. Anlisis del Sistema de Informacin (ASI). El propsito de este proceso es conseguir la especificacin detallada del sistema de informacin, a travs de un catlogo de requisitos y una serie de modelos que cu-bran las necesidades de informacin de los usuarios para los que se desarrollar el sistema de informacin y que sern la entrada para el proceso del diseo del sis-tema de informacin. Se elabora el pro-



3636


ducto especificacin de requisitos soft-ware. Se inicia la especificacin del plan de pruebas, que se completar en el DSI. La participacin activa de los usuarios es una condicin imprescindible para el anlisis del sistema de informacin.

3. Diseo del Sistema de Informacin (DSI). El propsito del DSI es obtener la defini-cin de la arquitectura del sistema y del entorno tecnolgico que le va a dar so-porte, junto con la especificacin deta-llada de los componentes del sistema de informacin. A partir de dicha informa-cin, se generan todas las especificacio-nes de construccin relativas al propio sistema, as como la especificacin tcni-ca del plan de pruebas, la definicin de los requisitos de implantacin y el dise-o de los procedimientos de migracin y carga inicial, cuando proceda. En el dise-o de arquitectura del sistema participa-rn activamente los responsables de sis-temas y explotacin.

4. Construccin del Sistema de Infor-macin (CSI). Tiene como objetivo fi-nal la construccin y prueba de los dis-tintos componentes del sistema de informacin, a partir del conjunto de es-pecificaciones lgicas y fsicas de ste-obtenido en el DSI. Se desarrollan los procedimientos de operacin y seguri-dad y se elaboran los manuales de usua-rio final y de explotacin, como parte del proceso de desarrollo del proyecto Para ello, se recoge la informacin rela-tiva al producto obtenido del proceso de diseo, se prepara el entorno de produc-cin, se genera el cdigo de cada uno de los componentes del sistema de informa-cin y se realizan las pruebas unitarias de cada uno de ellos y las pruebas de inte-gracin entre subsistemas.

5. Implantacin y Aceptacin del Sistema (IAS). Tiene como objetivo principal la en-

trega y aceptacin del sistema en su totali-dad; un segundo objetivo es llevar a cabo las actividades oportunas para el paso a produccin del sistema. En este proceso se elabora el plan de mantenimiento del sistema. Tambin se establece el acuerdo de nivel de servicio[14].

Modelo de madurez de capacidad (CMM)

Al final de los aos ochenta y a comienzos de los noventa el SEI desarroll el modelo de madurez de capacidad CMM que captur las mejores prcticas de las organizaciones para el desarrollo de software. El CMM es un fra-mework construido sobre las mejores prcti-cas de las organizaciones. La mejora del pro-ceso ha demostrado aumentar el producto y la calidad del servicio, mientras que las orga-nizaciones la aplican para alcanzar sus obje-tivos del negocio.

El CMM define cinco niveles de madurez de software basados sobre las reas de procesos que soportan a las organizaciones.

Nivel 1. Inicial. Describe a una orga-nizacin con procesos indefinidos e inmaduros.

Nivel 2. Repetible. Describe a una orga-nizacin que requiere gestin en planea-cin, seguimiento de proyectos, subcon-tratacin, aseguramiento de la calidad y configuracin en software.

Nivel 3. Definido. Define a una organi-zacin que adopta procesos de organiza-cin focalizados, definidos, programas de entrenamiento, manejo de software integrado, productos de ingeniera y co-ordinacin grupal.

Nivel 4. Gestionable. Describe organi-zaciones que tienen anlisis, medicin y prevencin de defectos sobre sus proce-sos y productos de software.




ucnv

3737

Nivel 5. Optimizado. Organizaciones con innovaciones tecnolgicas y procesos de manejo al cambio.

Los niveles 2, 3, 4 y 5 describen organizacio-nes con sucesivos niveles mejores de pro-cesos de madurez de software. La primera meta de las organizaciones es alcanzar el ni-vel 3 de madurez.

El modelo CMM tiene las siguientes desventajas: Est soportado sobre el modelo en

cascada. No hace nfasis sobre los procesos de ar-

quitectura y diseo. Tiene mtodos policivos en las revisio-

nes, inspecciones y en el aseguramiento de calidad.

Hay una sobre documentacin, ya que se considera que entre ms detalles es mejor.

Hay conflictos entre el modelo CMM y el ISO9001.

Proliferacin de modelos: modelos SE-CMM, desarrollo del producto integrado IDP-CMM, adquisicin de software SA-CMM y recursos humanos People-CMM.

Como respuesta a lo anterior, el SEI desarro-ll la integracin de modelo de madurez de capacidad CMMI.

Proceso personal de software (PSP)

Watts Humphrey, junto con el equipo del SEI, deciden aplicar los principios subyacen-tes del CMM a las prcticas del desarrollo de software enfocado al desarrollador. El resul-tado de este esfuerzo es el proceso personal de software (PSP), diseado para ser un pro-ceso de nivel 5 CMM, para los desarrollado-res de software.El 70% de los costos de desarrollo en un pro-yecto, lo constituyen las habilidades y los h-

bitos del trabajo de los ingenieros, los cuales determinan en gran parte el resultado del de-sarrollo de software. El proceso personal de software PSP (el cmo) puede ser utilizado por los ingenieros como una gua a un acer-camiento disciplinado y estructurado al de-sarrollo de software.

El PSP ensea a los ingenieros lo siguiente: Cmo manejar la calidad de sus

proyectos. Hacer la cosas simples para dar

soluciones. A mejorar tiempos de estimacin y

planeacin. Reducir los defectos de los productos.

El PSP puede aplicar a muchas partes del de-sarrollo de software, incluyendo: Desarrollo de programas. Definicin de requisitos. Estructura de la documentacin. Pruebas del sistema. Mantenimiento de los sistemas. Desarrollo de sistemas de software

grandes.

Este proceso se centr en una persona y se ol-vid que en los proceso de desarrollo inter-vienen ms de una persona.

Proceso de software del equipo (TSP)

Pronto lleg a ser obvio que mientras los re-sultados con el PSP eran excelentes, era casi imposible mantener la prctica en ambientes de desarrollo colaborativos. Entonces, Watts Humphrey desarrolla el proceso de software de equipo TSP para la unidad operacional ms pequea de las organizaciones de soft-ware, el equipo del proyecto. TSP fue disea-do para ser un proceso de nivel 5 CMM, para los equipos del proyecto.



3838


El proceso del software del equipo (TSP), jun-to con el proceso personal del software PSP, ayuda al ingeniero de alto rendimiento a: Aseguramiento de la calidad de los pro-

ductos de software. Crear productos de software seguros. Mejora el proceso de gerencia en una

organizacin.

Los grupos de la ingeniera que utilizan el TSP aplican conceptos integrados del desa-rrollo de sistemas orientados al software, lle-vando al equipo a:

Establecer metas. Definir papeles del equipo. Determinacin de riesgos. Producir un plan del equipo.

Los equipos pueden estar integrados por slo desarrolladores o equipos integrados que participan en la obtencin del producto. Los equipos pueden estar integrados de 3 a 20 personas.

Conclusiones

El modelo en Cascada posee grandes incon-venientes, en particular, cuando un cambio de requisitos se realiza al final del proceso debido a la rigidez que tiene este modelo. Un mal levantamiento requerimientos en la par-te inicial del proceso conllevar a un fracaso. En los modelos en espiral, el proceso de soft-ware es evolutivo e incluye riesgos que de-ben ser tenidos en cuenta desde el inicio de ste, lo que hacen de estos modelos una op-cin ms acorde.

RUP tiene una caracterstica importante ex-plicada en un modelo denominado las seis mejores prcticas. Este modelo le permite a un grupo de trabajo desarrollar un proyecto teniendo en cuenta los requerimientos, el de-sarrollo iterativo, el diseo bajo un lenguaje de modelado visual, un control calidad, una

arquitectura basada en componentes y un control de cambios del software.

La metodologa XP es exitosa porque enfa-tiza la satisfaccin del cliente y promueve el trabajo en equipo. Las actividades improduc-tivas han sido eliminadas para reducir costos y frustraciones. Esta metodologa ha sido di-seada para solucionar el eterno problema del desarrollo de software por encargo, es decir, entregar el resultado que el cliente ne-cesita a tiempo.

La metodologa Mtrica versin 3 proporcio-na un conjunto de mtodos y tcnicas que le permite a los diseadores de sistemas de in-formacin desarrollar los procesos del ciclo de vida de un proyecto informtico. A fin de mejorar la productividad y asegurar la cali-dad de los productos resultantes, la metodo-loga est soportada por herramientas dis-ponibles en el mercado que automatizan en mayor o menor grado su utilizacin. En cual-quier caso, no todos los productos resultan-tes de cada tarea son susceptibles de obtener-se de forma automatizada.

El mtodo Delphi permite obtener lo mxi-mo del conocimiento, experiencia y habili-dades de un grupo entero de personas, en el cual cada uno cuenta con un conocimiento y una perspectiva nica y diferente. Es espe-cialmente bueno para la planeacin estrat-gica de negocios en medio de la incertidum-bre y ambientes de movimiento y cambio rpido. Sin embargo, es asincrnico, pues re-duce la retroalimentacin directa que ofrece un grupo de trabajo. En ocasiones, los desa-rrollos futuros no son siempre predichos por los expertos en consensos iterativos, sino que en ocasiones se obtienen mejores resultados con panelistas no expertos. Los participan-tes pueden ser expertos buenos, pero pobres estimadores. Los expertos pueden tender a considerar el futuro aisladamente de otros eventos.




ucnv

3939

Referencias bibliogrficas

[1] R. Pressman. IngenieradelSoftware:unenfoque prctico. 5 Edicin. Mc Graw-Hill 2001.

[2] http://www.itlp.edu.mx/publica/tutoriales/analisis

[3] http://juanfc.lcc.uma.es/EDU/PM/1.IngSoft.pdf

[4] B. Bruegas, A Dutoit. Ingenierade soft-ware orientada a objetos. Ed. Prentice-Hall. 2002.

[5] http://www.objectmentor.com/re-sources/articles/RUPvsXP.pdf

[6] http://www.dcs.ed.ac.uk/teaching/cs2/online/Lectures/CS2Ah/Sof-tEng/se06-slides.PDF

[7] http://www.stc-online.org/cd-rom/1999/slides/EBestPra.pdf

[8] P. Abrahamsson, O. Salo, J. Ronkain-en, J. Warsta. AgilesoftwaredevelopmentmethodsReviewandanalysis. VTT Pub-lications. 2002.

[9] Beck, K.. Extreme Programming Ex-plained. Embrace Change, Pearson Ed-

ucation, 1999. Traducido al espaol como: Una explicacin de la program-acinextrema.Aceptarelcambio. Addison Wesley. 2000.

[10] http://pespmc1.vub.ac.be/ASC/DEL-PHI_METHO.html

[11] http://www.ryerson.ca/~mjoppe/ResearchProcess/841TheDelphiMethod.htm

[12] http://www.iit.edu/~it/delphi.html[13] http://www.corporate-partnering.

com/info/delphi-method-business-planning.htm

[14] Metodologa de Planificacin y De-sarrollo de Sistemas de Informacin. Guas de Referencia, de Tcnicas y del Usuario. http://www.csi.map.es/csi/metrica3/index.html.

[15] A. Durn y B. Bernrd. Metodologaparala Elicitacin de Requisitos de SistemasSoftwareVersin2.1.

[16] Desarrollos Mecame S.L. Madrid (Espa-a). Tcnicas y Prcticas. http://www.desarrollos-mecame.com/formacion/Ingenieria-software/Ingenieria%20software_archivos/tecnicas.pdf


Documents

Ingenieria de Software - Procesos