Estándares de desarrollo de sistemas software

Transcripción

1 Estándares Estándares de desarrll de sistemas sftware Fecha: 30/06/2011 Referencia: EJIE S.A. Mediterráne, 14 Tel * Fax Vitria-Gasteiz Psta-kutxatila / Apartad: Vitria-Gasteiz Este dcument es prpiedad de EJIE, S.A. y su cntenid es cnfidencial. Este dcument n puede ser reprducid, en su ttalidad parcialmente, ni mstrad a trs, ni utilizad para trs prpósits que ls que han riginad su entrega, sin el previ permis escrit de EJIE, S.A.. En el cas de ser entregad en virtud de un cntrat, su utilización estará limitada a l expresamente autrizad en dich cntrat. EJIE, S.A. n pdrá ser cnsiderada respnsable de eventuales errres u misines en la edición del dcument.

2 Cntrl de dcumentación Títul de dcument: Históric de versines Códig: Versión: 2.0 Fecha: 30/06/2011 Resumen de cambis: Se incluyen las actividades y tareas derivadas del mdel estándar de aseguramient de la calidad. Se especifican ls rles identificads y se cmpleta el fluj de ejecución de prcess Se asignan las tareas más imprtantes del análisis al persnal de EJIE Se incrpran las matizacines y cambis prpuests pr DIT Se añade la necesidad de validar las aplicacines en trs navegadres Se actualiza para cntemplar la metdlgía de pruebas Prbamet y el mdel de aseguramient de la calidad (mdel SQA) Cambis prducids desde la última versión Primera versión. Cntrl de difusión Respnsable: Aprbad pr: Ander Martínez Begña Gutierrez Firma: Fecha: 30/06/2011 Distribución: Referencias de archiv Autr: Ander Martínez Nmbre archiv: Lcalización: Estándares de desarrll de sistemas sftware

3 Cntenid Capítul/sección Página 1 Intrducción 2 2 Objetiv 2 3 Estructura 4 4 Prcess rganizativs Prces: Preparación y prvisión Actividad: Adquisición Actividad: Equipamient Actividad: Infraestructura técnica Prces: Administración del pryect Actividad: Gestión del pryect Actividad: Gestión del cambi 11 5 Prcess perativs Prces: Análisis Prces: Diseñ Prces: Implementación Prces: Implantación y aceptación del sistema Prces: Aseguramient de la calidad Actividad: Verificación dcumental Actividad: Auditrías SQA 20 6 Fluj de prcess 23 7 Anex I. Arquitectura 24 8 Anex II. Cntexts de albergue 26 9 Anex III Herramientas de desarrll Anex IV. Sistemas hrizntales 28 Estándares de desarrll de sistemas sftware

4 1 Intrducción En el entrn de GV-EJIE para cada pryect que es adjudicad y cnstruid el prces de desarrll del sftware viene siend aplicad baj distints criteris acrdads entre prveedr y cntratante. En las distintas fases de desarrll del prduct servici, la sistemática de trabaj y traspas de ls entregables resultad ha pdid ser resuelta en muchs cass cn distintas herramientas cn el mism cmetid, inclus se han aplicad distints mdels de trabaj que en la práctica han hech dificultar el prpi prces de desarrll. Aunque ya están definidas las distintas nrmativas a seguir para cada prblemática y fase del desarrll, éstas acusan cierta dispersión y falta de cherencia en su cnjunt, n pr ell dejand de ser perfectamente válidas. Desde una perspectiva más tecnlógica es cnveniente que tdas la actividades y tareas necesarias en el prces de desarrll del sftware sean estandarizadas e intercnectadas entre si facilitand y acelerand de este md ya n sl dich prces sin también la prpia perativa prductiva de ls sistemas. 2 Objetiv Es bjet del presente dcument: Establecer el cnjunt mínim de requerimients y recmendacines técnicas que estandaricen el prces de desarrll de sftware en las fases definidas pr las metdlgías de aplicación. Definir una serie de instruccines de trabaj estandarizadas y cherentes en dich prces. Prprcinar un marc de referencia de terminlgía y vcabulari cmún para el desarrll del sftware. Identificar las principales expectativas a gestinar en las distintas mdalidades de cntratación del desarrll. Cn recurss humans y/ materiales prpis y/ ajens, etc. Se fijará especialmente en ls entregables (códig, ejecutables, dcumentación, etc.) a exigir y auditar. Estandarizar las herramientas de gestión asciadas a las fases del cicl de vida del prces de desarrll del sftware. Enfatizar las necesidades de gestión de la calidad de l prducts a implantar rientadas a minimizar al máxim ls falls del servici en el entrn de prducción. Limitar las psibles arquitecturas sftware y hardware, ajustándlas al mdel de albergue de GV- EJIE. El estándar cntiene un cnjunt de prcess, actividades y tareas diseñadas para ser utilizadas en ls pryects de desarrll sftware, alineadas en tds ls cass cn la metdlgía nrmalizada. Se ha tmad cm referencia el estándar para ls prcess de cicl de vida del sftware de la rganización ISO, ISO/IEC Infrmatin Technlgy / Sftware Life Cycle Prcesses, el cual establece un prces de cicl de vida para el sftware que incluye prcess y actividades que se aplican desde la definición de requisits, pasand pr la adquisición y cnfiguración de ls servicis del sistema, hasta la finalización de su us. Este estándar tiene cm bjetiv principal prprcinar una estructura cmún para que cmpradres, prveedres, desarrlladres, persnal de mantenimient, peradres, gestres y técnics invlucrads en el desarrll de sftware usen un lenguaje cmún. Este lenguaje cmún se establece en frma de prcess bien definids. El estándar n define explícitamente el cntenid, nmbre frmat de ls entregables a prducir. El estándar será aplicable en la prvisión del desarrll y mantenimient de un sistema sftware. Estándares de desarrll de sistemas sftware 2

5 N cntendrá el detalle de las nrmas definidas y aprbadas, sól será un cmpendi rdenad de éstas dentr de la secuencia de fases del cicl de vida del desarrll sftware. Las nrmativas sól estarán referenciadas per n descritas íntegramente. El ámbit de aplicación del presente dcument se circunscribe tant a ls desarrlls gestinads desde GV cm a ls cntratads desde EJIE. El estándar identifica al mens ls siguientes rles: Jefe de pryect de EJIE. Respnsable de la prvisión del servici de desarrll de mantenimient de aplicacines demandad pr el cliente y de la calidad de ls prducts btenids. Cliente. El cliente es la persna que define y acuerda cn el jefe de pryect de EJIE la prvisión del servici de desarrll de mantenimient de una aplicación. Se refiere al directr de servicis del departament que demanda la prestación. Usuari final. La persna que utiliza y explta el prduct aplicación btenid cm resultad del servici cntratad. Prveedr. Tercer respnsable de suministrar td parte del servici de desarrll de aplicacines slicitad pr el cliente. Analista respnsable del pryect de EJIE. Respnsable de la entrega del servici de desarrll de aplicacines cntratad pr el cliente. Se refiere al técnic de análisis de EJIE que gestina y participa en la prvisión del servici. Respnsable del sistema. Respnsable de la entrega del servici de desarrll de mantenimient de aplicacines cnvenid. Se refiere al jefe de pryect asignad pr el prveedr extern cm respnsable últim del servici ante el jefe de pryect de EJIE. Respnsable del módul. Respnsable del desarrll de un módul subsistema en ls que se descmpne el sistema sftware. Se refiere al analista analista-prgramadr asignad pr el prveedr extern para la cnstrucción de un módul. Desarrlladr. Respnsable del desarrll de un cnjunt de artefacts que cmpnen un módul subsistema. Se refiere al analista-prgramadr prgramadr asignad pr el prveedr extern para la cnstrucción de un módul. Tester. Respnsable del diseñ y ejecución de las pruebas, y del cálcul de ls indicadres. Se refiere al equip de pruebas (respnsable de pruebas e ingeniers de pruebas). Oficina técnica de calidad (OTC). Vela pr la ejecución de tdas las actividades relacinadas cn el aseguramient de la calidad del prduct sftware a btener y definidas en el mdel SQA (Sftware Quality Assurance). Verifica el cumplimient de las metdlgías de aplicación (ARINbide y Prbamet), y pr ende, de ls entregables dcumentales que estas establecen. Se refiere al equip de SQA (respnsable SQA e ingeniers SQA). Oficina técnica de calidad de EJIE (OTC-EJIE). Supervisa las actividades realizadas pr las ficinas técnicas de calidad de cada pryect. Oficina de evaluación. Evalúa ls niveles de calidad btenids para el prduct sftware btenid e infrma al CAB sbre dichs resultads. CAB (Change advisry bard). Persnal que asesra al gerente de cambis en la valración, prirización y planificación de ls cambis. El lenguaje utilizad en la redacción de ls prcess, actividades y tareas de ls estándares indicará el grad de exigencia para su cnfrmidad: Estándares de desarrll de sistemas sftware 3

6 Deberá Debería Puede Si entnces: deberá debería puede Indica un requisit bligatri para su cnfrmidad. Indica una fuerte recmendación que n es bligatria para su cnfrmidad. Indica una frma autrizada de cumplir un requisit de evitar la necesidad de satisfacer la cnfrmidad. Indica que el grad de cnfrmidad indicad está sujet al cumplimient de ciertas cndicines. Del mism md se remarcan aquells aspects que deben ser tratads y cumplids de manera rigursa 3 Estructura El estándar se descmpne en: Prcess rganizativs Englba ls prcess más relacinads cn la gestión y preparación, necesaris para el desarrll del sistema sftware. Prces: Preparación y prvisión. Definir el alcance del desarrll a realizar, las infraestructuras técnicas necesarias para su ejecución y ls acuerds de gestión del prces. Prces: Administración del pryect. Cmprende las actividades y tareas necesarias para la crrecta administración del pryect. Prcess perativs Define ls prcess a realizar desde el punt de vista de la cnstrucción del sistema sftware. Prces: Análisis Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de análisis del sistema de infrmación (ASI), y las definidas pr Prbamet en la fase de planificación de pruebas (PPB1), y parcialmente, en la fase de análisis y diseñ de las pruebas (APB), indicand además las herramientas de us en cada actividad y tarea. Prces: Diseñ Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de diseñ del sistema de infrmación (DSI), y parcialmente, las definidas pr Prbamet en la fase de análisis y diseñ de las pruebas (APB)., indicand además las herramientas de us en cada actividad y tarea. Prces: Implementación Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de cnstrucción del sistema de infrmación (CSI), y parcialmente, las definidas pr Prbamet en la fase de ejecución de pruebas (EPB), indicand además las herramientas de us en cada actividad y tarea. Se indican también las mejres prácticas de aplicación en dicha fase, rientadas a mejrar tant la ejecución del prpi prces, cm a ptimizar la tarea de entrega del sistema sftware. Estándares de desarrll de sistemas sftware 4

7 Prces: Implantación y aceptación del sistema Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de implantación y aceptación del sistema (IAS), y parcialmente, las definidas pr Prbamet en la fase de ejecución de pruebas (EPB). Prces: Aseguramient de la calidad Asegurará que ls prducts btenids y ls prcess del cicl de vida del pryect cumplen cn ls requerimients y ls planes establecids. 4 Prcess rganizativs En el prces de desarrll de ls sistemas sftware se deberá aplicar: La metdlgía de desarrll de aplicacines ARINbide. La metdlgía de pruebas Prbamet. El mdel de aseguramient de la calidad estándar de GV-EJIE (Mdel SQA) 4.1 Prces: Preparación y prvisión Definir el alcance del desarrll a realizar, de las infraestructuras técnicas necesarias para su ejecución y de ls acuerds de gestión del prces. Este prces se descmpne en las actividades descritas a cntinuación Actividad: Adquisición El jefe de pryect de EJIE deberá definir las necesidades del sistema a cnstruir, adquirir mantener, indicand además en el plieg de bases técnicas la bligatriedad de adscripción a ls presentes estándares, incluyend entnces la exigencia en la aplicación de las metdlgías ARINbide y Prbamet, y del mdel de aseguramient de la calidad del sftware (mdel SQA). Se deberá indicar también el valr NAC 1 (nivel de aseguramient de la calidad) asignad al pryect. El jefe de pryect de EJIE deberá señalar en el plieg de bases técnicas las implicacines emanadas de las siguientes bligacines y recmendacines relativas a las actividades marcadas pr la metdlgía de desarrll ARINbide: La fase de Requisits de usuari que cnsta de las actividades de Definición del Sistema (ASI 1) y la de Establecimient de Requisits (ASI 2) deberán ser realizadas pr el analista respnsable del pryect de EJIE Y al mens las actividades de Identificación de subsistemas de análisis (ASI 3), Análisis de cass de us (ASI 4) y la de Análisis de clases (ASI 5), deberían también ser realizadas pr el analista respnsable del pryect de EJIE El jefe de pryect de EJIE deberá decidir la idneidad de la cntratación de un equip adicinal que actúe cm Oficina Técnica de Calidad para el pryect, pr l tant, distint al que realizará las actividades de ingeniería, y al que realizará las tareas de pruebas. Inclus se pdría decidir que las tareas de pruebas pasen a ser respnsabilidad de dicha Oficina Técnica de Calidad. En cualquier cas se deberá asegurar que dich rl queda cubiert. 1 El valr NAC (Nivel de Aseguramient de la Calidad) permite determinar el grad de calidad necesari para un pryect de desarrll sftware, y en cnsecuencia, identificar qué cntrles mínims serán de bligad cumplimient, las tiplgías y niveles de pruebas a ejecutar, y ls umbrales admitids para ls indicadres identificads en el mdel de aseguramient de la calidad. Estándares de desarrll de sistemas sftware 5

8 El jefe de pryect de EJIE deberá realizar el prces de selección del prveedr, acrdand ls mdels de prestación del servici más adecuads a las necesidades demandadas pr el cliente, y prpniend así la cntratación del prveedr más aprpiad Actividad: Equipamient Prveer de ls bienes básics para la ejecución del pryect de desarrll de sftware. Cmprende tant el hardware, el sftware, las herramientas, ls estándares y las facilidades para el desarrll, peración y mantenimient. Este prces se descmpne en las tareas descritas a cntinuación. Tarea: Prvisión del puest de trabaj. Sea cual sea la mdalidad de la cntratación, ls miembrs de ls equips de desarrll y mantenimient deberán prveerse del mism cnjunt de herramientas y recurss hardware hmlgads en el entrn de GV-EJIE. O si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste debería prveerse del mism cnjunt de herramientas y hardware que las especificadas para GV-EJIE, bien de aquellas que cnsidere suficientes para cubrir adecuadamente el prces de desarrll sftware para el que ha sid cntratad, facilitand y acelerand así la entrega de ls prducts cnstruids. Recurss sftware: Se ha establecid el cnjunt mínim de herramientas que se deberá dispner en base al perfil del usuari asignad. Tds ls perfiles (jefe de pryect, analista, desarrlladr) cntarán cn un mism cnjunt básic de herramientas, ampliándse éste para el perfil de desarrlladr. Herramientas cmunes para jefe de pryect, analista desarrlladr: Sftware de base: Windws XP Micrsft Office 2003 u OpenOffice Navegadres: Internet Explrer Mzilla Firefx Chrme Opera Diseñ de imágenes: Gimp Utilidades para desarrll: Framewrk.NET. Necesari para ejecución aplicacines NET en lcal Java JRE: Necesari para ejecución aplicacines Java en lcal Bases de dats Oracle: Cliente Oracle. Herramientas administrativas cliente de Oracle Oracle SQL Develper. Gestión de base de dats Oracle (v>=9) Estándares de desarrll de sistemas sftware 6

9 Bases de dats SQL-Server: Cliente SQL-Server. Herramientas administrativas cliente de SQL-Server Herramientas de desarrll y pruebas: Micrsft Prject. Planificación de pryects. Enterprise Architect. Mdelad UML, diagramación, dcumentación, e ingeniería inversa. XML Spy. Edición, depuración y tratamient de XML y tecnlgías asciadas. Subversin: Sistema pen-surce para cntrl de versines. AIS web accesibility (AWA) Tlbar para Internet Explrer. Utilidades para análisis de nrmas WAI, XHTML, CSS Web Develper extensión (WDE) Tlbar para Firefx. Utilidades para análisis de nrmas WAI, XHTML, CSS Badby y Selenium. Utilidad para generación de scripts de navegación para un siti web. JMeter. Pruebas de rendimient y stress sbre aplicacines web (sól para cliente) KeyTlIUI: Herramienta gráfica para la manipulación de frmats criptgráfics. (Certificads, keystres, firmas, claves en diverss frmats). Xlid Sign: Herramienta gráfica de firma electrónica. SapUI: Herramientas para teste de servicis web. Prtal SQA: Aplicación web crprativa de EJIE de gestión y cnsulta de resultads del Mdel SQA Gestión de errres e incidencias: Registr, cntrl y gestión de las incidencias generadas en un pryect: Mantis: Aplicación web para el registr y gestión de bugs. Gestión de pruebas: Registr, cntrl y gestión de pruebas en un pryect: TestLink: Aplicación web para la gestión de pruebas (requisits, planes de pruebas, cass de prueba). Gestión de librerías y dependencias: cntrl de us de librerías de aplicación: Maven: repsitri de librerías y utilidades para la descarga y publicación Archiva: herramienta cn interfaz gráfica para gestión de repsitris prpis (departamental de aplicacines hrizntales) Sl para perfil desarrlladr: Sftware de desarrll: Firebug: Extensión de Firefx cmpuesta pr un paquete de utilidades para editar, mnitrizar y depurar el códig fuente, CSS, HTML y JavaScript de una página web. Fiddler: prxy para capturar y analizar el tráfic de las peticines web Herramientas de desarrll y pruebas: QuickREx: Plugin de ayuda a la creación de expresines regulares. Sl para perfil desarrlladr J2EE/JEE: Sftware de desarrll: Entrn desarrll java. Oracle Weblgic Server JDK Eclipse OEPE. Entrn integrad de desarrll J2EE Estándares de desarrll de sistemas sftware 7

10 Plugin UDA: plugin crprativ para desarrll rápid de aplicacines Hibernate Tls: plugin de Eclipse que permite generar el mdel de dats a partir de uma base de dats relacinal QuickREx: gestión de expresines regulares Subversive: El pryect Subversive se cupa de facilitar la integración de Subversin para Eclipse. JUnit. Plugin para Eclipse, para pruebas unitarias. Checkstyle. Plugin para Eclipse, para pruebas de cheque de códig, en base a reglas de cdificación. PMD. Plugin para Eclipse, para pruebas de cheque de códig, detectand códig muert, códig repetid, etc. FindBugs. Plugin para Eclipse de detección de errres de códig Java. jquery: libería Javascript para desarrll de aplicacines web enriquecidas Sl para perfil desarrlladr.net: Sftware de desarrll: Visual Studi.NET. Entrn integrad de desarrll.net AnkhSVN: Plug-in para Visual Studi para trabaj desde puest lcal de desarrll cn el repsitri de versines Subversin. Herramientas de desarrll y pruebas: NUnit: Permite realizar pruebas unitarias para cualquier lenguaje de.net. Usuaris Se deberá slicitar la creación de ls usuaris de red y cnfiguracines XLNetS necesaris en el entrn de desarrll, y en el de pruebas cuand se estime cnveniente. Tarea: Prvisión del canal de acces. Si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces se deberá prveer el canal de cmunicacines entre dich puest y ls servidres de desarrll a ls que sea precis acceder. En este supuest, el jefe de pryect de EJIE deberá asegurar que el prveedr dispne de acces desde sus ficinas a tras herramientas crprativas de desarrll tales cm el repsitri de mdels UML Enterprise Architect, el de gestión de versines Subversin, la herramienta de gestión de errres Mantis (incluid el repsitri de cncimient de EJIE), y la de gestión de pruebas TestLink. Preferentemente se deberá ptar pr una cnexión VPN entre el prveedr y EJIE cn las siguientes prestacines mínimas recmendadas: Tip de cnexión: ADSL Simétric cn IP fija Velcidad: 2 MB Sftware de cliente VPN (prprcinad pr EJIE) Esta cnexión vía VPN deberá cndicinarse cn un acuerd previ de cmprmiss entre EJIE y la empresa clabradra, e incluyend además la prvisión pr parte de EJIE del sftware de cliente VPN y la creación de ls usuaris de cnexión que se hayan acrdad. Tarea: Emulación. Estándares de desarrll de sistemas sftware 8

11 Si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces el adjudicatari debería implantar en sus ficinas las slucines de servidr que permitan agilizar el desarrll del sistema sftware y su implantación psterir en ls servidres de EJIE. Existen diversas maneras de facilitar ls desarrlls de aplicacines. En general éstas pasan pr intentar emular el entrn existente en EJIE, así cm sus aplicacines hrizntales (emuland-virtualizand máquinas bien cn tras técnicas). Algunas de estas sugerencias se detallan a cntinuación: Emulación virtualización de máquinas Se reduce a intentar emular ls sistemas básics existentes en el entrn de EJIE; para ell se expnen ds de las psibilidades que existen: las imágenes virtuales y las distribucines arrancables. Imágenes virtuales: Se trataría de un ficher cn una máquina virtual que simulase el entrn de desarrll en servidr de EJIE; este ficher cntendría tds ls sistemas utilizads en EJIE cn su misma cnfiguración. Distribución arrancable: El sistema que estaría implantad en esta distribución arrancable sería el mism que la imagen virtual cn la diferencia de que n se necesitaría el prgrama base de la imagen virtual para su ejecución sin que se ejecutaría en el arranque del sistema. Emulación de aplicacines hrizntales Esta sugerencia cnsiste en buscar una fórmula que permita emular de alguna manera las aplicacines hrizntales para evitar la dependencia exclusiva de ests sistemas de EJIE y que puedan prvcar retrass en ls desarrlls. Una de las psibilidades sería utilizand clases huecas que devuelvan uns valres predefinids acrdes cn ls valres válids que retrnarían esas aplicacines hrizntales y que permitan n tener que mdificar el sistema a la hra de implantar la aplicación en ls servidres de desarrll de EJIE; un ejempl práctic puede ser emular la API de XLNets mediante unas clases huecas y un xml que emule un tken de sesión que es interrgad desde dichas clases Actividad: Infraestructura técnica Establecer y mantener la infraestructura técnica necesaria para el rest de prcess. Cmprende tant el hardware, el sftware, las herramientas, ls estándares y las facilidades para el desarrll, peración y mantenimient, desde la perspectiva del us de ls sistemas de infraestructura y de su albergue. Este prces se descmpne al mens en las tareas descritas a cntinuación. Tarea: Sistema de infraestructura XLNetS y PKI Ls prcess de autenticación de usuaris mediante pares usuari-passwrd mediante certificad electrónic, así cm la gestión de autrizacines de acces a ls recurss de la aplicación deberán valerse del sistema de seguridad crprativ XLNetS. Se deberá slicitar la creación de ls recurss y cnfiguracines XLNetS del entrn de desarrll, pruebas, y prducción necesaris para el sistema sftware (cadena de cnexión a BD, usuaris, unidades rgánicas, inclusión de ls PCs de trabaj en dminis, etc.) Estándares de desarrll de sistemas sftware 9

12 Se deberá seguir el prcedimient de administración de usuaris definid para la rganización; SCP-34. Ls certificads electrónics de us de la aplicación deberán slicitarse a Izenpe. Tarea: Sistema de infraestructura PLATEA-Tramitación Se deberá slicitar la creación de ls recurss PLATEA-Tramitación del entrn de desarrll, pruebas, y prducción necesaris para el sistema sftware (alta del prcedimient en el catálg de prcedimients, alta en el catálg de trámites y tareas, etc.) Tarea: Sistema de infraestructura PLATEA-Presencia en Internet Se deberá slicitar la creación de ls recurss PLATEA-Presencia en Internet del entrn de desarrll, pruebas y prducción necesaris para el sistema sftware (wrkareas de aplicación, usuaris Interwven y Open Deply, etc.) Tarea: Albergue Para el sistema a cnstruir, y en base a la cmbinación de clectivs usuaris y sus psibles canales de acces, se deberá determinar el cntext cntexts de albergue así cm su dispsición en una varias aplicacines. Se deberá definir además que aplicación aplicacines deben desplegarse en ls cntexts de Internet, Intranet, Extranet-Jakinaplus Extranet-Jas. El prces de desarrll de cada aplicación deberá adscribirse en cada cas a ls mdels de despliegue establecids y a ls librs de estil vigentes. En cualquier cas se deberán cnsiderar las reglas de visibilidad y acces impuestas pr el sistema de seguridad de red definid en GV, tant para el cas de invcacines entre distints cntexts cm para peticines dentr del mism. Cualquier requerimient de arquitectura de sistema que n cumpla el mdel de seguridad de red deberá ser estudiad y aprbad, si prcede, pr EJIE, siempre cm pas previ al inici de cualquiera de ls prcess perativs. Tarea: Dcumentación, nrmativas y ntas técnicas El jefe de pryect de EJIE deberá facilitar al prveedr el cnjunt de las nrmativas vigentes, y de tda la dcumentación que se cnsidere de interés en la cnstrucción del sistema sftware, así cm de tdas aquellas ntas técnicas internas que sean publicadas. Deberá prestar especial atención a las actualizacines que vayan surgiend de md que el prveedr esté cntinuamente infrmad de las nvedades cambis que se prduzcan. Si se acrdó la prvisión del puest de trabaj en ls lcales del prveedr entnces el jefe de pryect de EJIE deberá asegurar que éste dispne de acces al repsitri de cncimient técnic de EJIE, al cual pdrá acudir ante cualquier eventualidad técnica que surja. 4.2 Prces: Administración del pryect Cmprende las actividades y tareas necesarias para la crrecta administración del pryect. Este prces se descmpne en las actividades descritas a cntinuación. Estándares de desarrll de sistemas sftware 10

13 Actividad: Gestión del pryect Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de gestión del pryect (GPR), las definidas pr Prbamet en su fase de seguimient de pruebas (PPB2), y las marcadas pr el mdel de aseguramient de la calidad (Mdel SQA) en su fase de ejecución y seguimient de las actividades SQA (SQA 3). Se deberán ejecutar las actividades y tareas definidas pr ARINbide en el módul de gestión de pryects (GPR), así cm las indicadas pr Prbamet en su fase de seguimient de pruebas (PPB2), y las establecidas pr el Mdel SQA en su fase de ejecución y seguimient de las actividades SQA (SQA 3). Se deberá seguir el prcedimient de gestión de pryects definid para la rganización; SCP-60 para el cas de cntratacines gestinadas pr EJIE. Para la generación de la dcumentación se deberán utilizar las herramientas fimáticas hmlgadas en GV-EJIE, Micrsft Office u OpenOffice. Para elabrar ls entregables de planificación se deberá utilizar Micrsft Prject cualquier tra herramienta que permita su imprtación psterir en ésta Actividad: Gestión del cambi Se deberá seguir el prcedimient de gestión de cambis definid para la rganización. Ls traspass entre entrns (desde desarrll a pruebas, y desde pruebas a prducción) deberán ser planificads y prpuests cn antelación suficiente para que ls servicis de gestión del cambi y gestión del despliegue de EJIE puedan planear adecuadamente ls trabajs a realizar. Para la generación de la dcumentación se deberá prveer de Micrsft Office de OpenOffice cm herramienta fimática hmlgada en GV-EJIE. 5 Prcess perativs Se deberá aplicar: La metdlgía de desarrll de aplicacines ARINbide. La metdlgía de pruebas Prbamet. El mdel de aseguramient de la calidad estándar de GV-EJIE (Mdel SQA) Estándares de desarrll de sistemas sftware 11

14 Mdel SQA Gestión de actividades de SQA Medición y Análisis de Indicadres Auditrías SQA Verificación dcumental Verificación Dc.Análisis Auditría ASI Verificación Plan de Pruebas Auditría DSI Verificación Dc.Diseñ Verificación Especificación Cass Prueba Auditrías CSI Cntrucción, PU y PI P.Sistema Verificación Dc Cnstrucción Auditría Final SQA Verificación Dc.Implantación ARINBIDE ASI - Requisits Análisis del Sistema DSI - Diseñ del Sistema CSI - Cnstrucción IAS - Implantación GPR-Gestión de Pryects PROBAMET EPB EJECUCIÓN Análisis de Códig PPB1 PLANIFICACIÓN Elabración Plan de Pruebas APB ANÁLISIS Y DISEÑO Especificación Cass de Prueba EPB EJECUCIÓN Pruebas Unitarias EPB EJECUCIÓN Pruebas Integración EPB EJECUCIÓN Pruebas Aceptación EPB EJECUCIÓN Pruebas Sistema PPB2 - Seguimient de Pruebas 5.1 Prces: Análisis Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de análisis del sistema de infrmación (ASI), y las definidas pr Prbamet en la fase de planificación de pruebas (PPB1), y parcialmente, en la fase de análisis y diseñ de las pruebas (APB). Se indica para cada cas las herramientas de us en cada actividad y tarea. Puest que el prces se crrespnde cn las fases de ARINbide y de Prbamet ya indicadas, n se detallan las actividades y tareas en las que se descmpne, sól se remarcan cierts aspects especialmente imprtantes que deberán deberían cumplirse. Se deberán ejecutar las actividades y tareas definidas pr ARINbide en esta fase, así cm las dictadas pr Prbamet para este cicl. Estas se deberán realizar cnsiderand el us de sól las herramientas, librerías y sistemas especificads en el dcument de estándares tecnlógics publicad pr la Dirección de Infrmática y Telecmunicacines del GV. Ante cualquier tra nueva necesidad, EJIE deberá realizar un estudi detallad determinándse la idneidad n de la prpuesta. Las actividades de Definición del Sistema (ASI 1) y la de Establecimient de Requisits (ASI 2) definidas pr la metdlgía de desarrll ARINbide en su fase de Requisits de usuari, deberán ser realizadas pr Estándares de desarrll de sistemas sftware 12

15 el analista respnsable del pryect de EJIE. Y al mens las actividades de Identificación de subsistemas de análisis (ASI 3), Análisis de cass de us (ASI 4) y la de Análisis de clases (ASI 5), también deberían ser realizadas pr el analista respnsable del pryect de EJIE. Para la generación de la dcumentación se deberá utilizar Micrsft Office u OpenOffice cm herramienta fimática hmlgada en GV-EJIE. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar ls frmats cmpatibles que puedan ser gestinads pr alguna de estas. Para la creación de ls mdels UML y de sus descripcines detalladas a incluir en la dcumentación, se deberá utilizar Enterprise Architect. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar el frmat estándar XMI, de md que dichs mdels resultad puedan ser gestinads pr esta. Se deberá utilizar un únic repsitri de mdels UML. Si el pryect es de cierta envergadura dich repsitri se deberá crear en el servidr remt habilitad a tal efect, facilitand así el trabaj en equip En la actividad de definición de interfaces de usuari, ls prttips deberán cnstruirse cn un sftware de prttipad al us (cm pr ejempl Pencil Micrsft Web Express) si se pta pr la pción de psibilidad de navegación, cn GIMP si se prefieren mdels más estátics. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar ls frmats cmpatibles cn estas. Se deberá pner especial atención al prces de revisión y aprbación de requisits definids y especificads para el sistema sftware. El valr NAC asignad al pryect determinará las tiplgías y niveles de pruebas a ejecutar. Así, el plan de pruebas deberá cntemplar la ejecución del cnjunt de: Pruebas de aceptación. Que deberá realizar el usuari en el entn de pruebas, y que permitirán determinar la aceptación n del sistema cnstruid. Pruebas de sistema. Cnjunt de pruebas del sistema sftware que aseguren la cbertura cmpleta de la especificación de requisits. Pruebas funcinales. Que permitan asegura que se cumplen ls requisits funcinales definids para cada un de ls móduls de análisis del sistema. Pruebas n funcinales. Ls ensays de instalación y cnfiguración, de cnsistencia de dats, de seguridad, de prestacines (rendimient, escalabilidad, capacidad, carga, estrés, vlumen y estabilidad), de fall y recuperación del sistema, de accesibilidad y de usabilidad. El plan de pruebas deberá identificar también: Pruebas de integración. Se deberá establecer al mens la estrategia de pruebas de integración a realizar. Pruebas unitarias. En esta fase se deberán identificar al mens ls camins y prcess crítics (riesgs) del sistema a partir de ls cuales en la fase de implementación se crearán ls artefacts de pruebas básicas de cmpnentes. En esta fase se deberán definir al mens a alt nivel ls cnjunts de cass de prueba Estándares de desarrll de sistemas sftware 13

16 emanads de las pruebas de aceptación y de sistema. 5.2 Prces: Diseñ Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de diseñ del sistema de infrmación (DSI), y parcialmente, las definidas pr Prbamet en la fase de análisis y diseñ de las pruebas (APB). Se indican para cada cas las herramientas de us en cada actividad y tarea. Puest que el prces se crrespnde cn las fases de ARINbide y de Prbamet ya indicadas, n se detallan las actividades y tareas en las que se descmpne, sól se remarcan cierts aspects especialmente imprtantes que deberán deberían cumplirse. Se deberán ejecutar las actividades y tareas definidas pr ARINbide en esta fase, así cm las dictadas pr Prbamet para este cicl. Éstas se deberán realizar cnsiderand el us de sól las herramientas, librerías y sistemas especificads en el dcument de estándares tecnlógics publicad pr la Dirección de infrmática y telecmunicacines del GV. Ante cualquier tra nueva necesidad, EJIE deberá realizar un estudi detallad determinándse la idneidad de la prpuesta. Para la generación de la dcumentación se deberá utilizar Micrsft Office u OpenOffice cm herramienta fimática hmlgada en GV-EJIE. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar ls frmats cmpatibles que puedan ser gestinads pr alguna de estas. Para la creación de ls mdels UML y de sus descripcines detalladas a incluir en la dcumentación, se deberá utilizar Enterprise Architect. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar el frmat estándar XMI, de md que dichs mdels resultad puedan ser gestinads pr esta. Se deberá utilizar el mism repsitri de mdels UML y definicines detalladas que el slicitad en la fase de análisis. Se deberá cmpletar exhaustivamente el plan de pruebas establecid en el prces de análisis y almacenad en el repsitri TestLink, ampliand y detalland además el cnjunt de cass de prueba a realizar. Si se trata de un aplicativ cn interfaz web que será desplegad en el cntext de internet, las pruebas del sistema deberán cntemplar ls ensays necesaris para garantizar que el sistema se cmprta crrectamente en ls navegadres más utilizads (Internet Explrer, Firefx, Chrme, Opera, y Safari) 2. Mientras que si el cntext de despliegue es intranet (cn PCs gestinads), el sistema deberá sprtar ls navegadres hmlgads pr ls estándares tecnlógics publicads pr la Dirección de infrmática y telecmunicacines del GV para dich cntext (Internet Explrer y Firefx). Para el cas de extranet, la lista de navegadres a sprtar se deberá decidir en función de ls clectivs usuaris de la aplicación y del us n de PCs gestinads. Se deberá establecer perfectamente la matriz de trazabilidad requisit cass de prueba que permitirá validar que ésts se cumplen y se satisfacen adecuadamente. 2 Se han incluid ls navegadres más utilizads a nivel mundial a fecha de Ener de N bstante, y cn bjet de dar cbertura al máxim númer de usuaris en el mment de realizar el pryect, se recmienda cnsultar las estadísticas de us de ls navegadres web en el cntext de ls interesads de la aplicación que se va a cnstruir, para así ampliar reducir para cada cas la lista de navegadres a sprtar. Estándares de desarrll de sistemas sftware 14

17 Cn bjet de minimizar el esfuerz a realizar, y haciend us del cnjunt de herramientas hmlgadas, se deberá sistematizar al máxim el prces de ejecución de las pruebas que se hayan definid. Se deberán tener en cnsideración las restriccines impuestas pr el mdel de seguridad de red y pr ende las arquitecturas lógicas y físicas que este impne. Para más infrmación cnsultar el Anex I. Arquitectura. Se deberá cnsiderar especialmente la infrmación necesaria a reflejar en el manual de implantación del sistema sftware. Para más infrmación cnsultar el prces de implantación y aceptación del sistema (5.4) Las tareas relacinadas cn la gestión de pruebas establecidas pr Prbamet deberán realizarse cn la herramienta de gestión de pruebas estándar, TestLink, cnteniend pr l tant el cnjunt de requisits definids para el pryect, así cm el detalle de ls cass de prueba que ls validan. 5.3 Prces: Implementación Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de cnstrucción del sistema de infrmación (CSI), y parcialmente, las definidas pr Prbamet en la fase de ejecución de pruebas (EPB). Se indica para cada cas las herramientas de us en cada actividad y tarea. Puest que el prces se crrespnde cn las fases de ARINbide y de Prbamet ya indicadas, n se detallan las actividades y tareas en las que se descmpne, sól se remarcan cierts aspects especialmente imprtantes que deberán deberían cumplirse. Se indican también las mejres prácticas de aplicación en dichas fases, rientadas a mejrar tant la ejecución de ls prpis prcess cm a ptimizar la tarea de entrega del sistema sftware. Se deberán ejecutar las actividades y tareas definidas pr ARINbide en esta fase, así cm las dictadas pr Prbamet para este cicl. Éstas se deberán realizar cnsiderand el us de sól las herramientas, librerías y sistemas especificads en el dcument de estándares tecnlógics publicad pr la Dirección de infrmática y telecmunicacines del GV. Ante cualquier tra nueva necesidad, EJIE deberá realizar un estudi detallad determinándse la idneidad de la prpuesta. Para la generación de la dcumentación se deberá utilizar Micrsft Office u OpenOffice cm herramienta fimática hmlgada en GV-EJIE. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar ls frmats cmpatibles que puedan ser gestinads pr alguna de estas. Para la creación de ls mdels UML a incluir en la dcumentación se deberá utilizar Enterprise Architect. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar el frmat estándar XMI, de md que dichs mdels resultad puedan ser gestinads pr esta. Se deberá utilizar el mism repsitri UML que el slicitad en el prces de análisis (5.1). El prcedimient de catalgación y gestión de errres que puedan prducirse durante el prces de implementación de cualquiera de las áreas del sistema sftware (códig ejecutable, elements estátics, scripts de creación de BD, ejecución del plan de pruebas, etc.) deberán tratarse utilizand la herramienta Mantis. Estándares de desarrll de sistemas sftware 15

18 Previamente se deberá crear dich repsitri y asignar ls rles (infrmadr, validadr, reslutr, etc.) y usuaris que se cnsideren necesaris. Las tareas relacinadas cn la gestión de pruebas establecidas pr Prbamet deberán realizarse cn la herramienta de gestión de pruebas estándar, TestLink, cnteniend pr l tant el cnjunt de requisits definids para el pryect, el detalle de ls cass de prueba que ls validan, y ls resultads btenids para cada cas de prueba. El tratamient de ls fichers plans se puede realizar cn la herramienta UltraEdit32. El diseñ de ls fichers XML se puede realizar cn la herramienta XMLSpy. El acces al servidr de desarrll de EJIE se deberá realizará cn la herramienta SecureCRT, cn SecureFX si l que se desea es hacer una carga FTP. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta cmpatible cn la cnfiguración del servidr. Se deberán generar y ejecutar intensivamente ls cass de prueba definids en ls prcess anterires para el sistema sftware. Cntenids estátics El diseñ de las interfaces gráficas en frmat HTML junt cn el rest de artefacts web (CSS, javascript, etc.) se deberá realizar cn Micrsft Web Designer Las imágenes se deberán crear cn la herramienta GIMP. Y si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces éste puede utilizar cualquier tra herramienta que permita generar ls frmats cmpatibles cn esta. Las entregas de cntenids estátics se deberán realizar siempre a través del repsitri de versinad Subversin, en la rama de estatic. Para sistemas a desplegar en el cntext de Internet, ls cntenids estátics deberán ser cargads en la wrkarea de aplicación del servidr de cntenids Interwven. Psterirmente se deberán desplegar en ls servidres web Apache cn la herramienta de Open Deply. Este prces se repetirá en ls entrns de pruebas y de prducción. En el rest de cntexts (Intranet y Extranet) se deberán cpiar ests cntenids en el servidr web Apache del entrn crrespndiente haciend una carga FTP. Y para el pas a prducción se deberá utilizar la aplicación M26 para su despliegue definitiv en dich entrn. Códig, cnfiguración y pruebas Si se trata de un sistema cn tecnlgía JEE entnces se deberá utilizar UDA cm utilidad de generación de códig básic a partir del cual se cnstruirá el sistema. Cm herramienta de desarrll IDE en entrn J2EE se deberá utilizar Eclipse junt cn el plugin UDA. Estándares de desarrll de sistemas sftware 16

19 El prces de cdificación y el de generación del cnjunt de pruebas unitarias se deberá realizar en el PC lcal. N se permite desplegar en el servidr de desarrll ningún códig que n haya sid perfectamente prbad y validad previamente en el entrn de PC lcal. N se permite utilizar el servidr de desarrll cm única herramienta entrn de cmpilación y pruebas unitarias. Las entregas de códig, de ls fichers de cnfiguración en el servidr de desarrll y de ls cnjunts de pruebas autmatizadas (unitarias, integración y sistema) se deberán realizar siempre a través del repsitri de versinad Subversin en la rama de cdig, en la de cnfig, y en las de test (test_unit, test_integratin y test_system) respectivamente. Es decir, desde el PC de desarrll se alimentará el repsitri, y desde éste y haciend us de las tareas habilitadas a tal efect se descargará en el servidr de desarrll para su cmpilación y despliegue. Haciend us de la herramienta para la autmatización de la ejecución de pruebas, Hudsn, el desarrlladr deberá lanzar el prces de análisis estátic del códig, así cm tdas aquellas pruebas unitarias y de integración autmáticas que se hayan cnfiguradas. Este prces se pdrá ejecutar tantas veces cm se cnsidere necesari. Ls resultads btenids se recgerán autmáticamente en la herramienta de gestión de pruebas TestLink y las incidencias prducidas se darán de alta en la herramienta de gestión de errres Mantis. Sól el respnsable del módul pdrá realizar el despliegue de dich módul en el servidr de desarrll. Esta acción se deberá hacer de manera prgramada y crdinada cn el rest de respnsables de móduls, idealmente un máxim de una vez al día hasta que el módul testead se cnsidere crrect. Se deberá reducir pr tant al máxim el númer de despliegues a realizar en el servidr de desarrll. Cualquier códig que esté generand prblemas de estabilidad en el servidr de desarrll deberá ser descargad y subsanad en el entrn PC lcal, nunca en el servidr. Una vez desplegad el módul: Haciend us de la herramienta de generación de scripts autmátics de pruebas de sistema-funcinales, Selenium, el respnsable del módul deberá generar ls escenaris de validación y pruebas de cada un de ls móduls cntenids en su ámbit de respnsabilidad. El respnsable del módul y/ el desarrlladr deberá generar también el cnjunt de pruebas de sistema n funcinales: de instalación y cnfiguración, de cnsistencia de dats, de seguridad, de prestacines (rendimient, escalabilidad, capacidad, carga, estrés, vlumen y estabilidad), de fall y recuperación del sistema, de accesibilidad y de usabilidad. Se deberá utilizar el cnjunt de herramientas estandarizadas para cada cas ( Ais Web Accessibility Fr Internet Explrer, sapui, etc.). Para más infrmación cnsultar el Anex III. Herramientas de desarrll. Haciend us de la herramienta para la autmatización de la ejecución de pruebas, Hudsn, el respnsable del módul deberá lanzar, para cada un de sus móduls, el prces de validación de tdas aquellas pruebas de sistema autmáticas que se hayan cnfigurad. Este prces se pdrá ejecutar tantas veces cm se cnsidere necesari. Ls resultads btenids se deberán recger en la herramienta de gestión de pruebas TestLink y las incidencias prducidas se deberán dar de alta en la herramienta de gestión de errres Mantis. Estándares de desarrll de sistemas sftware 17

20 Ls prcess de ejecución de pruebas que n sea psible autmatizar cn el us de las herramientas deberán realizarse de manera manual. Sól cuand ya estén validads ls distints móduls de la aplicación: De md similar al estadi anterir (pruebas de móduls), el respnsable del sistema y/ el desarrlladr deberán generar, cnfigurar y ejecutar las pruebas de integración entre móduls, y las de sistema (funcinales y n funcinales), per esta vez para td el sistema. Dats Las tareas de gestión de ls dats albergads en base de dats se deberán realizar cn SQLDevelper si la base de dats es Oracle y cn la Cnsla SQLServer si la base de dats es SQLServer. Las entregas de scripts de creación de base de dats se deberán realizar siempre a través del repsitri de versinad Subversin en la rama de scripts, y ls dats en la rama de dats. Se deberá definir adecuadamente la vlumetría de dats del sistema, cumplimentand para ell la hja de cálcul estándar en EJIE. En l referente al códig fuente, ls cntenids estátics y scripts de creación de BD, si se acrdó que el puest de trabaj estuviese en ls lcales del prveedr, entnces, y tras acuerd pr ambas partes, éste puede utilizar cualquier cnjunt de herramientas de sus elección siempre y cuand permitan entregar a EJIE ls frmats de sprte definids para ls servidres de desarrll de GV-EJIE. 5.4 Prces: Implantación y aceptación del sistema Cmprende las actividades y tareas dictadas pr la metdlgía de aplicación ARINbide en la fase de implantación y aceptación del sistema (IAS), y parcialmente, las definidas pr Prbamet en la fase de ejecución de pruebas (EPB). Se indica para cada cas las herramientas de us en cada actividad y tarea. Puest que el prces se crrespnde cn las fases de ARINbide y de Prbamet ya indicadas, n se detallan las actividades y tareas en las que se descmpne, sól se remarcan cierts aspects especialmente imprtantes que deberán deberían cumplirse. Se deberán ejecutar las actividades y tareas definidas pr ARINbide en esta fase, así cm las dictadas pr Prbamet para este cicl. Éstas se deberán realizar cnsiderand el us de sól las herramientas, librerías y sistemas especificads en el dcument de estándares tecnlógics publicad pr la Dirección de infrmática y telecmunicacines del GV. Ante cualquier tra nueva necesidad, EJIE deberá realizar un estudi detallad determinándse la idneidad de la prpuesta. De md similar al estadi anterir (pruebas de sistema), el usuari final y/ el respnsable del sistema deberán ejecutar las pruebas de aceptación de usuari que se hayan definid. Cn el fin de realizar estas pruebas en un entrn más similar al de prducción, estas deberán realizarse bligatriamente en el entrn de pruebas. Las incidencias y psibles mejras detectadas pr el usuari se deberán registrar y tratar a través de la herramienta Mantis, siguiend siempre el prces de reslución del cicl cmplet de creación de códig. Estándares de desarrll de sistemas sftware 18

21 Cm pas previ al despliegue definitiv del sistema en el entrn de prducción, y bligatriamente en el entrn de pruebas, se deberán ejecutar el cnjunt ttal de pruebas (análisis estátic del códig, pruebas unitarias, de integración y de sistema), vaidand que el resultad de dichas pruebas es el esperad, y que pr l tant el sistema cumple cn ls indicadres de calidad establecids. Se deberá reflejar en el manual de implantación del sistema sftware: Necesidades de visibilidad y acces entre ls cmpnentes del sistema y entre máquinas físicas y trs sistemas de GV externs (DDFF, Ministeris red SARA-, etc.), puerts de escucha (si es que se cncen) Prtcls de cmunicación utilizads (HTTP, HTTPS sbre SSL ne-way tw-way, FTP, NFS, IMAP, POP3, etc.) Sftware librerías hmlgadas necesarias junt cn sus versines Parámetrs de cnfiguración de: Ples (JDBC) de cnexión a BD Descriptres de despliegue de ls EJBs de la aplicación Clas JMS Etc. Relación de scripts de creación de bjets de BD u trs, que se deben ejecutar. Cnfiguracines a realizar en trs sistemas de infraestructura de platafrma cm puede ser PLATEA, crre Exchange, etc. Otras necesidades especiales En definitiva, td aquell que se cnsidere relevante para la crrecta instalación del sistema en ls distints entrns. Se deberán elabrar entnces: Esquema detallad de la arquitectura física del sistema Esquema detallad en el que se refleje su arquitectura lógica En cnsnancia cn la actividad de gestión del cambi (4.2.2) definida cm parte del prces de administración del pryect (4.2), se deberá elabrar detalladamente el plan se implantación del sistema, que deberá cntemplar las especificacines y requisits definids en el manual de implantación. Se asegura así la crrecta instalación del prduct en ls entrns de pruebas y de prducción. 5.5 Prces: Aseguramient de la calidad Asegurará que ls prducts btenids y ls prcess del cicl de vida del pryect cumplen cn ls requerimients y ls planes establecids. Se deberá aplicar el mdel de aseguramient de la calidad estándar en GV-EJIE (Mdel SQA). El prces de btención de ls indicadres que realmente determinan el grad de calidad del prduct sftware se deberá realizar en el entrn de pruebas, puest que se entiende que este entrn cuenta cn una cnfiguración y recurss más similares a ls dispnibles en el entrn de prducción. Td pryect de cnstrucción mantenimient de un sistema sftware deberá incluir bligatriamente el rl de Oficina Técnica de Calidad. El prces de aseguramient de la calidad deberá ser ejecutad pr la Oficina Técnica de Calidad del pryect, que deberá: Asegurar que se ejecutan tdas las actividades relacinadas cn el aseguramient de la calidad Estándares de desarrll de sistemas sftware 19

22 del prduct sftware definidas en el mdel SQA Verificar el cumplimient de las metdlgías de aplicación: ARINbide y Prbamet, y pr ende, que ls entregables dcumentales que estas establecen sn crrects y suficientes. Verificar que se superan ls umbrales establecids pr ls indicadres de calidad. El Jefe de pryect de EJIE, cm respnsable últim del pryect, deberá asegurar que el sistema sftware cnstruid cumple cn ls estándares de calidad definids. El Mdel SQA se fundamenta en un calendari de entregas versinadas del prduct (dcumentación y ejecutables) y en el plan SQA que deberá ser elabrad y acrdad previamente entre ls equips de desarrll y de pruebas, y la ficina técnica de calidad. Este prces se descmpne en las actividades descritas a cntinuación Actividad: Verificación dcumental En el tiemp, se ejecutará en paralel a cada un de ls prces de desarrll y pruebas del sistema sftware. En función del NAC asignad al pryect se habrán determinad ya: Ls cntrles de calidad (SQA) a realizar durante el desarrll del sistema. Las tiplgías de pruebas a ejecutar. Ls indicadres estándar y sus umbrales permitids En las entregas de la dcumentación asciada al pryect se deberá asegurar que se cumplen ls cntrles de calidad (SQA) definids, garantizand así el cumplimient de la metdlgía de desarrll, ARINbide, y de pruebas, Prbamet, así cm la calidad de dicha dcumentación: Verificación dcumentación de análisis Verificación del pan de pruebas Verificación dcumentación de diseñ Verificación de la especificación de cass de prueba Verificación dcumentación de cnstrucción Verificación dcumentación de implantación Ls resultads de la verificación realizada deberán recgerse en el prtal SQA de EJIE, frmand parte entnces de ls indicadres de calidad calculads para el sistema sftware. El analista respnsable del pryect de EJIE deberá asegurar que se cumplen ls cntrles de calidad (SQA) definids Actividad: Auditrías SQA En el tiemp, se ejecutará en paralel a cada un de ls prces de desarrll y pruebas del sistema sftware. Al finalizar cada una de las fases del desarrll y pruebas del sistema sftware indicadas pr ARINbide (ASI; DSI, CSI e IAS) y pr Prbamet se deberá ejecutar la auditría de fin de fase, bteniend así el grad de calidad del sistema según ls indicadres recgids: Indicadres de pruebas Análisis estátic de códig Estándares de desarrll de sistemas sftware 20

23 Pruebas unitarias Pruebas de integración Pruebas de sistema Pruebas basadas en requisits (tant funcinales cm n funcinales) Rendimient (prestacines): Cumplimient glbal indicadres prestacines Indicadres servidr web Indicadres servidr de aplicacines Indicadres servidr bbdd Seguridad grad cumplimient wasp tp 10 Usabilidad grad cumplimient evaluación heurística Accesibilidad: Indicadres de calidad SQA Indicadres de Fin de Fase Se deberá prestar especial atención a ls indicadres de rendimient btenids (us de la memria del servidr, de la CPU, tiemp de respuesta de las peticines http, parámetrs de cnfiguración de ples de cnexión a base de dats, descriptres de despliegue de EJBS, clas JMS, etc.) ls cuales nrmalmente tienden a descuidarse. En el entrn de pruebas, haciend us de la herramienta de pruebas de carga LadRunner se debería asegurar que el sistema sftware cnstruid cumple cn las especificacines de rendimient definidas. Per si se entiende que el sistema debe sprtar una gran carga de trabaj, bien pr el tip de prces que resuelve, bien pr el númer de usuaris cncurrentes pr cualquier tra circunstancia, entnces las pruebas de carga deberán realizarse de manera bligatria. Ls resultads btenids deberán recgerse en el prtal SQA de EJIE, frmad parte entnces de ls indicadres de calidad calculads para el sistema sftware. Las incidencias y psibles mejras detectadas se deberán registrar y tratar a través de la herramienta Mantis. Estas deberán ser slventadas en ls PCs de desarrll, nunca en el servidr y siguiend siempre el prces de reslución del cicl cmplet del códig. Ante cualquier incidente extern al sistema sftware, se deberá seguir el prcedimient de gestión de incidencias definid para la rganización; SCP-32. El analista respnsable del pryect de EJIE deberá asegurar que se cumplen ls cntrles de calidad (SQA) definids, garantizand así el cumplimient de ls indicadres de calidad establecids y pr tant, cn ls requisits del sistema. Durante la fase de cnstrucción del sistema (CSI) en ls PCs lcales se deberá asegurar que el códig cnstruid cumple cn las reglas de calidad de códig estátic definidas pr las herramientas estandarizadas: CheckStyle, PMD y FindBugs. Traspas al entrn de Prducción Una vez que el usuari final acepta el sistema sftware cnstruid, y siguiend la nrmativa de traspass vigente, se deberá realizar la implantación del aplicativ en el entrn de prducción. Cm pas previ al entrn de prducción se deberá ejecutar la auditría final SQA el cual permitirá cnslidar ls resultads de las actividades de calidad realizadas en el pryect y el grad de calidad btenid Estándares de desarrll de sistemas sftware 21

24 en ls prducts generads. Esta auditría establece además cnclusines y recmendacines para el CAB en la tma de decisines para el pas a prducción del sistema. El analista respnsable del pryect de EJIE deberá crear en Subversin una versión estable del sistema sftware para el entrn de prducción. El sistema sftware deberá ser traspasad desde el entrn de pruebas ajustand las cnfiguracines óptimas calculadas y especificadas en el manual de implantación Durante ls ds primers meses en ls que el sistema esté perativ en el entrn de prducción se deberá realizar un seguimient exhaustiv del mism asegurand así que éste funcina de manera adecuada. Se deberá cmprbar especialmente td aquell que pueda prvcar la inestabilidad del sistema y pr extensión, de ls servidres en ls que se encuentren desplegads Transcurrid el períd de depuración y ajuste final en el entrn de prducción, si n se tiene previst que el sistema sftware sufra ningún cambi, adaptación mejra, este deberá deshabilitarse del servidr de desarrll y de pruebas, evitand así un cnsum innecesari de recurss. Estándares de desarrll de sistemas sftware 22

25 6 Fluj de prcess El fluj de ejecución de prcess deberá seguir el siguiente esquema: Y para el prces de implementación: Si se acrdó la prvisión del puest de trabaj en ls lcales del prveedr entnces éste deberá entregar el sistema sftware debidamente prbad y validad previamente en sus instalacines. N bstante se deberán realizar entregas parciales pr móduls fases para pder validar y asegurar de manera temprana y cntinua la calidad del sistema que se está cnstruyend. Tdas las entregas de cntenids estátics, códig, scripts de base de dats, etc. deberán realizarse sbre el repsitri de versines Subversin, y pr tant crrectamente etiquetads e identificads, evitand siempre la carga directa pr SFTP sbre ls servidres de desarrll. Estándares de desarrll de sistemas sftware 23

26 El equip de desarrll deberá realizar la implementación del sistema y la cdificación de las pruebas unitarias en ls PCs lcales. Puest que el códig generad se deberá cmpilar y desplegar en el servidr de desarrll, este se deberá descargar siempre desde el repsitri Subversin al disc del servidr, para así pder ser cmpilad y desplegad. Un vez realizad se pdrán ejecutar tdas las pruebas que se cnsidere necesarias. El desarrlladr pdrá dejar en el repsitri de Subversin tantas versines cm cnsidere necesari. Se deberá realizar la subida y ejecución de ls scripts del mdel de dats en ls servidres de back-end. Se deberá realizar la subida del cntenid estátic mediante la aplicación M26 (aplicación intranet) a través de Interwven y Open Deply (aplicación Internet) En el entrn de desarrll, una vez realizadas el cnjunt de pruebas básicas que garanticen al mens el funcinamient elemental del sistema, este se pdrá prmcinar al entrn de pruebas. Se deberán definir y generar ls scripts de simulación de escenaris, pudiend ejecutar así las pruebas de sistema. En el entrn de pruebas, el equip de pruebas deberá btener ls valres de las métricas marcadas pr ls indicadres definids pr el mdel de aseguramient de la calidad (análisis estátic del códig, pruebas unitarias, pruebas de integración y pruebas de sistema) reflejand dicha infrmación en el Prtal SQA. En el entrn de pruebas se deberían realizar las pruebas de carga del sistema que se cnsideren necesarias. Se deberá asegurar también que la dcumentación asciada al pryect cumplen ls cntrles de calidad definids, garantizand así el cumplimient de la metdlgía de desarrll, ARINbide, y de pruebas, Prbamet. La Oficina técnica de calidad deberá velar pr la ejecución de tdas las actividades relacinadas cn el aseguramient de la calidad del prduct sftware a btener y definidas en el mdel SQA, y cmprbar que ls resultads btenids están dentr de ls umbrales aceptads. El usuari final deberá realizar las pruebas del sistema. Ls defects errres, y pr tant las mdificacines, deberán seguir el mism prces que el rest de incidencias detectads en las fases de desarrll del sistema. En tds ls cass, las incidencias errres deberán reflejarse y tramitarse a través de Mantis, asignándse así la subsanación al desarrlladr crrespndiente Una vez aceptad el sistema sftware en el entrn de pruebas pr parte del usuari final, se deberá establecer cm versión para prducción la que tenga actualmente el entrn de pruebas, es decir, la aceptada pr el usuari, siend pr l tant la que se traspasará al entrn de prducción. Se deberá realizar el traspas del sistema sftware al entrn de prducción. Cm pas previ a la implantación definitiva en el entrn de prducción, la Oficina de evaluación deberá infrmar al CAB al respect de las cnclusines y recmendacines btenidas en l relativ a ls niveles de calidad del sistema sftware a implantar. 7 Anex I. Arquitectura En el ámbit de GV-EJIE, la arquitectura física y pr ende la arquitectura lógica de alt nivel es idéntica para cada un de ls entrns existentes, desarrll, pruebas y prducción. En el entrn de desarrll se realizará la primera integración de l desarrllad en PC lcal a la arquitectura y el entrn tecnlógic que sustentará el aplicativ. En el entrn de pruebas se realizarán las pruebas de usuari planteadas cm requisits del aplicativ cm pas previ al entrn prductiv. El entrn de prducción será el entrn final dnde la aplicación se ejecutará cn ls usuaris finales y ls dats reales. El pas entre ls diferentes entrns se realizará mediante una sistemática de traspass. Estándares de desarrll de sistemas sftware 24

27 Platafrma multicapa La arquitectura física impuesta pr el mdel de seguridad de red define un mdel de tres capas. Dich mdel presenta además una distribución de cmpnentes sftware, distinguiéndse tres niveles lógics cn cmetids distints: un para ls servicis de usuari, tr para ls servicis de la lógica de negci (la lógica principal de la aplicación), y tr nivel para ls servicis de dats. Estas capas están físicamente distribuidas de tal manera que únicamente pseen cnectividad un a un, es decir, la capa de presentación sl tiene acces a la de negci, y ésta sól tendrá acces a la de dats. Presentación La lógica de presentación es básicamente la encargada de prprcinar la interfaz necesaria para presentar la infrmación y recger las slicitudes de prces de ls usuaris. Es la parte de funcinalidad de la aplicación que permite al usuari interactuar cn la misma. En la capa de presentación se englban al mens ls cntenids estátics necesaris para la aplicación (CSSs, javascript, imágenes, etc.) que se desplegarán en el servidr web Apache del cntext y entrn crrespndiente. Negci aplicación La lógica de negci es el puente entre el usuari y ls servicis de dats. Ests servicis de negci respnden a peticines del usuari, y de trs servicis de negci, implementand prcedimients y tratamients sbre ls dats que cmprenden las principales funcinalidades y bjetivs de la aplicación. Cm medi para la implementación y sprte de esta capa lógica, así cm para el funcinamient de tda esta arquitectura, estará el servidr de aplicacines Oracle Weblgic Server para tecnlgía Java, y Micrsft IIS para tecnlgía.net. El servidr prprcina ls servicis necesaris para gestinar el tratamient de ls cmpnentes de negci desarrllads así cm su cntrl transaccinal. Dats Back-end La capa de dats representa ls servicis de dats para la aplicación. Esta capa es la respnsable de prprcinar medis para recuperar y actualizar la infrmación y mantener la integridad de dats. La capa de dats estará sustentada en un sistema de gestión de base de dats. Esta capa sustentará aquells prcess batch prgramads para su ejecución cn Cntrl-M y gestinads pr la aplicación K31/O75 Integración Se añade una capa de integración cm: Intermediari y agregadr de funcines de interés general suministrads pr distints sistemas para su expsición y cnsum Suministradr de servicis cn frmat de servici web Ámbit de despliegue de prcess de negci inter-sistemas (rquestación de servicis) Prveedr de adaptadres que faciliten el acces a distintas tecnlgías subyacentes Prpuesta de ámbits de publicación y cnsum de events cn un únic punt de entrada per cn diversas tecnlgías de publicación y reclección Aceleradr de reutilización de sistemas y de interperabilidad técnica Estándares de desarrll de sistemas sftware 25

28 Tds ests cmpnentes se distribuyen entnces en capas lógicas, per cn dispsición en frma de servicis para aquellas funcines de interés general (SOA) En el prces de desarrll del sftware en el ámbit de GV-EJIE, ests cmpnentes deberán de implantarse en el entrn de desarrll para psterirmente ir traspasándse a ls entrns de pruebas y de prducción. El pas de desarrll a pruebas se hará a través de las znas de traspas, mientras que para el pas a prducción se utilizará l existente en las znas de pruebas, es decir, td pas a prducción deberá ser transferid y validad previamente en el entrn de pruebas. 8 Anex II. Cntexts de albergue Ls sistemas sftware aplicacines se van a clasificar en ls diferentes cntexts de albergue según sus características de negci. Una aplicación pdrá tener móduls en diferentes cntexts en función de las necesidades existentes aunque el tratamient para ls prcess de desarrll e implantación será cm si de aplicacines independientes se tratara. Ests cntexts de albergue se crrespnden cn ls cntexts de Internet, de Intranet y de Extranet. El cntext de Internet está asciad a aquellas aplicacines que requieren un acces de ls usuaris desde Internet. Este cntext tiene cnntacines especiales en l referente a la publicación de ls cntenids estátics y estils. El cntext de Intranet está asciad a aquellas aplicacines que requieren únicamente un acces de ls usuaris de la intranet de GV. En este cntext estará ubicada la platafrma de Integración que actúa cm intermediari y agregadr de funcines de interés general suministrads pr distints sistemas para su expsición y cnsum. El cntext de Extranet está asciad a aquellas aplicacines que requieren expner td parte de su negci a un grup limitad y definid de usuaris apyándse en tras redes que n se crrespnden cn la intranet de GV, habitualmente Internet. Actualmente existen ds tips de extranet; la extranet de jakinaplus y la extranet de Jas. En l referente a la arquitectura de ls diferentes cntexts, se trata de una arquitectura replicada para las capas de presentación y de negci cmpartiend la capa de Back-End. Las diferencias básicas entre ls diferentes cntexts de albergue se limitan, sbre td, en ls aspects referentes a la seguridad y la cnectividad. Estándares de desarrll de sistemas sftware 26