gO 2, Resolucton Administrativa No 4.201 }7-MTC/33.6 Lima, 20 JUL 2017 VISTO: EI Memorandum No. 109-2017-MTC/33.6.5 de la Jefatura de Informatica de fecha 26 de abril de 2017 de la Autoridad Autonoma del Sistema Eléctrico de Transporte Masivo de Lima y Callao, por el cual remite, entre otros, los proyectos de Metodologia de Desarrollo y Mantenimiento de Software y de Metodologia de Gestion de Riesgos de Seguridad de la Informacion, para la Autoridad Autnoma del Sistema Eléctrico de Transporte Masivo de Lima y Callao, en adelante la AATE; CONSIDERANDO: Que, la Norma Técnica Peruana “NTP- ISO/IEC 12207:2004- Tecnologia de la Informacién. Procesos del ciclo de vida del software. 1* Edicién’, fue aprobada mediante Resolucién No. 048-2004/CRT-INDECOPI, siendo reemplazada por la "NTP ISO/IEC 12207:2006- Tecnologia de la Informacién. Procesos del ciclo de vida del software. 2° Edicién’, aprobada por Resolucién No. 055-2006/INDECOPI-CRT, finalmente reemplazada por la nueva versién de la Norma Técnica Peruana ‘NTP- ISONEC 12207:2016- Ingenieria de Software y Sistemas. Procesos del ciclo de vida de! Software. 3° Edicién” aprobada por Resolucién Directoral No. 013-2016- INACALIDN, actualmente vigente, en adelante la NTP-ISO/IEC 12207:201 2) Que, mediante Resolucién Ministerial No. 041-2017-PCM, de fecha 27 de 7 yppe7) febrero de 2017, se aprobé el uso obligatorio de la NTP-ISO/IEC 12207:2016, en todas las entidades integrantes del Sistema Nacional de Informatica, entre ellas la AATE; Que, mediante Resolucién No. 129-2014/CNB-INDECOP! de la Comision 1G de Normalizacién y de Fiscalizacién de Barreras Comerciales No Arancelarias de p INDECOPI, de fecha 20 de noviembre de 2014, se aprueba la Norma Técnica Peruana NTP-ISO/IEC 27001:2014 Tecnologia de la Informacion. Técnicas de seguridad. Sistemas de gestién de seguridad de Ia informacién. Requisitos. 2* Edicién’, en adelante la NTP-ISO/IEC 27001:2014, Ia misma que reemplaza y deja sin efecto a la NTP-ISO/IEC 27001:200:Ministerial No. 004-2016-PCM, de fecha 08 de enero de 2016, se aprueba el uso obligatorio de la NTP-ISO/IEC 27001:2014, en todas las entidades integrantes del Sistema Nacional de Informatica, entre ellas la AATE; Que, de conformidad con el numeral 6.1 de la NTP-ISO/IEC 27001:2014, cuando se planifica para el sistema de gestién de seguridad de la informacién, la organizacién debe considerar los asuntos referidos en el numeral 4.1 y los requisitos referidos en el numeral 4.2 y daterminar los riesgos y oportunidades que necesitan ser tratados, lo que implica, entre otros, que la organizacién debe planificar: acciones que traten estos riesgos y oportunidades; asi como j) integrar ¢ implementar estas acciones en sus procesos del sistema de gestion de seguridad de Ia informacién; y, il) evaluar Ia efectividad de estas acciones, lo cual permitira resguardar la informacién de la ATE; Que, de conformidad con el objetivo de control “A.14.2 Seguridad en los procesos de desarrollo y soporte” del Anexo A de la NTP-ISO/IEC 27001:2014, se debe garantizar que la seguridad de la informacién esté disefiada e implementada dentro del ciclo de vida de desarrollo de los sistemas de informacién, lo cual coadyuvara a mantener la seguridad de la informacién; Que, de conformidad con lo esbozado la NTP-ISO/MEC 27001:2014, tiene por objeto establecer, implementar, mantener y mejorar el sistema de gestion de seguridad de la informacién, siendo necesario para una éptima implementacin de sus lineamientos, tener en cuenta y aplicar las disposiciones aprobadas mediante la NTP- ISO/EC 12207:2016; Que, el Anexo No, 03 Niveles de Elaboracién, Revision y Aprobacién de los Documentos de la AATE, conformante del Procedimiento OPE-OYP-PRO01 “Elaboracién y Control de Documentos", aprobado mediante Resolucién Administrativa No. 012-2015-MTC/33.2, sefiala que para el tipo de documento denominado “Metodologia’, su aprobacién esta a cargo de la Jefatura del Organo, ademas que la actividad 9 del numeral 9 del citado Procedimiento, precisa que se emitiré una Resolucién Administrativa; Con la visaci6n de la Jefatura de Informatica; SE RESUELVE: ARTICULO PRIMERO.- Aprobar la “Metodologia de Desarrollo y Mantenimiento de Software” y la “Metodologia de Gestion de Riesgos de Seguridad de la Informacién’, ambas para la Autoridad Auténoma del Sistema Eléctrico de Transporte Masivo de Lima y Callao (AATE)’, las cuales en Anexos 01 y 02, son parte integrante de la presente.Ore, Resolucién Administrativa No, = -2017-MTC/33.6 ARTICULO SEGUNDO.- Disponer que la presente Resolucién y sus anexos sean publicados en el Portal Institucional de la AATE (www.aate.gob.pe). ARTICULO _TERCERO- Remitase a la Oficina de Programacién, Evaluacién e Informacién (OPE!) la versién original de las Metodologias aprobadas mediante el articulo primero, para su custodia y difusién, de conformidad con lo dispuesto en el Anexo No. 02 Responsabilidad de la Oficina de Programacién, Evaluacién e Informacion, del Procedimiento OPE-OYP-PR001 “Elaboracién y Control de Documentos’. Registrese y Comuniquese. Ramér Vicente Veigoyen’ Jefe dela Ofcna de Administacion ‘AATESe nl sah * aeAUTORIDAD AUTONOMA DEL SISTEMA ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO Wieany io Crane elss Desarrollo y Mantenimiento de Software de la Autoridad Auténoma del Sistema Eléctrico de Transporte Masivo de Lima y Callao (AATE) Metodologia: OA-INF-ME001 Version: 1.0 OFICINA DE ADMINISTRACION Elaborado por: Oscar Gaspar Chumpitaz Firma: 77/7 Cargo: Especialista en Desarrollo de Sistemas / Ys Fecha: 03/04/2017 / f Revisado por: Luis Pérez Pichis : Cargo: Jefe (0) de Informatica Fecha: 18/05/2017 ‘Aprobado por: Ramén Yrigoyen Yrigoyen Cargo: Jefe de Oficina de Administracion Fecha: 05/06/2017‘Gédiga: OAINF-MEOO Versin : 1.0 METODOLOGIA ‘DESARROLLO V MANTENIMIENTO SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (ATE) Pagina 2 de 110 CONTROL DE VERSIONES ITEM VERSION FECHA DONE aaa aRe) Elaboracion inicial det o1 10 | 03.0 ‘documento técnico 017 UNMETODOLOGIA ‘CBdigo: OAINF-MEOOT Version: 1.0 DESARROLLO ¥ MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA, ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (ATE) Pagina s de 110 inDICE 4. INTRODUCCION.. 2. TERMINOS Y DEFINICIONES. 3. OBJETIVOS 4. BASE LEGAL. 5. ROLES Y RESPONSABILIDADES 6. DESARROLLO DEL CONTENIDO. 6.1. MARCO TEORICO.. 6.1.4. NTP ISO/IEC 12207. 6.1.2. SCRUM... 64.8. RUP ncn 6.2. VISION GENERAL DE LA METODOLOGIA........ 6.2.1. FASES DEL DESARROLLO DE SOFTWARE. 62.2, ESQUEMAS DE LA METODOLOGIA... ; 6.3. DISPOSICIONES ESPECIFICAS DEL DESARROLLO DE SOFTWARE. 6.3.1. FASE DE REQUERIMIENTOS. 6.3.2. FASE DE ANALISIS Y DISENO.. 6.3.3. FASE DE DESARROLLO... 63.4. FASE DE PRUEBAS 6.3.5. _ FASE DE TRANSICION 6.4. DISPOSICIONES ESPECIFICAS DEL M/ 7. DOCUMENTOS RELACIONADOB....... No se presentan.. 8. ANEXOS... ‘SOFTWARE... {N087 ‘Cédigo: OR-INE-MEOO? METODOLOGIA Ge Sas ‘DESARROLLO Y WANTENIMTENTO DE SOFTWARE ELA AUTORIDAD AUTONOMA DEL SISTEMA” | pacing «do 110 ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y [CALLAO (ATE) 4. INTRODUCCION Hoy en dia las enpresas que desarrollan software se enfrentan a grandes retos tanto de demanda como de calidad en sus productos, el uso de las tecnologias de la informacion en la industria de cualquier tipo se ha vuelto una herramienta de primera necesidad y entre la sociedad un estilo de vida, la mayoria dependemos de alguna forma de tecnologia, sin. embargo, a pesar de que existen muchas empresas alrededor del mundo que se dedican a satisfacer la necesidad de contar con sistemas o aplicaciones de software que procesen la informacion, no todas lo hacen de forma correcta, ordenada y con calidad. Actualmente existe un alto indice de fracaso en los proyectos de desarrollo de software, las empresas no alcanzan a terminar en tiempo y dentro de los costos planificados por falta de implementaci6n de un modelo de procesos de calidad, Reconocemos que un software es un emprendimiento flexible, que durante su ciclo de construccién suftiré cambios, modificaciones y mejoras. Por lo tanto, éstas generan un ciclo de vida que permite incorporar nuevas ideas en cualquier momento, sin sacrificar la productividad o al tiempo de entrega del proyecto. En esta misma linea, las aproximaciones agiles apuntan a desarrollar software de manera iterativa e incremental, entregndole al cliente software ejecutable en cada periodo de tiempo fijado por el Jefe de Proyecto, el cual el cliente puede explorer, eriticar y mejorar. Con cada iteracién incorpora nuevos conocimientos, se despliega un proceso de constante aprendizaje y refinamiento del producto final. 2. TERMINOS Y DEFINICIONES aio} Drea ole) =) Autoridad Autonoma del Sistema Eléctrico de Transporte Masivo de Lima AATE y Callao. Puesto definido en el Manual de Organizacién y Funciones de la Jefatura carne de Informatica de la AATE. Ciclo de desarrollo de | Tiempo entre Ia iniciacién del desarrollo del software y la entrega del software mismo. Entregable Este puede ser un bien, un servicio, un documento, un producto, un informe. Equipo Se refiere al equipo de colaboradores designados en la elaboracién del Software, también llamados Team. Es la aplicacién de conocimientos, habilidades, herramientas y técnicas a Gestién de Proyectos las actividades de un proyecto para cumplir con los requisitos del mismo. Representacién de un requisito de software escrito en una 0 dos frases Historias de Usuario utilizando frases sencillas que describan el requisito. Denominacién que se le da a los entregables del proyecto sea, alcance, ava Base tiempo o costo. Marco de proceso Es un proceso genérico que define las actividades requeridas para comin elecutar un proyecto software, Puede ser adaptado para un proyecto ‘AMUSEMETODOLOGIA Cédigo: OAINF-MEOO Version: 1.0 DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA | », ELECTRICO DE TRANSPORTE MASIVO DE LIMA | Pagina S de 110 CALLAO (ATE) aca} Drala} especifico, Métodos de ingenieria del software Los métodos de ingenieria del software proporcionan el "como" para la construccién del software. Abarcan las tareas técnicas requeridas para realizar y documentar el andlisis de requisitos, el disefio, la construccién de programas, las pruebas y el mantenimiento. Modelos de proceso giles Los modelos de proceso Agiles son enfoques de desarrollo donde los requisitos del cliente se cumplen temprano en el ciclo de vida de desarrollo del software a través de continuas entregas de software. En estos modelos, los cambios en los requisites son bienvenidos. Modelo de proceso de software Un modelo de proceso de software es una estrategia abstracta para la onstruccién y mantenimiento de un producto software. Ayuda a los jefes de proyecto en la planificacién y ejecucién de un proyecto. También se le llama modelo de ciclo de vida o paradigma de ingenieria del software. Modelo de proceso El modelo de proceso es un enfoque en el que el producto se entrega al incremental cliente incrementalmente sobre un periodo de tiempo planiticado, Es un conjunto de actividades 0 eventos (coordinados u organizados) Proceso que se realizan o suceden (alternativamente o simultaneamente) bajo ciertas circunstancias en un determinado lapso de tiempo. Productos de trabajo |El€mentos que se crean durante el curso del proceso software, tales | como documentos, software y manuales. Product Backlog | Listado de requerimientos que debe cubrir e! producto software, que van de la mano con sus historias de usuarios respectva PMBOK Project Management Body of Knowledge o Gula de los Fundamentos ara la direccién de Proyectos. Proyecto Es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio 0 resultado nico, Requerimiento Un requerimiento, de acuerdo con las definiciones generalmente aceptadas constituye “una capacidad o condicién que deberé ser ssatisfecha". Cuando se aplica al contexto del software, un requerimiento del software constituye una "capacidad 0 condicién que debera ser alcanzada por el producto software’. Fool estandar propuesto para ejecutar segiin corresponda diversos Rol procesos durante un Ciclo de Vida de Software Rational Unified Process en espafiol Proceso Unificado de Rational, es oh un proceso de desarrollo de software, el cual constituye la metodologia estindar més utlizada para el andiisis, disefo, implementacién y documentacién de sistemas. Sistema de Conjunto de elementos orientados al tratamiento y administracién de datos e informacién, organizados y listos para su uso posterior, (N00 a‘METODOLOGIA ae 110 ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (AATE) aeer PROCESO DE MODELAMIENTO DE NEGOCIO - DESARROLLO POR TERCEROS Roe ACTIVIDADES UNC NTU) SADC) ito 1. En esta actividad se debe revisar las principales 4. lWentcar los Casos de| * Analsta | Ca7@cteristcas del Producto Software, que representan 128] s4emnorgndum Uso det Negocia, Funcional | {unelonalidades que debe realizar el Software a realizar en) or et imento) grandes rasgos. (Por ejemplo: Solicitar informacién del _| usuario, Emitr Planitia.) 1. Los Casos de Uso del Negocio dentificados en el paso| + Memorandum 2, Identicar actores de los}, praigiq | amerior, son activados realizados por un Actor (Rol)| (Requerimiento) Casos de Uso de] ” A’SINE | encargado de realizar, activar 0 iniciar el Caso de Uso del] + Organigrama Negocio Negocio. (Por ejempio: Usuario (Actor) -> Solicta Informe de| Funcional de la Pagos). AATE, 1. Una vez identificados los Casos de Uso del Negocio con sus 3. Elaborar Diagramas de| , praca | Fespectivos Actores, se debe mapear todos los casos de uso “Diagramas de Casos de Uso de] " fier || del negocio identiicado, y como se relacionan con los Gasos de Uso del Negocio diferentes roles que participan con estos y asi elaborar el Negocio, diagrama de Casos de Uso del Negocio. «. Priorizar los Gasos de} ” Afalsla_|7. Una vez realizado el diagrama de Casos de Uso del Negocio, | * Diagrama de Casos | Funcional | se debe realizar la priorizacién de los principales Casos de de Uso de! Negocio Uso de negocio. Cliente Uso por et Cliente (Priorizado) ~ 1. Una vez priorizado los Casos de Uso del Negocio, se procede Snocments nas Eapecifcar los Casos de| * Analista | Parr de esta prorzacion. a ealzar los fujos de PS C598 iagrama de Casos| Especifcacon de los Uso de negocio Funcional | > Fiujo Principal de Casos de Uso del Negocio. de Uso (Priorizado) | Casos de Uso del 3, Flujo Alternativo de Casos de Uso del Negocio. _ Negocio*.'$018018 | J0d ojjou12Saq — CIDOBaN ep oJUSIWEIEPOW Bp OSE004d 79 .N EANBIY SoLNeMATIANDTY 30354 euopuna esHeuy '8018010 | 10d oj/ou1e88q — O190B2N ap clualWel@apoW 8p osedoid 12 eoyEdB 2s UpIoBNUMUCD y (aivv) ovnivo A vn 30 OnISYW aLNOASNYALL 30 ODRILDTTS ‘WWALSIS 130 VWONOINY GvaRiOLNY V1 3d 3UVMLJOS 30 OLNSIMINSINVN A OTIONMYS3A TO03W-INI-¥O =061p09 yiso10do13METODOLOGIA ‘DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA | ps aing 4 ge 110 ELECTRICO DE TRANSPORTE MASIVO DE Lima y | Pédina 24 de | ‘CALLAO (ATE) 6.3.1.2, REQUERIMIENTOS En este proceso se detallan los pasos a seguir para la correcta identificacion de los Requerimientos. Proyectos de Desarrollo In House En caso de los Proyectos de Desarrollo In House, se debera especificar los requerimientos de cada caracteristica del Producto Software, y asi finalmente dividirios en Tareas, las cuales podrén ser asignadas a los miembros del equipo y ser desarrollados por estos. Proyectos de Desarrollo por Terceros En el caso de Proyectos de Desarrollo por Terceros, se realizara la identificacién de los Requerimientos por parte de los principales Usuarios del Proyecto a realizarse, en paralelo se realiza el Proceso de Elaboracién de! Acta de Constitucién del Proyecto®, el cual rescata los Actores de los Casos de Uso del Negocio y asi poder acordar entrevistas con ellos y escuchar sus necesidades y expectativas acerca del Proyecto a realizarse. Una vez realizadas las entrevistas, se deben listar los requerimientos, tanto funcionales como no funcionales del Sistema con su respectiva priorizacién del cliente de igual forma como se realizé para los Casos de Uso del Negocio. * Para mayor detalle revisar el documento MET_PROY-001 Metodologia de Gestion de Proyectos‘aremyos op soILaTWueNbaty ap BT Z AN OH—LY J9A ,, Soot | sovqumus sq. spmuie peta Koda sl op0 Rue paul un os epend Cena odnbe fp SOUR 1 UE BpoeED Ue KL opr > EB LWv ep salibe soveKo1d 2p UopRSIUWIDe A oaiOyUOW! ‘oIUeIWINBES ep | S1eMYOS BIUAIWENEH B| UB sLeseiBUl UBJOgep 2s SOIS] “Z J0un ss(@pezuoUd) (sopeziue6i0) aquawrejoiu eproaiqeise erp & sremyos ap faremyog = ap-—fugioeztioud e| ofeq A “(o,Sopewnsa soduiol,) sowaruuenbeuy soquawianbey —_| ojjouresap o/A uoroeioqele @p peynowyp ns e uorouny us couse “soquejuiuenboy ap es_+ lap eism_+ | upsezuoud as soqualwuenbas so] sopeziuebio Zan BUN“ vepn_+ [op wisn ei _sezuoud “e (sopezue69) ‘odinbe je ugseBeoua ‘s1aMyos op eremyog ap cowsonmnta 28 ewewioue\sod onb sageGanue ap sodni6 oa1uoe sojuaywiuenbe: sowanwuenbos | a souenbed sewoy JS2 A soqweluuanbar so| s221U2610 sep] = [so sezueiQ Z ap ess | mel agap_as sowalwuenbe: so) sopeedew zea Eun ‘1 sluudg ep uoroeaylueld B] ua seise ap upioBubise ouensn |g gpa, | 18) U2 UOISINP B| Bled EWUEND UB UBIEWIO) 2s ‘eremyogep ap seuoisiy : soquetuuanbes ‘quejepe us sayen so} ‘ezemyog ep soqwarwuanboy oojuo9s Soqvemuvonboy S0| JB}S| @qap es sOIse uo ‘OVENS ap BUCIS yep) = [U2 Sonoea ep eis (opezuoug) | JBISI| OGEP 2 NP BUOISI PM * |ionpod 18 aes) “b Gonoeg tonpoy + | PAHEd8=u ns Uod ‘sue [9 40d epeasap eonstc}9eIe0 ‘peo 1od ‘opezuioud Bopjaeg yonpolg jap osn opusIOeH * Dero) er eterna y ST Taran] svauvL SOWAOUAL Od OTIONUWSIO ~ SOLNSIWINANDTY 3d OSIDOUd onsepszeurtea (aivv) ovTvo 4 vr 30 OnIs¥WW a1NOASNYeAL 30 ODRILDZT \WwALSIS 7130 VAONOINY GvGINOLNY V1 30 SYVMLJOS 30 OLNSIMINSINVN A OTIOWUVSIO OL Tuese TOOEREINFYO *961P99 ypotodo1aw‘METODOLOGIA DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (ATE) Pagina 25 de 110 A continuacién se gratica el proceso de Requerimientos ~ Desarrollo por Terceros, Product Backlog 2 titaae 8 TPiorzadol E Requerinientos : z se Soroore x 3 “tare! roauee Pa ae pS mee H. E requerinietor 3 é Requerinientos de 2 [Organtzados) 5 é g] ib ener asst E é z 3 é& sta de Requernintas de Sertware orzo Figura N° 7: Proceso de Requerimientos — Desarrollo por Tercerosi Reps " ‘o1emyog op ae ‘sojueluitianbas sou uso oyualwiuenbeu unBye soquanuuanber sousnwerb—s |, soyoy iZiOS | emo seovepuedep sei sonnuupe So se¥Be) ecep oF en o) | eiSIeuy «enue —seauepuodep ep sn a ash “oo|Wigisis anbojue ja oleg sojualuenbs1 so| sopeadew 26A eu se] sensiuupy |) “uowunees op ‘sey ‘so6ses sapuei8 v e12Myog oYonpold 19 49n Jse K SoveZIUeBLO souens | sepod ered oojwigisis enbojug un ofeq sopeziue6.o 48s upseqep soqwatwuenbes (sopeziue6io) | ep seanejoadxy | sojuajuiuanba: soise ‘(uolunay @p sejoy) seIOUesAP B BUIAISIS eysqeuy = |us sepepisooau azemyos 2p | sopepissoeN ep eis! «| {ep SoueNsn so] UoD SEISINeLIUA SB] UB SOPEZ|Iee! SOURUWIOD 52} 1221U2610) sowetuuenbey A seneiadxe se uoo sowuotuuenbes so) sopeireiep 20 wun | ep asn “soquetwvenbos 50] 1e\!819p { BOIUPBIO pePIUN e| 40d opeUe wWnpURLOWAW\ [2 -souensn o1S060N jap ue UEiN ond sowenUHenbeu So UoD seIsasuE Se UO opeIUndE sowensn ap senjejoedxy |S0S80 eP BUIBeIG «| oj Je0qoL00 uaqap es ‘sepez|eal seIsIAG.IUe sei ep OBEN sisjeuy «|S! 9 SeNlD0GK0 A sapepiseoony (owenuuenboy) | “esiezees v o1DeKoig jap UBsedse anb senyeisedxe A sopepiseoou - Sepepisacou ep est] wnpuBoWa\y «| sns ap BoLa0B 'sopEJON|OAU! OID0BANY ap SosEd0!q ap UOOBDYLHUEP! °p urea “2 2p sousjue osed je us uove}s| es enb ‘(sopesesaqu! ‘aiUal {eUy oueNsN) soueNsn sejediouud so| UOO seIsiMestUa sezIeY 10088, ‘o19080N j9p os) 058N 6 “OSJEZIBO) B O}EADIg [9 UB UBBUEMIEIUL 9p sosea 9p BUIBIBEIG » a 7 a Peat and ‘o1ooBeu ep sejBe: A (sopeionjonul) sejos ‘sepepinoe exoreuy «| SOPBOnIONUI 1pOBEN ap sojo1 ‘souensn, ep = opersry ey (cwuajuienbay) winpuBOWs)_« TTI) ns ‘o1906au Jap sosaocid so} s2oynuap! Bied ‘oI00B=N fe Oj@poW svauvl CET ae) Sos@00!4 $0} JeOYAUOP| "| rele Ay SOUSOUSL NOd OTIONNVSAM ~ SOLNAINIINDIY 30 OSIDONd OL op zz euibeg (aiwv) ovo 4 v7 ad ONISYWW aLNOdSNYEL 30 ODRILOTTS \VWaLSIS 730 VINONOLNY GvOINOLNY V7 30 SHVMLIOS 3G OLNSIWINGINVN A OTIONIVE3G OIE TOOEW-INFWO "061p99 yjsoToao1aw maMETODOLOGIA DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA | piscina oa de 110 ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (ATE) a 7. Una vez que los requerimientos han sido mapeados, bajo las rm = Lista de 5. Validar lista de necesidades, expectativas de los usuarios, hayan sido Requerimientos Ravan * Cliente ‘organizados y revisados por dependencia entre estos, se pasan a Op ead lequerimientos: presentar al Cliente quien los validard, con lo cual se firma la Lista (Validados) de Requerimientos 6. Prionzar la Lista de|= Cliente. |1. Una vez realizada la Lista de Requerimientos completa del/* Linea Base de|* Lista de Requerimientos. Producto Software, el Cliente debe participar en las Reunién, en| Alcance (Aprobada). Requerimientos: las cuales tanto ar Técnico como el equipo de Trabajo de Software estardn presentes, deberd priorizar los requerimientos mas |* Lista de! (Priorizada)'? importantes a reali pre corroborando con la Linea base del| Frequerimientos. Alcance (Aprobado) de! Proyecto. "2 Ver Anexo N* 2 Lista de Requerimientos de Software,38 oN eanBiy 8010038 | 10% janbey ap oseooid [a Boyeu6 es UOYoBNUUCO y sounemmenosi 203504 Ob 8p 62 eulBeg (3ivv) ovrvo A Vr 3a OAISYW 3LNOASNYL 30 ODRILOZTA VWLSIS 730 VNONOLNY aVaINOLNY V1 30 SEVMLIOS 30 OLNSININGINVW A OTIONUYS3A igSA viso10qo1aN D0NEANEYO ‘9bip9;‘Céadiga: OA-INF-MEDOA METODOLOGIA (ae DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA | pssing a0 de 110 ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (ATE) 6.3.2.FASE DE ANALISIS Y DISENO Proyectos de Desarrollo In House En esia Fase se debe realizar el andlisis detallado de cada requerimiento en pequefios entregables (Tareas) y realizables en corto tiempo (No més de un dia), y asi poder agruparlos en un Sprint Backlog y encargarlos a los miembros del Equipo (Team). Dado la agilidad del proyecto a realizar, la planificaci6n se realizara en base a Sprints, los cuales estardn conformados por pequefios grupos de entregables y en plazos establecidos (de 22 4 semanas), dependiendo de la dificutad de cada tarea perteneciente al Sprint, finalizado el plazo del Sprint se realizaré un examen del Sprint en presencia con el Cliente el ‘cual podrd ver los entregablos dosarrollados hasta ese momento (Entrogables funcionales). Proyectos de Desarrollo por Terceros En caso de Proyectos de Desarrollo por Terceros se realiza el trabajo planificado de los entregables de ingenieria que figuran en el Cronograma detallado del Proyecto'®. Se realiza la especificacién de los requerimientos que facilitara el mecanismo apropiado para comprender lo que el cliente quiere (necesidades y deseos), integrarlas, definir una solucién razonable y sin ambigledad, Esta Fase incluye los procesos de Anélisis y Disefio del producto software que cubren una serie de procesos, actividades y tareas que definirén las caracteristicas de la arquitectura del Produsto Software. Estd dividido en cinco procesos esenciales: Elaboracién del Analisis. Disefo de la Interfaz de usuario. Disefio de Componentes del Sistema. Elaboracién del Documento de Arquitectura, Disefio del Modelo de Datos. gene A continuacion la gréfica de los Procesos que integran la Fase de Analisis y Disefio - Mediana y Alta Complejidad. GHG Figura N° 9: Procesos que integran la Fase de Andlisis y Disefio — Mediana y Alta Complejidad jayor tale evisar ol documento MET_PROY-001 Metodologia de Gestién de ProyectosSiMe ‘o40ues0p ap asp (9 EOuadsip and sy szefoly ap UpRERUUY K OaIOHLON ‘oLeWNBeS ap EWAIWELEH Bod sopeInoeD URES widS AP OdwR 1 Sm | ~ b |‘owawinBes ep eiemyog mualweiey e| ap epnke u0Q Zz 4, ofON x) iy s0> quudg Jod seuewes y ez e11Ue @1JeA epualWwooe, vss 2s oipawoid ua A ‘soqo enue ‘odinbe jap ,,pEpIDOIEA cuts | SPP80UEM | Sotnour wares epeo. 9p peunoup top Yapuoda owe s sease) is See eee any banoc widen a squids seoyueig a ouepusrea + |, “og | BBennue op ozerd ofr LNidaS UN UD (wy . e201 @ searey ep sodnuS ap pepques BuE!D seoyUEld & | 2p200id as ‘azemyog ep soiuarwuanbety so] ep upioezuOUd | B| 9p uoloun} ua A ‘seaiey sp| sopednibe Zan BUN *L Bopjoee wuds lp wel) 0 odnuB oyenbed epeo eubise ojne as odinbe (sepedniby) searey y oo1uo9 svar, op vis op yoy | 9P SO:quIONW EpaD Jse A "Js eNUe BpeLODEIA! SUWEYE wee. seer sednuby TT * [9p "| ‘\eise vase, epeo apuop ‘sodniB souenbad ua seaiey sei Ps sedrube @ apeooid as ‘sezi/201 2 Seal8} Sel SEPEISI|Z0A BUN“ (sopezuoid) dnb exenyjog SSOpEISi| B1EMYOS ep ean cwvejuuenber seo opeisr] = |ap 80 | soualwiuenbey so| Uod syduuno eed Jezijees & SeUeseau u ; cowog, | epeo sod sere). 22187 wwatwuenbay | svasey se] upuUjep odinb3 |e OWOD OEY ‘ooIL9eL Jap FAL Wor) ep asn . Sopezuous ems “vopewonu | sore MUS | pyonw eased es OU Jeno Jap ouelwLenbe: UNBIe e1/eIep ews rooney, ep so ; . sojuaiwuenbeey $9] 0180 onb ered ‘seuesedau uees enb S208 $e} eIUEII 2 dint. qualwuenboy odinby + |ap ajeiep —se1pI10g Bo waaey _ oU02 S2uatuna! JeupIoe® upreqep odnba lap SouqWaN $07.“ ST ETE) EN ae (z'¢'9) ASNOH NI OTIONUYSAG - ONASIC A SISITYNY 3d 3Sv4 OEE T ao Pelee Ea ObL ep Le euiBed (3Lwv) ovrivo 4 vIn a9 OnISYW aLNOaSNYaL 30 ODRILOZTa \WwELSIS 7130 VWONOLNY GVGOLNY V7 3d SUVMLJOS 30 OLNSININGINYIN A OTIONNYSAG a TOA TOOSW-INI-VO :061099 viootodo13N Badigo: OA:INF-MEOOI METODOLOGIA ‘Pédigo: OA DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA | pcina go, ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (ATE) a de la velocidad del equipo tad y tiempos de desarrollo estimados por cada tarea, que servird como insumo para la Planificacin de Sprints. 5. Asignar Tareas = Equipo | 3. Cada miembro del Equipo se auto asignard una o varias Lista de| = Lista de Tareas grupos de Tareas (Sprint Backiog ftem), que deberd) Tareas (Asignadas). ar en el plazo establecido segin (Agrupadas) corresponda.‘@sno} ul ojjozes8q — cyesig A sis\IpUY Bp OS8001d ‘OF oN BANBIS fropednusyl save 9p es] soquayujanboy ap ayaap D105 sea4g, eUbisy's suds 3 ue) 3 oamLanoay : a piniod | socom bopeusis samp ew saeuopIey = oyasa 4 SSN asva ott ap ce wuibeg (LWW) ovro 4 vNr7 20 OAISYWN aLNOASNYALL 3a ODRLOZTS \YWaisis 730 VIONOLNY GvORIOANV V1 3d SUVMLIOS 30 OLNAININGINVM A OTIONUYSZO o vyjsoroao1aW TOoEHEIN-VOMETODOLOGIA MEOOT Version 1.0 DESARROLLO Y MANTENIMIENTO DE SOFTWARE DE LA AUTORIDAD AUTONOMA DEL SISTEMA. ELECTRICO DE TRANSPORTE MASIVO DE LIMA Y CALLAO (ATE) Pagina 34 de 110 PROCESOS DE LA FASE DE ANALISIS Y DISENO - DESARROLLO POR TERCEROS (6.3.2) PROCESOS rom hoe oA} ENTRADAS ETE) * Analista Especificacién de los 1. Elaboracién del Ané = Tae [Ver Proceso 6.3.2.1 Elaboracién del Analisis] Casos de Uso del Técnico Sistema (Aprobado) = Disefiador Documento de 2 Disofio de la Interfaz dey [Ver Proceso 6.3.2.2 Disefo de la Interfaz de Usuario] Prototipo de Interfaz usuario Lider de Usuario Técnico (Aprobado) Modelo de < aquitecto Implomentasien 3. Disefio de Iver Proceso 6.3.2.3 Disefio de los Componentes del (Aprobada) Componentes + Lider Sistema] Documento de Técnico A Disefio de Clases (Aprobado). 4 Disefio deta] = Arquitecto [= [Ver Proceso 69.2.4 Elaboracién del Documento de Documento de Arguitectura. Arquitectural Arquitectura, = DBA 7 4 -_ peer ae sew ce | ermecse 62.5 eto delModdl odo Wie oo ase Técnico‘eworsig jp 087 9p s0seD 9p LOI s(eysendog) watsis jep os, ep soseg op ugioeayoeds3 ap BUEIBe(G |e Ue opeayedse 188 Hlecep OOS “SEUIEIBED oun ® BozaUaued osn ep oseo un osko U3 “eoausyed Jeno |1e osn ep oseg ep euiesbeIg [9 UploBIepisuco Ue opua!uey sewersig sopeaioadse J8s upseqap osn ap sose9 soj sopoi ‘ewsisig | ep wIsteUy 2p OSf ap Ose epeO ap oIoBOYIoadse B| JeZIEEL aqep eS ‘| ewaIs'S ep osm ep soseg $0] 9p ugiaeoyloads3 (epeqoidy) exemos Bwalsig [9p os, ap Bwelsig ep osp)_| BlInsuco © Bly BI B SopeUo!OEIaL OsN |p sosED :o\dwle 10d) ep soseg ap eweiBeiq eisr]_+| un ‘soquerwuenbe: so) sopo ap osn ap soseo so 1eueSIq “| “ Lowe sol 28 . come ano eerie ee CUMME ap so ap esr] + 10 op eou F]epRISIEUY +) soins Je0ynuepl (epeqoidy) axemyos, ‘sn ap ose9 sewars BUIsiS jap 057 2 souetuendeyy |iep edouud olny 12 seoynuep! agen 2s ‘Oise opeziee: zen |, visieuy ep ose9 jap rediouud ln ae quep| (ugeuojul op oWwenwUIUeW A sauodes ‘upioeWO!UI ep —_| cowoe4 Jp] 08n1 ap SOseO soise 9p upjsezuOUd BI BZIEO: aS “BWIEISIS sewarsig liep osm ap ose9 ep sewes6eIp so opeziees Zen eu “| |9P__PISIEUY, ‘BWAISIS [9p OSP) @p SOseQ SO] JEZUOUd ep ep BwesdeIg » svarvs TINE) ELEN AM 'se|0y ap BurBsBRIG serious ep euwiBeid «| (epegoidy) evemyos ‘eWOIsig 19P OSN 9p SosED ap eweiBeIC ja seIOGeS Oo sewars BuSISIS 8P | ap soqueluutenbou ‘Ss sn ap soseg seioqoe sonqoadse: sns uo |@P—BISiIeUY esr = BUIBISIS I8P SN BP SOSED SO} UEOYAUAP) as soIsa ep sMed ‘eseMyjOg ep solusjuivenbay 2p eIs!| B| opegoide Z@N BUN DOr ar Bwolsig ep os, ap sose9 so} seo\sIUapI ete Une SISITYNV 73d NOlOvuOavTa “1'2't'9 or ep se euibed (avy) ovTwv9 4 WNIT 20 OAISYWN aLNOdSNVEL 30 091819373 \WHALSIs 730 VWONOLNY GVGINOLNY V1 30 SUVAULIOS 30 OLNAININGINVM A OTIONNVSIO TL USSR TOGaREaNI¥O 25199 yioo1odo13W