Universidad de Pamplona

Portada
Proceso de Desarrollo de Software
Ingeniera de Sistemas

2011

http://www.unipamplona.edu.co/

Tabla de ontenidos
1 INTRODUCCIN....................................................................................................................... 1 2 MODELOS DE PROCESOS..................................................................................................... 2 2.1 MODELO EN CASCADA................................................................................................... 8 2.1.1 PROCESO.................................................................................................................. 9 2.1.2 PRODUCTO............................................................................................................. 10 2.1.3 PERSONAL.............................................................................................................. 10 2.1.4 TECNOLOGIA.......................................................................................................... 10 2.2 MODELO EN ESPIRAL.................................................................................................... 10 2.2.1 PROCESO................................................................................................................ 11 2.2.2 PRODUCTO............................................................................................................. 13 2.2.3 PERSONAL.............................................................................................................. 13 2.2.4 TECNOLOGIA.......................................................................................................... 13 2.3 PROTOTIPADO EVOLUTIVO.......................................................................................... 13 2.3.1 PRODUCTO............................................................................................................. 14 2.3.2 PERSONAL.............................................................................................................. 17 3 ESTANDARES........................................................................................................................ 18 3.1 IEEE 12207...................................................................................................................... 19 3.1.1 INTRODUCCION...................................................................................................... 19 3.1.2 PROCESO DEL CICLO DE VIDA.............................................................................20 3.1.3 ACTIVIDAES Y TAREAS.......................................................................................... 23 3.2 IEEE 1074........................................................................................................................ 25 3.2.1 GENERALIDADES................................................................................................... 25 3.2.2 ACTIVIDADES.......................................................................................................... 27 4 MODELOS DE MEJORA........................................................................................................ 35 4.1 CMM................................................................................................................................. 35 4.1.1 PRINCIPIOS Y CONCEPTOS..................................................................................35 4.1.2 NIVELES DE MADUREZ: ........................................................................................ 36 4.1.3 ESTRUCTURA DEL MODELO SW CMM................................................................3! 4.1.4 ESTRUCTURA DEL CMM........................................................................................ 39 4.2 CMMI................................................................................................................................ 44 4.2.1 PRINCIPIOS Y CONCEPTOS..................................................................................44 4.2.2 MADUREZ................................................................................................................ 44 4.2.3 CAPACIDAD............................................................................................................. 45 4.2.4 ESTRUCTURA DEL MODELO CMMI .....................................................................45 4.2.5 REPRESENTACI"N POR NIVELES........................................................................45 4.2.6 NIVEL DE MADUREZ 1 INICIAL..............................................................................45 4.2.7 NIVEL DE MADUREZ 2 ADMINISTRADO...............................................................46 4.2.! NIVEL DE MADUREZ 3 DE#INIDO..........................................................................46 4.2.9 NIVEL DE MADUREZ 4 GESTIONADO CUANTITATIVAMENTE............................47 4.2.10 NIVEL DE MADUREZ 5 OPTIMIZADO..................................................................4! 4.2.11 REPRESENTACI"N CONTINUA...........................................................................49 4.2.12 CATEGORIZACI"N DE LAS $REA DE PROCESO..............................................50 4.3 ISO................................................................................................................................... 51 4.3.1 NORMAS ISO 9000 3 PARA SO#TWARE...............................................................51 5 METODOLOGIAS................................................................................................................... 53 5.1 RUP.................................................................................................................................. 58 5.1.1 PROCESO................................................................................................................ 60 5.1.2 PRODUCTO............................................................................................................. 62 5.1.3 PERSONAL.............................................................................................................. 66 5.1.4 TECNOLOGIA.......................................................................................................... 6! 5.2 XP.................................................................................................................................... 69 5.2.1 PROCESO................................................................................................................ 71 5.2.2 PRODUCTO............................................................................................................. 75

5.2.3 PERSONAL.............................................................................................................. 76 5.2.4 TECNOLOGIA.......................................................................................................... 76 5.3 SCRUM............................................................................................................................ 78 5.3.1 PROCESO................................................................................................................ 7! 5.3.2 PRODUCTO............................................................................................................. 79 5.3.3 PERSONAL.............................................................................................................. !0 5.3.4 REUNIONES............................................................................................................ !0 5.4 CRYSTAL (CLEAR)......................................................................................................... 81 5.4.1 PROCESO................................................................................................................ !2 5.4.2 PRODUTO................................................................................................................ !3 5.4.3 PERSONAL.............................................................................................................. !4 5.4.4 TECNOLOGIA.......................................................................................................... !5 5.5 PSP.................................................................................................................................. 85 5.5.1 PROCESO................................................................................................................ !6 5.5.2 TECNOLOGIA.......................................................................................................... !7 5.6 TSP.................................................................................................................................. 93 5.6.1 PROCESO................................................................................................................ 94 5.6.2 PRODUCTO............................................................................................................. 97 5.6.3 PERSONAL.............................................................................................................. 97 5.6.4 TECNOLOGIA.......................................................................................................... 97 5.7 MS .................................................................................................................................. 97 5.7.1 PROCESO................................................................................................................ 9! 5.7.2 PRODUCTO............................................................................................................. 99 5.7.3 PERSONAL............................................................................................................ 101 5.8 ASD................................................................................................................................ 103 5.!.1 PROCESO.............................................................................................................. 104 5.!.2 PRODUCTO........................................................................................................... 110 5.!.3 PERSONAL............................................................................................................ 111 5.!.4 TECNOLOGIA........................................................................................................ 111 5.!.5 GLOSARIO............................................................................................................. 113 5.9 DD................................................................................................................................ 114 5.9.1 PROCESO.............................................................................................................. 115 5.9.2 PRODUCTO........................................................................................................... 116 5.9.3 PERSONAL.......................................................................................................... 117 5.9.4 TECNOLOGIA .................................................................................................... 11! 5.10 DSDM........................................................................................................................... 119 5.10.1 PROCESO............................................................................................................ 119 5.10.2 PRODUCTO......................................................................................................... 121 5.10.3 PERSONAL.......................................................................................................... 122 5.10.4 TECNOLOGIA...................................................................................................... 122

!ndice de "iguras
ILUSTRACIN 1: CICLO DE VIDA CLSICO PARA EL DESARROLLO DE SOFTWARE......2 ILUSTRACIN 2: MODELO EN V............................................................................................... 4 ILUSTRACIN 3: MODELO YOURDON.....................................................................................5 ILUSTRACIN 4: MODELO EN CASCADA CON SU PROYECTORES..................................5 ILUSTRACIN 5: MODELO DE ENTREGA POR ETAPAS........................................................! ILUSTRACIN !: MODELO DE PROTOTIPADO EVOLUTIVO.................................................! ILUSTRACIN ": MODELO DE PROTOTIPADO DES#EC#A LE..........................................." ILUSTRACIN 8: MODELO DE DESARROLLO INCREMENTAL............................................." ILUSTRACIN $: MODELO SEMIAUTOMATI%ADO................................................................." ILUSTRACIN 1&: MODELO EN ESPIRAL................................................................................8 ILUSTRACIN 11: MODELO EN CASCADA.............................................................................$ ILUSTRACIN 12: MODELO DE PROCESO DE ESPIRAL.....................................................11 ILUSTRACIN 13: DESARROLLO EVOLUTIVO' ACTIVIDADES...........................................14 ILUSTRACIN 14: VIDA PROTOTIPADO EVOLUTIVO...........................................................14 ILUSTRACIN 15: ES(UEMA ESTRUCTURAL DEL IEEE 122&"..........................................2& ILUSTRACIN 1!: ACTIVIDADES DEL IEEE 1&"4.................................................................2" ILUSTRACIN 1": ESTRUCTURA DEL MODELO SW)CMM..................................................3! ILUSTRACIN 18: DIAGRAMA DE LA ESTRUCTURA DETALLADA DEL CMM..................3$ ILUSTRACIN 1$: LOS CINCO NIVELES DE MADURE% DE CAPACIDAD DEL MODELO CMMI.......................................................................................................................................... 45 ILUSTRACIN 2&: REPRESENTACIN CONTINUA...............................................................4$ ILUSTRACIN 21: ES(UEMA DEL ISO $&&1..........................................................................53 ILUSTRACIN 22: METODOLOGIAS......................................................................................54 ILUSTRACIN 23: METODOLOG*AS ORIENTADAS A PROCESOS.....................................55 ILUSTRACIN 24: METODOLOG*AS ORIENTADAS A DATOS.............................................55 ILUSTRACIN 25: METODOLOG*AS #I RIDAS....................................................................5! ILUSTRACIN 2!: ELEMENTOS DE UNA METODOLOG*A...................................................5! ILUSTRACIN 2": #ISTORIA DE RUP....................................................................................58 ILUSTRACIN 28: CICLO DE VIDA DE RUP...........................................................................!1 ILUSTRACIN 2$: CICLO DE VIDA DE RUP...........................................................................!1 ILUSTRACIN 3&: DISTRI UCIN T*PICA DE RECURSOS #UMANOS...............................!2 ILUSTRACIN 31: PROYECTO DE PROGRAMACIN E+TREME........................................"1 ILUSTRACIN 32: SPI,ES - OS(UEJOS.............................................................................."2 ILUSTRACIN 33: PLANIFICACIN DE LA ENTREGA.........................................................."3 ILUSTRACIN 34: COMEN%AR ITERACIN..........................................................................."3 ILUSTRACIN 35: PROGRAMACIN......................................................................................"4 ILUSTRACIN 3!: MANTENIMIENTO ) PRUE AS DE ACEPTACIN..................................."4 ILUSTRACIN 3": #ISTORIA DE USUARIO..........................................................................."5

ILUSTRACIN 38: METODOLOG*A SCRUM..........................................................................."$ ILUSTRACIN 3$: ETAPAS DE LA METODOLOGIA CRYSTAL CLEAR...............................83 ILUSTRACIN 4&: NIVELES DE PSP......................................................................................8! ILUSTRACIN 41: FLUJO DEL PROCESO EN PSP...............................................................8" ILUSTRACIN 42: ESTNDAR TIPOS DE DEFECTOS I........................................................$& ILUSTRACIN 43: ESTNDAR TIPO DE DEFECTOS II.........................................................$1 ILUSTRACIN 44: RESUMEN DEL PLAN...............................................................................$2 ILUSTRACIN 45: ESTRUCTURA TSP...................................................................................$5 ILUSTRACIN 4!: PROCESO DE MSF....................................................................................$8 ILUSTRACIN 4": ESCALA DE E(UIPOS............................................................................1&1 ILUSTRACIN 48: SCALE UP................................................................................................ 1&2 ILUSTRACIN 4$: EJEMPLO DE LOS ROLES EN SCALE DOWN......................................1&3 ILUSTRACIN 5&: EL CICLO DE VIDA ADAPTATIVO. TOMADA DE /#IG#SMIT#' 2&&&0.1&4 ILUSTRACIN 51: ACTIVIDADES DEL CICLO DE VIDA ADAPTATIVO. TOMADA DE /#IG#SMIT#' 2&&&0................................................................................................................. 1&5 ILUSTRACIN 52: ACTIVIDADES DE ASD...........................................................................11& ILUSTRACIN 53: FASES DEL FDD.....................................................................................115 ILUSTRACIN 54: PROCESO ITERATIVO DE DISE1O Y CONSTRUCCIN POR FUNCIONALIDAD.................................................................................................................... 11! ILUSTRACIN 55: O TENCIN DE RE(UERIMIENTOS EN DSDM...................................11$ ILUSTRACIN 5!: FASES EN DSDM....................................................................................121

!ndice de Tablas
TA LA 1: PERSONAL EN PROTOTIPADO EVOLUTIVO........................................................18 TA LA 2: PROCESO DE GRUPO DE IEEE 1&"4....................................................................2! TA LA 3: CMM VS CMMI NIVEL 2 DE MADURE%..................................................................4! TA LA 4: CMM VS CMMI NIVEL 3 DE MADURE%..................................................................4" TA LA 5: CMM VS CMMI NIVEL 4 DE MADURE%..................................................................48 TA LA !: CMM VS CMMI NIVEL DE MADURES 5..................................................................48 TA LA ": CMM VS CMMI......................................................................................................... 5& TA LA 8: CMMI......................................................................................................................... 51 TA LA $: DISTRI UCIN T*PICA DE ESFUER%O Y TIEMPO...............................................!2 TA LA 1&: ARTEFACTO RUP.................................................................................................. !2 TA LA 11: E+PLICACIN ARTEFACTO RUP........................................................................!3 TA LA 12: NIVELES DE REVISIN RUP................................................................................!3 TA LA 13: ARTEFACTOS MODELADO DEL NEGOCIO........................................................!4 TA LA 14: ARTEFACTOS RE(UERIMIENTOS......................................................................!4 TA LA 15: ARTEFACTOS ANALISIS Y DISE1O....................................................................!5 TA LA 1!: ARTEFACTOS IMPLEMENTACIN......................................................................!5 TA LA 1": ARTEFACTOS PRUE AS.....................................................................................!5 TA LA 18: ARTEFACTOS DESPLIEGUE................................................................................!! TA LA 1$: ARTEFACTOS ADMINISTRACIN Y CONFIGURACIN DE CAM IOS.............!! TA LA 2&: PRODUCTOS EN CRYSTAL CLEAR....................................................................84 TA LA 21: GUIONES DE PROCESO.......................................................................................88 TA LA 22: LOG DE REGISTRO DE TIEMPO..........................................................................8$ TA LA 23: EJEMPLO LOG DE REGISTRO.............................................................................$& TA LA 24: ROLES (UE SON POSI LES FUSIONAR Y ROLES NO RECOMENDADOS...1&3

P#$ %S$ D% D%S&##$''$ D% S$"T(&#%

INTRODUCCIN

Un Ingeniero de Software tiene )ue estar mu* bien preparado para administrar sus pro*ectos sea cual sea. Para esto e+isten normas, modelos * metodologas a los cuales un profesional de la ingeniera del software debe apegarse. %l modo de traba-ar depende de gustos * de las necesidades, *a )ue algunos procedimientos puede )ue sean m.s efectivos )ue otros de acuerdo al pro*ecto )ue se est. llevando a cabo. /a )ue el mundo inform.tico est. evolucionando en una forma acelerada, puede )ue las tecnologas en el futuro vallan cambiando, pero estos conocimientos son base fundamental para entender las formas de desarrollo )ue puedan surgir a lo largo del tiempo. &l final del curso de debe tener un rango de conocimiento amplio *a )ue habremos estudiados distintos m0todos de desarrollo. %n esta breve introducci1n podramos abordar temas tales como el ciclo de vida el cual es tratado de forma distinta en los temas posteriores. &)u veremos la forma cl.sica del ciclo de vida del desarrollo del software. I '$ D% 2ID& '&SI $ P&#& %' D%S&##$''$ D%' S$"T(&#% %l ciclo de vida software es un marco de referencia )ue contiene los procesos, las actividades * las tareas involucradas en el desarrollo, la e+plotaci1n * el mantenimiento de un producto software, abarcando la vida del sistema desde la definici1n de los re)uisitos hasta la finali3aci1n de uso. Un proceso se define como un con-unto de actividades interrelacionadas )ue trasforman entradas en salidas. Un proceso define )uien est. haciendo )u0, cu.ndo * c1mo alcan3ar un determinado ob-etivo. Pese a la e+istencia de numerosas metodologas de desarrollo de software, los conceptos de ciclo de vida cl.sico permanecen implcitos en cual)uier metodologa. %l m0todo del ciclo de vida para el desarrollo de sistemas software consta de las siguientes actividades: 4 Investigaci1n preliminar &claraci1n de la solicitud %studio de factibilidad o "actibilidad t0cnica. o "actibilidad econ1mica. o "actibilidad operacional

4 4 4 4 4 4

&probaci1n de la solicitud Determinaci1n de los re)uisitos del sistema. Dise6o del sistema 7dise6o l1gico8 Desarrollo de software 7dise6o fsico8. Prueba de sistemas. Implantaci1n * evaluaci1n. %valuaci1n operacional Impacto organi3acional $pini1n de los administradores Desempe6o del desarrollo

Ilustracin 1: Ciclo de vida Clsico para el Desarrollo de Software

MODELOS DE PROCESOS
9$D%'$

#epresentaci1n de procesos o sistemas )ue conforman un conglomerado ma*or o supra: sistema, )ue pretende el an.lisis de interacci1n de ellos, a fin de mantener una relaci1n fle+ible )ue les permita cumplir su funci1n particular * coad*uvar para cumplir la funci1n del supra:sistema. %l resultado pretende proponer m0todos para fortalecer los

elementos * los procesos de interacci1n para la pervivencia * fortalecimiento del supra: sistema. P#$ %S$

Un proceso 7del latn processus8 es un con-unto de actividades o eventos )ue se reali3an o suceden 7alternativa o simult.neamente8 con un fin determinado. on-unto de actividades )ue, reali3adas en forma secuencial, permiten transformar uno o m.s insumos en un producto o servicio. %s una secuencia temporal de e-ecuciones de instrucciones )ue corresponde a la e-ecuci1n de un programa secuencial. %s cual)uier operaci1n o secuencia de operaciones )ue involucren un cambio de energa, estado, composici1n, dimensi1n, u otras propiedades )ue pueden referirse a un dato. <= Proceso es la serie de pasos utili3ados para producir un resultado deseado>= seg?n el oncise &merican @eritage Dictionar*, 5ABC P#$ %S$ D% D%S&##$''$ D% S$"T(&#%

on-unto de actividades, m0todos, pr.cticas * transformaciones )ue la gente usa para desarrollar * mantener software * los productos de traba-o asociados 7planes de pro*ecto, dise6o de documentos, c1digo, pruebas, manuales de usuario, etc.8 Proceso o con-unto de procesos usados por una organi3aci1n o pro*ecto, para planificar, gestionar, e-ecutar, monitori3ar, controlar * me-orar sus actividades software relacionadas. on-unto coherente de polticas, estructuras organi3acionales, tecnologas, procedimientos * artefactos )ue son necearas para concebir, desarrollar empa)uetar * mantener un producto software. on-unto parcialmente ordenado de actividades llevadas a cabo para gestionar, desarrollar * mantener sistemas software. %l proceso software define como se organi3a, gestiona, mide, soporta * me-ora el desarrollo, independientemente de las t0cnicas * m0todos usados. 9$D%'$ D% P#$ %S$

Un modelo de proceso de software es una representaci1n simplificada de un proceso de software )ue conlleva una estrategia global para abordar el desarrollo de software o 9odelos de proceso de software: o odificar * corregir 7code:and:fi+8

o Desarrollo en cascada o Desarrollo evolutivo

o Desarrollo formal de sistemas o Desarrollo basado en reutili3aci1n o Desarrollo incremental o Desarrollo en espiral 9$D%'$S P&#& D%S&##$''$ D%' S$"T(&#%

& continuaci1n se dar.n a conocer algunos de los modelos utili3ados para el desarrollo de software * sus estructuras.

Ilustracin 2: Modelo en V

Ilustracin 3: Modelo Yourdon

Ilustracin 4: Modelo en Cascada con Su pro!ectores

Ilustracin ": Modelo de #ntre$a por #tapas

Ilustracin %: Modelo de &rototipado #volutivo

Ilustracin ': Modelo de &rototipado Des(ec(a le

Ilustracin ): Modelo de Desarrollo Incre*ental

Ilustracin +: Modelo Se*iauto*ati,ado

Ilustracin 1-: Modelo en #spiral

&lgunos de estos modelos ser.n e+plicados con m.s profundidad a lo largo del documento. 2.1 MODELO EN CASCADA

%l modelo en cascada comen31 a dise6arse 5AGG * tuvo auge hasta alrededor de 5ACH. %ste modelo se define como una secuencia de fases en la )ue al final de cada una de ellas se verifica si re?ne la documentaci1n para garanti3ar )ue cumple las especificaciones * re)uisitos antes de pasar a la siguiente fase. De esta forma cual)uier error de dise6o es detectado.

2.1.1 PROCESO

Ilustracin 11: Modelo en Cascada Ingeniera * &n.lisis del Sistema &n.lisis de los #e)uisitos Dise6o odificaci1n Prueba 9antenimiento

Ingeniera * an.lisis del sistema: omo el software va ser parte de un sistema ma*or el traba-o comien3a estableciendo los re)uisitos de todos los elementos del sistema * utili3ar alg?n subcon-unto de esos re)uerimientos para el software. &n.lisis de los re)uerimientos: Se anali3an las necesidades de los usuarios finales del software para determinar los ob-etivos )ue se deben cubrir. Importante acordar todo lo )ue re)uiere el sistema para evitar percances en etapas siguientes. Dise6o: Se enfoca en E atributos distintos de programaci1n: o %structura de los datos.

o 'a ar)uitectura del software. o %l detalle procedimental. o Determinaci1n de la interfa3. %n este proceso nos encargamos de traducir los re)uisitos en una representaci1n del software con la calidad re)uerida antes )ue comience la codificaci1n. odificaci1n: %l dise6o se traduce en forma legible para la m.)uina. &)u se hacen pruebas para detectar * corregir errores. Pruebas: 'os elementos, *a programados, se ensamblan para componer el sistema * se comprueba )ue funcione correctamente * )ue cumple con los re)uisitos, antes de ser entregado. 9antenimiento: %n esta etapa se destina CFI de los recursos *a )ue en el mantenimiento de software, los usuarios al utili3ar el sistema puede ser )ue no cumpla con todas las e+pectativas. 2.1.2 PRODUCTO 2.1.3 PERSONAL 2.1.4 TECNOLOGIA 2.2 MODELO EN ESPIRAL

Definido por primera ve3 por Jarr* Joehm 7Inform.tico estadounidense8 en 5ABB, autor de ; artculos destacados, los cuales son: 9odelos de estimaci1n de esfuer3o * tiempo )ue se consume en hacer productos software 9odelos de ciclo de vida

%l modelo no es aplicable ?nicamente a la ingeniera del software, sino a cual)uier otro proceso )ue tenga actividades * necesite obtener un resultado, por e-emplo: %l desarrollo de ensamble de un carro, la construcci1n de una casa, la composici1n de una canci1n= etc. %n el modelo en espiral, las actividades se implementan en forma de iteraciones o bucles, cada nueva iteraci1n o bucle est. formada de un con-unto de actividades, la idea )ue motiv1 a Jarr* a implementar este modelo fue el factor de los riesgos a la hora de desarrollar un software, e-emplos de riesgos en este caso son: Tiempo, el riesgo al afirmar )ue el software estar. listo en determinados horas, das, semanas o a6os. osto, el riesgo al no contar con las herramientas necesarias

5H

alidad, el riesgo al escoger una estrategia de calidad )ue no aumente este factor a lo sumo.

Kstos * otros riesgos se observan en el modelo espiral en la actividad an.lisis de riesgos, en donde a grandes rasgos se busca obtener nuevos riesgos, pero )ue sean asumibles 70stos son a)uellos )ue se pueden sobrellevar con m.s facilidad8, las actividades de cada nueva iteraci1n o bucle son definidas gracias al an.lisis de riesgos hecho en la iteraci1n previa.

Ilustracin 12: Modelo De &roceso de #spiral

2.2.1 PROCESO %l proceso est. organi3ado en las siguientes fases: $b-etivos: %n esta fase se llevan a cabo las siguientes actividades: o Definir ob-etivos o Definir restricciones del proceso * del producto o #eali3ar dise6o detallado del plan administrativo o Identificar riesgos o %laborar estrategias alternativas de acuerdo a los riesgos #educci1n de riesgos: %n esta fase se llevan a cabo las siguientes actividades: o &nali3ar detalladamente los riesgos *a identificados en la fase previa o Desarrollar prototipos para reducir el riesgo de re)uisitos dudosos

55

o Seguir los pasos para reducir los riesgos Desarrollo: %n esta fase se llevan a cabo las siguientes actividades: o %scoger modelo de desarrollo de acuerdo a los riesgos identificados para esta fase 7cascada, sistemas formales, evolutivo, prototipado, etc.8 o &plicar el modelo de desarrollo escogido Planeaci1n: %n esta fase se llevan a cabo las siguientes actividades: o Determinar si continuar o no con otro ciclo o Si se decide continuar, planear la siguiente fase del pro*ecto, es decir, la fase I $b-etivos, pero en una nueva iteraci1n. Por cada ciclo se van a recorrer las E fases, ob-etivos, reducci1n de riesgos, desarrollo * planeaci1n, dentro del modelo es importante identificar * entender dos ciclos: iclo 7Jucle o iteraci1n8 inicial: %n este inicia el pro*ecto. 'as fases ob-etivos, reducci1n de riesgos * el desarrollo son fundamentales en este primer ciclo * se caracteri3a por)ue las actividades no se basan en ning?n otro ciclo. iclo 7Jucle o iteraci1n8 final: %n este est. finali3ando el pro*ecto, la fase de desarrollo * planeaci1n son mu* importantes a)u por)ue estas definen la finali3aci1n del pro*ecto, *a no ha* por lo menos ning?n riesgo )ue no sea asumible.

%l comportamiento de los ciclos depende de la efectividad del cumplimiento de las actividades en cada fase, los ciclos internos ser.n la base de todo el pro*ecto * revelan )ue el pro*ecto se est. apenas consolidando, los ciclos e+ternos tienden un poco m.s hacia el desarrollo * reducci1n de riesgos por)ue en estos ciclos se est. planeando la finali3aci1n del pro*ecto, la me-or versi1n del pro*ecto * la ?nica se ve en el ciclo final.

5;

2.2.2 PRODUCTO 2.2.3 PERSONAL 2.2.4 TECNOLOGIA 2.3 PROTOTIPADO EVOLUTIVO

%l modelo de desarrollo evolutivo 7algunas veces denominado como prototipado evolutivo8 constru*e una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras )ue la apro+imaci1n incremental presupone )ue el con-unto completo de re)uerimientos es conocido al comen3ar, el modelo evolutivo asume )ue los re)uerimientos no son completamente conocidos al inicio del pro*ecto. %n el modelo evolutivo, los re)uerimientos son cuidadosamente e+aminados, * s1lo esos )ue son bien comprendidos son seleccionados para el primer incremento. 'os desarrolladores constru*en una implementaci1n parcial del sistema )ue recibe s1lo estos re)uerimientos. %l sistema es entonces desarrollado, los usuarios lo usan, * proveen retroalimentaci1n a los desarrolladores. Jasada en esta retroalimentaci1n, la especificaci1n de re)uerimientos es actuali3ada, * una segunda versi1n del producto es desarrollada * desplegada. %l proceso se repite indefinidamente. %l desarrollo de software en forma evolutiva re)uiere un especial cuidado en la manipulaci1n de documentos, programas, datos de prueba, etc. desarrollados para distintas versiones del software. ada paso debe ser registrado, la documentaci1n debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada. 'a especificaci1n * el desarrollo est.n intercalados. Un modelo sirve de prototipo para la construcci1n del sistema final.

%n la figura siguiente se muestra el proceso del desarrollo evolutivo de un sistema.

5D

Ilustracin 13: Desarrollo #volutivo. /ctividades

Ilustracin 14: Vida &rototipado #volutivo

2.3.1 PRODUCTO documento de planeaci1n del negocio 7Jusiness Planning Document8 documento de gesti1n de configuraci1n 7 onfiguration 9anagement Document8 plan del pro*ecto 7Pro-ect Plan8

5E

plan de declaraci1n/garanta de calidad de software 7Software Lualit* &ssurance Plan8 documento de estimaci1n del pro*ecto 7Pro-ect %stimation Document8 polticas de privacidad 7Privac* Polic*8 polticas de seguridad 7Securit* Polic*8 especificaci1n de re)uerimientos 7#e)uirements Specification8 especificaci1n del dise6o 7Design Specification8 agenda de reuniones de riesgo * revision 7 #eview / #isM 9eeting &genda8 plan de pruebas 7Test Plan8

Uno de los primeros tems )ue se crea cuando es apropiado o necesitado es el plan de negocios 7ubica el pro*ecto dentro de un mercado, mostrado su demanda, usabilidad etc. Se debe modificar constantemente para mostrar el estado del pro*ecto * del mercado ob-etivo8. Tambi0n en la etapa inicial del ciclo de desarrollo, se escribe el plan de pro*ecto 7funciona como el enrutador o conductor del pro*ecto8. &mbos planes deben evolucionar al igual )ue lo hace el pro*ecto, en vista de )ue los calendarios, personal, roles, responsabilidades, descripciones del pro*ecto o documentos relacionados cambian constantemente, estos cambios se deben refle-ar en el plan del pro*ecto. %s importante destacar )ue cuando se ubica el pro*ecto en el 9ercado deben establecerse polticas de privacidad * seguridad desde el inicio del pro*ecto, se deben crear * de igual manera incluirlas en el sistema )ue se est. creando con el fin de )ue sean efectivas. I '$ 5 'os primeros re)uerimientos de entrada )ue da el usuario sirven como base para el plan de traba-o, el administrador del pro*ecto * el escritor t0cnico establecen el plan de pro*ecto con a*uda del grupo entero de traba-o bas.ndose en la plantilla de plan de pro*ecto establecida, esto permite la creaci1n * entendimiento de los roles, responsabilidades, calendarios * descripci1n del pro*ecto. &pro+imadamente al mismo tiempo se debe traba-ar en las polticas de privacidad * seguridad )ue guiaran el pro*ecto, todo el e)uipo colabora con las polticas las cuales servir.n como medida para la cualidad del sistema producido. 'os re)uerimientos deben ser documentados de acuerdo a la plantilla del documento de re)uerimientos por el escritor t0cnico liderando la creaci1n de la documentaci1n. %l ciclo termina con una reuni1n de revisi1n/riesgos para anali3ar los esfuer3os del e)uipo, las direcciones, problemas * soluciones, est.n basadas en la plantilla de las reuniones de revisi1n/riesgos. %n este ciclo se crean los siguientes tems:

5F

Plan de traba-o usando la plantilla del plan de traba-o. Plan del pro*ecto usando la plantilla del plan de pro*ecto. Polticas de privacidad * seguridad. Documentaci1n de los re)uerimientos inciales usando la plantilla del documento de re)uerimientos. Se lleva a cabo la reuni1n de revisi1n * riesgos de acuerdo a la plantilla de reuniones de revisi1n * riesgos.

I '$ ; &l inicio de este ciclo se ha desarrollado el plan de negocios, el pro*ecto ha sido planeado, e+isten polticas de privacidad * seguridad, unos re)uerimientos inciales han sido descubiertos * documentados * se han establecido estrategias de mitigaci1n de riesgos. Para a*udar en el entendimiento del sistema * establecer una comunicaci1n entre el cliente * el e)uipo de desarrollo, el actual ciclo se dedica en crear prototipos de interfaces de usuario para asegurarse )ue el pro*ecto va en el camino correcto. Se crean pantallas de interfa3 b.sicas con a*uda del e)uipo completo. %stas pantallas se archivan por parte del escritor t0cnico de acuerdo a las polticas de gesti1n de configuraci1n adem.s en paralelo el ar)uitecto -efe empie3a a traba-ar en la creaci1n de un dise6o del sistema basado en los re)uerimientos identificados. 'as pantallas generadas sirven para descubrir )ue re)uerimientos hacen falta * )ue problemas de comunicaci1n e+isten, estos son discutidos por los desarrolladores * el cliente, produciendo as nuevos re)uerimientos o la modificaci1n de otros, estos son documentados por el escritor t0cnico como una secci1n complementaria del documento de re)uerimientos original. 'as pantallas del sistema son archivadas * no se utili3an de nuevo. %n este ciclo se crean los siguientes tems: Prototipo de interfa3 de usuario Dise6o inicial del sistema basado en la plantilla del documento de dise6o 9odificaci1n de los re)uerimientos basados en la retroalimentaci1n de la evaluaci1n de la interfa3 de usuario de acuerdo a la plantilla del documento de re)uerimientos. Se lleva a cabo la reuni1n de revisi1n * riesgos de acuerdo a la plantilla de reuniones de revisi1n * riesgos

I '$ D uando el prototipo es completado se muestra al cliente. %l cliente revisa el prototipo creado * en con-unto con los desarrolladores descubren si ha* re)uerimientos nuevos o )ue necesitan ser cambiados. &l igual )ue antes los re)uerimientos nuevos o

5G

modificados son documentados por el escritor t0cnico como una secci1n complementaria del documento original de re)uerimientos. %l ciclo termina con una reuni1n de revisi1n * riesgos para conocer el estado del pro*ecto, descubrir riesgos, crear estrategias de mitigaci1n de riesgos * -u3gar la efectividad de las mismas. %n este ciclo se crean los siguientes tems: Dise6o completo del sistema de acuerdo a la plantilla del documento de dise6o. Primer prototipo )ue inclu*e el dise6o * los re)uerimientos. 'os re)uerimientos nuevos o modificados se documentan de acuerdo a la plantilla del documento de re)uerimientos. Se lleva a cabo la reuni1n de revisi1n * riesgos de acuerdo a la plantilla de reuniones de revisi1n * riesgos

I '$ E &l inicio de este punto del ciclo de vida, los re)uerimientos finales han sido creados * validados * el cliente ha contribuido con el primer prototipo. %n este ciclo se crean los siguientes tems: Dise6o consistente del sistema basado en la plantilla del documento de dise6o. Prototipo final )ue inclu*e los re)uerimientos * dise6o final. Se lleva a cabo la reuni1n de revisi1n * riesgos de acuerdo a la plantilla de reuniones de revisi1n * riesgos Prototipo final probado 7cubriendo los re)uerimientos * cumpliendo lo establecido en el plan de garanta de calidad de software8 se entrega al cliente. 2.3.2 PERSONAL
Rol Individuos Descripcin del rol Tipo de rol Administrador del Nombre(s) proyecto !e encar"a sobretodo de la supervisin del proyecto# T,cnico $alida las pr%cticas de "estin de con&i"uracin# 'antiene el plan de proyecto Dele"a la recoleccin de re(uerimientos !e encar"a de la implementacin Arbitra los problemas si los )ay 'iembro del e(uipo de in"enier*a del so&t+are# $i"ila y mantiene la documentacin# 4estin o t,cnico .r"ani/a las reuniones y su documentacin# Act0a como el e1perto de "estin de con&i"uracin# -scribe las pol*ticas de privacidad y se"uridad y ase"ura 2ue los productos de traba3o est,n acorde a ellas# Reali/a implementacin cuando es necesario# 'iembro del e(uipo de in"enier*a del so&t+are# 5idera la recoleccin de re(uerimientos# 4estin !e comunica con los sta6e)olders7 clientes7 usuarios &inales# 8onduce las entrevistas con los sta6e)olders#

-scritor t,cnico

Nombre(s)

In"eniero deNombre(s) re(uerimientos

5C

Administrador ne"ocios Ar(uitecto 3e&e

deNombre(s)

Nombre(s)

-1perto ase"uradorNombre(s) de calidad

Pro"ramador l*der Nombre(s)

-specialista temas

enNombre(s)

Act0a como inter&ace para el cliente# Documenta los re(uerimientos as* como las pol*ticas de&inidas# 'iembro del "rupo de in"enier*a del so&t+are# Desarrolla el plan de ne"ocio7 si es necesario lo"estin edita# 'antiene el plan de ne"ocio# 'iembro del e(uipo de in"enier*a del so&t+are# $i"ila el dise9o del con3unto del sistema# T,cnico 8ate"ori/a el traba3o de implementacin# Reali/a la planeacin de recursos# Reali/a implementacin# 'iembro del e(uipo de "arant*a de calidad de so&t+are# Dise9a los casos de prueba# T,cnico Reali/a las pruebas# 'antiene los reportes de &allas y errores# Reali/a implementacin# 'iembro del e(uipo de "arant*a de calidad de so&t+are# Dele"a el traba3o de implementacin# T,cnico $i"ila la solucin de de&ectos# Reali/a implementacin# 'iembro del e(uipo de desarrollo de so&t+are# 8onoce ciertos temas espec*&icos# 4estin o t,cnico Reali/a implementacin# 'iembro del e(uipo de desarrollo de so&t+are# 8rea un storyboard (prototipo en papel o "enerado por un editor )tml) 'iembro del e(uipo de desarrollo de so&t+are# un dise9o "estin

-specialista enNombre(s) dise9o de inter&a/ de usuario

0a la 1: &ersonal en &rototipado #volutivo

ESTANDARES

Un est.ndar es algo )ue sirve como tipo, modelo, norma, patr1n o referencia por ser corriente. 'as organi3aciones )ue desarrollan est.ndares relacionados con la ingeniera del software son: o Software %ngineering Institute 7S%I8 o &ssociation for omputing 9achiner* 7& 98 o Jritish omputer Societ* 7J S8 o I%%% omputer Societ* o #USS$"T &ssociation o Societ* of Software %ngineers 'os est.ndares * modelos relacionados con la gesti1n del proceso son:

5B

o I%%% 5;;HC Information Technolog*:Software life:c*cle processes 7Procesos del ciclo de vida del software8 o I%%% 5HCE I%%% Standard for Developing Software 'ife Processes o S(: 99 Software : apabilit* 9aturit* 9odel o 99I apabilit* 9aturit* 9odel Integration *cle

I%%% 7Institute of %lectrical and %lectronics %ngineers8 en espa6ol Instituto de Ingenieros %l0ctricos * %lectr1nicos, es una asociaci1n t0cnico:profesional mundial dedicada a la estandari3aci1n. & continuaci1n se describe dos est.ndares relacionados con los procesos de desarrollo de software para el desarrollo de software. 3.1 IEEE 12207 3.1.1 INTRODUCCION %l software es una parte esencial de sistemas comerciales * de tecnologa de la informaci1n. @a* una gran proliferaci1n de normas, procedimientos, m0todos, herramientas * entornos para desarrollar * gestionar el software. %sta proliferaci1n a creado dificultades en la gesti1n * en la ingeniera del software especialmente en la integraci1n de productos * servicios. 'a disciplina de software necesita evolucionar desde esta proliferaci1n hacia un marco de referencia com?n )ue pueda ser usado por los profesionales del software para <hablar el mismo lengua-e>, a la hora de crear * gestionar el software. 'a norma I%%% 5;;HC proporciona ese marco de referencia com?n. $JN%TI2$ %sta norma I%%% 5;;HC establece un marco de referencia com?n para el proceso del ciclo de vida del software, con una tecnologa bien definida a la )ue puede hacer referencia la industria del software. ontiene procesos, actividades * tareas para aplicar durante la ad)uisici1n de un sistema )ue contiene software, un producto software puro o un servicio software * durante el suministro, desarrollo, operaci1n * mantenimiento de productos software. P#$ %S$ D%' I '$ D% 2ID& D%' S$"T(&#%. %sta norma agrupa las actividades )ue se pueden llevar a cabo durante el ciclo de vida del software en cinco procesos principales, ocho procesos de apo*o * cuatro procesos organi3ativos. ada proceso del ciclo de vida est. dividido en un con-unto de actividadesO cada actividad se sub:divide a la ve3 en un con-unto de tareas. %SLU%9& %ST#U TU#&' D%' I%%% 5;;HC

5A

Ilustracin 1": #s1ue*a #structural del I### 122-'

3.1.2 PROCESO DEL CICLO DE VIDA 'os procesos principales del ciclo de vida dan servicio a las partes principales durante el ciclo de vida del software. Una parte principal es a)uella )ue inicia o lleva a cabo el desarrollo, operaci1n o mantenimiento de los productos software. %stas partes principales son el ad)uiriente, el proveedor, el desarrollador, el operador * el responsable de mantenimiento de producto software. '$S P#$ %S$S P#IP IP&'%S S$P: Proceso de ad)uisici1n: Define las actividades del ad)uiriente, la organi3aci1n )ue ad)uiere un sistema, producto software o servicio software. o Inicio. o Preparaci1n de la solicitud de propuestas. o Preparaci1n * actuali3aci1n del contrato. o Seguimiento del proveedor. o &ceptaci1n * finali3aci1n. Proceso de suministro: Define las actividades del proveedor, organi3aci1n )ue proporciona un sistema, producto software o servicio software al ad)uiriente.

;H

o Inicio. o Preparaci1n de la respuesta. o ontrato.

o Planificaci1n. o %-ecuci1n * control. o #evisi1n * evaluaci1n. o %ntrega * finali3aci1n. Proceso de desarrollo: Define las actividades del desarrollador, organi3aci1n )ue define * desarrolla el producto software. o Implementaci1n del proceso. o &n.lisis de los re)uerimientos del sistema. o Dise6o de la ar)uitectura del sistema. o &n.lisis de los re)uerimientos software. o Dise6o de la ar)uitectura del software. o Dise6o detallado del software. o odificaci1n * pruebas del software.

o Integraci1n del software. o Pruebas de calificaci1n del software. o Integraci1n del sistema. o Pruebas de calificaci1n del sistema o Instalaci1n del software. o &po*o a la aceptaci1n del software. '$S P#$ %S$S D% &P$/$ S$P: Proceso de verificaci1n: Define las actividades 7para el ad)uiriente, proveedor o una parte independiente8 para verificar hasta una nivel de detalle dependiente del pro*ecto software, los productos software. o Implementaci1n del proceso. o 2erificaci1n.

;5

Proceso de validaci1n: Define las actividades 7para el ad)uiriente, proveedor o una parte independiente8 para validar los productos software del pro*ecto software. o Implementaci1n del proceso. o 2alidaci1n.

Proceso de revisi1n con-unta: Define las actividades para evaluar el estado * productos de una actividad. %ste proceso puede ser empleado por cual)uiera de las dos partes, donde una de las partes 7revisora8 revisa a la otra parte 7la parte revisada8 de una manera con-unta. o Implementaci1n del proceso. o #evisiones de la gesti1n del pro*ecto. o #evisiones t0cnicas.

Proceso de auditora: Define las actividades para determinar la conformidad con los re)uerimientos, planes * contrato. %ste proceso puede ser empleado por dos partes cuales)uiera, donde una parte 7auditora8 audita los productos software o actividades de otra parte 7la auditada8. o Implementaci1n del proceso. o &uditoria.

Proceso de soluci1n de problemas: Define las actividades para anali3ar * eliminar los problemas 7inclu*endo las no conformidades8 )ue sean descubiertos durante la e-ecuci1n del proceso de desarrollo, operaci1n, mantenimiento u otros procesos, cuales )uiera )ue sea su naturale3a o causa. o Implementaci1n del proceso. o Soluci1n de problemas.

P#$ %S$S $#Q&PIR&TI2$S D%' I '$ D% 2ID& D%' S$"T(&#%. Se emplean por una organi3aci1n para establecer e implementar una infraestructura constituida por procesos * personal asociado al ciclo de vida * para me-orar continuamente esta infraestructura. Se usan habitualmente fuera del .mbito de pro*ectos * contratos especficosO sin embargo, la e+periencia ad)uirida mediante dichos pro*ectos * contratos contribu*e a la me-ora de la organi3aci1n. '$S P#$ %S$S $#Q&PIR&TI2$S S$P: Proceso de gesti1n: Define las actividades b.sicas de gesti1n, inclu*endo la gesti1n de pro*ectos, durante un proceso del ciclo de vida. o Inicio * definici1n del alcance. o Planificaci1n.

;;

o %-ecuci1n * control. o #evisi1n * evaluaci1n. o "inali3aci1n. Proceso de infraestructura: Define las actividades b.sicas para establecer la infraestructura de un proceso del ciclo de vida. o Implementaci1n del proceso. o %stablecimiento de la infraestructura. o 9antenimiento de la infraestructura. Proceso de me-ora de proceso: Define las actividades b.sicas )ue una organi3aci1n 7ad)uiriente, proveedor, desarrollador, operador, responsable de mantenimiento o gestor de otro proceso8 lleva a cabo para establecer, medir, controlar * me-orar sus procesos del ciclo de vida. o %stablecimiento del proceso. o %valuaci1n del proceso. o 9e-ora del proceso. Proceso de recursos humanos: Define las actividades b.sicas para conseguir personal adecuadamente capacitado. o Implementaci1n del proceso. o Desarrollo del material de formaci1n. o Implementaci1n del plan de formaci1n. %N%9P'$. Proceso de ad)uisici1n: contiene las actividades * las tareas del ad)uiriente. %l proceso comien3a con la identificaci1n de la necesidad de ad)uirir un sistema, un producto software o un servicio software. %l proceso continua con la preparaci1n * publicaci1n de una solicitud de propuesta, la selecci1n de un proveedor * la gesti1n del proceso de ad)uisici1n hasta la aceptaci1n del sistema, del producto software o servicio software. 'a organi3aci1n )ue tiene la necesidad puede a su ve3 contratar a un tercero )ue se encargue de este proceso. 7%l ad)uiriente puede ser el propietario o el tercero8 3.1.3 ACTIVIDAES Y TAREAS IPI I$: %l ad)uiriente inicia el proceso de ad)uisici1n describiendo un concepto o una necesidad de ad)uirir, desarrollar o me-orar un sistema, un producto o un servicio de software.

;D

%l ad)uiriente definir. * anali3ara los re)uerimientos del sistema. onviene )ue los re)uerimientos del sistema inclu*an re)uerimientos de negocio, organi3ativos * de usuario, as como de seguridad fsica * de acceso * otros re)uerimientos crticos, -unto con los procedimientos * normas de dise6o, pruebas * confiabilidad relacionados. %l ad)uiriente contrata a un proveedor para llevar a cabo el an.lisis de re)uerimientos del sistema, el ad)uiriente aprobara los re)uerimientos anali3ados. 7o lo pueda llevar a cabo el mismo8 %l ad)uiriente considera las opciones para la ad)uisici1n a partir del an.lisis de los criterios apropiados )ue inclu*an los riesgos, costos * beneficios de cada opci1n. 'as posibles opciones son: o omprar un producto software pre elaborado )ue satisfaga los re)uerimientos.

o Desarrollar un producto de software u obtener el servicio del software internamente o c. Desarrollar el producto de software u obtener el servicio de software mediante un contrato. o Una combinaci1n de la primera, segunda * tercera. o me-orar un producto de software *a e+istente. onviene )ue el ad)uiriente prepare, documente * e-ecute un plan de ad)uisici1n. onviene )ue el ad)uiriente defina * documente la estrategia * condiciones de aceptaci1n.

P#%P&#& I$P D% '& S$'I ITUD D% P#$PU%ST&S: onviene )ue el ad)uiriente documente los re)uerimientos de la ad)uisici1n * estos deben incluir: re)uerimientos del sistema, definici1n del alcance, instrucciones para los ofertantes, lista de los productos de software, t0rminos * condiciones, control de los sub:contratos, restricciones t0cnicas 7por e-emplo entorno de destino8. 'a documentaci1n de la ad)uisici1n definir. tambi0n los hitos del contrato en los )ue el progreso del proveedor ser. revisado * auditado como parte de la supervisi1n de la ad)uisici1n. Se deber. proporcionar a la organi3aci1n seleccionada, los re)uerimientos de ad)uisici1n para llevar a cabo las actividades de la ad)uisici1n.

P#%P&#& I$P / & TU&'IR& I$P D%' $PT#&T$:

;E

onviene )ue el ad)uiriente seleccione un proveedor bas.ndose en la evaluaci1n de las propuestas de los proveedores, su capacidad * otros factores )ue deban tener en cuenta. %l ad)uiriente preparara * negociara un contrato con el proveedor estableciendo los re)uerimientos de la ad)uisici1n, inclu*endo costos * pla3os del producto o servicio software a entregar. %l contrato tendr. en cuenta los derechos de marca, uso, propiedad, garanta * licencia asociados a los componentes pre:elaborados reutili3ables.

S%QUI9I%PT$ D%' P#$2%%D$#. %l ad)uiriente supervisara las actividades del proveedor de acuerdo con el proceso de revisi1n con-unta * el proceso de auditora. %l ad)uiriente cooperara con el proveedor para proporcionar toda la informaci1n necesaria en el momento preciso * resolver todos los asuntos pendientes.

& %PT& I$P / "IP&'IR& I$P. onviene )ue el ad)uiriente prepare la aceptaci1n bas.ndose en la estrategia * los criterios de aceptaci1n definidos. Deber. incluirse la preparaci1n de los casos de pruebas, datos de prueba, procedimientos de prueba * entorno de las pruebas. Debera definirse hasta )u0 grado se involucra al proveedor. %l ad)uiriente lleva a cabo revisiones de aceptaci1n * pruebas de aceptaci1n del producto o servicio software entregable * solo lo aceptara del proveedor cuando se satisfagan todas las condiciones de aceptaci1n. Tras la aceptaci1n el ad)uiriente deber. asumir la responsabilidad sobre la gesti1n de la configuraci1n del producto software entregado. IEEE 1074

3.2

& #SPI9$S: S' : iclo De 2ida Software S' 9: 9odelo De iclo De 2ida Software S' P: Proceso De iclo De 2ida Software SP9PI: Plan De Informaci1n De Qesti1n De 'a onfiguraci1n Software ST&PD&#D "$# D%2%'$PIPQ S$"T(&#% 'I"% / '% P#$ %SS%S 7%STTPD&# P&#& %' D%S&##$''$ D% P#$ %S$S D% I '$ D% 2ID& S$"T(&#%8 3.2.1 GENERALIDADES %l est.ndar I%%% 5HCE especifica los procesos del ciclo de vida del software para el desarrollo * mantenimiento del mismo. Determina el con-unto de actividades esenciales, no ordenadas en el tiempo, )ue deben ser incorporadas dentro del desarrollo de un

;F

producto de software. %l ciclo de vida )ue seguir. el producto a desarrollar es seleccionado * establecido por el -efe del pro*ecto para cada pro*ecto. I%%% 5HCE no define ni prescribe un ciclo de vida en particular. ada organi3aci1n )ue usa el est.ndar debe instanciar las actividades especificadas en el mismo dentro de su propio proceso de desarrollo. D%"IP%: 'as actividades )ue constitu*en los procesos necesarios para el desarrollo * el mantenimiento de software, *a sea parte de un sistema ma*or o aut1nomo 7stand:alone8 'os procesos de gesti1n * soporte a lo largo de todo el ciclo de vida iclo de vida: <una apro+imaci1n l1gica a la ad)uisici1n, el suministro, el desarrollo, la e+plotaci1n * el mantenimiento del software> %l est.ndar re)uiere la definici1n de un ciclo de vida ada organi3aci1n debe asociar las actividades definidas en el est.ndar a su propio ciclo de vida del software. %l seguimiento del est.ndar no implica el uso de ning?n m0todo especfico, ni la creaci1n de determinados documentos.
Procesos !eleccin de un 'odelo de 8iclo de $ida Inicio del proyecto !upervisin y control del proyecto 4estin de la calidad del so&t+are -1ploracin de conceptos Asi"nacin del sistema Re(uerimientos Dise9o Aplicacin Instalacin .peracin y !oporte 'antenimiento Retiro $eri&icacin y validacin Administracin de la con&i"uracin del so&t+are Desarrollo de la documentacin -ntrenamiento

Proceso de 4rupo 'odelado del ciclo de vida 4estin del proyecto Pre desarrollo Desarrollo Post desarrollo

Procesos inte"rales

0a la 2: &roceso de 2rupo de I### 1-'4

%l proceso de selecci1n del ciclo de vida identifica * selecciona un ciclo de vida para el software )ue se va a construir. 'os procesos de gesti1n son el con-unto de procesos )ue establecen la estructura del pro*ecto, coordinan * gestionan sus recursos durante todo el ciclo de vida del software. 'os procesos orientados al desarrollo del software se inician con la identificaci1n de una necesidad de automati3aci1n. %sta necesidad, para ser satisfecha, puede re)uerir una nueva aplicaci1n, o un cambio de todo o parte de una aplicaci1n e+istente. & partir del informe de la necesidad, con el soporte de las actividades de los procesos integrales * ba-o el plan de gesti1n del pro*ecto, los

;G

procesos de desarrollo producen el software 7c1digo * documentaci1n8. Por ?ltimo, se deben reali3ar las actividades para instalar, operar, soportar, mantener * retirar el producto de software. 'os procesos integrales son necesarios para completar con 0+ito las actividades del pro*ecto de software. Son simult.neos a los procesos orientados al desarrollo del software e inclu*en actividades de )ue no tienen )ue ver con el desarrollo. Se utili3an para asegurar la completitud * calidad de las funciones del pro*ecto.

Ilustracin 1%: /ctividades del I### 1-'4

3.2.2 ACTIVIDADES %ste ane+o contiene las actividades obligatorias * <&plicables> )ue deben ser las tra3adas de acuerdo al S' 9 seleccionado. Q#UP$ D% P#$ %S$S D% Q%STISP D%' P#$/% T$

%stos Qrupos de &ctividad inician, monitorean, * controlan un pro*ecto del software a todo lo largo de su ciclo de vida. o & TI2ID&D%S D% IPI I$ D%' P#$/% T$ 'as actividades de Inicio del pro*ecto son esas &ctividades )ue crean * actuali3an la infraestructura de un pro*ecto del software de desarrollo o de mantenimiento. onstru*en la base para el S' P completo.

;C

'as actividades de Inicio del pro*ecto son reaci1n del Proceso de iclo de 2ida Software #eali3aci1n %stimaciones Ubicaci1n de #ecursos del Pro*ecto Definici1n de 90trica o & TI2ID&D%S D% Q%STISP D% '& &'ID&D D%' S$"T(&#% 'as actividades de gesti1n de la calidad del software se ocupan de la planificaci1n para toda la administraci1n del pro*ecto, inclu*endo contingencias. %stas &ctividades pueden estar hechas seg?n se necesite. 'as actividades de gesti1n de la calidad son: Planificaci1n de %valuaciones Planificaci1n de &dministraci1n de onfiguraciones Plan de Transici1n del Sistema 7Si &plicable8 Plan de Instalaci1n Plan de Documentaci1n Plan de %ntrenamiento Pla de &dministraci1n Del Pro*ecto Plan de Integraci1n o & TI2ID&D%S P#$/% T$ D% 9$PIT$#%$ / D% $PT#$' D%'

%stas &ctividades se usan para rastrear * mane-ar el pro*ecto. Durante las &ctividades de 9onitoreo * ontrol del Pro*ecto, la funci1n real del pro*ecto es rastreada, reportada, e ingeniada en contra de la funci1n planificada. 'a causa especial es dada a la gerencia de riesgo. 'as &ctividades de 9onitoreo * de ontrol del Pro*ecto son 9ane-o de #iesgos 9ane-o del Pro*ecto Identifi)ue * 9e-ora de las Pecesidades del S' P #etenci1n de #egistros olecci1n * &n.lisis de Datos 90tricos

Q#UP$S D% P#$ %S$S D% P#%D%S&##$''$

;B

Kstos son los Qrupos de &ctividad )ue e+ploran conceptos * ubican #e)uerimientos del sistema antes de )ue el desarrollo del software pueda comen3ar. o & TI2ID&D%S D% %UP'$#& ISP D% $P %PT$S %l Qrupo de &ctividad de %+ploraci1n de onceptos e+amina los #e)uerimientos en el nivel del sistema, produciendo una Declaraci1n de Pecesidad )ue inicia la &signaci1n del Sistema o Qrupo de &ctividad de #e)uerimientos. 'as actividades de %+ploraci1n de conceptos son Identificaci1n de Ideas o Pecesidades "ormulaci1n de &cercamientos Potenciales %studio de onducta de "actibilidad #efinamiento * "inali3aci1n de la Idea o Pecesidad o & TI2ID&D%S D% &SIQP& ISP D%' SIST%9& %l Qrupo de &ctividad de &signaci1n del Sistema es el puente entre la %+ploraci1n de onceptos * la definici1n de #e)uerimientos del software. %ste Qrupo de &ctividad tra3a un mapa de las funciones re)ueridas para software * hardware * las personas. 'as actividades de &signaci1n del Sistema son &n.lisis de "unciones Desarrollo de &r)uitectura del Sistema Descomposici1n de los #e)uerimientos del Sistema Q#UP$ D% P#$ %S$S D% D%S&##$''$

Kstos son los Qrupos de &ctividad )ue se reali3an durante el desarrollo de un producto de software. o & TI2ID&D%S D% #%LU%#I9I%PT$S %n el desarrollo de un sistema )ue contiene hardware, personas, * los componentes del software, el Qrupo de &ctividad de #e)uerimientos sigue el desarrollo de re)uerimientos totales del sistema, * la asignaci1n funcional de esos re)uerimientos del sistema para hardware, personas, * el software. 'as actividades de re)uerimientos son Definici1n * Desarrollo de los #e)uerimientos del Software Definici1n de #e)uerimientos de la Interfa3 Prioridad e Integraci1n de #e)uerimientos del Software D%"IPI ISP / D%S&##$''$ D% '$S #%LU%#I9I%PT$S D%' S$"T(&#%

;A

'a primera &ctividad en este Qrupo de &ctividad, definici1n de los re)uerimientos del software, es usualmente iterativa en naturale3a. Si el desarrollo del software constitu*e el pro*ecto entero o es de un sistema, los #e)uerimientos del software, incluidas las restricciones, ser.n generados de documentos de Informaci1n de &porte, resultados de modelado, prototipado, u otras t0cnicas. Usando la anteriormente citada Informaci1n de &porte, el desarrollador anali3ar. el software funcional * re)uerimientos funcionales para determinar posibilidad de rastreo, claridad, valide3, comprobabilidad, seguridad, * algunas otras caractersticas especificadas en el pro*ecto. %l uso de una metodologa global es recomendado para asegurar )ue los re)uerimientos son completos * coherentes. 'as t0cnicas como el an.lisis estructurado, el modelado, prototipado, o an.lisis de transacci1n son de a*uda en esta &ctividad. 'os #e)uerimientos Preliminares del Software * la determinaci1n de #e)uerimientos de Instalaci1n incluir.n la consideraci1n de #estricciones del Sistema como cronometrar * dimensionar el lengua-e * la tecnologa. D%"IPI ISP D% #%LU%#I9I%PT$S D% '& IPT%#"&R Todo usuario, software, e interfaces del hardware estar.n definidos usando la Informaci1n de &porte. %stas interfaces estar.n definidas *a sea como los #e)uerimientos o como las restricciones, * ser.n revisadas por todas las partes involucradas. 'a interfa3 de usuario es crtica en determinar la usabilidad del sistema. 'a definici1n de la interfa3 de usuario especificar. no s1lo el flu-o de informaci1n entre el usuario * el sistema, pero tambi0n la manera en la cual un usuario usa el sistema. 'os #e)uerimientos de la Interfa3 del Software especificar.n todas las interfaces del software )ue son re)ueridas para soportar el desarrollo * e-ecuci1n del soporte l1gico. 'as interfaces del software pueden verse afectadas por #estricciones del Sistema inclu*endo sistema operativo, administradores de base de datos, compiladores de lengua-e, herramientas, utilidades, controladores de protocolo de red, e interfaces de hardware. P#I$#ID&D % IPT%Q#& ISP D% '$S #%LU%#I9I%PT$S D%' S$"T(&#%. D%S #IP ISP 'os #e)uerimientos funcionales ser.n revisados, en el orden en )ue se dio prioridad a la lista de #e)uerimientos para producir cual)uier cambio )ue pueda necesitarse. 'os #e)uerimientos del Software describir.n las funciones, interfaces, * los #e)uerimientos funcionales, * tambi0n definir.n ambientes operacionales del soporte. o & TI2ID&D%S D% DIS%V$ %l ob-etivo del Qrupo de &ctividad del Dise6o es desarrollar una representaci1n coherente, bien organi3ada del soporte l1gico )ue se responsabili3a por los #e)uerimientos del Software. %n el nivel ar)uitect1nico del dise6o, el 0nfasis est. en los componentes del software )ue comprenden el soporte l1gico, * la estructura e

DH

interacci1n de esos componentes. %n el nivel detallado del dise6o, el 0nfasis est. sobre las estructuras de datos * los algoritmos para cada componente del software. 'as actividades de dise6o son #eali3aci1n del Dise6o &r)uitect1nico Dise6o de Jase De Datos 7Si &plicable8 Dise6o de Interfaces #eali3aci1n del Dise6o Detallado #%&'IR& ISP DIS%V$ &#LUIT% TSPI $. D%S #IP ISP 'a &ctividad del Dise6o &r)uitect1nico transforma los conceptos de #e)uerimientos del Software * la &r)uitectura de Sistema en dise6o de alto nivel. Durante esta &ctividad, los componentes del software )ue constitu*en el soporte l1gico * sus estructuras son identificados. %l software comprado * los contenidos de las bibliotecas de programas pueden influenciar el dise6o ar)uitect1nico. 'as t0cnicas como modelado * prototipado pueden servir para evaluar dise6os alternativos. DIS%V$ D% J&S% D% D&T$S 7SI &P'I &J'%8. D%S #IP ISP 'a actividad de Dise6o Jase de Datos tiene aplicaci1n cuando una base de datos debe ser creada o modificada como una parte del pro*ecto. %sta &ctividad especificar. la estructura de la informaci1n )ue se esbo31 en los #e)uerimientos del Software * sus caractersticas dentro del soporte l1gico. 'a actividad de Dise6o de Jase de Datos implica tres separados pero relacionados pasos: dise6o conceptual de la base de datos, dise6o l1gico de la base de datos, * dise6o fsico de la base de datos. DIS%V$ D% IPT%#"& %S. D%S #IP ISP 'a &ctividad de Dise6o de Interfaces estar. ligada con el usuario, software, * el hardware interactuante con el soporte l1gico )ue se obtuvo en los #e)uerimientos del Software. #%&'IR& ISP D%' DIS%V$ D%T&''&D$. D%S #IP ISP %n esta &ctividad, las alternativas del dise6o ser.n escogidas para implementar las funciones )ue son especificadas para cada componente del software. 'os detalles de las interfaces ser.n identificados dentro del Dise6o Detallado del Software. o & TI2ID&D%S D% I9P'%9%PT& ISP 'as &ctividades incluidas en el Qrupo de &ctividad de Implementaci1n dan como resultado la transformaci1n de la representaci1n Detallada del Dise6o de un producto del software en una reali3aci1n de lengua-e de programaci1n. %ste Qrupo de &ctividad produce el 1digo %-ecutable, la Jase de Datos, * la documentaci1n )ue constitu*e la manifestaci1n fsica del dise6o. &dem.s, el c1digo * la base de datos son integrados. 'as actividades de implementaci1n son

D5

reaci1n del 1digo %-ecutable reaci1n de la Documentaci1n $perativa #eali3aci1n de Integraci1n #%& ISP D%' SDIQ$ %N% UT&J'%. D%S #IP ISP %l 1digo "uente, incluidos los comentarios necesarios, ser.n generados utili3ando el S' P, el SP9PI * el Dise6o Detallado del Software. %l c1digo ser. agrupado en unidades procesables. Todas las unidades ser.n transformadas en 1digo %-ecutable * eliminados los defectos del programa. %l c1digo incorrecto sint.cticamente, es identificado, ser. revisado hasta )ue el 1digo "uente se encuentre libre de errores sint.cticos. #%& ISP D% '& D$ U9%PT& ISP $P%#&TI2&. D%S #IP ISP %sta &ctividad producir. la documentaci1n operativa del pro*ecto del software del Dise6o Detallado del Software * los #e)uerimientos de la Interfa3 del Software, de conformidad con la Informaci1n de la Plan de Documentaci1n. 'a Documentaci1n $perativa es re)uerida para instalar, funcionar, * mantener al sistema a todo lo largo del ciclo de vida. #%&'IR& ISP D% IPT%Q#& ISP. D%S #IP ISP %sta &ctividad integrar. la Jase de Datos, el 1digo "uente, el 1digo %-ecutable, concentradores * controladores, especificados en la Informaci1n del Plan de Integraci1n para la Integraci1n del Software. Si un sistema inclu*e varios componentes de hardware * software, la integraci1n del sistema podra ser incluida como parte de esta &ctividad. Q#UP$ D% P#$ %S$S D% P$STD%S&##$''$

Kstos son los Qrupos de &ctividad )ue son reali3ados para instalar, operar, soportar, mantener, * retirar un producto de software. o & TI2ID&D%S D% IPST&'& ISP 'a instalaci1n consiste en el transporte e instalaci1n de un soporte l1gico desde el ambiente de desarrollo para el ambiente del traba-o. Inclu*e las modificaciones necesarias del software, ca-a blanca, * la aceptaci1n del cliente. 'as actividades de instalaci1n son Distribuci1n de Software Instalaci1n de Software &ceptaci1n del Software en &mbiente $peracional o & TI2ID&D%S D% $P%#& ISP / S$P$#T% %l Qrupo de &ctividades de $peraci1n Soporte involucra la operaci1n del usuario del sistema * soporte en curso. %l soporte inclu*e asistencia t0cnica, consultas al usuario, *

D;

registro de peticiones del soporte del usuario manteniendo un #egistro de Petici1n de Soporte. 'as &ctividades de $peraci1n * Soporte son 9ane-o del Sistema Proporcionar &sistencia T0cnica * onsultora 9antenimiento del #egistro de Petici1n de Soporte o & TI2ID&D%S D% 9&PT%PI9I%PT$ %l Qrupo de &ctividad de 9antenimiento est. encargado de la identificaci1n de fortale3as * la resoluci1n de errores, fallas, * fracasos del software. 'os re)uerimientos para iniciar el mantenimiento del software cambia el S' P. %l S' P es replanteado * e-ecutado, tratando el Qrupo de &ctividad de 9antenimiento como iteraciones de desarrollo. 'as actividades de mantenimiento son Identificaci1n de Pecesidades de 9e-ora del Software Implementaci1n del 90todo de Informaci1n de Problemas #eaplicaci1n del S' o & TI2ID&D%S D% #%TI#$ %l Qrupo de &ctividad de #etiro implica la remoci1n de un sistema e+istente de su uso o soporte activo, *a sea suspendiendo su operaci1n o soporte, o reempla3.ndola con un sistema nuevo o una versi1n me-orada del sistema e+istente. 'as actividades de retiro son Potificaci1n &l Usuario Transmisi1n de $peraciones Paralelas 7Si &plicable8 #etiro del Sistema Q#UP$ D% P#$ %S$S IPT%Q#&'%S

Kstas son las &ctividades )ue se necesitan para completar e+itosamente &ctividades del pro*ecto. %stas &ctividades son utili3adas para asegurar la terminaci1n * la calidad funcional del pro*ecto. o & TI2ID&D%S D% 2%#I"I & ISP / 2&'ID& ISP 'as actividades de verificaci1n * validaci1n son esas &ctividades reali3adas durante el S' P )ue son dise6adas para revelar defectos en el producto o en los procesos )ue se usan para desarrollar el producto. %sto inclu*e actividades de revisi1n * de auditora, an.lisis de posibilidad de rastreo, e-ecuci1n * preparaci1n e+perimental, * la informaci1n de los resultados de todas las &ctividades de %valuaci1n.

DD

'as actividades de verificaci1n * validaci1n son #epaso de onducta reaci1n de 9atri3 de Posibilidad de #astreo &uditora de onducta Desarrollo de Pruebas Selectivas reaci1n de Datos de Prueba %-ecuci1n de Pruebas #eporte de #esultados de %valuaci1n o &D9IPIST#& ISP D% '& $P"IQU#& ISP D%' S$"T(&#% 'a administraci1n de configuraci1n del software identifica los artculos en un pro*ecto de desarrollo del software * provee ambos para el control de los artculos identificados para la generaci1n de Informaci1n de %status #eportada para la responsabilidad * visibilidad administrativa a todo lo largo del S' . 'as actividades de configuraci1n son Desarrollo e Identificaci1n de onfiguraci1n #eali3aci1n de ontrol de onfiguraci1n #eali3aci1n de uentas de %status o D%S&##$''$ D% '& D$ U9%PT& ISP %l Qrupo de &ctividades de Desarrollo de la Documentaci1n para el desarrollo * uso del software es el grupo de &ctividades )ue planifica, dise6a, implementa, edita, produce, distribu*e, * mantiene esos documentos )ue necesitan los desarrolladores * usuarios. %l prop1sito del Qrupo de &ctividad de Desarrollo de la Documentaci1n es proveerle la documentaci1n oportuna del software a esos )ue lo necesitan. 'as actividades de la documentaci1n son Implementaci1n de la Documentaci1n Producci1n * Distribuci1n de la Documentaci1n o & TI2ID&D%S D% %PT#%P&9I%PT$ %l desarrollo de productos del software de calidad es ma*ormente dependiente en personas informadas * e+pertas. %stos inclu*en al personal t0cnico del desarrollador * el gerente. %l personal del cliente tambi0n puede necesitar adiestrarse en instalar, funcionar, * mantener el software. 'as &ctividades de entrenamiento son Desarrollo de 9ateriales de %nse6an3a

DE

2alidaci1n del Programa de %ntrenamiento Implementaci1n del Programa de %ntrenamiento

4
4.1

MODELOS DE MEJORA
CMM

%l 99 es un modelo de calidad del software )ue clasifica las empresas en niveles de madure3. %stos niveles sirven para conocer la madure3 de los procesos )ue se reali3an para producir software. 'os niveles del 99 se dividen en inicial, repetible * definido. "ue dise6ado a finales de los ochenta por Software %ngineering Institute 7S%I8 a instancias del ongreso Porteamericano, como medio para evaluar a las empresas suministradoras de software para el Departamento de Defensa Porteamericano. 99 7como se le denomina abreviadamente8 define F niveles de madure3 para las organi3aciones, en funci1n de cu.les son los procesos )ue emplean en el desarrollo * mantenimiento de software * los grados de capacidad e institucionali3aci1n de cada unoO * puede emplearse con dos finalidades: riterio para la evaluaci1n de la madure3 de la organi3aci1n. Qua para la me-ora de sus procesos.

%s un modelo )ue describe como las pr.cticas de ingeniera de software de una organi3aci1n evolucionan ba-os ciertas condiciones el traba-o reali3ado es organi3ado * visto como un proceso 'a evoluci1n del proceso es gestionada sistem.ticamente

Tiene una estructura pensada para ser modificada %l 99 es un est.ndar progresivo con una dimensi1n din.mica )ue conduce a una organi3aci1n a me-orar continuamente sus pr.cticas actuales de software. 4.1.1 PRINCIPIOS Y CONCEPTOS 'a calidad de un producto o de un sistema es en su ma*or parte consecuencia de la calidad de los procesos empleados en su desarrollo * mantenimiento. 9&DU#%R

&tributo de las organi3aciones )ue desarrollan o mantienen los sistemas de software. %n la medida )ue 0stas llevan a cabo su traba-o siguiendo procesos, * en la )ue 0stos se encuentran homog0neamente implantados, definidos con ma*or o menor rigorO conocidos * e-ecutados por todos los e)uipos de la empresaO * medidos * me-orados de forma constante, las organi3aciones ser.n m.s o menos <maduras>. &P& ID&D

DF

&tributo de los procesos. %l nivel de capacidad de un proceso indica si s1lo se e-ecuta, o si tambi0n se planifica se encuentra organi3ativa * formalmente definido, se mide * se me-ora de forma sistem.tica.

Ilustracin 1': #structura del Modelo S34CMM

4.1.2 NIVELES DE MADUREZ: %l <escalonado> 99 define F niveles posibles de madure3 para las organi3aciones )ue desarrollan * mantienen software: PI2%' 5: IPI I&'

'os resultados de calidad obtenidos son consecuencia de las personas * de las herramientas )ue emplean. Po de los procesos, por)ue o no los ha* o no se emplean. PI2%' ;: #%P%TIJ'%

Se considera un nivel ; de madure3 cuando se llevan a cabo pr.cticas b.sicas de gesti1n de pro*ectos, de gesti1n de re)uisitos, control de versiones * de los traba-os reali3ados por subcontratistas. 'os e)uipos de los pro*ectos pueden aprovechar las pr.cticas reali3adas para aplicarlas en nuevos pro*ectos. T#%&S '&2% D% P#$ %S$ PI2%' ; o Qesti1n de #e)uisitos o Planificaci1n del pro*ecto de software o Seguimiento * Supervisi1n del pro*ecto o Qesti1n de subcontratos de software

DG

o Qaranta de calidad de software o Qesti1n de la configuraci1n del software PI2%' D: D%"IPID$

'os procesos comunes para desarrollo * mantenimiento del software est.n documentados de manera suficiente en una biblioteca accesible a los e)uipos de desarrollo. 'as personas han recibido la formaci1n necesaria para comprender los procesos. T#%&S '&2% D% P#$ %S$ PI2%' D o %nfo)ue en el proceso de la organi3aci1n o Definici1n del proceso de la organi3aci1n o Programa de formaci1n o Qesti1n integrada del software o Ingeniera de software del producto o oordinaci1n entre grupos

o #evisi1n de pares PI2%' E: Q%STI$P&D$

'a organi3aci1n mide la calidad del producto * del proceso de forma cuantitativa en base a m0tricas establecidas. 'a capacidad de los procesos empleados es previsible, * el sistema de medici1n permite detectar si las variaciones de capacidad e+ceden los rangos aceptables para adoptar medidas correctivas. T#%&S '&2% D% P#$ %S$ PI2%' E o Qesti1n cuantitativa de proceso o Qesti1n de la calidad del software PI2%' F: $PTI9IR&D$

'a me-ora continua de los procesos afecta a toda la organi3aci1n, )ue cuenta con medios para identificar las debilidades * refor3ar la prevenci1n de defectos. Se anali3an de forma sistem.tica datos relativos a la eficacia de los procesos de software para anali3ar el coste * el beneficio de las adaptaciones * las me-oras. Se anali3an los defectos de los pro*ectos para determinar las causas, * su mapeado sobre los procesos. T#%&S '&2% D% P#$ %S$ PI2%' F o Prevenci1n de defectos o Qesti1n del cambio de tecnologa

DC

o Qesti1n del cambio del proceso 4.1.3 ESTRUCTURA DEL MODELO SW-CMM %l S(: 99 est. estructurado de la siguiente manera Piveles de madures: indica la capacidad * madure3 del proceso * estos a su ve3 est.n compuestos por Trea clave de proceso: )ue alcan3an un ob-etivo 7)ue se consigue cuando se lleva acabo8 * est.n a su ve3 compuestas por pr.cticas claves. o practicas claves: las pr.cticas claves se agrupan en cinco categoras del 99 denomina <caractersticas comunes>, cada .rea clave de proceso tiene las cinco tipos de caractersticas comunes * al menos una pr.ctica ba-o cada caracterstica com?n, las caractersticas comunes 7colecci1n de pr.cticas claves8 permiten la implementaci1n de los ob-etivos de las .reas claves de proceso. o aractersticas comunes 7 colecci1n de pr.cticas claves8: son las siguientes

ompromiso para reali3ar 7 o8: las pr.cticas claves de tipo compromiso para reali3ar demuestran el prop1sito de la organi3aci1n para hacer )ue el .rea clave de proceso asociada sea un modo normal de negocio. Una pr.ctica de compromiso para reali3ar es generalmente una poltica de la organi3aci1n firmada por la alta direcci1n apacidad para reali3ar 7&b8: las pr.cticas de capacidad para reali3ar aseguran )ue los recursos 7generalmente dinero * tiempo8 est.n disponibles para llevar a otras pr.cticas claves. &ctividades reali3adas 7&c8: la caracterstica com?n de las actividades reali3adas sugiere las acciones )ue se pueden reali3ar el e)uipo t0cnico * los mandos intermedios para llevar a cabo la planificaci1n, o el seguimiento, o el entrenamiento 7capacitaci1n8 dentro de ese .rea de proceso. Sin las actividades reali3adas, no podra institucionali3arse ninguna de las otras caractersticas comunes. 9edici1n * an.lisis 79e8: la caracterstica com?n de medici1n * an.lisis asegura )ue el estado de las pr.cticas del .rea de proceso se conoce cuantitativamente. 2erificaci1n de la implementaci1n 72e8: la caracterstica com?n de verificaci1n demanda una revisi1n regular por la direcci1n * generalmente por el aseguramiento de la calidad del software, para asegurar )ue la implementaci1n del .rea de proceso tiene el efecto pretendido * para ver si se necesita la acci1n de la direcci1n para resolver los problemas de implementaci1n %n resumen cada p0rtica clave puede ser de tipo ompromiso para reali3ar, apacidad para reali3ar, 9edici1n * an.lisis, &ctividades reali3adas, 2erificaci1n de la implementaci1n * esto depende del tema en especfico )ue aborde cada pr.ctica clave 'as actividades reali3adas: implementan los ob-etivos * est.n compuesta por pr.cticas claves

DB

Ilustracin 1): Dia$ra*a de la #structura Detallada del CMM

& continuaci1n se muestra como est. estructurado del 99 de acuerdo al grafico anterior. %s solo una parte estructura b.sica *a )ue modelo es mucho m.s largo. 4.1.4 ESTRUCTURA DEL CMM PI2%' ;: #%P%TIJ'%

T#%&S '&2%S o Q%STISP D% #%LU%#I9I%PT$S

DA

$JN%TI2$ 5: re)uerimientos de software controlados para establecer una lnea base %stablecimiento de una lnea base para los re)uerimientos. 'nea base: )ue todas las versiones de un documento identificadas * la versi1n actual este controlada &ctividades &c5: #evisar re)uerimientos antes de incorporar al pro*ecto $JN%TI2$ ;: los planes, productos * actividades software se mantienen consistentes con los re)uerimientos del sistema asignados al software Prev0 cambio en los re)uerimientos * e+ige )ue otras partes de pro*ecto se a-usten a ellos &ctividades &c;: Usar re)uerimientos para planes, productos * actividades &c;: #evisar cambios e incorporarlos apropiadamente 7tener un proceso para gestionar * controlar los cambios8 &#& T%#!STI &S $9UP%S #esponsabilidad de anali3ar * asignar re)uerimientos Documentaci1n de los re)uerimientos Proporcionar recurso * financiaci1n adecuados para gestionar re)uerimientos 7personas, herramientas8 Personal de software centrando en gesti1n de re)uerimientos o T#%& '&2% D%' P#$ %S$: P'&PI"I & ISP D% P#$/% T$S D% S$"T(&#% $JN%TI2$ 5: las estimaciones est.n documentadas para usar la planificaci1n * seguimiento del pro*ecto &ctividades &cA: estimaci1n de tama6o %stimaci1n de tama6o de los productos 7intermedios * finales8, as como las estimaciones en los cambio de sus tama6os se obtendr. conforme a un procedimiento documentado Tama6o: lneas de c1digo fuente, n?mero de p.ginas &c5H: estimaci1n del esfuer3o * el costo &c55: seguir un procedimiento documentado para reali3ar estimaciones de recursos crticos de computador 7memoria, procesador %/S8

EH

&5;: establecer la estimaci1n del calendario mediante un procedimiento documentado $JN%TI2$ ;: se planifican * documentan las actividades * compromisos de pro*ecto de software &ctividades &c;: planificaci1n temprana en paralelo con el pro*ecto &cF: Utili3aci1n del ciclo de vida de software apropiado 7modelo en cascada, prototipado, etc.8 &c5E: planes para recursos * herramientas &cB: productos de software necesitados para establecer * mantener un control, identificados Identificar con-unto de producto intermedios * finales sobre los )ue el pro*ecto necesita mantener control &cA: riesgos identificados * evaluados T0cnicos 7factibilidad de la ingeniera8, program.ticos 7costes, calendario8 &cG: SDP 7plan de desarrollo de software8 se desarrolla de acuerdo aun procedimiento documentado &cC: SDP documentado $JN%TI2$D: las personas * grupos afectados aceptan sus compromisos relacionados con el pro*ecto de software &ctividades &c5: el grupo de ingeniera del software forma parte de la propuesta del pro*ecto 7IS( no hace parte de la planificaci1n del pro*ecto, el IS( no revisa re)uerimientos, ni negocia calendario8 &cE: ompromisos del pro*ecto de software revisados con el director o T#%& D% P#$ %S$: S%QUI9I%PT$ P#$/% T$ D% S$"T(&#% 7PT$8 / $PT#$' D%'

%s el con-unto de pr.cticas agrupadas ba-o esta .rea de proceso proporciona visibilidad sobre las actividades * estado del pro*ecto $JN%TI2$ 5: se efect?a el seguimiento de los resultados * de las e-ecuciones reales compar.ndolas con los planes del software &ctividades &c5: plan de desarrollo de software documentado para reali3ar el seguimiento de las actividades * comunicar el estado &cF: seguimiento del tama6o

E5

&cG: seguimiento de esfuer3o, coste &cC: seguimiento de recursos crticos de computador &cB: seguimiento de calendario de le pro*ecto &cA: seguimiento de actividades t0cnicas de ingeniera de software &c5H: seguimiento de riesgo de software, tanto t0cnico como program.tico &ct55: e+ige )ue se registren los datos reales del pro*ecto, es decir, medidas * datos de rendimientos utili3ados para la re planificaci1n &c5;: revisiones internas de grupo de ingeniera de software, para seguir progreso t0cnico, la reali3aci1n * las cuestiones )ue surgen el plan de desarrollo de software &c5D: #evisiones formales de hitos $JN%TI2$ ;: se adoptan medidas correctivas * se controlan hasta su terminaci1n cuando los resultados * la e-ecuci1n reales se desven notablemente de los planes de software &ctividades &c;: #evisi1n del plan de desarrollo de software mediante un procedimiento documentado Se toman acciones correctivas para las siguientes actividades. cuando suceden desviaciones &cF: Tama6o: &cG: %sfuer3o * coste &cC: #ecursos crticos de computador &cB: alendario de actividades software &cA: &ctividades de ingeniera del software &c5H: %+pectativas de riesgo $JN%TI2$ D: 'as personas * grupos afectados acuerdan los cambios a introducir en las compromisos de software &ctividades &cD: los compromisos del pro*ecto de software )ue afectan a individuos e+ternos a la organi3aci1n se revisan con la alta direcci1n conforme a un procedimiento documentado &cE: los cambios aprobados en los compromisos7hechos por el director8 )ue afectan al pro*ecto se comunican a los grupos de software &#& T%#!STI &S $9UP%S &b5: el plan de desarrollo de software est. documentado * aprobado

E;

&b;: #esponsabilidad de actividades * productos 7asignadas al -efe del pro*ecto8 &bD: "inanciaci1n de recursos para el seguimiento &bE: 'os mandos intermedios de software entrenados en gesti1n de aspectos t0cnicos * de personal del pro*ecto &bE: $rientaci1n a mandos intermedios de primer nivel en aspectos t0cnicos pro*ecto de software PI2%' D: %' P#$ %S$ D%"IPID$ o T#%& '&2% D%' P#$ %S$: %P"$LU% %P %' P#$ %S$ D% '& $#Q&PIR& ISP Se encarga de la recopilaci1n * la transferencia de las me-oras pr.cticas en los pro*ectos * en toda la organi3aci1n $JN%TI2$ 5: las actividades de desarrollo * me-ora de proceso de software se coordinan en la organi3aci1n $JN%TI2$ ;: los puntos fuertes * d0biles del proceso de software utili3ado se identifican &ctividades &c5: proceso de software evaluado peri1dicamente. Se desarrollan planes de acci1n para abordar los halla3gos de la evaluaci1n $JN%TI2$ D: se planifican las actividades de desarrollo * de me-ora del proceso a nivel de organi3aci1n PI2%' E: %' P#$ %S$ Q%STI$P&D$ o T#%& D% P#$ %S$: Q%STISP D% &'ID&D D% S$"T(&#% $JN%TI2$ 5: se planifican las actividades de gesti1n de calidad de software de pro*ecto $JN%TI2$ ;: se definen los ob-etivos medibles * sus prioridades para la calidad del producto software $JN%TI2$ D: se cuantifica * gestiona el progreso real para alcan3ar los ob-etivos de la calidad de los productos software &ctividades )ue lo implementan &c5: el plan de calidad del software se desarrolla * se mantiene mediante un procedimiento. Se escribir. un plan de calidad de software * se revisara &c;: se supervisa el plan de calidad del software procedente de la actividad 5. %specificaci1n de puntos del proceso donde se reali3an mediciones PI2%' F: $PTIPU& $PTI9IR& ISP D%' P#$ %S$ del

ED

o &#%& '&2% D% P#$ %S$: P#%2%P ISP D% D%"% T$S $JN%TI2$ 5: se planifican las actividades de planificaci1n de defectos &ctividades )ue lo implementan &c5 se desarrolla un plan para actividades de prevenci1n de defectos &c;: al comien3o de una tarea de desarrollo de software los miembros del e)uipo de la tarea se re?nen para preparar las actividades de la tarea * las actividades de prevenci1n de defectos $JN%TI2$ ;: se buscan e identifican las causas comunes de defectos $JN%TI2$ D: se priori3an * eliminan sistem.ticamente las causas de defectos comunes 4.2 CMMI

Integraci1n de 9odelos de 9adure3 de apacidades o apabilit* 9aturit* 9odel Integration 7 99I8 es un modelo para la me-ora * evaluaci1n de procesos para el desarrollo, mantenimiento * operaci1n de sistemas de software. & finales de los AH algunas organi3aciones llevaban a cabo planes de calidad )ue integraban de forma simult.nea varios modelos 99. Para facilitar la incorporaci1n de varios modelo 99I )ue integra: 99:S( S%: 99 IPD: 99 99Ws, S%I desarrolla * publica en ;HH5 el

Desde entonces estos tres modelos *a no evolucionan de forma separada. 4.2.1 PRINCIPIOS Y CONCEPTOS 99I se asienta en el mismo principio e+puesto para 99: 'a calidad de un producto o de un sistema es en su ma*or parte consecuencia de la calidad de los procesos empleados en su desarrollo * mantenimiento. 4.2.2 MADUREZ &tributo de las organi3aciones )ue desarrollan o mantienen los sistemas de software. %n la medida )ue 0stas llevan a cabo su traba-o siguiendo procesos, * en la )ue 0stos se encuentran homog0neamente implantados, definidos con ma*or o menor rigorO conocidos * e-ecutados por todos los e)uipos de la empresaO * medidos * me-orados de forma constante, las organi3aciones ser.n m.s o menos <maduras>.

EE

4.2.3 CAPACIDAD &tributo de los procesos. %l nivel de capacidad de un proceso indica si s1lo se e-ecuta, o si tambi0n se planifica se encuentra organi3ativa * formalmente definido, se mide * se me-ora de forma sistem.tica. 4.2.4 ESTRUCTURA DEL MODELO CMMI & diferencia de 99, )ue s1lo tiene representaci1n por niveles, 99I tiene dos representaciones: 58 Por niveles, ;8 ontinua. 'a representaci1n por niveles es similar a la de 99. Son cinco niveles, cada uno de los cuales contiene P&Ws 7Process &reas. %n 99 se denominan Xe* Process &reas8. 'as organi3aciones pueden optar por una u otra representaci1n. 'a compa6a )ue eli-a la representaci1n por niveles, va logrando la madure3 como en 99. &lcan3a el nivel de madure3 ; cuando cumple con todas las P& de nivel ;, * as sucesivamente. Luienes eli-an el modelo continuo, alcan3an la madure3 por Process &reas. %n este caso, por e-emplo, se puede ser nivel F en una Process &rea * nivel 5, ;, o cual)uier otro, en las dem.s. 'a representaci1n continua le permite a las organi3aciones madurar completamente en las Treas de Proceso )ue mas les interesen. 'a idea surgi1 por)ue 99 es un modelo )ue toma a6os * muchsimo dinero para implementarlo hasta el nivel F, ra31n )ue desanimaba a muchas compa6as a adoptarlo. Para ser nivel F en 99I se re)uiere )ue todas las P&Ws est0n en nivel F. 4.2. REPRESENTACIN POR NIVELES

omparaci1n entre el modelo 99 * la representaci1n por niveles del 99I

Ilustracin 1+: 5os Cinco 6iveles de Madure, de Capacidad del Modelo CMMI

4.2.! NIVEL DE MADUREZ 1 INICIAL %n el nivel de madure3 5, los procesos son generalmente ad:hoc * ca1ticos. 'a organi3aci1n generalmente no proporciona un entorno estable para dar soporte a los procesos. %l 0+ito en estas organi3aciones depende de la competencia * heroicidad del personal de la organi3aci1n * no del uso de procesos probados. & pesar de este caos, las

EF

organi3aciones de nivel de madure3 5 a menudo producen productos * servicios )ue funcionanO sin embargo, frecuentemente e+ceden sus presupuestos * no cumplen sus calendarios. 'as organi3aciones de nivel de madure3 5 se caracteri3an por una tendencia a comprometerse en e+ceso, a abandonar los procesos en tiempos de crisis * a una incapacidad para repetir sus 0+itos. 4.2.7 NIVEL DE MADUREZ 2 ADMINISTRADO

8'' :PA;s de nivel 2 (1) 4estin de Re(uerimientos (2) Plani&icacin del proyecto so&t+are (<) !e"uimiento y supervisin del proyecto !o&t+are (=) !o&t+are de 4estin de subcontratos

8''I PA;s de nivel 2 (1) 4estin de Re(uerimientos (2) Plani&icacin del Proyecto (<) 'onitori/acin y control de proyecto (=) 4estin de acuerdos con proveedores (>)'edicin y an%lisis

(>) !o&t+are de 8ontrol de 8alidad (?) !o&t+are 4estin de con&i"uracin 0a la 3: CMM vs CMMI 6ivel 2 de Madure,

(?) Ase"uramiento de la calidad de proceso y de producto (@) 4estin de con&i"uracin

9edici1n * an.lisis. %staba d0bilmente implcita en Seguimiento * supervisi1n del pro*ecto Software, pero se mencionaba en cada XP&. 99I la desarrolla en detalle en el nivel ; * omite su menci1n en cada XP&. Divide Seguimiento * supervisi1n del pro*ecto Software en dos P&Ws: 9onitori3aci1n * control de pro*ecto * 9edici1n * an.lisis. 9edici1n * an.lisis en el nivel ; no tiene e+igencias de ontrol %stadstico de Procesos. %n el nivel de madure3 ;, los pro*ectos de la organi3aci1n han asegurado )ue los procesos se planifican * reali3an de acuerdo a polticasO los pro*ectos emplean personal con habilidad )ue dispone de recursos adecuados para producir resultados controladosO involucran a las partes interesadas relevantesO se monitori3an, controlan * revisanO * se eval?an en cuanto a su adherencia a sus descripciones de proceso. 'a disciplina de proceso refle-ada por el nivel de madure3 ; a*uda a asegurar )ue las pr.cticas e+istentes se mantienen durante tiempos de estr0s. uando estas pr.cticas est.n en su lugar, los pro*ectos se reali3an * gestionan de acuerdo a sus planes documentados. 4.2." NIVEL DE MADUREZ 3 DE#INIDO

8'' :PA;s de nivel <

8''I PA;s de nivel <

EG

(1) Desarrollo de re(uerimientos (2) !olucin t,cnica (<) Inte"racin de producto (=) $eri&icacin (>) $alidacin (1) -n&o(ue en procesos de la or"ani/acin (2) De&inicin de procesos de la or"ani/acin (<) Pro"rama de 8apacitacin (=) 4estin inte"rada de so&t+are (>) Producto !o&t+are de In"enier*a (?)8oordinacin de Inter"rupo (@) Peer Revie+s (10) 4estin de ries"os (11) An%lisis de decisiones y resolucin 0a la 4: CMM vs CMMI 6ivel 3 de Madure, (?) -n&o(ue en procesos de la or"ani/acin (@) De&inicin de procesos de la or"ani/acin (A) Bormacin or"ani/ativa (C) 4estin inte"rada de proyecto

Desarrollo de re)uerimientos Desarrollada en m.s detalle. %staba d0bilmente implcita en P% de 99. Soluci1n t0cnica, Integraci1n de producto, 2erificaci1n * 2alidaci1n estaban incluidas en P%. 2erificaci1n inclu*e el antiguo Peer #eview. Qesti1n de riesgos. Incluida en Planificaci1n de Pro*ectos * Qesti1n integrada de software de 99 7nivel ;8. 9ucho m.s desarrollada en 99I. &n.lisis de decisiones * resoluci1n. ompletamente nueva. &n.lisis de decisiones * resoluci1n. P& ompletamente nueva. Se desarroll1 para obligar a las organi3aciones a tomar las decisiones importantes mediante la utili3aci1n de un proceso formal de &n.lisis de Decisiones. De esta forma se pretende evitar )ue las decisiones importantes se tomen con base en la intuici1n solamente. 'a P& impone condiciones de documentaci1n de decisiones importantes. %n el nivel de madure3 D, los procesos son bien caracteri3ados * comprendidos, * se describen en est.ndares, procedimientos, herramientas * m0todos. %l con-unto de procesos est.ndar de la organi3aci1n, )ue es la base del nivel de madure3 D, se establece * me-ora a lo largo del tiempo. %stos procesos est.ndar se usan para establecer la consistencia en toda la organi3aci1n. 'os pro*ectos establecen sus procesos definidos adaptando el con-unto de procesos est.ndar de la organi3aci1n de acuerdo a las guas de adaptaci1n. 4.2.$ NIVEL DE MADUREZ 4 GESTIONADO CUANTITATIVAMENTE

8'' :PA;s de nivel =

8''I PA;s de nivel =

EC

(1) 4estin cuantitativa de proceso (2) 4estin cuantitativa de so&t+are 0a la ": CMM vs CMMI 6ivel 4 de Madure,

(1) Rendimiento de procesos de la or"ani/acin (2) 4estin cuantitativa de proyecto

#endimiento de procesos de la organi3aci1n. %staba implcito en las dos XP&Ws del nivel E de 99. 99I detalla en #endimiento de procesos de la organi3aci1n las e+igencias en cuanto a ob-etivos, baselines, etc. Qesti1n cuantitativa de pro*ecto. Inclu*e las e+igencias de 99 para administrar cuantitativamente el desempe6o de los procesos * la calidad, e+igencias )ue estaban incluidas en dos XP&Ws de 99. 99I es e+plcito en la e+igencia del ontrol %stadstico de Procesos. %n el nivel de madure3 E, la organi3aci1n * los pro*ectos establecen ob-etivos cuantitativos en cuanto al rendimiento de calidad * del proceso, * los utili3an como criterios en la gesti1n de los procesos. 'os ob-etivos cuantitativos se basan en las necesidades del cliente, usuarios finales, organi3aci1n e implementadores del proceso. %l rendimiento de calidad * del proceso se comprende en t0rminos estadsticos * se gestiona durante la vida de los procesos YS%I ;HH5Z. 4.2.10 NIVEL DE MADUREZ OPTIMIZADO

8'' :PA;s de nivel >

8''I PA;s de nivel > (1) Innovacin y desplie"ue en la or"ani/acin

(1) Prevencin de de&ectos (2) 4estin del 8ambio de Tecnolo"*a (<) 4estin del 8ambio de Proceso 0a la %: CMM vs CMMI 6ivel de Madures "

(2) An%lisis causal y resolucin

Innovaci1n * despliegue en la organi3aci1n. #e?ne Qesti1n del ambio de Tecnologa and Qesti1n del ambio de Proceso del modelo 99. &n.lisis causal * resoluci1n. Pr.cticamente la misma )ue Prevenci1n de defectos. %n la redacci1n, e+tiende el an.lisis causal a cual)uier tipo de problemas, no solo a defectos, cosa )ue resultaba evidente en 99. %n el nivel de madure3 F, una organi3aci1n me-ora continuamente sus procesos bas.ndose en una comprensi1n cuantitativa de las causas comunes de variaci1n inherentes a los procesos. %l nivel de madure3 F se centra en me-orar continuamente el rendimiento de procesos mediante me-oras incrementales e innovadoras de proceso * tecnol1gicas. 'os ob-etivos cuantitativos de me-ora de procesos para una organi3aci1n se establecen, se revisan continuamente para refle-ar el cambio a los ob-etivos del negocio, * se utili3an como criterios para gestionar la me-ora de procesos. 'os efectos de las me-oras de procesos desplegadas se miden * eval?an frente a los ob-etivos

EB

cuantitativos de me-ora de procesos. Tanto los procesos definidos como el con-unto de procesos est.ndar de la organi3aci1n son ob-eto de las actividades de me-ora cuantitativa. 4.2.11 REPRESENTACIN CONTINUA 99 no tiene representaci1n continua. %sta es e+clusiva de 99I. 'a organi3aci1n selecciona las .reas de proceso * los niveles de capacidad seg?n sus ob-etivos de me-ora de procesos. 'a me-ora se mide utili3ando niveles de capacidad. 'os niveles de capacidad: 9iden la madure3 de un proceso particular en toda la organi3aci1n. Se califican desde H a F.

'os perfiles de nivel de capacidad se usan para establecer un ob-etivo * reali3ar el seguimiento del rendimiento de la me-ora de procesos. omo parte de una evaluaci1n, la e)uivalencia por etapas permite derivar un nivel de madure3 a una organi3aci1n )ue use la apro+imaci1n continua para la me-ora de procesos.

Ilustracin 2-: 7epresentacin Continua

Debido a la representaci1n continua, el detalle del modelo tiene diferencias con relaci1n a 99.
8'' Detalle del modelo 'etas 8''I Detalle del modelo metas espec*&icas

EA

8ompromiso a llevar a cabo (Pol*ticas) 8apacidad para reali/ar (Precondiciones) Actividades reali/adas (Actividades) 'edicin y An%lisis $eri&icacin de la Implementacin

Practicas especi&icas Practicas "en,ricas 8ompromiso a llevar a cabo 8apacidad para reali/ar $eri&icacin de la Implementacin Directivo de la aplicacin

0a la ': CMM vs CMMI

Debido a las e+igencias de la representaci1n continua, cuando se recorre el modelo dentro de cada P&, lo primero )ue se lee son las metas * pr.cticas especficas 7actividades en 998. 'uego de las pr.cticas especficas, el modelo presenta las pr.cticas gen0ricas, pr.cticas )ue cubren ompromiso a llevar a cabo 7polticas8, apacidad 7 pre condiciones8, Directivo de la aplicaci1n 7dirigiendo la implementaci1n, )ue contiene algunos direccionamientos para implementar la P&8 * 2erificaci1n de la Implementaci1n. 9edici1n * &n.lisis es una nueva .rea de proceso. 4.2.12 CATEGORIZACIN DE LAS %REA DE PROCESO Por efectos de clasificaci1n, las P& se agrupan en cuatro diferentes tipos: 58 &dministraci1n de procesosO ;8 &dministraci1n de pro*ectosO D8 Ingeniera * E8 Soporte
8ate"or*a Administracin de procesos Drea de proceso De&inicin de procesos de la or"ani/acin -n&o(ue en procesos de la or"ani/acin Bormacin or"ani/ativa Rendimiento de procesos de la or"ani/acin Innovacin y desplie"ue en la or"ani/acin Administracin de proyectos Planeacin de proyecto 'onitori/acin y control de proyecto 4estin de Acuerdo de Proveedores 4estin inte"rada de proyecto 4estin de ries"os 4estin cuantitativa de proyecto In"enier*a 4estin de re(uerimientos Desarrollo de re(uerimientos !olucin t,cnica Inte"racin de producto $eri&icacin Nivel < < < = > 2 2 2 < < = 2 < < < <

FH

$alidacin !oporte 4estin de con&i"uracin Ase"uramiento de la calidad de proceso y de producto 'edicin y An%lisis An%lisis de decisiones y resolucin An%lisis causal y resolucin 0a la ): CMMI

< 2 2 2 < >

4.3

ISO

'a IS$ / I% 5FEHE:F modelo de evaluaci1n de procesos de ciclo de vida de software %sta serie de normas han sido adoptadas por la U.%. como normas nacionales UP% * editadas en distintas denominaciones con las siglas UP%/%P/IS$ AHHH )ue acredita la identidad entre las normas internacionales, europeas o nacionales. %stas normas recogen los criterios * re)uisitos )ue deben aplicarse a la implantaci1n de sistemas de gesti1n de la alidad * de los tres diferentes modelos de sistemas de aseguramiento e+terno cuando se aplican contractualmente. %stas normas no contemplan ning?n aspecto sobre las caractersticas fsicas de alidad relacionadas con los productos o servicios. %stas caractersticas son establecidas separadamente * definidas como especificaciones. %sta serie de normas han ido evolucionando a trav0s de las tres ?nicas normas contractuales IS$ AHH5, IS$ AHH; e IS$ AHHD hasta formar un cuerpo de normas )ue recogen las guas para facilitar la implantaci1n de las tres normas citadas referidas a la implantaci1n de Sistemas de Qesti1n de la alidad, en organi3aciones )ue produ3can cual)uier tipo de producto o servicio. 4.3.1 NORMAS ISO $000-3 PARA SO#TWARE #ese6a hist1rica: [Lu0 se entiende por calidad\

Seg?n IS$ BEH;, < alidad son todas las caractersticas )ue permiten )ue un producto satisfaga necesidades e+plicitas o implcitas a un costo aceptable> de esta manera la calidad de los productos puede ser medida comparando en las caractersticas o atributos. [Lu0 es IS$\

'a $rgani3aci1n Internacional para la %standari3aci1n es la agencia especiali3ada en estandari3aci1n m.s grande a nivel mundial, establecida en 5AEC con la finalidad de promover la estandari3aci1n internacional para facilitar el intercambio de bienes * servicios as como de desarrollo cientfico * tecnol1gico. &ctualmente IS$ abarca los est.ndares nacionales en 5FA pases. IS$ comprende alrededor de 5BH comit0s t0cnicos encargados de desarrollar desde las abreviaturas de los sistemas de medici1n hasta la especificaci1n detallada de los productos a evaluar.

F5

IS$ establece los est.ndares de calidad en respuesta las necesidades claramente e+presadas por los sectores * staMeholders sobre determinado producto. Serie de est.ndares IS$ AHHH:

Son un grupo de F est.ndares internacionales de administraci1n * aseguramiento de calidad gen0ricos, es decir, aplicables a cual)uier producto en este documento solo trataremos la IS$ AHHH:D *a )ue son los est.ndares utili3ados para el desarrollo, suministros * mantenimiento del software. 'a certificaci1n IS$ AHHH no es un re)uerimiento legal para acceder a mercados internacionales sin embargo es un gran beneficio como una herramienta de competencia de mercado 7mercadeo8. Porma IS$ AHHH:D

Tmbito de aplicaci1n: o Desarrollo de sistemas de informaci1n. o Procesos del ciclo de vida. o alidad del software

on la IS$ AHHH:D se busca dar orientaciones en las )ue se e+i-a la descomposici1n de la capacidad de un proveedor para desarrollar, suministrar * mantener productos de software. 'a norma sugiere clases de control * m0todos para la producci1n de software )ue satisfaga los re)uisitos establecidos. 'a norma IS$ AHHH:D sirve para interpretar la norma IS$ AHH5 en el .mbito de la ingeniera del software de hecho su nombre es <QUI& P&#& '& &P'I & ISP D%' IS$ AHH5 P&#& %' D%S&##$''$, '& &P'I & ISP / 9&PT%PI9I%PT$ D% S$"T(&#%>. 'a norma IS$ AHHH:D es re)uerida por todas las compa6as desarrolladoras de software para o Incursionar en el mercado europeo. o ubrir las e+pectativas de los clientes.

o $btener beneficios de calidad. o omo estrategia de mercadeo.

o Para reducir costos de producci1n. '& IS$ AHHH:D S% DI2ID% %P: o &dministraci1n de la responsabilidad. o Sistemas de calidad. o &uditoras internas de calidad.

F;

o #evisi1n de contratos o ontrol de documentos * datos.

o Planificaci1n del dise6o * el desarrollo. o Inspecci1n * pruebas. o o ontrol, calibraci1n * mantenimiento de los e)uipos de inspecci1n, medici1n * pruebas utili3ados por la empresa. ontrol del producto no conforme.

o &cciones correctivas * preventivas. o o ontrol de los registros de calidad. apacitaci1n.

o %stadsticas.

Ilustracin 21: #s1ue*a del IS8 +--1

METODOLOGIAS
Un m0todo es camino o a la va para llegar donde )ueremos. 9etodologa hace referencia al con-unto de procedimientos basados en principios l1gicos, utili3ados para alcan3ar una gama de ob-etivos. %n el caso de ingeniera del software estaramos hablando de los pasos o procedimientos *a establecidos para tener un orden al momento de reali3ar nuestro desarrollo. %n un pro*ecto de desarrollo de software la metodologa define Lui0n debe hacer Lu0, u.ndo * 1mo debe hacerlo.

FD

Ilustracin 22: Metodolo$ias

Po e+iste una metodologa de software universal. 'as caractersticas de cada pro*ecto 7e)uipo de desarrollo, recursos, etc.8 e+igen )ue el proceso sea configurable. 9%T$D$'$QI&S %ST#U TU#&D&S

'os m0todos estructurados comen3aron a desarrollar:se a fines de los CHWs con la Programaci1n %structurada, luego a mediados de los CHWs aparecieron t0cnicas para el Dise6o primero * luego para el &n.lisis. %nfocados a implementaciones usando lengua-es de Dra generaci1n. %-emplos de metodologas estructuradas gubernamentales: 9%#IS% 7"rancia8, 9KT#I & D 7%spa6a8, SS&D9 7#eino Unido8. %-emplos de m0todos estructurados en el .mbito acad0mico: Qane ] Sarson, (ard ] 9ellor, /ourdon ] De9arco e Information %ngineering. o $rientadas a procesos o $rientadas a datos. o @brida

FE

Ilustracin 23: Metodolo$9as 8rientadas a &rocesos

Ilustracin 24: Metodolo$9as 8rientadas a Datos

FF

Ilustracin 2": Metodolo$9as :i ridas

%'%9%PT$S D% UP& 9%T$D$'$QI&

Ilustracin 2%: #le*entos de ;na Metodolo$9a

9%T$D$'$QI&S T#&DI I$P&'%S / 9%T$D$'$QI&S &QI'%S

'as metodologas tradicionales imponen una disciplina de traba-o sobre el proceso de desarrollo del software, con el fin de conseguir un software m.s eficiente. Para ello, se hace 0ntasis en la planificaci1n total de todo el traba-o a reali3ar * una ve3 )ue est. todo

FG

detallado, comien3a el ciclo de desarrollo del producto software. Se centra especialmente en el control del proceso, mediante una rigurosa definici1n de roles, actividades, artefactos, herramientas * notaciones para el modelado * documentaci1n detallada. &dem.s, las metodologas tradicionales no se adaptan adecuadamente a los cambios, por lo )ue no son m0todos adecuados cuando se traba-a en un entorno, donde los re)uisitos no pueden predecirse o bien pueden variar. %ntre las metodologas tradicionales o pesadas podemos citar: o #UP 7#ational Unified Procces8 o 9S" 79icrosoft Solution "rameworM8 o (in:(in Spiral 9odel o Iconi+ Pero sin dudas adaptarse a la agitada sociedad actual implica ser <.gil>, es decir, tener la capacidad de proveer respuestas r.pidas * ser adaptables al cambio. &mbas cualidades siempre han sido deseables, pero en el entorno de negocio actual resultan indispensables. %ste re)uerimiento de agilidad en las empresas, gobiernos * cual)uier otra organi3aci1n provoca )ue el software tambi0n deba ser desarrollado de manera .gil. 'as necesidades de un cliente pueden sufrir cambios importantes del momento de contrataci1n de un software al momento de su entregaO * es mucho m.s importante satisfacer estas ?ltimas )ue las primeras. %sto re)uiere procesos de software diferentes )ue en lugar de recha3ar los cambios sean capaces de incorporarlos. 'os procesos .giles son una buena elecci1n cuando se traba-a con re)uisitos desconocidos o variables. Si no e+isten re)uisitos estables, no e+iste una gran posibilidad de tener un dise6o estable * de seguir un proceso totalmente planificado, )ue no va*a a variar ni en tiempo ni en dinero. %n estas situaciones, un proceso adaptativo ser. mucho m.s efectivo )ue un proceso predictivo. Por otra parte, los procesos de desarrollo adaptativos tambi0n facilitan la generaci1n r.pida de prototipos * de versiones previos a la entrega final, lo cual agradar. al cliente. 'as metodologas .giles proporcionan una serie de pautas * principios -unto a t0cnicas pragm.ticas )ue puede )ue no curen todos los males pero har.n la entrega del pro*ecto menos complicada * m.s satisfactoria tanto para los clientes como para los e)uipos de entrega. %ntre las metodologas .giles m.s destacadas hasta el momento se pueden nombrar: o UP 7%+treme Programming8 o Scrum o r*stal lear

o DSD9 7D*namic S*stem Development 9ethod8 o "DD 7"eature Driven Development8

FC

o &SD 7&daptive Software Development8 o UJreed o %+treme 9odeling 9&PI"I%ST$ P$# %' D%S&##$''$ TQI' D% S$"T(&#%

%stamos descubriendo formas me-ores de desarrollar software tanto por nuestra propia e+periencia como a*udando a terceros. & trav0s de este traba-o hemos aprendido a valorar: o IPDI2IDU$S % IPT%#& I$P%S sobre procesos * herramientas.

o S$"T(&#% "UP I$P&PD$ sobre documentaci1n e+tensiva. o $'&J$#& I$P $P %' 'I%PT% sobre negociaci1n contractual.

o #%SPU%ST& &PT% %' &9JI$ sobre seguir un plan %sto es, aun)ue valoramos los elementos de la derecha, valoramos m.s los de la i3)uierda. .1 RUP

'a siguiente figura ilustra la historia de #UP. %l antecedente m.s importante se ubica en 5AGC con la 9etodologa %ricsson 7%ricsson %nfo)ue8 elaborada por Ivar Nacobson, una apro+imaci1n de desarrollo basada en componentes, )ue introdu-o el concepto de aso de Uso. %ntre los a6os de 5ABC a 5AAF Nacobson fund1 la compa6a $b-ector* &J * lan3a el proceso de desarrollo $b-ector* 7abreviaci1n de $b-ect "actor*8.

Ilustracin 2': :istoria de 7;&

Posteriormente en 5AAF #ational Software orporation ad)uiere $b-ector* &J * entre 5AAF * 5AAC se desarrolla #ational $b-ector* Process 7#$P8 a partir de $b-ector* D.B *

FB

del %nfo)ue #ational 7#ational &pproach8 adoptando U9' como lengua-e de modelado. Desde ese entonces * a la cabe3a de Qrad* Jooch, Ivar Nacobson * Names #umbaugh, #ational Software desarroll1 e incorpor1 diversos elementos para e+pandir #$P, destac.ndose especialmente el flu-o de traba-o conocido como modelado del negocio. %n -unio del 5AAB se lan3a #ational Unified Process. &#& T%#!STI &S %S%P I&'%S 'os autores de #UP destacan )ue el proceso de software propuesto por #UP tiene tres caractersticas esenciales: est. dirigido por los asos de Uso, est. centrado en la ar)uitectura, * es iterativo e incremental. Dirigido por asos de Uso: %l proceso utili3a asos de Uso para mane-ar el proceso de desarrollo desde la Incepci1n hasta el Despliegue. entrado en &r)uitectura: %l proceso busca entender los aspectos est.ticos * din.micos m.s significativos en t0rminos de ar)uitectura de software. 'a ar)uitectura se define en funci1n de las necesidades de los usuarios * se determina a partir de los asos de Uso base del negocio. Iterativo e Incremental: %l proceso reconoce )ue es pr.ctico dividir grandes pro*ectos en pro*ectos m.s pe)ue6os o mini:pro*ectos. ada mini:pro*ecto comprende una iteraci1n )ue resulta en un incremento. Una iteraci1n puede abarcar la totalidad de los flu-os del proceso. 'as iteraciones son planificadas en base a los asos de Uso.

FA

.1.1 PROCESO %l ciclo de vida #UP es una implementaci1n del Desarrollo en espiral. "ue creado ensamblando los elementos en secuencias semi:ordenadas. %l ciclo de vida organi3a las tareas en fases e iteraciones. #UP divide el proceso en cuatro fases, dentro de las cuales se reali3an varias iteraciones en n?mero variable seg?n el pro*ecto * en las )ue se hace un ma*or o menor hincapi0 en las distintas actividades. %n la siguiente Ilustraci1n A muestra c1mo vara el esfuer3o asociado a las disciplinas seg?n la fase en la )ue se encuentre el pro*ecto #UP. 'as primeras iteraciones 7en las fases de Inicio * %laboraci1n8 se enfocan hacia la comprensi1n del problema * la tecnologa, la delimitaci1n del .mbito del pro*ecto, la eliminaci1n de los riesgos crticos, * al establecimiento de una baseline 7'nea Jase8 de la ar)uitectura. Durante la fase de inicio las iteraciones hacen ma*or 0nfasis en actividades de modelado del negocio * de re)uisitos. %n la fase de elaboraci1n, las iteraciones se orientan al desarrollo de la baseline de la ar)uitectura, abarcan m.s los flu-os de traba-o de re)uisitos, modelo de negocios 7refinamiento8, an.lisis, dise6o * una parte de implementaci1n orientado a la baseline de la ar)uitectura. %n la fase de construcci1n, se lleva a cabo la construcci1n del producto por medio de una serie de iteraciones. Para cada iteraci1n se selecciona algunos asos de Uso, se refina su an.lisis * dise6o * se procede a su implementaci1n * pruebas. Se reali3a una pe)ue6a cascada para cada ciclo. Se reali3an tantas iteraciones hasta )ue se termine la implementaci1n de la nueva versi1n del producto. %n la fase de transici1n se pretende garanti3ar )ue se tiene un producto preparado para su entrega a la comunidad de usuarios.

GH

omo se puede observar en cada fase participan todas las disciplinas, pero )ue dependiendo de la fase el esfuer3o dedicado a una disciplina vara.

Ilustracin 2): Ciclo de Vida de 7;&

Ilustracin 2+: Ciclo de Vida de 7;&

'a duraci1n * esfuer3o dedicado en cada fase es variable dependiendo de las caractersticas del pro*ecto. Sin embargo, la tabla muestra porcenta-es frecuentes al respecto. onsecuente con el esfuer3o se6alado, la gr.fica )ue esta luego de la tabla ilustra una distribuci1n tpica de recursos humanos necesarios a lo largo del pro*ecto.
Inicio -laboracin 8onstruccin Transicin

G5

-s&uer/o Tiempo dedicado

>E 10E

20E <0E

?>E >0E

10E 10E

0a la +: Distri ucin 09pica de #sfuer,o ! 0ie*po

Ilustracin 3-: Distri ucin 09pica de 7ecursos :u*anos

.1.2 PRODUCTO Un artefacto es un peda3o de informaci1n )ue es creado, modificado o usado por un proceso tal como un modelo, un caso de uso, un documento, c1digo fuente o un archivo e-ecutable. #UP provee plantillas 7templates8, guas * e-emplos para todos los artefactos. Para obtener plantillas de artefactos #UP: http://sce.uhcl.edu/helm/#ationalUnifiedProcess/process/templates.htm %l formato de la tabla utili3ada para registrar los artefactos )ue se producen en #UP se muestra en la siguiente tabla.
Arte&actos 8readoFRevisado Revisar Detalles 8onst Trans Gerramientas Hsadas

RHP Arte&acto 1

Inicia

-lab

0a la 1-: /rtefacto 7;&

%UP'I & ISP D% '& T&J'& &#T%"& T$ #UP 'a siguiente tabla da una e+plicaci1n de las columnas en la Tabla &rtefacto #UP mostrada en la tabla anterior.
Nombre de 8olumna Arte&actos Propsito 8ontenidosF8omentarios -l nombre del arte&acto# Hn Hna re&erencia al arte&acto en el arte&acto es un entre"able del Rational Hni&ied Process# proceso#

G;

8reado F Revisado

Hna ;I; en una o m%s de las celdas Base7 si"ni&ica (ue 8ali&ica cmo es usado el planeamos con"elar ese arte&acto a trav,s del ciclo de arte&acto en esa &ase particularJ vida Iniciacin7 -laboracin7 8onstruccin y Transicin# De&ine el nivel de revisinK Decidir el nivel de revisinJ Bormal procedimientos de revisin (ue van-1terno a ser aplicados al arte&acto# Bormal Interno In&ormal Nin"uno

Revisar Detalles

Gerramientas Hsadas

De&inicin de la )erramienta (oRe&erencia a los detalles de las )erramientas) usadas para )erramientas usadas para desarrollar y producir el arte&acto# mantener el arte&acto#

0a la 11: #<plicacin /rtefacto 7;&

P#$ %DI9I%PT$S D% #%2ISISP Durante el ciclo de vida de un pro*ecto, una revisi1n de un artefacto o con-unto de artefactos es presentada al usuario, cliente u otras partes interesadas para comentarios * aprobaci1n. #UP ha adoptado los niveles de revisi1n indicados en la siguiente tabla.
Nivel de Revisin Bormal -1terno -1plicacin 8omentarios

-ste arte&acto es un entre"able en unPor e3emplo7 la $isin y el 8aso del Ne"ocio )ito espec*&ico# Re(uiere al"0n tipo son arte&actos (ue deber*an ser revisados por de aprobacin del cliente7 elsta6e)olders# patrocinador o al"0n 5os resultados de la revisin son mane3ados en la otro sta6e)older e1terno# con&i"uracin 3unto con el arte&acto# -l arte&acto es revisado &ormalmente el e(uipo del proyecto# Por e3emplo7 las inter&aces de dise9o de porsubsistemas deber*an ser revisados y aprobados por varios miembros del e(uipo del proyecto# 5os resultados de la revisin son mane3ados en la con&i"uracin 3unto con el arte&acto#

Bormal Interno

In&ormal

-l arte&acto es revisadoK pero no es 5as 8lases de Dise9o y los 8omponentes son aprobado &ormalmente# e3emplos de arte&acto (ue no son aprobados &ormalmente# -l arte&acto es desarrollado y mantenido# Normalmente no es descartado lue"o (ue el proyecto termina# 5os resultados de la revisin no son mane3ados en la con&i"uracin con el arte&acto#

Nin"uno

-ste arte&acto no revisado ni aprobado#

necesita

ser -l arte&acto es creado como in&ormacin de traba3o# A menudo es un arte&acto temporal (ue es descartado lue"o (ue el proyecto termina#

0a la 12: 6iveles de 7evisin 7;&

GD

&#T%"& T$S D%' 9$D%'&D$ D%' P%Q$ I$ 'os &rtefactos del 9odelado del negocio pretenden dar un me-or entendimiento de la organi3aci1n donde se va a traba-ar. 'a siguiente tabla identifica los artefactos )ue deben ser desarrollados cuando se 9odela el negocio.
Arte&actos 8reado F Revisado Inicia Plan De Desarrollo 8aso De Ne"ocio 5ista de Ries"os I I I I -lab I 8onst I Trans I Bormal -1terno Bormal -1terno Bormal -1terno '! Lord Re(uisite ProK '! Lord Re(uisite Pro Revisar Detalles Gerramientas Hsadas

0a la 13: /rtefactos Modelado del 6e$ocio

&#T%"& T$S D% #%LU%#I9I%PT$S 'os &rtefactos de #e)uerimientos capturan * presentan informaci1n usada en definir las capacidades re)ueridas por el sistema. 'a siguiente tabla identifica los artefactos )ue deben ser desarrollados cuando se captura los re)uerimientos del sistema.
Arte&actos 8reado F Revisado Inicia Actor 4losario -speci&icacin !uplementaria 8aso de Hso 'odelo de 8aso de Hso $ision 0a la 14: /rtefactos 7e1ueri*ientos -lab I I I I I 8onst I I I I I Trans In&ormal Bormal -1terno Bormal -1t erno Bormal -1terno Bormal -1terno Bormal -1terno Rational Rose Re(uisite ProK '! Lord Re(uisite ProK '! Lord Rational RoseK Re(uisite ProK '! Lord Rational Rose Re(uisite ProK '! Lord Revisar Detalles Gerramientas Hsadas

&#T%"& T$S D% &PT'ISIS / DIS%V$ 'os &rtefactos para &n.lisis * Dise6o capturan * presentan informaci1n relativa a la soluci1n de los problemas planteados durante el (orMflow de #e)uerimientos. 'a siguiente tabla identifica los artefactos )ue deber.n producirse durante el (orMflow de &n.lisis * Dise6o.
Arte&actos 8reado F Revisado Inicia I 'odelo de Dise9o -lab I 8onst I Trans Bormal -1terno Rational Rose Revisar Detalles Gerramientas Hsadas

GE

I 'odelo de Datos Documento de Ar(uitectura del !o&t+are I I

In&ormal Interno

Rational Rose

Bormal -1terno

Re(uisteProK '! Lord

0a la 1": /rtefactos /nalisis ! Dise=o

&#T%"& T$S P&#& '& I9P'%9%PT& ISP 'os &rtefactos para la Implementaci1n capturan * presentan la reali3aci1n de la soluci1n presentada en el (orMflow de &n.lisis * Dise6o. 'a siguiente tabla identifica los artefactos )ue deben producirse durante el (orMflow de Implementaci1n.
Arte&actos 8readoFRevisado Inicia 8onstruccin -lab I 8onst I Trans I Bormal -1terno Rational Rose Revisar Detalles Gerramientas Hsadas

0a la 1%: /rtefactos I*ple*entacin

&#T%"& T$S D% P#U%J&S 'os artefactos presentados en la siguiente tabla son productos finales e intermedio )ue son producidos * usados durante el (orMflow de Pruebas de un pro*ecto. 'os artefactos de Pruebas capturan * comunican informaci1n de pruebas * pueden tomar la forma de un documento, un modelo o un elemento de modelo. 'a siguiente tabla identifica los artefactos )ue deben ser desarrollados en el (orMflow de Pruebas.
Arte&actos 8reado F Revisado Inicia 8aso de Prueba Plan de PruebasF Procedimientos Resultados las Pruebas !cript de Pruebas 0a la 1': /rtefactos &rue as de I I Bormal Interno Test 'ana"er -lab I I I 8onst Trans In&ormal Interno Bormal -1terno o Prueba Interna Test 'ana"er 'ana"er Revisar Detalles Gerramientas Hsadas

In&ormal Interno

Robot7 'anual Test

&#T%"& T$S P&#& %' D%SP'I%QU% 'os artefactos de Despliegue capturan * presentan informaci1n relativa a posicionar el sistema, presentado en el (orMflow de Implementaci1n, dentro del ambiente de producci1n. 'a siguiente tabla identifica los artefactos )ue deben ser producidos durante el (orMflow de Despliegue.

GF

Arte&actos

8readoFRevisado Inicia -lab 8onst I I I Trans I I I I I I I

Revisar Detalles

Gerramientas Hsadas

Relacin de 'ateriales Plan de Desplie"ue Producto Notas del Release 'ateriales de -ntrenamiento 0a la 1): /rtefactos Desplie$ue

In&ormal In&ormal Bormal -1terno Bormal Interno Bormal -1terno

'! Lord '! Lord '! Lord '! Lord '! Lord

&#T%"& T$S #UP &D9IPIST#& ISP / $P"IQU#& ISP D% &9JI$S 'os artefactos e &dministraci1n de onfiguraci1n * ambios capturan * presentan informaci1n relativa a las actividades 9. 'a siguiente tabla identifica los artefactos )ue deben ser producidos durante el (orMflow de &dministraci1n de onfiguraci1n * ambios.
Arte&actos 8readoFRevisado Inicia Re(uerimiento de 8ambio Repositorio del Proyecto Lor6space -lab I I I 8onst I I I Trans I I I In&ormal Nin"uno Nin"uno Rational 8lear2uest Rational 8lear8ase Rational 8lear8ase Revisar Detalles Gerramientas Hsadas

0a la 1+: /rtefactos /d*inistracin ! Confi$uracin de Ca* ios

Pota: Para grandes organi3aciones con un numerosos e)uipos de ingenieros la comunicaci1n entre cada e)uipo es crtica por lo tanto es necesario )ue los artefactos sean completos * bastante comprensivos %n tanto )ue para pe)ue6os pro*ectos no es recomendable presentarse tanto rigor en las preparaciones de los artefactos, la eficiencia del proceso depende m.s de las habilidades de cada traba-ado .1.3 PERSONAL &nalistas: &nalista de procesos de negocio. Dise6ador del negocio. &nalista de sistema.

GG

%specificador de re)uisitos.

Qestores: Nefe de pro*ecto Nefe de control de cambios. Nefe de configuraci1n. Nefe de pruebas Nefe de despliegue Ingeniero de procesos #evisor de gesti1n del pro*ecto Qestor de pruebas.

Desarrolladores: &po*o: Documentador t0cnico &dministrador de sistema %specialista en herramientas Desarrollador de cursos &rtista gr.fico &r)uitecto de software. Dise6ador Dise6ador de interfa3 de usuario Dise6ador de c.psulas. Dise6ador de base de datos. Implementador. Integrador

%specialista en pruebas: %specialista en Pruebas 7tester8 &nalista de pruebas

GC

Dise6ador de pruebas

$tros roles: StaMeholders. #evisor oordinaci1n de revisiones #evisor t0cnico ual)uier rol .1.4 TECNOLOGIA @erramientas del #UP #e)uisite pro. #ational rose. lear case. o #e)uisite Pro %s una herramienta de #ational )ue se apo*a en el traba-o en e)uipo basado en el mane-o de re)uerimientos Se integra con 9icrosoft (ord para capturar los documentos de re)uisitos &utomati3a el mane-o de re)uerimientos para el rastreo. #astreo es un enlace o relaci1n entre dos re)uerimientos. o #acional #ose %s una herramienta de #&TI$P&' S$"T(&#% U9'. $#P$#&TI$P con el soporte de

#ose posesionado por #ational $b-ect est. orientado a la Ingeniera del software. %s usado para el an.lisis, modelado, dise6o * construcci1n del ob-eto orientado. %sta dentro de las herramientas de modelamiento visual Soporte m?ltiple para el mane-o del modelamiento de la ar)uitectura. o lear ase

%s una herramienta para el conflicto entre versiones. &dministra todos los artefactos en el proceso de desarrollo para dise6ar modelos, codificaci1n * pruebas. &umenta la administraci1n del espacio de traba-o inclu*endo vistas din.micas.

GB

.2

&P

%UT#%9% P#$Q#&99IPQ UP es una metodologa .gil centrada en potenciar las relaciones interpersonales como clave para el 0+ito en desarrollo de software, promoviendo el traba-o en e)uipo, preocup.ndose por el aprendi3a-e de los desarrolladores, * propiciando un buen clima de traba-o. Seg?n Xent JecM, ^la programaci1n e+trema es una forma ligera, eficiente, fle+ible, predecible, cientfica * divertida de generar software^ 7Xent JecM, %+treme Programming %+plained8. &#& T%#!STI &S D% UP Desarrollo iterativo e incremental: Pe)ue6as me-oras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas * automati3adas, inclu*endo pruebas de regresi1n: Se aconse-a escribir el c1digo de la prueba antes de la codificaci1n. Programaci1n en pare-as: Se recomienda )ue las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. o Se supone dar ma*or calidad al c1digo escrito de esta manera o %l c1digo es revisado * discutido mientras se escribe o %s m.s importante )ue la posible p0rdida de productividad inmediata. "recuente integraci1n del e)uipo de programaci1n con el cliente o usuario: Se recomienda )ue un representante del cliente traba-e -unto al e)uipo de desarrollo. orrecci1n de todos los errores antes de a6adir nueva funcionalidad: @acer entregas frecuentes. #efactori3aci1n del c1digo: #eescribir ciertas partes del c1digo para aumentar su legibilidad * mantenibilidad pero sin modificar su comportamiento. 'as pruebas han de garanti3ar )ue en la refactori3aci1n no se ha introducido ning?n fallo. Propiedad del c1digo compartida: %n ve3 de dividir la responsabilidad en el desarrollo de cada m1dulo en grupos de traba-o distintos, este m0todo promueve el )ue todo el personal pueda corregir * e+tender cual)uier parte del pro*ecto. 'as frecuentes pruebas de regresi1n garanti3an )ue los posibles errores ser.n detectados. Simplicidad en el c1digo: %s la me-or manera de )ue las cosas funcionen. uando todo funcione se podr. a6adir funcionalidad si es necesario. o 'a programaci1n e+trema apuesta )ue es m.s sencillo hacer algo simple * tener un poco de traba-o e+tra para cambiarlo si se re)uiere, )ue reali3ar algo complicado * )ui3.s nunca utili3arlo.

GA

o 'a simplicidad complementarias. o

la

comunicaci1n

son

e+traordinariamente

on m.s comunicaci1n resulta m.s f.cil identificar )u0 se debe * )u0 no se debe hacer.

o 9ientras m.s simple es el sistema, menos tendr. )ue comunicar sobre este, lo )ue lleva a una comunicaci1n m.s completa, especialmente si se puede reducir el e)uipo de programadores P#T TI &S D% UP: #etroalimentaci1n a escala fina. o Desarrollo Dirigido por Pruebas o %l -uego de la planificaci1n o liente in:situ

o Programaci1n en pare-as Proceso continuo en lugar de por lotes. o %ntregas pe)ue6as. o #efactori3aci1n. o Integraci1n contin?a. %ntendimiento compartido. o Dise6o Simple 7lo m.s simple )ue funcione, simplificar vigorosamente8. o 9et.fora del sistema o Propiedad colectiva del c1digo o onvenciones de c1digo. %st.ndares de programaci1n

Jienestar del programador. o EH horas por semana

P#$/% T$ D% P#$Q#&9& I$P %UT#%9%:

CH

Ilustracin 31: &ro!ecto de &ro$ra*acin #<tre*e

.2.1 PROCESO UP define @istorias de Usuarios como base del software a desarrollar. %stas historias las escribe el cliente * describen escenarios sobre el funcionamiento del software, )ue no solo se limitan a la QUI si no tambi0n pueden describir el modelo, dominio, etc. & partir de las @istorias de Usuarios * de la ar)uitectura perseguida se crea un plan de %ntregas entre el e)uipo de desarrollo * el cliente. Para cada %ntrega se discutir.n los ob-etivos de la misma con el representante del cliente * se definir.n las Iteraciones 7de pocas semanas de duraci1n8 necesarias para cumplir con los ob-etivos de la %ntrega. %l resultado de cada Iteraci1n es un programa )ue se transmite al cliente para )ue lo pruebe * con base a su opini1n se definen las siguientes Iteraciones del pro*ecto * si el cliente no est. de acuerdo se adaptara el plan de %ntregas e Iteraciones hasta )ue el cliente de su aprobaci1n * este satisfecho con el software. Nunto a las @istorias de Usuarios est.n los %scenarios de pruebas los cuales describen el escenario contra el )ue se comprueba la reali3aci1n de las @istorias de Usuarios. @istorias de Usuarios * asos de Pruebas son la base del traba-o del desarrollador. omo primer paso de cada Iteraci1n se escribir.n las Pruebas, de tal forma )ue puedan ser e-ecutadas autom.ticamente, de manera )ue pueda comprobarse la correcci1n del software antes de cada %ntrega. I '$ D% 2ID& D% UP %l ciclo de vida ideal de UP consiste de seis fases: "&S% I. %UP'$#& ISP.

C5

%s la fase en la )ue se define el alcance general del pro*ecto, el cliente describe lo )ue necesita mediante la redacci1n de sencillas <@istorias de Usuarios>. 'os programadores estiman los tiempos de desarrollo con base a esta informaci1n. 'as estimaciones reali3adas en esta fase son primarias 7*a )ue estar.n basadas en datos de mu* alto nivel8, * podran variar cuando se analicen en detalle en cada iteraci1n. %sta fase dura tpicamente un par de semanas, * el resultado es una visi1n general del sistema, * un pla3o total estimado.

Ilustracin 32: Spi>es ?@os1ueAosB

"&S% II. P'&PI"I & ISP D% '& %PT#%Q&.

'a planificaci1n es una fase corta, en la )ue el cliente, los gerentes * el grupo de desarrolladores acuerdan el orden en )ue deber.n implementarse las @istorias de Usuario * asociadas a 0stas, las %ntregas. Tpicamente esta fase consiste en una o varias reuniones grupales de planificaci1n. %l resultado de esta fase es un Plan de %ntregas, o <#elease Plan> %l cronograma de entregas establece )u0 @istorias de Usuario ser.n agrupadas para conformar una entrega * el orden de las mismas. %ste cronograma ser. el resultado de una reuni1n entre todos los actores del pro*ecto 7cliente, desarrolladores, gerentes, etc.8. UP denomina a esta reuni1n <Nuego de la Planificaci1n> 7<Planning game>8.

C;

Ilustracin 33: &lanificacin de la #ntre$a

"&S% III. IT%#& I$P%S.

%sta es la fase principal en el ciclo de desarrollo de UP. 'as funcionalidades son desarrolladas en esta fase, generando al final de cada Iteraci1n un entregable funcional )ue implementa las @istorias de Usuario asignadas a la Iteraci1n. omo las @istorias de Usuario no tienen suficiente detalle como para permitir su an.lisis * desarrollo, al principio de cada Iteraci1n se reali3an las tareas necesarias de an.lisis, obteniendo con el cliente todos los datos )ue sean necesarios. l cliente, por lo tanto, tambi0n debe participar activamente durante esta fase del ciclo. 'as Iteraciones son tambi0n utili3adas para medir el progreso del pro*ecto. Una Iteraci1n terminada sin errores es una medida clara de avance.

Ilustracin 34: Co*en,ar Iteracin

CD

"&S% I2. P#$DU

ISP.

%sta fase re)uiere de pruebas adicionales * revisiones de rendimiento antes de )ue el sistema sea trasladado al entorno del cliente, Si bien al final de cada Iteraci1n se entregan m1dulos funcionales * sin errores, puede ser deseable por parte del cliente no poner el sistema en producci1n hasta tanto no se tenga la funcionalidad completa. &l mismo tiempo, se deben tomar decisiones sobre la inclusi1n de nuevas caractersticas a la versi1n actual, debido a cambios durante esta fase. %n esta fase no se reali3an m.s desarrollos funcionales, pero pueden ser necesarias Tareas de &-uste 7<fine tuning>8.

Ilustracin 3": &ro$ra*acin

"&S% 2. 9&PT%PI9I%PT$.

9ientras la primera versi1n se encuentra en producci1n, el pro*ecto UP debe mantener el sistema en funcionamiento al mismo tiempo )ue desarrolla nuevas Iteraciones. Para reali3ar esto se re)uiere de tareas de soporte para el cliente, de esta forma, la velocidad de desarrollo puede ba-ar despu0s de la puesta del sistema en producci1n. 'a fase de mantenimiento puede re)uerir nuevo personal dentro del e)uipo * cambios en su estructura.

Ilustracin 3%: Manteni*iento 4 &rue as de /ceptacin

CE

"&S% 2I. 9U%#T% D%' P#$/% T$.

%s cuando el cliente no tiene m.s historias para ser incluidas en el sistema, esto re)uiere )ue se satisfagan las necesidades del cliente en otros aspectos como rendimiento * confiabilidad del sistema. Se genera la documentaci1n final del sistema * no se reali3an m.s cambios en la ar)uitectura. 'a muerte del pro*ecto tambi0n ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no ha* presupuesto para mantenerlo. .2.2 PRODUCTO 'a metodologa UP tiene unos productos o artefactos de los )ue se pueden mencionar: @istoria del usuario 7UserStories8: %stas deben proporcionar s1lo el detalle suficiente como para poder hacer ra3onable la estimaci1n de cu.nto tiempo re)uiere la implementaci1n de la historia, difiere de los casos de uso por)ue son escritos por el cliente, no por los programadores, empleando terminologa del cliente.

Ilustracin 3': :istoria de ;suario

'as @istorias de Usuario tienen tres aspectos: o Tar-eta: %n ella se almacena suficiente informaci1n para identificar * detallar la historia. o onversaci1n: liente * programadores discuten la historia para ampliar los detalles 7verbalmente cuando sea posible, pero documentada cuando se re)uiera confirmaci1n8

o Pruebas de &ceptaci1n: Permite confirmar )ue la historia ha sido implementada correctamente. Tareas de ingeniera 7tasM card8

CF

Tar-etas # 7 lase : #esponsabilidad _ olaborador8: %stas tar-etas se dividen en tres secciones )ue contienen la informaci1n del nombre de la clase, sus responsabilidades * sus colaboradores. o lase: es cual)uier persona, cosa, evento, concepto, pantalla o reporte.

o #esponsabilidades: de una clase son las cosas )ue conoce * las )ue reali3a, sus atributos * m0todos. o olaboradores: de una clase son las dem.s clases con las )ue traba-a en con-unto para llevar a cabo sus responsabilidades. 'os pasos a seguir para llenar las tar-etas son los siguientes: encontrar clases, encontrar responsabilidades, definir colaboradores, disponer las tar-etas.

Pruebas unitarias * de integraci1n Plan de la entrega 1digo .2.3 PERSONAL

%+isten diferentes roles 7actores8 * responsabilidades en UP para diferentes tareas * prop1sitos durante el proceso: Programador 7Programmer8 dise6an, programan * reali3an las pruebas #esponsable de decisiones t0cnicas #esponsable de construir el sistema sin distinci1n entre analistas, dise6adores o codificadores liente 7 ustomer8 %s parte del e)uipo, determina )u0 construir * cu.ndo escribe tests funcionales para determinar cu.ndo est. completo un determinado aspecto %ntrenador 7 oach8 %l lder del e)uipo toma las decisiones importantes, principal responsable del proceso, tiende a estar en un segundo plano a medida )ue el e)uipo madura #astreador 7TracMer8 79etric 9an8, $bserva sin molestar, hist1ricos onserva datos

Probador 7Tester8 &*uda al cliente con las pruebas funcionales, se asegura de )ue los tests funcionales se e-ecutan .2.4 TECNOLOGIA

Uplanner: %s una @erramienta Para Planificaci1n olaborativa de pro*ectos * el seguimiento para e)uipos )ue utili3an %+treme Programming . Permitir hacer estimaciones de los recursos necesarios 7tiempo, coste, personal8, viendo si el pro*ecto en si es viable o no. %sta herramienta tambi0n es fundamental *a )ue

CG

permite e+aminar el avance del pro*ecto, detectando lo antes posible desviaciones respecto de las estimaciones. De esta forma se puede adelantar a posibles problemas * reducir los riesgos. "itnesse: %s una herramienta para me-orar la colaboraci1n en el desarrollo de software. Permite a los clientes, los probadores * programadores aprendan lo )ue el software debe hacer, * compara autom.ticamente )ue es lo )ue realmente hace. ompara las e+pectativas de los clientes con los resultados reales. ruise ontrol: %s una aplicaci1n de c1digo abierto basado en Nava )ue permite la compilaci1n autom.tica de pro*ectos Nava, utili3ando &nt o 9aven. %s una herramienta com?nmente utili3ada en integraci1n continua )ue cada cierto tiempo, o cuando ha* cambios en el gestor de versiones 7por e-emplo 2S o Subversion8, hace una compilaci1n * e-ecuta tests 7m.s cual)uier otra cosa )ue est0 configurada en &nt o 9aven8 * una ve3 acaba presenta el resultado. 9antis: %s una de las soluciones m.s completas para la gesti1n de tareas entre un e)uipo de traba-o. %s una aplicaci1n $penSource hecha en php * m*s)l, utili3ada en las empresas para testear soluciones, hacer un registro hist1rico de alteraciones * gestionar e)uipos remotamente. &simismo resulta mu* pr.ctico para depurar errores de aplicaciones, sitios web * todo lo )ue necesite seguimiento * me-oras continuas * constantes. Subversion: %s un sistema de control de versiones, es software libre ba-o una licencia de tipo &pache/JSD * se le conoce tambi0n como svn, Una caracterstica importante es: 'os archivos versionados no tienen cada uno un n?mero de revisi1n independiente, en cambio, todo el repositorio tiene un ?nico n?mero de versi1n )ue identifica un estado com?n de todos los archivos del repositorio en un instante determinado. "ish%*e: Qenera b?s)uedas, informes * alertas )ue sean necesarias para controlar repositorio Subversion. NI#&: %s una aplicaci1n basada en web para el seguimiento de errores, de incidentes * para la gesti1n operativa de pro*ectos. Tambi0n se utili3a en .reas no t0cnicas para la administraci1n de tareas. rucible: simplifica la revisi1n del c1digo del e)uipo. hori3o: pruebas autom.ticas de seguridad web. Selenium: Pruebas funcionales automati3adas 7pruebas de regresi1n8. +Unit: on-unto de herramientas para pruebas unitarias )ue engloba herramientas como php:Unit o -Unit ab _ &pache JenchmarMing tool httperf: Permite, de forma sencilla, reali3ar varias peticiones http simult.neas para ver c1mo reacciona el servidor. &pache -9etter: Sirve para medir el stress )ue soporta el servidor.

CC

.3

SCRUM

Scrum es una metodologa m.s de las muchas )ue ha*, * 0sta en concreto, se basa en la filosofa del desarrollo .gil )ue fue e+puesto por dos -aponeses alrededor del a6o 5ABG. %n 5AA5 Peter DeQrace * 'eslie Stahl en su libro (icMed Problems, #ighteous Solutions 7& problemas malvados, soluciones virtuosas8, se refirieron a esta apro+imaci1n como scrum 7mel0 en ingl0s8, un t0rmino propio del rugb* Donde el e)uipo entero `act?a como un s1lo hombre para intentar llegar al otro lado del campo, pasando el bal1n de uno a otroa, mencionado en el artculo por TaMeuchi * PonaMa. %l desarrollo .gil pone de manifiesto b.sicamente lo siguiente: %l mercado actual es altamente competitivo * la tecnologa es mu* cambiante. %n el desarrollo del Software se pide b.sicamente rapide3, calidad * reducci1n de costes, pero para asumir estos retos, es necesario tener agilidad * fle+ibilidad. 'os ciclos de desarrollo por otro lado, acostumbran a ser largos, * lo )ue se e+ige por otra parte, es )ue esos ciclos sean lo m.s cortos posibles.

%l desarrollo .gil aboga por estas premisas principalmente. .3.1 PROCESO %n el proceso de Scrum se usan t0rminos propios de la metodologa, )ue a continuaci1n se definen: Product JacMlog 7Pila de Producto8: orresponde a una lista de todas la tareas, funcionalidades o re)uerimientos a reali3ar. Sprint JacMlog 7Pila de Sprint8: orresponde a un componente compuesto por varias tareas )ue provienen del Product JacMlog. Dail* Scrum 9eeting 7#euni1n diaria de Scrum8: %s una tarea iterativa )ue se reali3a todos los das )ue dure el Sprint JacMlog con el e)uipo de desarrollo o de traba-o. Se trata de una reunion operativa, informal * agil de un tiempo ma+imo de DH minutos, donde se da respuesta a D preguntas )ue se hacen a cada integrante. o [Lu0 ha hecho\ o [Lu0 va hacer\ o [Lu0 a*uda necesita\

CB

Ilustracin 3): Metodolo$9a SC7;M

%n la anterior ilustraci1n se muestra el proceso de Scrum, )ue a su ve3 se dividen en D fasesO Pre-uego, Nuego * Pos-uego. 'a fase de Pre-uego abarca le reali3aci1n del Product JacMlog. 'a fase de Nuego comprende crear el Sprint JacMlog * entregarlo al Sprint con el fin de crear un incremento, recordemos )ue Sprint es nada m.s )ue un periodo de tiempo 7bcDH das8, en el cual se reali3a la parte t0cnica necesaria. 'a fase de Pos-uego comprende integrar los incrementos del producto * reali3ar pruebas de integraci1n. .3.2 PRODUCTO omo producto en Scrum se reali3an D artefactos: Product JacMlog: este es un documento din.mico )ue contiene los re)uerimentos del sistema 7funcionalidades, tareas investigativas * bugs 8, se dice )ue es din.mico por)ue se puede agregar, eliminar * a-ustar componentes seg?n sea necesario * conveniente, 0ste se mantiene durante todo el ciclo de vida del sistema, hasta su retiro.

CA

Sprint JacMlog: es un documento dinamico )ue contiene las tareas a reali3ar en un sprint, con el fin de lograr un incremento, adem.s se debe registrar lo reali3ado diariamente para armar el grafico de avance del pro*ecto Jurndown hart: dste grafico permite conocer de manera agil * visual el progreso o no de los traba-os del pro*ecto. Diariamente cada miembro del e)uipo de desarrollo actuali3a la7s8 tarea7s8 en )ue est. traba-ando, * estima el tiempo necesario para terminar la7s8 tarea7s8. .3.3 PERSONAL

'as principales personas alrededor de un scrum son: Product $wner 7Propietario del producto8: o #epresenta a todos los interesados en el producto final o "inancia el pro*ecto o Provee los re)uerimientos del sistema o Priori3a los "uncionalidades o &dapta los incrementos de cada Sprint Scrum 9aster o %s el manager del pro*ecto o %s responsable de velar * difundir los valores * las pr.cticas de Scrum o Su tarea principal es remover impedimentos %)uipo de Desarrollo o Tpicamente de F:5H personas o 9ulti:funcional o 'os miembros deben estar full:time o 'os e)uipos son auto:organi3ativos o S1lo puede haber cambio de miembros entre los Sprints .3.4 REUNIONES Planificaci1n de sprint: Nornada de traba-o previa al inicio de cada sprint en la )ue se determina cu.l va a ser el traba-o * los ob-etivos )ue se deben cumplir en esa iteraci1n. #euni1n diaria: Jreve revisi1n del e)uipo del traba-o reali3ado hasta la fecha * la previsi1n para el da siguiente.

BH

 .4

#evisi1n de sprint: &n.lisis * revisi1n del incremento generado. CRYSTAL 'CLEAR(

9etodologa de tipo .gil, creada por &listair ocMburn a pedido del grupo de consultora de IJ9 en el a6o 5AA5. & diferencia de muchas metodologas para la gesti1n del desarrollo del software, r*stal lear se centra m.s en el factor humano )ue en los procesos * artefactos. %sta metodologa presenta las siguientes propiedades, siendo e+igibles las tres 7D8 primeras: %ntregas "recuentes: %s imperante )ue al final de cada iteraci1n, se haga entrega a los usuarios el c1digo debidamente testeado. on ello se busca )ue el e)uipo de desarrollo pueda efectuar correcciones en la aplicaci1n en caso la funcionalidad no cumpla con las necesidades del usuario. %s m.s sencillo efectuar los cambios sobre los entregables de cada iteraci1n )ue sobre un pro*ecto completamente integrado. 9e-oras #efle-adas: onsiste en identificar los puntos en los )ue el pro*ecto marcha bien, en los )ue marchan mal * los )ue pueden ser me-orados. Dichas me-oras seran aplicadas en la siguiente iteraci1n. %sta propiedad debe de estar presente a lo largo de todo el pro*ecto. Ssmosis en la omunicaci1n: Propiedad imprescindible de esta metodologa en la )ue los miembros abocados a la programaci1n se distribu*en en dentro de una misma habitaci1n o dentro de un ambiente )ue permita una comunicaci1n fluida * sin obst.culos entre todo el e)uipo. Seguridad Personal: onsiste en brindar apo*o a los dem.s miembros del e)uipo. %l e)uipo de traba-o est. conformado por personas, cada una de las cuales tienen sus propias fortale3as, debilidades * problemas. 'os aspectos negativos pueden solucionarse apo*ando a los dem.s miembros */o buscando apo*o en ellos. %nfo)ue: Destinar tiempo adecuado para poder cumplir con las prioridades )ue se tienen asignadas. %s importante apo*ar a los dem.s miembros en las dudas * problemas )ue presentenO sin embargo, siempre ha* )ue destinar un tiempo a las actividades asignadas. &cceso sencillo para usuarios e+pertos: Tener facilidad de acceso a usuarios e+pertos )uienes verificar.n )ue a lo largo de cada iteraci1n se est.n cumpliendo sus e+pectativas. %l acceso puede ser por visitas semanales * llamadas telef1nicasO uno o m.s de un usuario e+perto dentro del e)uipoO desarrolladores especiali3ados )ue han asumido el papel de usuarios 7no es mu* recomendado el uso de esta ?ltima8. &mbiente t0cnico con pruebas automati3adas continuas a medida )ue se programa, gesti1n de la configuraci1n 7acompa6ada de una adecuada gesti1n de cambios8, integraci1n frecuente de los avances reali3ados.

B5

.4.1 PROCESO 'os pro*ectos son vistos como un ciclo continuo, *a )ue al concluir un pro*ecto, siempre habr. otro esperando a ser comen3ado. Un ciclo de pro*ecto, dentro de r*stal lear, est. conformado por tres etapas: T#&R&D$ D% & TI2ID&D%S %sta primera etapa puede abarcar desde un par de das hasta un par de semanas. Dentro de este perodo, se llevan a cabo las siguientes tareas: "or-ar el cora31n del e)uipo, )ue consiste en definir los tres principales roles _ el desarrollador lder, el patrocinador * el usuario clave. &n.lisis e+ploratorio de DGHe, se lleva a cabo un estudio de viabilidad llevando a cabo una revisi1n de alto nivel de los pilares del esfuer3o aplicado en la etapa de desarrollo: el valor del negocio esperado, los re)uerimientos capturados, el .mbito del modelo, la tecnologa a utili3arse, el plan de pro*ecto, la conformaci1n del e)uipo * la metodologa o acuerdos a utili3arse. Tra3ando la metodologa, conformado por los convenios definidos al inicio del pro*ecto )ue pueden ir siendo me-orados * corregidos al inicio de cada nueva iteraci1n. onstru*endo el plan de pro*ecto inicial, se elabora el 9apa del Pro*ecto _ diagrama e)uivalente al diagrama de precedencia _ * el Plan de Pro*ecto _ indicando los ciclos de entrega * los perodos )ue cada iteraci1n involucra.

D$S $ 9TS I '$S D% %PT#%Q& ada ciclo de entrega involucra las siguientes actividades: #ecalibrar el plan de pro*ecto, se eval?a tanto los re)uerimientos como el plan de pro*ecto al inicio de cada ciclo de entrega con el ob-etivo de corregir desviaciones producidas respecto al alcance del pro*ecto. Desarrollo en Iteraci1n7es8, cada iteraci1n presenta una duraci1n ma*or a una semana * menor a tres meses. Se efect?an las siguientes labores: o Planear la iteraci1n: se definen prioridades de las tareas o iclo Programaci1n _ testeo _ integraci1n

o #itual de fin de iteraci1n %ntrega a usuarios reales, se entrega la aplicaci1n, resultado de la iteraci1n, a un grupo de usuarios reales para as conocer si los resultados obtenidos hasta la fecha son un fiel refle-o de los re)uerimientos presentados por el usuario. #efle+i1n sobre el producto creado * los convenios usados.

I%##% D% P#$/% T$

B;

%n esta etapa final se llevan a cabo las siguientes tareas: Pruebas de aceptaci1n Se prepara el producto final * el ambiente del usuario para llevar a cabo la implantaci1n de la soluci1n. #ecopilaci1n de los conocimientos ad)uiridos a fin de poder ser utili3ados en un pro*ecto )ue se presente a futuro.

%T&P&S D% '& 9%T$D$'$QI& #IST&' '%&#

Ilustracin 3+: #tapas de la Metodolo$ia Cr!stal Clear

.4.2 PRODUTO %l cuadro presentado a continuaci1n brindar. un breve resumen de la documentaci1n generada por cada uno de los roles de la metodologa.
Tra/ado de Actividades Recalibrar plan proyecto Iteracin -ntre"a a usuarios reales Re&le1in sobre el producto y los acuerdos 8ierre Proyecto

Patrocinador -(uipo

'isin proyecto Acuerdos e(uipo

Dise9o Pantallas

-mpa(uetar solucin

BD

8oordinador

5*der Desarrollo Hsuario -1perto

'apa proyecto Plan lan/amiento 5ista ries"os Plan iteracin 8rono"rama Ar(uitectura 8asos de uso Re(uisitos 8at%lo"o actores

Dmbito 'odelo Dia"ramas Dise9o 8di"o &uente -stado del proyecto

Tester Redactor 0a la 2-: &roductos en Cr!stal Clear

Reporte Pruebas F -rrores 'anual de Hsuario

Reporte pruebas aceptacin

.4.3 PERSONAL Dentro de esta metodologa es posible identificar los siguientes roles: Patrocinador: %s el encargado de definir c1mo se distribuir. el capital dentro del pro*ecto, suele ser )uien contrata los servicios del organismo desarrollador. %n consecuencia, su decisi1n tendr. importancia al momentos de definir las prioridades en cuanto las funcionalidades a implementar. Usuario e+perto: &dicionalmente a conocer las funciones desempe6adas por un usuario del sistema, cumple las funciones de un e+perto de negocio, es decir, conoce los procesos )ue se llevan a cabo dentro del negocio. 'der de Dise6o/Desarrollo: 9iembro del e)uipo con gran conocimiento en temas de desarrollo de software. %s )uien lleva el control del avance del e)uipo. %)uipo de Dise6o/Desarrollo: Dem.s integrantes del e)uipo abocados a la tarea de desarrollar e implementar la soluci1n. Suele haber un lder de dise6o/desarrollo por cada tres miembros del e)uipo. oordinador del pro*ecto: %ste rol puede ser ocupado tanto por el patrocinador como por el lder de dise6o/desarrollo. Se encargar. de enumerar las funciones a ser entregadas al final de cada ciclo de entrega. 'leva el control de las funciones a entregarse acorde al tiempo establecido en el cronograma.

BE

Tester: %ste rol es desempe6ado por todos los miembros del e)uipo a lo largo de todo el proceso de implementaci1n. Su funci1n es la de reportar todos los bugs * errores detectados en el sistema siendo desarrollado. #edactor: %ste rol es llevado a cabo por los mismos miembros del e)uipo, )uienes se encargar.n de la redacci1n del manual de usuario a ser entregado -unto con la soluci1n. .4.4 TECNOLOGIA

9uestra de cat.logo asos de Uso #e)uisitos no funcionales &r)uitectura Pruebas de los asuntos Dise6o de interfa3 de usuario PSP I$P

IPT#$DU

Despu0s de la segunda guerra mundial, la estrategia de calidad en la ma*ora de las organi3aciones industriales se basaba casi por completo en las pruebas. 'as empresas establecieron departamentos especiales de la calidad para encontrar * arreglar problemas despu0s de la producci1n de los productos. PSP se concentra en las pr.cticas de traba-o de los ingenieros en una forma individual. %l principio detr.s de PSP es 0se, sirve para producir software de calidad, cada ingeniero debe traba-ar en la necesidad de reali3ar traba-o de calidad. PSP se dise61 para )ue se utilicen constantemente pr.cticas sanas de ingeniera de software. &s mismo a c1mo planear * darle un seguimiento al traba-o, a utili3ar un proceso bien definido * medido, a establecer metas mesurables, * finalmente a la utili3aci1n del rastreo constante para alcan3ar dichas metas. PSP les demuestra a los ingenieros a c1mo mane-ar la calidad desde el principio del traba-o, a c1mo anali3ar los resultados de cada traba-o, * a c1mo utili3ar los resultados para me-orar el proceso del pro*ecto siguiente. P#IP IPI$S: ada ingeniero es esencialmente diferenteO para ser m.s precisos, los ingenieros deben planear su traba-o * basar sus planes en sus propios datos personales. Para me-orar constantemente su funcionamiento, los ingenieros deben utili3ar personalmente procesos bien definidos * medidos.

BF

Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos. uesta menos encontrar * arreglar errores en la etapa inicial del pro*ecto )ue encontrarlos en las etapas subsecuentes. %s m.s eficiente prevenir defectos )ue encontrarlos * arreglarlos. 'a manera correcta de hacer las cosas es siempre la manera m.s r.pida * m.s barata de hacer un traba-o . .1 PROCESO

Ilustracin 4-: 6iveles de &S&

PSPH _ Se establece una lnea base del rendimiento mensurable.

'os aspectos de inter0s en este nivel se relacionan con la estimaci1n del tiempo para desarrollar un producto de software * la identificaci1n, clasificaci1n * mane-o de los defectos producidos durante el proceso de desarrollo. PSP5 _ Se hace planes de tama6o, recursos * calendario

Utili3ando informaci1n recabada en procesos anteriores, se concentra en el uso de un m0todo de naturale3a estadstica denominado P#$J%, para la estimaci1n del tama6o * tiempo necesario para el desarrollo de productos de software. PSP; _ Se Practica gesti1n de defectos * rendimiento.

BG

%l aspecto de inter0s en PSP; es la calidad. 'a calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de defectos )ue el producto de software contiene. PSPD : &mpliamos los m0todos del PSP a pro*ecto ma*ores.

%l cambio )ue ha reali3ado el ingeniero de software en la forma de reali3ar sus actividades ha sido de forma individual *, para pro*ectos de ba-a comple-idad, PSPD introduce los lineamientos iniciales para considerar pro*ectos de ma*or comple-idad * dentro de un entorno de desarrollo integrado por m.s de un desarrollador.

Ilustracin 41: CluAo del &roceso en &S&

Debido a )ue generalmente ciertos m0todos de PSP no son utili3ados por los desarrolladores, los m0todos de PSP son presentados en una serie de siete versiones de procesos. %stas versiones son denominadas como PSPH a PSPD. con-unto de log, formularios, scripts, * est.ndares. ada versi1n tiene un mismo

'os scripts de proceso definen los pasos de cada parte del proceso, los logs * formularios proveen templates para registrar * almacenar datos, * los standards guan a los desarrolladores a mientras. . .2 TECNOLOGIA QUI$P%S D% P#$ %S$

BC

N0mero de Base

Propsito -ntradas Necesarias

2ue )acerM N Descripcin del problema Bormulario de Resumen del plan del Proyecto P!P. Tablas de Re"istro de Tiempos y De&ectos 8ronometro (opcional)

Plani&icacin

Producir u obtener los re(uisitos -stimar las 5.8 necesarias -stimar el tiempo de desarrollo necesario Indicar los datos del plan en el Resumen del Plan de Proyecto 8ompletar el 5o" de Re"istro de Tiempos

Desarrollo

Dise9ar el pro"rama Implementar el dise9o 8ompilar el pro"rama y corre"ir todos los de&ectos encontrados 8ompletar la Tabla de Re"istro de Tiempos N 8ompletar el Resumen del plan del Proyecto con los datos actuales de tiempo7 de&ectos y tama9o

<

Post mortem

8riterios de salida Hn pro"rama probado Hn resumen del Plan de Proyectos con los datos estimados y actuales 5as tablas de Re"istro de Tiempos y De&ectos Rellenos 0a la 21: 2uiones de &roceso

o Planificaci1n %stimar tiempo de desarrollo. o Desarrollo Desarrollar el producto utili3ando m0todos actuales. o Post:mortem ompletar el resumen del plan pro*ecto, con los tiempos gastados * defectos encontrados e in*ectados en cada fase. o Dise6o Dise6ar el programa, usando m0todos de dise6o actuales. o odificaci1n

Implementa el programa. o ompilaci1n

ompila hasta )ue est0 libre defectos.

BB

o Prueba Prueba el programa * corrige todos los defectos. o #egistra los defectos en el 'og de defectos * tiempos por fase en el 'og de tiempos.
&ec)a

'$Q D% #%QIST#$ D% TI%9P$

Inicio Bin Tiempo Interrupcin deTiempo Delta Base 8omentarios

0a la 22: 5o$ de 7e$istro de 0ie*po

o "echa Indicar la fecha actual. o Inicio Indicar el tiempo en minutos cuando empie3as una fase del pro*ecto. o "in Indicar el tiempo en minutos cuando tu paraste tu traba-o en una fase del pro*ecto, aun cuando t? no has terminado esa fase. o Tiempo de interrupci1n Indicar el tiempo perdido por interrupciones desde el periodo de arran)ue a parada. o Tiempo Delta time Indicar el tiempo transcurrido desde el inicio al tiempo de parada descontado el tiempo de interrupci1n. o "ase &notar la fase en la )ue est.s traba-ando. Use el nombre de cada fase. o omentarios

Descripci1n de la interrupci1n

BA

'a tarea )ue est.s haciendo ual)uier aspecto significativo )ue afecte a tu traba-o
Bec)a CFC Inicio CJ00 12J=0 2J=> ?J2> 10FC 11J0? Bin CJ>0 1J1A <J>< @J=> 12J1C ?O> 10 Tiempo Interrupcin deTiempo Delta Actividad >0 <A >A A0 ?2 Planeacin Dise9o Dise9o 8odi&icacin 8odi&icacin Pa9o7 tom, ca&, Tel,&ono 8omentarios

0a la 23: #Ae*plo 5o$ de 7e$istro

'$Q D% #%QIST#$ D% D%"% T$S

Ilustracin 42: #stndar tipos de Defectos I

AH

Ilustracin 43: #stndar 0ipo de Defectos II

o %ncabe3ado Indicar el nombre, fecha, instructor, * n?mero de programa. o "echa Indicar la fecha cuando encontraste * corregiste el defecto. o P?mero Indicar un n?mero ?nico para este defecto. omien3a cada pro*ecto con 5. o Tipo Indicar el tipo de defecto a partir del est.ndar de tipos de defectos. o Introducido Indicar la fase donde t? -u3gas )ue el defecto fue in*ectado o introducido. o %liminado Indicar la fase en la )ue encontraste * eliminaste el defecto. o Tiempo de &rreglo Indicar el tiempo )ue tomaste para corregir el defecto. T? puedes dar el tiempo e+acto o usar tu me-or estimaci1n. o Defecto &rreglado Si este defecto fue in*ectado durante la correcci1n de otro defecto, indicar el n?mero de ese defecto o una U si lo desconoces.

A5

o Pota Un defecto es cual)uier cosa en el programa )ue debe ser cambiado para )ue sea desarrollado, me-orado o utili3ado de manera adecuada. #%SU9%P D%' P'&P

Ilustracin 44: 7esu*en del &lan

o %ncabe3ado Pombre, fecha, programa, instructor, lengua-e. o Tama6o del Programa Plan: Indica tu me-or estimaci1n del tiempo total )ue tendr. el desarrollo. &ctual: Indica el tiempo actual en minutos gastado en cada fase. o Tiempo & la fecha: Indica el tiempo total gastado en cada fase hasta ho*. Para programa 5&, es el tiempo gastado en el programa 5&.

A;

& la fecha I: Indica el porcenta-e del total tiempo hasta ho* )ue se gast1 en cada fase. o Defectos introducidos * removidos: Indicar el n?mero actual de defectos in*ectados * eliminados en cada fase. o Defectos & la fecha: Indica el total de defectos in*ectados * eliminados en cada fase hasta ho*. Para el programa 5&, son los defectos in*ectados * eliminados en el programa 5&. & la fecha I: Indicar el porcenta-e sobre el total defectos in*ectados * eliminados hasta ho* en cada fase. .! TSP

'a versi1n inicial de la TSP fue desarrollado por (atts @umphre* en 5AAG, * el Informe T0cnico de TSP se public1 en noviembre de ;HHH * patrocinado por el Departamento de Defensa de %%.UU. %l libro de (atts @umphre*, ^Introducci1n al Proceso de %)uipo l1gico^ 7&ddison (esle* Professional, 9assachusetts, 5AAA8, presenta el TSP en detalle *, en particular, se centra en el proceso de construcci1n de un e)uipo de producci1n de software, el establecimiento de metas del e)uipo, la distribuci1n las funciones del e)uipo, * otras actividades relacionadas con el traba-o en e)uipo. TSP fue creado en 5AAB, por (atts @umphre* para dar una me-ora en la calidad de los servicios de software en los aspectos organi3acionales. Prosigue con las estrategias de calidad americanas iniciadas por D%99IPQ %P '& IPDUST#I& %P 5AB;,"&Q&P %P %' P#$ %S$ D% S( 5ABG,(. @U9P@#%/ S(, 99 5ABC,(. @U9P@#%/ S(, PSP 5AAF,(. @U9P@#%/ S(, TSP 5AAA. %l Team Software Process 7TSP8 es un proceso de desarrollo para e)uipos de ingenieros basado en 99i. %ste modelo es una continuaci1n de la 99 7 apabilit* 9aturit* 9odel8 *a )ue al igual )ue 0ste, trata de demostrar )ue es m.s productivo traba-ar con pr.cticas de ingeniera de software * tambi0n es ben0fico para su mantenimiento. & diferencia de otros m0todos= 9e-ora el desempe6o tanto de e)uipos como individuos. %s disciplinado * .gil. Provee beneficios inmediatos * medibles. &celera las iniciativas de me-ora de procesos organi3acionales. omo *a se mencion1 TSP es una metodologa para dirigir el traba-o de me-ora * desarrollo de software adem.s de )ue establece un entorno donde el traba-o efectivo de e)uipo es normal * natural. 'a estructura de dicho entorno se muestras en la siguiente tabla. TSP permite resolver problemas tpicos de negocio: predictibilidad de costo * tiempo, me-orar la productividad * los ciclos de desarrollo, as como me-orar la calidad de los productos. PSP/TSP me-oran el desempe6o tanto de e)uipos como individuosO es disciplinado * .gilO provee beneficios inmediatos * mediblesO acelera las iniciativas de me-ora de procesos organi3acionales. on TSP, los e)uipos encuentran * reparan defectos en etapas tempranas del proceso de desarrollo.

AD

%sto reduce de manera importante el tiempo de pruebas. on un testing m.s corto, el ciclo completo se reduce. .!.1 PROCESO

! '$ D% 2ID& D% TSP 7TSPI8 %s una serie de ciclos )ue inician con la declaraci1n de las necesidades del producto * terminan con la entrega del producto final & continuaci1n presentaremos una representaci1n gr.fica con diagramas de actividades de TSP en su versi1n educativa conocida como TSPi. "&S%S 'an3amiento %strategia Planeaci1n #e)uerimientos Dise6o Implementaci1n Prueba Postmortem

AE

Ilustracin 4": #structura 0S&

'&PR&9I%PT$ #evisi1n de ob-etivos a perseguir. &signaci1n de e)uipos * roles al personal. Se describen las necesidades del cliente. Se establece las metas individuales * del e)uipo.

%ST#&T%QI& rear un dise6o conceptual para el producto. Se establece la estrategia de desarrollo: se decide )ue ser. producido en cada ciclo. Se hacen estimaciones iniciales de esfuer3os * tama6o. Se establece un plan de administraci1n de la configuraci1n. Se reutili3a el plan anterior. Se establecen riesgos de administraci1n.

P'&P%&9I%PT$ %stima el tama6o de cada artefacto a ser desarrollado.

AF

Se identifican las tareas: se estima el tiempo para completar cada tareaO se asignan tareas a los miembros del e)uipo. @acer un cronograma semanal para tareas. Terminadas. @acer un plan de calidad.

#%LU%#I9I%PT$S Se anali3an las necesidades del cliente * se entrevistan. Se especifican los re)uerimientos. Se hace inspecci1n de los re)uerimientos. Se dise6a un plan de pruebas del sistema.

DIS%V$ Se crea un dise6o de alto nivel. Se especifica el dise6o. Se inspecciona el dise6o. Se desarrolla un plan de pruebas de integraci1n.

I9P'%9%PT& I$P Se usa PSP para implementar m1dulos * unidades. Se crea el dise6o detallado de los m1dulos * unidades. Se revisa el dise6o. Se convierte el dise6o al c1digo. Se inspecciona el c1digo Se compilan * prueban los m1dulos * unidades. Se anali3a la calidad de los m1dulos/unidades.

P#U%J&S Se constru*e e integra el sistema. Se llevan a cabo las pruebas del sistema. Se produce la documentaci1n de usuario.

P$ST9$#T%P

AG

&n.lisis de resultados. Se escribe el reporte del ciclo. Se produce producen evaluaciones de pares * e)uipo. .!.2 PRODUCTO .!.3 PERSONAL .!.4 TECNOLOGIA

.7

MS#

D%S #IP I$P %sta es una metodologa fle+ible e interrelacionada con una serie de conceptos, modelos * pr.cticas de uso, )ue controlan la planificaci1n, el desarrollo * la gesti1n de pro*ectos tecnol1gicos. 9S" se centra en los modelos de proceso * de e)uipo de-ando en un segundo plano las elecciones tecnol1gicas. 9S" es un compendio de las me-ores pr.cticas en cuanto a administraci1n de pro*ectos se refiere. 9.s )ue una metodologa rgida de administraci1n de pro*ectos, 9S" es una serie de modelos )ue puede adaptarse a cual)uier pro*ecto de tecnologa de informaci1n. %ste modelo es parecido 7pero no igual8 al #UP * es propiedad de 9icrosoft por lo )ue resulta un poco caro. '&S &#& T%#!STI &S &daptable "le+ible %scalable &gn1stico a tecnologas

$tra de las caractersticas de 9S" es )ue ha evolucionado con la e+periencia de grupo reales de traba-o )ue lo ha utili3ado desde 5AAD. omo resultado de esta e+periencia las guas se han simplificado, consolidado * verificado para obtener un frameworM )ue sea f.cil de entender * adoptar. 9S" utili3a ; modelos * D disciplinas. %stos son: 9$D%'$S 9odelo de %)uipo: %ste modelo ha sido dise6ado para me-orar el rendimiento del e)uipo de desarrollo. Proporciona una estructura fle+ible para organi3ar los e)uipos de un pro*ecto. Puede ser escalado dependiendo del tama6o del pro*ecto * del e)uipo de personas disponibles. 9odelo de Proceso: Dise6ado para me-orar el control del pro*ecto, minimi3ando el riesgo, * aumentar la calidad acortando el tiempo de entrega. Proporciona una

AC

estructura de pautas a seguir en el ciclo de vida del pro*ecto, describiendo las fases, las actividades, la liberaci1n de versiones * e+plicando su relaci1n con el 9odelo de e)uipo. DIS IP'IP&S Disciplina de Qesti1n de #iesgos: Dise6ada para a*udar al e)uipo a identificar las prioridades, tomar las decisiones estrat0gicas correctas * controlar las emergencias )ue puedan surgir. %ste modelo proporciona un entorno estructurado para la toma de decisiones * acciones valorando los riesgos )ue puedan provocar. Disciplina de Qesti1n de Pro*ectos: %s una disciplina )ue describe el rol de la gesti1n del pro*ecto dentro del modelo de e)uipo de 9S", * como permite ma*or escalabilidad, desde pro*ectos pe)ue6os a pro*ectos largos * comple-os. Disciplina de Qesti1n de la Disposici1n %sta disciplina describe a)uellos conocimientos, aptitudes * habilidades )ue son necesarias para planificar, desarrollar * gestionar soluciones satisfactorias. .7.1 PROCESO

Ilustracin 4%: &roceso de MSC

"&S% 5 _ 2ISI$P 72IS$P / &' &P % &P#$J&D$S8

AB

$btener una visi1n del pro*ecto compartida, comunicada, entendida * alineada con los ob-etivos del negocio. &dem.s, identificar los beneficios, re)uerimientos funcionales, sus alcances * restriccionesO * los riesgos inherentes al proceso. 'a fase de estrategia * alcances trata uno de los re)uisitos m.s fundamentales para el 0+ito del pro*ecto, la unificaci1n del e)uipo detr.s de una visi1n com?n. %l e)uipo debe tener una visi1n clara de lo )ue )uisiera lograr para el cliente * ser capa3 de indicarlo en t0rminos )ue motivar.n a todo el e)uipo * al cliente. Se definen los lderes * responsables del pro*ecto, adicionalmente se identifican las metas * ob-etivos a alcan3arO estas ?ltimas se deben respetar durante la e-ecuci1n del pro*ecto en su totalidad, * se reali3a la evaluaci1n inicial de riesgos del pro*ecto. "&S% ; _ P'&P%& I$P 7P'&P D% P#$/% T$ &P#$J&D$8

%s en esta fase es cuando la ma*or parte de la planeaci1n para el pro*ecto es terminada. %l e)uipo prepara las especificaciones funcionales, reali3a el proceso de dise6o de la soluci1n, * prepara los planes de traba-o, estimaciones de costos * cronogramas de los diferentes entregables del pro*ecto. "&S% D _ D%S&##$''$ 7&' &P % $9P'%T$8

%sta fase es durante la cual el e)uipo constru*e * prueba la soluci1n. %sta fase inclu*e el c1digo, la infraestructura * la documentaci1n )ue se entregar.. "&S% E _ %ST&JI'IR& ISP 72%#SI$P& &P#$J&D&8

'a soluci1n implantada en la ma)ueta se pasa a un entorno real de e+plotaci1n, restringido en n?mero de usuarios * en condiciones tales )ue se pueda llevar un control efectivo de la situaci1n. "&S% F _ I9P'%9%PT& I$P 7%PT#%Q&8

Se llevar.n a cabo en esta fase los planes dise6ados en la anterior, principalmente el de despliegue * el de formaci1n. 'os principales traba-os e hitos a conseguir son, en este caso, adem.s de los obvios 7implantaci1n de la plataforma, puesta en servicio de todas las funciones, formaci1n a los usuarios * administradores8. .7.2 PRODUCTO "&S% 5 _ 2ISI$P 72IS$P / &' &P % &P#$J&D$S8 o Documento 2isi1n &ntecedentes * 2isi1n riterios de dise6o o Documento Detalle de 2isi1n Jeneficios, metas, ob-etivos, restricciones Perfiles de usuario

AA

asos de uso #e)uerimientos funcionales, no funcionales #e)uerimientos del sistema Plan de instalaci1n &r)uitectura l1gica 7Diagrama de componentes U9'8 &r)uitectura "sica 7Diagrama de despliegue U9'8 o Documento #e)uerimientos "uncionales Descripci1n detallada de los re)uerimientos * caractersticas )ue componen cada caso de uso descrito en el Documento Detalle de la 2isi1nO indicando perfiles asociados, recursos del e)uipo de pro*ecto, riesgos, observaciones * script de pruebas. o Documento 9atri3 de #iesgos Identifica posibles riesgos acerca de los re)uerimientos * las acciones a tomar en cada escenario. o &cta de &probaci1n de 2isi1n "&S% ; _ P'&P%& I$P 7P'&P D% P#$/% T$ &P#$J&D$8 o Documento de ronograma o &cta de &probaci1n de ronograma "&S% D _ D%S&##$''$ 7&' &P % $9P'%T$8 o "uentes * %-ecutables 7Seg?n lo acordado8 o Documentos 9anuales t0cnicos, de Usuario * de Instalaci1n si es necesario. o &cta de finali3aci1n de Desarrollo "&S% E _ %ST&JI'IR& ISP 72%#SI$P& &P#$J&D&8 o Documento de #egistro de Pruebas o &cta de &probaci1n de 2ersi1n &probada "&S% F _ I9P'%9%PT& I$P 7%PT#%Q&8 o on-unto de &rchivos 7e-ecutables, directorios, archivos varios, bases de datos, script, instaladores, manuales, licencias, entre otros 8 propios del producto )ue permitan su instalaci1n * correcto funcionamiento.

o &cta de entrega * de finali3aci1n del pro*ecto

5HH

.7.3 PERSONAL %l e)uipo 9S" tiene G roles.%s un modelo P$ -er.r)uico por lo )ue se considera )ue cada rol tiene la misma importancia en su contribuci1n al pro*ecto. Se representa con un diagrama circular. &un)ue en ciertas fases unos roles tiene m.s actividades )ue otros nunca se debe obviar ninguno de los roles. 'a comunicaci1n se encuentra en el centro del diagrama por)ue se considera )ue es parte integral del modelo. Diagrama del modelo:

Ilustracin 4': #scala de #1uipos

[LUK %S %S &'& D% %LUIP$S\ %l 9odelo de e)uipo de 9S" contiene G roles pero en ocasiones un grupo de traba-o es m.s o menos grande. %ste modelo es tan fle+ible )ue permite incrementar 7Scale Up8 o disminuir 7Scale Down8 el n?mero de personas en un grupo. S &'% UP: en el Scale Up es posible asignar un grupo de personas a un solo rol.

%l siguiente diagrama muestra un e-emplo de Scale Up el cual tiene un grupo lder )ue tiene todos los roles de 9S". Ja-o el grupo lder e+isten dos grupos funcionales. 'os grupos funcionales no cuentan con los roles de Qerencia de Producto * Puesta en

5H5

$peraci1n pues as lo indican las guas de 9S". ada grupo funcional tiene asignado completar una parte de la soluci1n.

Ilustracin 4): Scale ;p

S &'% D$(P: el Scale Down permite asignar varios roles a una misma persona pero limita los roles )ue se pueden unir para mantener la calidad de la soluci1n. 'a siguiente tabla muestra )ue roles es posible fusionar * cu.les no son recomendados.
4erencia de Producto 4erencia de proyecto N N N N Desarrollo Pruebas -1periencia Hsuario P I N de Puesta .peracin I P N en

4erencia Producto 4erencia proyecto Desarrollo

de de

N N

P I N

5H;

Pruebas -1periencia de Hsuario Puesta .peracin en

P P I

I I P

N N N P P

P I

0a la 24: 7oles 1ue son &osi les Cusionar ! 7oles no 7eco*endados

Ilustracin 4+: #Ae*plo de los 7oles en Scale Down

."

ASD

<&daptive Software Development : Desarrollo De Software &daptable> D%"IPI I$P 9etodologa desarrollada por Nim @ighsmith, despu0s de traba-ar muchos a6os con metodologas predictivas, conclu*o )ue son defectuosas. 9etodologa sin muchas ataduras * reglas a seguir, es la metodologa mas abierta. 'as personas deben colaborar de la me-or manera, para dar respuesta * soluciones creativas. %l m0todo .gil &SD Desarrollo &daptable de Software es un modelo de implementaci1n para desarrollo de software. &l igual )ue otras metodologas .giles, su funcionamiento es cclico * reconoce )ue en cada iteraci1n se producir.n cambios e incluso errores Se define como una metodologa se adapta al cambio en lugar de luchar contra 0l. Se basa en la adaptaci1n continua a circunstancias cambiantes. %n ella no ha* un ciclo de planificaci1n:dise6o: construcci1n del software, sino un ciclo especular:colaborar: aprender. Principales caractersticas del &SD son: Iterativo, $rientado a los componentes de software, Tolerante a los cambios, Quiado por los riesgos * 'a revisi1n de los componentes sirve para aprender de los errores * volver a iniciar el ciclo de desarrollo %ntre sus venta-as podemos encontrar )ue sirve para aprender de los errores * volver a iniciar el ciclo de desarrollo, utili3a informaci1n disponible acerca de cambios para me-orar el comportamiento del software * promulga colaboraci1n, la interacci1n de personas.

5HD

/ como desventa-as los errores o cambios )ue no son detectados en reuniones anteriores a tiempo, afecta la calidad del producto * a su costo total, dado a )ue es una metodologa .gil implica no reali3ar procesos )ue son re)ueridos en las metodologas tradicionales. &#& T%#ISTI &S Principales caractersticas del &SD son: Iterativo $rientado a los componentes de software Tolerante a los cambios Quiado por los riesgos 'a revisi1n de los componentes sirve para aprender de los errores * volver a iniciar el ciclo de desarrollo .".1 PROCESO &SD es un marco de desarrollo cu*o ob-etivo es acabar con el problema )ue supone la velocidad de desarrollo re)uerida * los cambios )ue se dan a lo largo del ciclo de vida del desarrollo del software. &SD propone utili3ar el ciclo de vida de la Ilustraci1n ;;, %specular: olaborar:&prender. %ste proceso permite pe)ue6as desviaciones en un sentido _ por lo )ue @ighsmith sugiere )ue cada ciclo se componga de una me3cla entre funcionalidades crticas, ?tiles * opcionales, en donde deben priori3arse las crticas *a )ue son las )ue ponen en -a)ue el pro*ecto, luego las ?tiles, )ue facilitaran el desarrollo del sistema * por ?ltimo las opcionales las cuales no son imprescindibles en el pro*ecto. Todo esto con tal de prever futuros retrasos en el pro*ecto.

Ilustracin "-: #l Ciclo de Vida /daptativoD 0o*ada de E:i$(s*it(. 2---F

5HE

Ilustracin "1: /ctividades del Ciclo de Vida /daptativoD 0o*ada de E:i$(s*it(. 2---F

%SP% U'&#:

Se lleva a cabo la planificaci1n tentativa del pro*ecto en funci1n de las entregas )ue se ir.n reali3ando. 'a utili3aci1n del verbo %specular demuestra el inter0s de @ighsmith en demostrar la naturale3a impredecible de los sistemas comple-os. %n esta etapa se fi-a un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento )ue no ser. el lugar en )ue finali3ar. el pro*ecto. %n cada iteraci1n, se aprender.n nuevas funcionalidades, se entender.n vie-as cuestiones, * cambiar.n los re)uerimientos. #especto a la especulaci1n, se recomienda reali3ar un component breaMdown structure en ve3 del mu* conocido * tradicional worM breaMdown structure 7(JS8 en el cual mediante una grilla u ho-a de c.lculo se pueda conocer la funcionalidad a ser liberada en cada ciclo. %n la iniciaci1n del pro*ecto se define la misi1n del pro*ecto. '& 9ISISP D%' P#$/% T$ 'a misi1n inclu*e ob-etivos, re)uisitos de alto nivel * restricciones del producto. Para escribir la misi1n se dan tres pasos: a8 Identificar la 9isi1n Debe ser concreta, * sin embargo invitar a pensar en distintos escenarios de aplicaci1n. Debe ser directa * definir el alcance del esfuer3o, no detallar el resultado final. %stablece un marco de referencia para la toma de decisiones en el pro*ecto. %l -efe de pro*ecto debe establecer prioridades para facilitar el alcance de los ob-etivos. b8 rear los componentes de la 9isi1n Se refiere al desarrollo de los documentos )ue componen la misi1n. Deben responder a tres preguntas. [De )u0 trata el pro*ecto\ [Por )u0 ha* )ue llevarlo a cabo\ [ 1mo se debera llevar a cabo\

'os componentes m.s importantes de la misi1n son:

5HF

&#T& D% 2ISISP D%' P#$/% T$: ofrece una corta definici1n 7de ; a 5H p.ginas8 de los ob-etivos de negocio, especificaciones del producto * posicionamiento en el 9ercado. Debe contener: &ntecedentes del pro*ecto Identificaci1n de la visi1n del pro*ecto &lcance del pro*ecto Patrocinadores Posici1n en el mercado lientes e+ternos e internos $b-etivos de negocio $b-etivos funcionales #iesgos del pro*ecto #e)uisitos de plantilla Pro*ectos dependientes #estricciones &sunciones

T&J'& D% D&T$S D%' P#$/% T$: es una ho-a donde se resumen los beneficios m.s importantes, las especificaciones del producto * la informaci1n para la gesti1n del pro*ecto. %sta ho-a inclu*e: lientes $b-etivo del pro*ecto resumido en una frase "uncionalidades Jeneficios para el cliente &tributos de calidad &r)uitectura #iesgos @itos 9iembros del pro*ecto

5HG

%SP% I"I & I$P%S D%' P#$DU T$: #ecoge todas las funcionalidades, ob-etos, datos operaciones * otra informaci1n relevante sobre el producto a alto nivel. ontiene: "uncionalidades estrat0gicas "uncionalidades competitivas aractersticas para la satisfacci1n del cliente

c8 2alores compartidos de la 9isi1n %+isten determinados atributos )ue garanti3an )ue la misi1n guiar. al e)uipo de desarrollo durante todo el pro*ecto: %l e)uipo de desarrollo traba-a -unto para desarrollar los componentes de la misi1n. %s una actividad continua. 'a ho-a de datos del pro*ecto est. visible en el puesto de traba-o del e)uipo de desarrollo 7en la pared por e-emplo8 * todos los documentos del pro*ecto est.n disponibles. %sto a*uda a recordar la visi1n del pro*ecto. uando ha* )ue tomar una decisi1n o resolver un problema, se consultan los componentes de la misi1n.

P'&P &D&PT&J'% D%' I '$ D% 2ID& %l desarrollo adaptable se da en ciclos o iteraciones durante las cuales se constru*en los componentes planificados para ese ciclo * los componentes )ue sur-an en ese ciclo. 'as fases de un ciclo adaptable son las siguientes: "&S% D% IPI I$ D%' P#$/% T$. %l ob-etivo de esta fase es establecer las e+pectativas del pro*ecto de parte de todos los grupos implicados. %n esta fase se redacta la misi1n del pro*ecto. Durante esta fase se reali3an las siguientes actividades: %l patrocinador establece el ob-etivo del pro*ecto * una idea apro+imada del alcance, calendario * recursos necesarios. %l cliente identifica ob-etivos de negocio * datos )ue deben ser incluidos, coste * beneficios. 'os desarrolladores identifican las funcionalidades del producto. D%T%#9IP&# '& DU#& ISP D%' P#$/% T$ 7TI9%:J$U8. Se estima la duraci1n del pro*ecto * el esfuer3o en base a buenas pr.cticas de estimaci1n como por e-emplo function:point. D%T%#9IP&# %' Pf9%#$ SPTI9$ D% I '$S / '& DU#& ISP D% &D& UP$ D% %''$S. ada ciclo debe durar entre E * B semanas para un pro*ecto de menos de A meses. Si el pro*ecto es m.s largo ser.n de G a 5H semanas. 'os dos primeros ciclos ser.n m.s cortos para confirmar )ue se ha definido bien.

5HC

%S #IJI# %' $JN%TI2$ D%' I '$. Para cada ciclo se escribe una frase con el ob-etivo del mismo. Para ello se basan en el ob-etivo del pro*ecto, los riesgos * la lista de componentes. &SIQP&# $9P$P%PT%S & '$S I '$S. Un componente debe ser asignado a un ciclo en el )ue se desarrollar.. &SIQP&# T% P$'$Q!& / $9P$P%PT%S D% S$P$#T% & &D& I '$. %l pro*ecto debe producir, adem.s del c1digo, otros documentos e instalar componentes tecnol1gicos necesarios para el desarrollo. %volucionar.n a lo largo de los distintos ciclos. D%"IPI# '& 'IST& D% T&#%&S D%' P#$/% T$. %s ?til a6adir tareas con detalle adicional a las listas de los componentes. @a* tareas ocasionales )ue no se relacionan con ning?n componente. $'&J$#&#:

%s a)uella en la )ue se constru*e la funcionalidad definida durante la especulaci1n. &SD define un omponente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteraci1n el e)uipo colabora intensamente para liberar la funcionalidad planificada. Tambi0n, e+iste la posibilidad de e+plorar nuevas alternativas, reali3ar pruebas de concepto, pudiendo eventualmente alterar el rumbo del pro*ecto profundamente. &SD no propone t0cnicas ni prescribe tareas al momento de llevar a cabo la construcci1n simplemente mencionando )ue todas las pr.cticas )ue sirvan para refor3ar la colaboraci1n ser.n preferidas, siguiendo de esta forma la lnea de las metodologas .giles respecto a la orientaci1n a componentes. %l 0nfasis se ubica en la relaciones entre las personas )ue deben estar lo suficientemente lubricadas para generar una propiedad imprescindible de los organismos comple-os: emergencia. 'a emergencia es una propiedad de los sistemas adaptativos comple-os )ue crea alguna propiedad m.s grande del todo 7comportamiento del sistema8 a partir de la interacci1n entre las partes 7comportamiento auto:organi3ativo de los agentes8. Qracias a esta propiedad los grupos de desarrollo logran sacar lo me-or de s en la el borde del caos. 'a colaboraci1n es activa, re)uiere participaci1n * traba-o en e)uipo. 'os miembros del e)uipo deben dares apo*o mutuamente. #alph Stace* 7Stace* AG8 define F par.metros de control o caractersticas )ue determinan )ue un e)uipo es colaborativo: #&TI$ D% IP"$#9& ISP. %st. relacionado con la velocidad, no con la densidad con la )ue flu*e la informaci1n. Po solo es transferencia de informaci1n, sino con el valor a6adido de la colaboraci1n activa. Q#&D$ D% DI2%#SID&D. 'a diversidad puede ser en cuanto a: conocimientos t0cnicos, diferencias raciales o culturales, e+periencia, car.cter de los componentes del e)uipo. & ma*or diversidad ma*or enri)uecimiento en el dise6o de productos competitivos. Sin embargo se dificulta tambi0n el proceso de crear un entorno colaborativo.

5HB

#ILU%R& D% '& $P% TI2ID&D. Se refle-a en el n?mero de cone+iones entre los miembros del e)uipo * el flu-o de datos. Si aumenta el n?mero de grupos interconectados aumenta la diversidad de la informaci1n. Pocas cone+iones provocan estancamiento * demasiadas provocan inestabilidad. 'a conectividad depende tanto del conte+to como del contenido. %l contenido proviene de los datos mientras )ue el conte+to viene de la e+periencia )ue a*uda a interpretar * entender los datos. PI2%' D% &PSI%D&D. 'a ansiedad contribu*e a la creatividad del e)uipo. Q#&D$ D% P$D%#. 'a introducci1n de la participaci1n * autoridad como pr.cticas de gesti1n parece eliminar el poder como herramienta de gesti1n. #%SP%T$ 9UTU$. #espetar a los dem.s por s mismos * por sus contribuciones. 'IJ#% P&#TI IP& ISP. 'a efectividad de los e)uipos abiertos, colaborativos me-ora cuando la participaci1n es libre. Po es s1lo dar a la gente una oportunidad para e+presarse, es un compromiso por parte de todos los miembros del e)uipo de intentar comprender a los dem.s. $9P#$9IS$. 'os miembros del e)uipo colaborativo se comprometen con los ob-etivos del pro*ecto * a traba-ar -untos * comparten la responsabilidad de lo )ue ocurra en el pro*ecto. &P#%PD%#:

onsiste en la revisi1n de calidad )ue se reali3a al final de cada ciclo. %n la misma se anali3an cuatro categoras de cosas para aprender Y@ighsmith, ;HHHZ: alidad del resultado de la desde la perspectiva del cliente alidad del resultado de la desde la perspectiva t0cnica %l funcionamiento del e)uipo de desarrollo * las pr.cticas )ue este utili3a %l status del pro*ecto Para evaluar la calidad desde el punto de vista del cliente se sugieren utili3ar grupos de enfo)ue en el cliente, mediante los cuales se e+plora un modelo de la aplicaci1n * se anotan los re)uerimientos de cambio del cliente. on respecto a alidad del resultado de la desde la perspectiva t0cnica, las revisiones al dise6o, al c1digo o a las pruebas permitir.n aprender sobre la calidad de los mismos. %n este caso, el 0nfasis estar. puesto en aprender cuales han sido los errores o desvos * poder resolverlos, * no en encontrar culpables. &simismo, est. es la etapa en )ue se evaluar.n las e+ploraciones )ue se ha*an reali3ado dando la capacidad de poder modificar la ar)uitectura del sistema si se ha encontrado alg?n camino )ue se a-usta me-or a lo )ue necesita el usuario o si han cambiado los re)uerimientos. %l tercer proceso de feedbacM est. relacionado con la interacci1n entre las partes, la din.mica de grupo, * las t0cnicas empleadas. Para medir la performance * el grado de cohesi1n del mismo, se podr.n reali3ar al final de cada ciclo pe)ue6as reuniones de postmortem. %n las mismas se discuten los aspectos del proceso )ue contribu*en al desarrollo * a)uellos )ue deben ser descartados por su influencia negativa.

5HA

%n relaci1n al status del pro*ecto, se reali3ar.n revisiones para determinar el estado del mismo en relaci1n a lo planificado. %n este momento, se detectar.n posibles diferencias )ue pueden surgir de la e+ploraci1n * )ue cambiar.n el rumbo a )ue apuntaba el pro*ecto. %n la siguiente ilustraci1n se puede ver el detalle interno de cada fase como *a fue e+plicado, mostr.ndose con una flecha )ue trasciende las tres fases en sentido inverso, el bucle de aprendi3a-e. %ste bucle es algo crtico para &SD *a )ue denota un cambio en el es)uema tradicional de la vista de un sistema en )ue se tena un bucle de control para detectar diferencias * corregirlas. %s decir, en las metodologas tradicionales las diferencias respecto a lo planificado eran vistas como errores )ue deban ser enmendados para )ue cumplieran lo pautado. &SD * las metodologas .giles plantean la necesidad de )ue el feedbacM necesario sea para aprender, nos da la posibilidad de entender m.s respecto al dominio * construir la aplicaci1n )ue me-or satisfaga las necesidades del cliente. @ighsmith lo e+pone claramente en la siguiente frase: %n ambientes comple-os, el seguir un plan al pie de la letra produce el producto )ue pretendamos, pero no el producto )ue necesitamos.

Ilustracin "2: /ctividades de /SD

.".2 PRODUCTO 'a regla a seguir es no producir documentos a menos )ue sean necesarios de forma inmediata para tomar una decisi1n importante, deben ser cortos * centrarse en lo fundamental. %n caso de integraci1n de un nuevo integrante al e)uipo de traba-o, las herramientas )ue le van a servir para ponerse al da son el c1digo * la interacci1n con el e)uipo.

55H

Si bien es sabido )ue las metodologas .giles no tienen mucha ceremonia en &SD se entregan dos tipos de documentos: %n el primero se inclu*e una visi1n del pro*ecto, una ho-a de datos, un perfil de la misi1n del producto * un es)uema de su re)uerimiento, este se entrega cuando el e)uipo tiene una idea general de lo )ue tratar. el sistema para poder reali3ar la iniciaci1n del pro*ecto 7%l cual se describe en la secci1n anterior )ue se refiere a la 9isi1n del Pro*ecto8. %n el segundo se entrega una descripci1n del sistema el cual es un Documento orientado al cliente )ue describe las caractersticas del sistema desde el punto de vista del usuario final. %l documento se utili3a para coordinar con-untamente los ob-etivos del sistema del usuario, cliente, desarrollador e intermediarios. Tambi0n se denomina: on$ps 7 oncept of $peration std. I%%% 5DG;8. #e)uisitos del sistema 7IS$ I% 5;;HC 5AAF, F.5.5.;8, esta se entrega al finali3ar el pro*ecto para anali3ar el software con-untamente con el usuario. .".3 PERSONAL 'os roles * responsabilidades ser.n: lientes: %ste rol -uega un papel mu* importante, *a )ue este ser. parte activa del e)uipo de traba-o, aportando * funcionalidades al sistema. &dem.s es esencial para el 0+ito del mismo, *a )ue un software )ue no tiene aceptaci1n dentro de la organi3aci1n -am.s llegara a ser construido a tiempo, forma * con consentimiento de los usuarios. 'der del pro*ecto: Tiene a cargo la planificaci1n del pro*ecto a lo largo de todo el ciclo de vida, asigna recursos * delega responsabilidades en los mismosO fomenta la uni1n del grupo haciendo actividades destinadas a eliminar roces dentro de este, adem.s monitorea el progreso del pro*ecto * establece estrategias para mitigar los riesgos )ue puedan presentarse dentro del desarrollo. %l lder del pro*ecto representa la cara visible del e)uipo de desarrollo, vendra siendo como un ne+o entre cliente * el e)uipo desarrollo. Programador: Tiene a cargo la codificaci1n de los componentes a desarrollar en cada iteraci1n, el posee los materiales * lleva a cabo la implementaci1n de los re)uerimientos capturados. Desarrolladores: Tiene a cargo la construcci1n l1gica del software * la continua refinaci1n de la misma en cada iteraci1n. %star. a cargo de la creaci1n de la interfa3 del software. Tester: Tiene a su cargo la generaci1n de pruebas al sistema a partir de los re)uerimientos e+trados * anali3ados. 'a importancia radica en la necesidad de construir un software de calidad )ue cumpla con los re)uerimientos del usuario. .".4 TECNOLOGIA %n todo pro*ecto, si bien la parte de planificaci1n * especulaci1n es importante, tambi0n tenemos la parte de tecnologa )ue es casi la m.s importante *a )ue esta condicionara procesos del desarrollo del sistema. Ser. la )ue se llevar. a la pr.ctica en el momento de presentar el producto final * en donde se traba-ar. en base a los re)uerimientos anteriormente capturados al cliente.

555

T% P$'$Q!& D%' S$"T(&#% Para &SD la tecnologa m.s usada * m.s efectiva a la hora de programar * reali3ar el pro*ecto es la orientada a ob-etos *a )ue ho* en da *a no se aplica solamente a los lengua-es de programaci1n, adem.s se viene aplicando en el an.lisis * dise6o con mucho 0+ito. %s )ue para hacer una buena programaci1n orientada a ob-etos ha* )ue desarrollar todo el sistema aplicando esta tecnologa, de ah la importancia del an.lisis * el dise6o orientado a ob-etos. %n cuanto a la programaci1n, la orientada a ob-etos 7P$$8 es una de las formas m.s populares de programar * viene teniendo gran acogida en el desarrollo de pro*ectos de software desde los ?ltimos a6os. %sto se debe a sus grandes capacidades * venta-as frente a las antiguas formas de programar. 'uego de esta introducci1n surge la pregunta: [ u.les son las venta-as de un lengua-e orientado a ob-etos\ 'as venta-as m.s importantes son las siguientes: "omenta la reutili3aci1n * e+tensi1n del c1digo. Permite crear sistemas m.s comple-os. #elacionar el sistema al mundo real. "acilita la creaci1n de programas visuales. onstrucci1n de prototipos &gili3a el desarrollo de software "acilita el traba-o en e)uipo "acilita el mantenimiento del software

'o interesante de la P$$ es )ue proporciona conceptos * herramientas con las cuales se modela * representa el mundo real tan fielmente como sea posible * m.s importante a?n, se adapta perfectamente a la metodologa de desarrollo &SD tomando en cuenta )ue el agili3ar el desarrollo de software * la construcci1n de prototipos, por nombrar algunas caractersticas, es propio de las metodologas .giles. Dentro de la tecnologa de software distinguimos las siguientes la plataforma, el lengua-e * el sistema operativo. on respecto a la Plataforma el grupo de traba-o debe poder elegir la m.s adecuada para satisfacer las necesidades * compatibili3ar esto con el lengua-e de programaci1n )ue se usar. para dar soluci1n a los re)uerimientos del cliente. @a* una buena variedad de lengua-es de programaci1n orientados a ob-etos )ue se adaptan perfectamente a las metodologas .giles. %l sistema operativo en donde se e-ecutar. el pro*ecto ser. el cual el cliente pida * el grupo de traba-o debe ser capa3 de lograr reali3arlo * e-ecutarlo ba-o el S$ deseado. TK PI &S / @%##&9I%PT&S

55;

%sta metodologa no propone t0cnicas ni tareas al momento de llevar la construcci1n, simplemente ocuparemos las pr.cticas )ue sirvan para refor3ar el desarrollo del sistema., siguiendo de esta forma la lnea de las metodologas .giles respecto a la orientaci1n a componentes. %l 0nfasis se ubica en las relaciones entre las personas, las cuales deben estar lo suficientemente buenas para lograr sacar lo me-or, si estamos en momentos crticos del desarrollo. %n la fase de la especulaci1n, se recomienda utili3ar un omponent JreaMdown Structure 7 JS8 en el cual mediante una grilla u ho-a de c.lculo se pueda conocer la funcionalidad )ue ser. entregada en cada ciclo desarrollado. $tra t0cnica )ue se recomienda son las sesiones N&D para capturar los re)uerimientos del software * la reali3aci1n de prototipos para descifrar ambiggedades )ue se presenten en el desarrollo. &lgunas de las t0cnicas de planificaci1n * de control de actividades m.s empleadas en las metodologas de desarrollo son la carta Qantt * el diagrama Pert. 'as herramientas para emplear las t0cnicas mencionadas tienen )ue ser las )ue me-or se adapten o en las )ue me-or dominio se tenga. .". GLOSARIO

&daptabilidad. "acilidad con la )ue un sistema o un componente pueden modificarse para corregir errores, me-orar su rendimiento u otros atributos, o adaptarse a cambios del entorno. &n.lisis de re)uisitos. 758 Proceso de estudio de las necesidades del usuario para conseguir una definici1n de los re)uisitos del sistema o del software. 7;8 Proceso de estudiar * desarrollar los re)uisitos del sistema o del software. iclo de vida. Periodo de tiempo )ue comien3a con la concepci1n del producto de software * termina cuando el producto est. disponible para su uso. Pormalmente, el ciclo de vida del software inclu*e las fases de concepto, re)uisitos, dise6o, implementaci1n, prueba, instalaci1n, verificaci1n, validaci1n, operaci1n * mantenimiento *, en ocasiones, retirada. Pota: %sta fases pueden superponerse o reali3arse iterativamente. Dise6o de ar)uitectura. 758 Proceso )ue define una colecci1n de componentes de software * hardware -unto con sus interfaces, para definir el marco de desarrollo de un sistema. 2er tambi0n: dise6o funcional. 7;8 %l resultado del proceso de 758. Dise6o funcional. 758 Proceso de definici1n de las relaciones de traba-o entre los componentes de un sistema. 7;8 %l resultado del proceso 758 %mergencia. %s una propiedad de los sistemas adaptativos comple-os )ue crea alguna propiedad m.s grande del todo a partir de la interacci1n de las partes. Qracias a esta propiedad los grupos de desarrollo logran sacar lo me-or de s en el borde del caos. N&D: taller en el )ue programadores * representantes del cliente se encuentran para discutir rasgos del producto en t0rminos no t0cnicos, sino de negocios.

55D

9antenimiento. 758Proceso de modificaci1n de un sistema de software o de un componente, despu0s de su puesta en funcionamiento para corregir fallos, me-orar el rendimiento u otros atributos, o adaptarlo a modificaciones del entorno. 7;8 Proceso primario del modelo de ingeniera )ue desarrolla tareas de mantenimiento 758. 9odelo de ciclo de vida. #epresentaci1n del ciclo de vida del software. $btenci1n. 7&plicado a re)uisitos8. Proceso en el )ue se implican las partes cliente * desarrolladora para descubrir, revisar, articular * comprender las necesidades * limitaciones )ue el sistema debe ofrecer a los usuarios. P%#T. 7Program %valuation and #eview Techni)ue8 90todo para el control de los tiempos de e-ecuci1n de diversas actividades integrantes de pro*ectos. "ue desarrollado en 5AFC por la armada de los %stados Unidos. &ctualmente se utili3an sus principios en combinaci1n con los del m0todo P9 en lo )ue se conoce como P%#T/ P9 Prototipo. 2ersi1n preliminar de un sistema )ue sirve de modelo para fases posteriores. #apid &pplication Development. 7#&D8 Denominaci1n gen0rica para t0cnicas * herramientas de desarrollo de software )ue permiten el desarrollo r.pido de aplicaciones. #e)uisito. 758 ondici1n o facultad )ue necesita un usuario para resolver un problema. 7;8 ondici1n o facultad )ue debe poseer un sistema o un componente de un sistema para satisfacer una especificaci1n, est.ndar, condici1n de contrato u otra formalidad impuesta documentalmente. 7D8 Documento )ue recoge 758 o 7;8. @ito: Un hito es lo )ue se espera )ue est0 hecho para alguna fecha, como por e-emplo, un m1dulo testeado o una caracterstica del funcionamiento, un logro )ue sea ob-etivo, f.cil de evaluar * notable. Deben e+istir al menos dos hitos en el pro*ecto entre el dise6o preliminar * el pla3o final de entrega. 'a divisi1n del traba-o debera ser e)uitativa. 7#esulta m.s ?til combinar los hitos * la asignaci1n de tareas dentro de una ?nica tabla )ue contenga las columnas tarea, )ui0n * cu.ndo, en lugar de especificar los hitos * la asignaci1n de tareas en dos documentos distintos )ue no guardan relaci1n8. #DD

.$

"eature Driven Development 7Desarrollo Jasado en "uncionalidades8 es un proceso .gil para el desarrollo de sistemas. "ue dise6ado por Peter oad, %ric 'efebvre * Neff De'uca. %n "DD no se hace 0nfasis en la obtenci1n de los re)uerimientos sino en c1mo se reali3an las fases de dise6o * construcci1n preocup.ndose por la calidad, por lo )ue inclu*e un monitoreo constante del pro*ecto. "DD Se basa en un proceso iterativo, con iteraciones cortas )ue producen un software funcional )ue el cliente * la direcci1n de la empresa pueden ver * monitorear. Define claramente entregas tangibles * formas de evaluaci1n del progreso del pro*ecto.

55E

.$.1 PROCESO %l proceso "DD consiste de cinco pasos secu0nciales durante los cuales se dise6a * se constru*e el sistema: Desarrollo de un modelo global. onstrucci1n de una lista de funcionalidades. Planeaci1n por funcionalidad. Dise6o por funcionalidad. onstrucci1n por funcionalidad.

Ilustracin "3: Cases del CDD

D%S&##$''$ D% UP 9$D%'$ Q'$J&' omo entrada a este proceso el cliente debe estar listo para comen3ar con la construcci1n del sistema. &dem.s se debe tener una lista de re)uerimientos especificada en alguna forma, hecha por los e+pertos del dominio. uando comien3a el proceso, los e+pertos del dominio est.n al tanto de la visi1n, el conte+to * los re)uerimientos del sistema a construir. Se divide el dominio global en .reas )ue son anali3adas detalladamente * los desarrolladores constru*en un diagrama de clases o de ob-etos por cada .rea. & su ve3 se constru*e un modelo global del sistema. %sta etapa termina con el desarrollo del diagrama de clases global del sistema, una lista de funcionalidades o caractersticas, * un modelo global del sistema a construir. $PST#U ISP D% UP& 'IST& D% "UP I$P&'ID&D%S

Una funcionalidad se define como un tem ?til a los o-os del cliente. Jasado en el modelo global obtenido en la etapa anterior, * en la lista de funcionalidades informal, se procede a elabora una lista de funcionalidades )ue resuma la funcionalidad general del sistema. Dicha lista debe ser elaborada por los desarrolladores * es evaluada por el cliente.

55F

Se divide la lista en subcon-untos seg?n la afinidad * la dependencia de las funcionalidades. 'uego la lista es finalmente revisada por los usuarios * los responsables para su validaci1n * aprobaci1n. P'&P%& ISP P$# "UP I$P&'ID&D %n este punto se procede a ordenar los con-untos de funcionalidades conforme a su prioridad * dependencia, * se asigna a los programadores -efes. Tambi0n se debe generar un cronograma donde se especifi)ue la duraci1n del dise6o * la construcci1n de cada una de las caractersticas. DIS%V$ P$# "UP I$P&'ID&D%S "UP I$P&'ID&D%S / $PST#U ISP P$#

%n esta etapa se selecciona un con-unto de funcionalidades de la lista * se procede a dise6ar * construir la funcionalidad mediante un proceso iterativo. Una iteraci1n puede tomar de unos pocos das a un m.+imo de dos semanas. %l proceso iterativo inclu*e inspecci1n de dise6o, codificaci1n, pruebas unitarias, integraci1n e inspecci1n de c1digo.

Ilustracin "4: &roceso Iterativo de Dise=o ! Construccin por Cuncionalidad

.$.2 PRODUCTO P#I9%#& & TI2ID&D 7D%S&##$''$ D% UP 9$D%'$ Q'$J&'8: 'ista de funcionalidades.

55G

Diagrama de clases o de ob-etos por cada .rea del dominio global. 9odelo global del sistema. 7 $PST#U ISP D% UP& 'IST& D%

S%QUPD& & TI2ID&D "UP I$P&'ID&D%S8:

'ista de funcionalidades )ue resuma la funcionalidad general del sistema. 'uego se divide en con-untos seg?n la afinidad * dependencia de cada una de las funcionalidades. se le asigna a cada con-unto de funcionalidades una prioridad bas.ndose en la satisfacci1n al cliente. 'as prioridades al cliente sugeridas por "DD son: o &7Debe tener8 o J7Seria ?til tener8 o 7&gregar si es posible8

o D7"uturo8 "inalmente se pondera la importancia de cada una para su posterior implementaci1n. T%# %#& & TI2ID&D 7P'&P%& ISP P$# "UP I$P&'ID&D8: Se genera un cronograma donde se especifica la duraci1n del dise6o * la construcci1n de cada una de las funcionalidades. $PST#U ISP P$#

U&#T& / LUIPT& & TI2ID&D 7DIS%V$ / "UP I$P&'ID&D8: %n el dise6o:

o Se identifican las clases, atributos * m0todos )ue reali3an en la funcionalidad re)uerida. o 9ediante diagramas de secuencia de U9', se verifica )ue el dise6o pueda ser implementado. %n la construcci1n: o Se desarrollan las clases definidas anteriormente. .$.3 PERSONAL

Se dividen en tres categoras: roles claves, roles de soporte * roles adicionales. #oles laves o &dministrador Del Pro*ecto: )uien tiene la ?ltima palabra en materia de visi1n, cronograma * asignaci1n del personal.

55C

o &r)uitecto Nefe: 7puede dividirse en ar)uitecto de dominio * ar)uitecto t0cnico8. o 9anager De Desarrollo: )ue puede combinarse con ar)uitecto -efe o manager de pro*ecto. o Programador Nefe: )ue participa en el an.lisis del re)uerimiento * selecciona funcionalidades del con-unto a desarrollar en la siguiente iteraci1n. o Propietarios De lases: )ue traba-an ba-o la gua del programador -efe en dise6o, codificaci1n, prueba * documentaci1n, repartidos por funcionalidades. o %+perto De Dominio: )ue puede ser un cliente, patrocinador, analista de negocios o una me3cla de todo eso. #oles De Soporte o &dministrador De %ntrega: )ue controla el progreso del proceso revisando los reportes del programador -efe * manteniendo reuniones breves con 0lO reporta al manager del pro*ecto o &bogado/Quru De 'engua-e: )ue conoce a la perfecci1n el lengua-e * la tecnologa. o Ingeniero De onstrucci1n: )ue se encarga del control de versiones de los builds * publica la documentaci1n. o @erramientista 7Toolsmith8: )ue constru*e herramientas ad hoc o mantiene bases de datos * sitios (eb. o &dministrador Del Sistema: )ue controla el ambiente de traba-o o producti3a el sistema cuando se lo entrega. #oles &dicionales o 2erificadores: encargados del despliegue * escritores t0cnicos. Un miembro de un e)uipo puede tener otros roles a cargo, * un solo rol puede ser compartido por varias personas. .$.4 TECNOLOGIA "DD tools:

"DD Tools es un programa gratuito * de c1digo abierto )ue intenta producir un Mit de herramientas multiplataforma compatible con la metodologa de "eature Driven Development. 'a herramienta produce gr.ficos se seguimiento de pro*ectos para compartir con el e)uipo de gesti1n * organi3aci1n en general. %sta herramienta solo proporciona soporte

55B

para una pe)ue6a parte de la metodologa "DD, pero aun asi resulta mu* ?til en su estado actual. %n la actualidad es compatible con los Sistemas $perativos 9ac, (indows UP, C * 'inu+ Ubuntu. .10 DSDM DSD9 es la ?nica de las metodologas a)u planteadas surgida de un onsorcio, formado originalmente por 5C miembros fundadores en %nero de 5AAE. %l ob-etivo del onsorcio era producir una metodologa de dominio p?blico )ue fuera independiente de las herramientas * )ue pudiera ser utili3ado en pro*ectos de tipo #&D 7#apid &pplication Development8. %l onsorcio, tomando las best practices )ue se conocan en la industria * la e+periencia trada por sus fundadores, liber1 la primera versi1n de DSD9 a principios de 5AAF. & partir de ese momento el m0todo fue bien acogido por la industria, )ue empe31 a utili3arlo * a capacitar a su personal en las pr.cticas * valores de DSD9. Debido a este 0+ito, el onsorcio comision1 al Presidente del omit0 T0cnico, Nennifer Stapleton, la creaci1n de un libro )ue e+plorara la realidad de implementar el m0todo. Dicho libro YStapleton, 5AACZ es tomado como gua para el an.lisis posterior de DSD9. Dado el enfo)ue hacia pro*ectos de caractersticas #&D esta metodologa encuadra perfectamente en el movimiento de metodologas .giles. .10.1 PROCESO 'a manera en )ue el pro*ecto presenta sus datos de la aplicaci1n se basa en el siguiente diagrama, este muestra caractersticas de este m0todo como lo es la forma iterativa de desarrollar el pro*ecto. %l siguiente diagrama muestra de manera clara )ue este m0todo utili3a como base modelos similares como por e-emplo prototipos para poder reali3ar tomas de re)uerimientos.

Ilustracin "": 8 tencin de 7e1ueri*ientos en DSDM

"&S%S

55A

"&S% 5: P#%:P#$/% T$

%n esta fase se identifican los pro*ectos propuestos, )uien financiara el pro*ecto, compromiso por parte de los e)uipos, usuarios * clientes. $JN%TI2$: %vitar Problemas en etapas siguientes. "&S% ;: I '$ D% 2ID& D%' P#$/% T$

Para crear un sistema de informaci1n esta fase se representa en F etapas las cuales describiremos a continuaci1n. 'as etapas muestran en t0rminos generales la retroalimentaci1n )ue necesita cada etapa como consecuencia de la anterior. Para entender me-or eso pasemos a describir cada una de las etapas )ue corresponden al ciclo de vida del Pro*ecto. %T&P&S o %T&P& 5: %STUDI$ D% 2I&JI'ID&D. Se e+aminan re)uisitos previos, en esta etapa se suelen hacer preguntas como las siguientes: [%l pro*ecto satisface la demanda del negocio\, [Se puede a-ustar el pro*ecto a este m0todo\, [Lu0 riesgos implica la elaboraci1n de este pro*ecto\ $JN%TI2$: Utili3ar el m0todo de prototipo para poder reali3ar tomas de re)uerimientos e identificaci1n de riesgos. o %T&P& ;: %STUDI$ D%' P%Q$ I$ %sta etapa se reali3a ?nicamente si se ha identificado )ue el pro*ecto es viable utili3ando este m0todo. &)u en esta etapa se determina como traba-a la empresa, )ue espera la empresa de nuestro traba-o, saber si los clientes saben )ue )uieren o no, ha* participaci1n de los usuarios. $JN%TI2$: utili3ar t0cnicas )ue faciliten * aseguren un pro*ecto de calidad, timebo+ing es una de las t0cnicas esencial para determinar tiempo, presupuesto * garanta deseada, sobre esta t0cnica hablaremos m.s adelante. o %T&P& D: IT%#& I$P D% 9$D%'&D$ "UP I$P&' Para reali3ar esta etapa nos valemos de recursos como el modelo de prototipos, este modelo forma una parte clave en esta etapa. Una parte importante de esta etapa es )ue a)u se reali3an las pruebas, )ue determinan el grado de calidad * efectividad del pro*ecto. $JN%TI2$: #eali3ar un modelado * un prototipo funcional )ue representen unificadamente todas las funciones )ue puede hacer la iteraci1n en la )ue nos encontremos traba-ando. o %T&P& E: IT%#& I$P D% DIS%V$ / D%S&##$''$.

5;H

'a construcci1n del dise6o consiste en integrar los componentes reali3ados en las etapas anteriores en un solo sistema )ue satisfaga las necesidades de los usuarios. $JN%TI2$: %ntregar a los usuarios un prototipo durante la fase de prueba * final del dise6o de construcci1n, para )ue pueda ser aprobado * entregado para la siguiente fase. o %T&P& F: &P'I & ISP Se le entrega una versi1n de prueba al usuario inclu*endo la documentaci1n. %sta versi1n entregada debe incluir los re)uerimientos )ue se han establecido en las etapas inciales. $JN%TI2$: %ntregar una versi1n del sistema, capacitaci1n de Usuarios * %valuar detalladamente los documentos del Sistema. "&S% D: P$ST _ P#$/% T$

&segurarse )ue el sistema operativo acepte de manera efica3 * segura el pro*ecto. %sta fase se reali3a por me-oras, mantenimiento * correcciones de acuerdo con los principios del DSD9.

Ilustracin "%: Cases en DSDM

.10.2 PRODUCTO 'a ma*ora de los productos dentro de DSD9 es los productos especialistas. %s decir, ellos o contienen informaci1n relacionada al sistema o desarrollo el pro*ecto es entregar o definir las t0cnicas del prototipo * m0todos ser usado. @a*, sin embargo, algunos productos de DSD9 )ue son completamente cual)uiera los productos de direcci1n o contienen las secciones de direcci1n de pro*ecto 7como el plan del contorno * plan de prototipo de contorno8 * algunos DSD9 calidad productos 7como los archivos de la revisi1n * archivos de la prueba8. %studio de viabilidad: Tomas de re)uerimientos e identificaci1n de riesgos a trav0s de m0todo de prototipo. %studio del negocio: 9odelamiento del negocio.

5;5

Iteraci1n Del 9odelado "uncional: un modelado * un prototipo funcional )ue representen unificadamente todas las funciones. Iteraci1n De Dise6o * Desarrollo: Prototipo de prueba para )ue sea aceptado * aprobado. Implementaci1n: %ntregar una versi1n del sistema, capacitaci1n de Usuarios * los documentos del Sistema 7guas de usuarios, instalaci1n, D$#, etc.8 .10.3 PERSONAL

%-ecutivo: DSD9 el Patrocinador %-ecutivo es responsable para el pro*ecto a la sociedad * / o direcci1n del programa. & lo largo del pro*ecto, el %-ecutivo <posee> el caso comercial %l Usuario principal: %l Usuario principal es responsable para comprometer el recurso del usuario al pro*ecto. DSD9 advierte )ue esa falta de un grupo del usuario claramente definido propone un riesgo al pro*ecto. %l Qerente del Pro*ecto: es responsable para la entrega e+itosa de los productos convenidos, a la norma convenida de calidad, a tiempo * dentro del presupuesto, * capa3 de entregar los beneficios declarados en el PID. %l Qerente del Pro*ecto puede venir de K' o la comunidad del usuario, e informes a la Tabla del Pro*ecto. Qerente del e)uipo: %ste individuo es responsable para asegurar )ue el e)uipo de desarrollo se encuentra sus ob-etivos entregando el sistema re)uerido %l oordinador T0cnico est. fuera del e)uipo del centro. %l 0l o ella es responsable para asegurar )ue el pro*ecto es t0cnicamente legtimo, se encuentra su especificaci1n t0cnica, * se encuentra las normas t0cnicas convenidas en con-unto para el pro*ecto 0l * la organi3aci1n %l Usuario * posiblemente el oordinador T0cnico es miembros del e)uipo del centro, ellos deben tener el acceso directo a la tabla si sus actividades de convicci1n les dicen )ue el Qerente del Pro*ecto est. dirigiendo el pro*ecto fuera del informe )ue se ha dado por la tabla. .10.4 TECNOLOGIA

TI9%J$UIPQ: Se utili3a para apo*ar los ob-etivos principales del DSD9 para reali3ar un desarrollo de software en tiempo, costo * calidad deseada. 'a idea de esta t0cnica es dividir en partes cada una con presupuesto * fecha fi-a de entrega. ada parte de los re)uisitos )ue se seleccionan son priori3ados de acuerdo con el principio 9$S $(. 'as ?nicas variables son los re)uisitos. 9$S $(: #epresenta una forma de priori3ar los temas, se deben priori3ar las necesidades. %sta es una sigla )ue significa:

5;;

o 9UST 7D%J%8 tener este re)uisito para satisfacer necesidades del negocio. o 9UST 7D%J%8 tener este re)uisito, pero el pro*ecto no depende de ello. o $U'D 7P$D#I&P8 tener este re)uisito sin )ue afecte las condiciones del sistema.

o ($U'D 7S%8 tiene este re)uisito en una fecha posterior. SIQPI"I &D$S: o Prototipos: Permite descubrir de manera previa deficiencia del sistema. o %+.menes: %s una t0cnica independiente para poder medir el logro de cada iteraci1n. o Taller: onsiste en llevar a las partes interesadas a discutir necesidades, funcionalidades, * comprensi1n mutua.

5;D