S ervicios de Desarrollo de Software (SDES) · ARCHIVO: Definición de los Servicios de Desarrollo CREADO: 29/3/2016 09:31 hs VERSION DEL 3/5/2016 03:05 hs Autor: Proyecto Gestión

ARCHIVO: Definición de los Servicios de Desarrollo CREADO: 29/3/2016 09:31 hs VERSION DEL 3/5/2016 03:05 hs

Autor: Proyecto Gestión de Servicios TI para CSEI PALABRAS: 9642 Nº. PÁG: 1/40

Banco de Previsión Social Coordinación de Servicios Informáticos

Servicios de Desarrollo de Software (SDES)

Documento de

DEFINICIÓN DE LOS SERVICIOS DE DESARROLLO DE SOFTWARE

Versión 2.9




Registros del documento

REGISTRO DE REALIZACION:

Completado por : Estela Hornos, Carolina Valverde Fecha : Mayo de 2012 Autorizado por : Gerencia SDES Estado : TRABAJO/REVISION/APROBADO

REGISTRO DE CAMBIOS:

Fecha Versión Responsable Cambio

08/05/2012 0.1 Estela Hornos, Carolina Valverde Creación del documento – primer borrador de la definición del Servicio de Desarrollo

01/03/2013 0.2 Estela Hornos, Gonzalo Arzúa, Carolina Valverde

Ajustes en el Servicio de Desarrollo a partir de comentarios recibidos de los Centros de Desarrollo

13/05/2013 0.5 Carolina Valverde, Estela Hornos Ajustes en Sección 3.Proceso del Servicio de Desarrollo

26/06/2013 0.6 Estela Hornos, Carolina Valverde Ajustes en secciones 5 y 6, a partir de feedback obtenido de la ejecución de Talleres.

26/08/2013 1.1 Carolina Valverde Inclusión de la definición del Servicio de Mantenimiento

04/09/2014 2.1 Carolina Valverde Ajustes de redacción. Las referencias a marcos conceptuales se mueven a “CSEI-Marcos de Referencia”.

01/12/2014 2.2 Carolina Valverde Inclusión de la definición del Servicio de Adecuación y Personalización de Paquetes

28/07/2015 2.6 Patricia Rolandi, Carolina Valverde

Ajustes en el documento a partir de revisiones y de modelado de servicios en EPF

28/12/2015 2.7 Patricia Rolandi, Agustín Mullin, Carolina Valverde

Inclusión de la definición del Servicio de Explotación de Información. El tipo “Desarrollo BI” se mueve a este nuevo servicio.

12/02/2016 2.9 Carolina Valverde Inclusión de los Servicios: Soporte, e Innovación y Propuestas al Negocio.

REGISTRO DE REVISIONES Y APROBACIONES:

Fecha Versión Revisor

01/03/2013 0.3 Gerencias Centros de Desarrollo

19/03/2013 0.4 Gonzalo Arzúa


06/09/2013 1.2 Estela Hornos

17/09/2013 1.3 Gerencias Centros de Desarrollo


11/12/2014 2.3 Estela Hornos, Mónica Borso


13/02/2015 2.5 Roque Villamil




29/12/2015 2.8 Gonzalo Arzúa, Virgina Casciato, Julia Ramponi, Estela Hornos




Contenido

SERVICIO DE DESARROLLO .......................................................................................................................7

1 PROPÓSITO ...........................................................................................................................................7

2 ALCANCE ..............................................................................................................................................7

2.1 CONTEXTO ..................................................................................................................................................... 7

2.2 TIPOS ............................................................................................................................................................ 7

2.3 MODALIDADES ............................................................................................................................................... 7

3 PROCESO ..............................................................................................................................................8

3.1 PROCESOS INTEGRADOS ................................................................................................................................... 8

3.2 PROCESO DEL PRODUCTO (RUP) – DESARROLLO ESTÁNDAR ................................................................................ 10

3.3 PROCESO DEL PRODUCTO (SCRUM) – DESARROLLO ÁGIL ................................................................................... 12

3.4 PROCESO DEL PRODUCTO - DESARROLLO ORIENTADO A PROCESOS ....................................................................... 14

3.5 PROCESOS DE GESTIÓN DE SOPORTE AL SERVICIO (ITIL) ...................................................................................... 14

3.6 GRUPOS DE PROCESO DE GESTIÓN DE PROYECTOS (PMBOK) .............................................................................. 14

4 ROLES ................................................................................................................................................ 14

5 ENTREGABLES Y CRITERIOS DE ACEPTACIÓN ................................................................................................ 15

6 HITOS Y ACTIVIDADES ............................................................................................................................ 15

7 VISTAS DEL SERVICIO ............................................................................................................................. 17

8 MÉTRICAS ........................................................................................................................................... 17

9 GLOSARIO ........................................................................................................................................... 17

10 ANEXOS ............................................................................................................................................ 17

SERVICIO DE MANTENIMIENTO .............................................................................................................. 18

1 PROPÓSITO ......................................................................................................................................... 18

2 ALCANCE ............................................................................................................................................ 18

2.1 CONTEXTO ................................................................................................................................................... 18

2.2 TIPOS .......................................................................................................................................................... 18

2.3 MODALIDADES ............................................................................................................................................. 19

3 PROCESO ............................................................................................................................................ 19

3.1 PROCESOS INTEGRADOS ................................................................................................................................. 19

3.2 PROCESO DEL PRODUCTO (RUP) – MANTENIMIENTO ESTÁNDAR .......................................................................... 20

3.3 PROCESO DEL PRODUCTO (KANBAN O SCRUMBAN) – MANTENIMIENTO ÁGIL ......................................................... 21


3.5 PROCESO DE GESTIÓN ................................................................................................................................... 21

4 ROLES ................................................................................................................................................ 22







8 MÉTRICAS ........................................................................................................................................... 24

9 GLOSARIO ........................................................................................................................................... 24

10 ANEXOS ............................................................................................................................................ 24

SERVICIO DE PERSONALIZACIÓN Y ADECUACIÓN DE PAQUETES .............................................................. 25

1 PROPÓSITO ......................................................................................................................................... 25

2 ALCANCE ............................................................................................................................................ 25

2.1 CONTEXTO ................................................................................................................................................... 25

2.2 TIPOS .......................................................................................................................................................... 25

2.3 MODALIDADES ............................................................................................................................................. 25

3 PROCESO ............................................................................................................................................ 25

3.1 PROCESO DE PERSONALIZACIÓN Y ADECUACIÓN DEL PAQUETE ............................................................................. 25

3.2 PROCESO DE ACTUALIZACIÓN DE VERSIONES DEL PAQUETE .................................................................................. 27



4 ROLES ................................................................................................................................................ 28




8 MÉTRICAS ........................................................................................................................................... 29

9 GLOSARIO ........................................................................................................................................... 29

10 ANEXOS ............................................................................................................................................ 29

SERVICIO DE EXPLOTACIÓN DE INFORMACIÓN ....................................................................................... 30

1 PROPÓSITO ......................................................................................................................................... 30

2 ALCANCE ............................................................................................................................................ 30

2.1 CONTEXTO ................................................................................................................................................... 30

2.2 TIPOS .......................................................................................................................................................... 30

2.3 MODALIDADES ............................................................................................................................................. 30

3 PROCESO ............................................................................................................................................ 30

3.1 PROCESO DEL PRODUCTO – SOLICITUD DE INFORMACIÓN .................................................................................... 30

3.2 PROCESO DEL PRODUCTO – DESARROLLO BI ..................................................................................................... 32

3.3 PROCESO DE GESTIÓN ................................................................................................................................... 34


4 ROLES ................................................................................................................................................ 34







8 MÉTRICAS ........................................................................................................................................... 37

9 GLOSARIO ........................................................................................................................................... 37

10 ANEXOS ............................................................................................................................................ 37

SERVICIO DE SOPORTE ........................................................................................................................... 38

1 PROPÓSITO ......................................................................................................................................... 38

2 ALCANCE ............................................................................................................................................ 38

2.1 CONTEXTO ................................................................................................................................................... 38

2.2 TIPOS .......................................................................................................................................................... 38

2.3 MODALIDADES ............................................................................................................................................. 38

3 PROCESO ............................................................................................................................................ 38

4 ROLES ................................................................................................................................................ 38


6 HITOS ................................................................................................................................................ 38

7 MÉTRICAS ........................................................................................................................................... 39

8 GLOSARIO ........................................................................................................................................... 39

SERVICIO DE INNOVACIÓN Y PROPUESTAS AL NEGOCIO .......................................................................... 40




SERVICIO DE DESARROLLO

1 PROPÓSITO

Este servicio tiene como propósito brindar, mediante el desarrollo de software, soluciones informáticas a nuevas necesidades de negocio o extensiones/evoluciones mayores de aplicaciones ya operativas de las distintas unidades de BPS, u otros ámbitos para los que el BPS se proponga (ejemplo: Estado, Mercosur, etc). Se considera una evolución mayor a aquellos desarrollos cuyo esfuerzo supera las 500 horas hombre, o se considere conveniente a juicio de la gerencia de SDES, ya sea por su visibilidad, dependencias y/o criticidad.

2 ALCANCE

2.1 Contexto Alcanza a todo CSEI (con mayor participación de SDES) y a los sectores funcionales de BPS.

2.2 Tipos Se definen diferentes tipos del servicio de desarrollo, según el proceso que se aplica.

Desarrollo estándar

Desarrollo ágil

Desarrollo orientado a procesos (herramientas de workflow)

2.3 Modalidades El servicio se brindará en distintas modalidades:

Desarrollo Interno: provisto por los Servicios de Desarrollo de BPS propiamente dichos.

Desarrollo Tercerizado: Integración exclusiva del equipo de desarrollo con recursos de la empresa de TI contratada por BPS, y cuyas contrapartes técnicas son los Servicios de Desarrollo de BPS.

Desarrollo Mixto: Integración mixta del equipo de desarrollo con recursos del proveedor y de los Servicios de Desarrollo de BPS.

El BPS podrá proponer la integración de técnicos propios al equipo de trabajo del proveedor, o viceversa. En ese caso, las tareas a asignar a dichos técnicos se acordarán entre ambas partes.

Tutoría: el BPS podrá proponer la integración de técnicos propios al equipo de trabajo del proveedor, el cual será responsable de la tutoría de los mismos, orientando su aprendizaje práctico de todas las actividades necesarias para el desarrollo y posterior mantenimiento del aplicativo. Los técnicos BPS que se incorporan en esta modalidad no podrán a la vez cumplir con el rol de contraparte, para el mismo proyecto.




3 PROCESO

3.1 Procesos Integrados A continuación se describe cómo se relacionan e interactúan los cinco grupos de procesos de gestión (descritos en las próximas secciones), con el ciclo de vida del proceso del producto y con los procesos de gestión de soporte al servicio. Vale mencionar que varias de las actividades correspondientes dichos procesos se superponen a lo largo del ciclo de vida de un proyecto.

Los grupos de procesos de gestión aseguran que el proyecto avance de manera eficaz durante toda su existencia. Un grupo de procesos incluye los procesos consecutivos de la gestión de proyectos que están vinculados por las entradas y salidas respectivas, de este modo el resultado de un proceso se convierte en la entrada de otro [ref: PMBOK].

El proceso del producto especifica y crea el producto del proyecto (esto es, el desarrollo propiamente dicho), en base a las fases definidas para el mismo.

Los procesos de soporte al servicio se ocupan de todos los aspectos que garanticen la continuidad, disponibilidad y calidad del servicio prestado al usuario. Se centra en asegurar que el Cliente tenga acceso a los servicios adecuados para soportar las funciones de negocio.

Los porcentajes presentados representan la distribución del esfuerzo a lo largo del ciclo de vida de un proyecto de desarrollo, y son tomados de valores estándares de la industria (para el proceso del producto basado en RUP), de valores planteados por autores reconocidos certificados en el PMI (Pablo Lledó, Rita Mulcahy, para los grupos de procesos de gestión), y de la propia experiencia de la organización (para los procesos de soporte al servicio).

Figura 1-Relación entre los Procesos de Soporte, Gestión y Producto del Servicio de Desarrollo




La Figura 1 ilustra cómo se integran los diferentes procesos durante el ciclo de vida de un proyecto de desarrollo.

Se describe, por cada uno de los grupos de procesos de gestión, las principales actividades que se llevan a cabo integrando el proceso del producto y de soporte al servicio.

Inicio (5%)

Durante el inicio del proyecto se comienza a elaborar el modelado del negocio y diseño macro (proceso orientado al producto) como parte del alcance inicial.

Planificación (20%) – Planificación Inicial (15%) + Planificación Gradual (5%)

Durante la planificación inicial se trabaja fuertemente en completar el modelado del negocio y diseño macro (proceso orientado al producto), y se relevan los requerimientos principales a alto nivel. Todo esto será la base para la planificación inicial de los releases a construir.

También se realiza la planificación de las comunicaciones, recursos, riesgos, calidad, etc.

Las actividades de planificación gradual se llevan a cabo durante todo el ciclo de vida del proyecto.

Además se planifican las actividades correspondientes a los procesos de soporte: gestión de cambios, liberaciones y configuraciones.

Ejecución (55%)

Durante la ejecución del proyecto se construye el producto propiamente dicho, y se ejecutan cada uno de los releases definidos durante la planificación (esto es, se lleva a cabo el proceso del producto). Por cada release, se ejecutan todas las fases del ciclo (Requerimientos, Análisis y Diseño, Construcción y Verificación, Validación e Implantación). El resultado de cada release será input para la ejecución de los próximos.

La coordinación y orquestación de estas actividades están enmarcadas en los procesos de soporte al servicio.

Seguimiento y Control (15%)

Las actividades de seguimiento y control se llevan a cabo durante todo el ciclo de vida del proyecto.

Cierre (5%)

Incluye las actividades de cierre del proyecto.




3.2 Proceso del Producto (RUP) – Desarrollo estándar A continuación se describen las fases que conforman el proceso del producto para un desarrollo estándar, basadas en RUP. La Figura 2 ilustra dicho proceso.

Figura 2-Proceso del Producto basado en RUP (Desarrollo Estándar)

I. Modelado de Negocio y Diseño Macro

Esta primera etapa comprende la definición de los procesos de negocio y los requerimientos macro del producto que forman parte del alcance del mismo, así como sus fronteras. A partir de estos se realiza un primer diseño macro del sistema (vista de la arquitectura) de manera de mostrar los principales componentes a alto nivel y sus interacciones. También se realiza el análisis de impacto macro que tendrá la construcción del producto en los procesos y organización.

El objetivo principal es establecer el alcance total del producto (a nivel funcional y no funcional); este será la base para la planificación de los releases en los cuales será construido el mismo.

II. Ciclo del Release

Para cada subproducto de software (release) incluido en el Plan de Releases, se recorre el ciclo completo del release que se detalla a continuación. Por lo tanto, existen tantos ciclos de desarrollo como releases se hayan indicado en el Plan.

Fase 0- Requerimientos

A partir de los procesos de negocio y requerimientos macro definidos, se especifican en detalle los requerimientos del sistema, tanto a nivel funcional como no funcional.

Además, a partir del diseño macro y los requerimientos no funcionales se complementa la arquitectura del sistema.

El objetivo principal de esta fase es describir qué es lo que debe hacer el sistema para ese release, y permite que tanto las áreas técnicas como funcionales acuerden en conjunto cuáles son los requerimientos. Para ello se deben obtener, organizar y documentar los requerimientos de funcionalidad así como las restricciones.

Fase 1- Análisis y Diseño

Se analiza la solución funcional, incluyendo la especificación de las funcionalidades requeridas en términos de casos de uso, y el modelado de las principales entidades del sistema.

Se completa y especifica en detalle la arquitectura del sistema. Se realiza el diseño detallado del sistema, incluyendo su estructura, componentes, responsabilidades e interacciones, y las decisiones tomadas a nivel de arquitectura y diseño.

Fase 2 Fase 0-Requeri-mientos

Fase 1-Análisis y Diseño

Fase 3- Validación (Aceptación)

Fase 4- Implanta-ción

Fase 2.1-Construcción

Fase 2.2-Verificación

I. Mod Neg y Diseño Macro





El objetivo es mostrar cómo el sistema será construido, de forma tal que sea capaz de cumplir con los requerimientos funcionales y no funcionales definidos en la fase anterior.

Fase 2- Construcción y Verificación

Esta fase comprende, por un lado, la construcción del producto propiamente dicho, así como de las funcionalidades de migración, depuración y réplicas si corresponde; y por otro lado, la verificación de los módulos implementados.

Dentro de esta fase se incluye también el esfuerzo de rework de testeo, esto es, la corrección de los defectos encontrados durante la verificación y la validación del producto.

o Fase 2.1: Construcción

Los objetivos principales de esta fase incluyen:

Definir la organización del código, en términos de subsistemas y capas, e implementar las clases/módulos definidos.

Integrar los módulos construidos.

Verificar los componentes a nivel unitario así como su integración, lo cual puede requerir de la construcción de componentes adicionales (stubs y/o drivers).

Para la construcción del software se deberán considerar las guías y pautas que se hayan definido.

Si corresponde, se construye un prototipo de la aplicación con el fin de mitigar ciertos riesgos y/o validar la solución brindada.

o Fase 2.2: Verificación

La verificación (o testeo interno) incluye el testeo del sistema completo, incluyendo el testeo tanto a nivel de la funcionalidad, como de los requerimientos no funcionales (técnicos). Deberá contemplar los requerimientos definidos en el Plan o Estrategia de Testing así como las Guías existentes, debiendo especificar, documentar y ejecutar los casos de prueba definidos.


Verificar la correcta interacción entre los objetos e integración de componentes.

Verificar que todos los requerimientos fueron correctamente implementados.

Identificar defectos, y asegurarse que son corregidos antes de la liberación del producto.

Fase 3- Validación (Testeo de Aceptación)

En esta fase se realiza la validación (aceptación) del producto, de acuerdo a lo establecido en el Plan o Estrategia de Testeo, por parte de los responsables del producto.

Se ejecutan los casos de testeo y se realizan los reportes correspondientes. Esto incluye pruebas de sistema principalmente a nivel funcional y de usabilidad. En caso de requerirse, también podrían realizarse las pruebas de stress y performance.


o Validar que el producto construido es correcto, esto es, satisface las necesidades y requerimientos del negocio.

o Identificar defectos, y asegurarse que son corregidos antes de la liberación del producto.

Fase 4- Implantación

Corresponde a la liberación de la aplicación en ambiente operativo (de producción) para ser usada por los usuarios finales. Tener en cuenta que algunas de las actividades comprendidas en esta fase deben ser iniciadas desde fases anteriores, tales como la estrategia de implantación, la construcción del ambiente y la generación de planes posibles de vuelta atrás, entre otros.




Además de la puesta en producción propiamente dicha, se libera la documentación del producto al usuario (Manuales de Usuario y Procedimiento), se realiza la verificación post-implantación y aceptación formal del producto.

Incluye también la ejecución de la capacitación (si corresponde), y el soporte del producto post-liberación.

3.3 Proceso del Producto (SCRUM) – Desarrollo Ágil Esta metodología debe ser combinada con las metodologías y marcos de referencias antes descriptos.

La descripción detallada del Proceso de Desarrollo basado en SCRUM se encuentra en el documento “Metodologías Ágiles”.

A continuación se describen las fases que conforman el proceso del producto y de gestión para un desarrollo ágil, basadas en SCRUM. La Figura 3 ilustra dicho proceso.

Ciclo del Release

Ciclo del Sprint

Modelado de Negocio y

Diseño Macro

Release Planning

ProductBacklog

Sprint Planning

SprintBacklog

SPRINT PROCESS Daily Meeting

Potentially Shippable Product

Product Review

Sprint Retrospective

Sprint 0

Figura 3 – Proceso del Producto basado en SCRUM

Consiste de las siguientes actividades (macro):

1. Modelado de Negocio y Diseño Macro

Esta etapa se ejecuta teniendo en cuenta las mismas consideraciones que para el Proceso del Producto basado en RUP.

2. Release Planning (equivalente a proceso de gestión – Planificación)

Por cada release que se haya definido durante la etapa de planificación inicial, se ejecuta el release planning.

El objetivo de esta reunión es definir:

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Metodologías%20Ágiles.pdf




Cuántos Sprints se ejecutarán, y de qué duración (timebox)

Fechas de inicio y fin: para el release y para cada Sprint

Planificación de las reuniones: Planning, Review, Retrospective

Visión del producto, a partir de las necesidades planteadas por el Producto Owner

Product Backlog del producto

Acuerdos generales:

o Team agree (acuerdo del equipo de trabajo)

o Criterio de listo (condiciones que debe cumplir el requerimiento para pasar a “DONE”)

2.1: Sprint 0

Los objetivos del Sprint 0 son:

o Adecuar la infraestructura de trabajo necesaria y el ambiente de desarrollo

o Definir y adecuar el escenario de construcción y las herramientas a utilizar

o Definir el esquema de seguridad y la arquitectura general – diseño macro del release

o Coordinar la generación del Product Backlog (para el release en cuestión, en base a la visión comprometida). El Product Owner asigna el valor de negocio para cada requerimiento.

3. Sprint planning (equivalente a proceso de gestión – Planificación)

Por cada Sprint que se haya definido durante el release planning, se ejecuta el Sprint Planning.

Los objetivos de esta reunión son:

Estimación de los puntos de esfuerzo para cada requerimiento por parte del Team.

Acuerdo de fechas:

o Con el Product Owner, se planifica el testeo de aceptación

o Con los Servicios de Infraestructura (SITO), se planifican las liberaciones en testeo y producción

Como resultado de esta planificación, se obtiene el backlog comprometido para el próximo Sprint, priorizado según el ROI (Valor de Negocio/Estimación).

4. Sprint process (equivalente al proceso del producto – Ejecución (todas las fases), y de soporte)

Es la ejecución propia del Sprint, durante la cual el team lleva adelante el trabajo comprometido.

Durante la ejecución del Sprint, se ejecutan las mismas etapas del Ciclo del Release correspondientes al Proceso del Producto basado en RUP (Requerimientos, Análisis y Diseño, Construcción, Verificación, Validación e Implantación), pero con menor rigurosidad.

4.1: Daily Meeting

Cada integrante del Team comunica:

o Avance del día

o Compromiso para el día siguiente

o Dificultades encontradas

o Opcionalmente, puede comunicar los puntos de esfuerzo realizados

5. Product review (equivalente al proceso del producto – Ejecución (Validación))

La revisión se realiza al final de cada Sprint, en base a los criterios de aceptación definidos.

Como resultado de la reunión, se obtiene la Conformidad/No conformidad para cada uno de los requerimientos por parte del Product Owner. También pueden surgir nuevos requerimientos y/o correcciones (bugs), que serán tenidos en cuenta en el próximo Sprint planning.




6. Sprint retrospective (equivalente a proceso de gestión – Seguimiento y Control)

El objetivo de esta reunión es revisar el proceso para mejorarlo.

Como resultado de la retrospectiva se obtiene el Process Backlog.

3.4 Proceso del Producto - Desarrollo Orientado a Procesos // Falta descripción, se completará en próxima versión del documento

3.5 Procesos de Gestión de Soporte al Servicio (ITIL) Los procesos que intervienen durante el Servicio de Desarrollo son: Gestión de Cambios, Gestión de Configuraciones, Gestión de Liberaciones. Ver: Definiciones de los Procesos.

3.6 Grupos de Proceso de Gestión de Proyectos (PMBOK) Estos grupos procesos son soportados por la plataforma de gestión de Proyecto, herramienta MS-PWA (Project Web Access). Ver: Definiciones para Gestión de Proyectos.

El Proceso de Gestión para los Servicios de Desarrollo que se ejecutan en modalidad de proyecto, se encuentra modelado en la herramienta EPF.

Para los procesos de Gestión Ágil ver documento de Metodologías Ágiles.

4 ROLES

Los roles y responsabilidades se encuentran descriptos en la planilla Excel SDES-Roles.

Nota: cuando cualquier rol se ejecuta como Contraparte, las responsabilidades principalmente serán de coordinación, participación y aprobación más que de elaboración.

http://intranetbps/sitios/cyms/cyp/Resultados%20de%20Proyectos/Forms/AllItems.aspx

http://intranetbps/sitios/activos_generales/Proyecto/Forms/AllItems.aspx

http://intranetbps/sitios/sdes/Gestin%20de%20Servicios%20de%20SDES/Roles-Servicios%20de%20Desarrollo.pdf




5 ENTREGABLES Y CRITERIOS DE ACEPTACIÓN

La Figura 4 muestra la EDT de productos entregables para el Servicio de Desarrollo (Proceso Estándar), integrando en el ciclo de vida de un Proyecto de Desarrollo los entregables correspondientes al proceso del producto y gestión.

Además se indica para cada entregable si existe un activo general asociado (ver sitio de Activos Generales).

También se cuenta con un diccionario de activos (en elaboración) donde se detalla por cada activo, a qué etapa corresponde, su objetivo/alcance, y los roles asociados.

El listado completo de los activos generales que aplican para el Servicio de Desarrollo, incluyendo entregables, pautas, guías y lineamientos, se encuentran en la lista de Servicio Desarrollo-Entregables, Pautas y Lineamientos, en el Sitio de Activos Generales. Los activos se encuentran agrupados por Grupo de Proceso de Gestión, y por Fase del proceso del producto a la que pertenecen. Para el caso de los entregables, la fase corresponde al momento en el que se elabora o completa el activo; para el caso de las pautas y lineamientos, la fase corresponde al momento en el cual debe ser considerado. Notar que si un activo es utilizado en más de una fase, entonces se incluye en cada una de estas.

Además, se indica, por cada activo:

A qué proceso corresponde: Producto, Producto-orientado a la Gestión, Gestión.

Qué tipo de activos es: si es Entregable, Pauta, Guía o Lineamiento, y si es Activo General o funcionalidad en PWA. Notar que además desde cada plantilla de entregable se hace referencia la pauta que se debe considerar (en sección “Anexos”).

Un link al documento en Activos Generales

Si es mínimo o no.

Esta lista contiene las siguientes vistas:

Entregables, Pautas y Lineamientos: contiene todos los entregables, pautas, guías y lineamientos que aplican para el servicio de desarrollo.

Todas las Pautas y Lineamientos: contiene todos los activos que son pautas, guías y lineamientos generales que aplican para el servicio de desarrollo.

Todos los Entregables: contiene todos los activos que son entregables que aplican para el servicio de desarrollo.

Entregables mínimos: contiene solo los entregables mínimos que aplican para el servicio de desarrollo.

6 HITOS Y ACTIVIDADES

En la Figura 4 se incluye la EDT de Entregables Base, que integra los entregables de todos los procesos que hacen al Servicio de Desarrollo (del producto, de gestión y de soporte), e incluye los roles responsables. El contenido de esta EDT constituye la base para la elaboración del cronograma de actividades del proyecto.

http://intranetbps/sitios/activos_generales

http://intranetbps/sitios/sdes/Lists/Servicio%20DesarrolloEntregables%20Pautas%20y%20Lineamient/TodosEntregablesPautas.aspx

http://intranetbps/sitios/sdes/Lists/Servicio%20DesarrolloEntregables%20Pautas%20y%20Lineamient/TodosEntregablesPautas.aspx

http://intranetbps/sitios/sdes/Gestin%20de%20Servicios%20de%20SDES/Servicio%20Desarrollo-EDT%20Entregables%20Base.pdf


Autor: Control y Mejora de los Servicios PALABRAS: 9642 Nº. PÁG: 16/40


Entregable orientado al proceso del producto, con Activo General asociado

Entregable orientado al proceso del producto, sin Activo General asociado

Entregable orientado a procesos de gestión, con Activo General asociado

Entregable orientado a procesos de gestión, sin Activo General asociado

Figura 4 – EDT de Entregables Base (Proceso de Desarrollo Estándar)




7 VISTAS DEL SERVICIO

En la herramienta EPF (Eclipse Process Framework Composer) se encuentran modeladas las siguientes Vistas para el Servicio de Desarrollo:

Por Proceso: ver todas las actividades que corresponden a cada Etapa y Fase del proceso, los entregables asociados y roles que participan.

Por Roles: ver todos los roles que participan en el servicio, en qué actividades y entregables intervienen, y en qué Etapa y Fase están ubicados.

Por Entregables: ver todos los entregables que se generan durante el servicio, qué roles son responsables de cada uno de ellos, como resultado de qué actividad se generan o actualizan, y en qué Etapa y Fase del proceso.

Por EDT (Estructura de Desglose de Trabajo): muestra de forma unificada y concisa todas las vistas mencionadas anteriormente: actividades, roles, entregables y su vinculación. Además se visualizan los diagramas en SPEM (Software & Systems Process Engineering Metamodel) asociados a cada Etapa y Fase del proceso.

8 MÉTRICAS

Los objetivos e indicadores de Esfuerzo definidos para SDES se encuentran detallados en: CSEI - Objetivos Indicadores Esfuerzo y Metas.

La definición detallada de estos indicadores se encuentra en la planilla: CSEI- Definiciones Indicadores Esfuerzo.

9 GLOSARIO

RUP: Rational Unified Process (descripto en Manual de Calidad SDES)

ITIL: Information Technology Infraestructure Library (descripto en Manual de Calidad CSEI)

PMBOK: Project Management Book Of Knowledge (descripto en Manual de Calidad CSEI)

PMI: Project Management Institute (descripto en Manual de Calidad CSEI)

EDT: Estructura Detallada de Trabajo

10 ANEXOS

Afiche SDES: incluyendo Procesos, Entregables y Participantes del Servicio de Desarrollo

http://intranetbps/sitios/activos_generales/Medicin%20y%20Anlisis/CSEI%20-%20Objetivos%20Indicadores%20Esfuerzo%20y%20Metas.pdf


http://intranetbps/sitios/sdes/Gestin%20de%20Servicios%20de%20SDES/Servicio%20Desarrollo-Afiche.pdf

http://intranetbps/sitios/activos_generales/Medicin y Anlisis/CSEI - Objetivos Indicadores Esfuerzo y Metas.pdf

http://intranetbps/sitios/activos_generales/Medicin y Anlisis/CSEI- Definiciones Indicadores Esfuerzo.xls




SERVICIO DE MANTENIMIENTO

1 PROPÓSITO

El propósito de este servicio es brindar, mediante el desarrollo de software, soluciones informáticas a necesidades y/o cambios sobre aplicaciones ya operativas de las distintas unidades de BPS u otros ámbitos para los que el BPS disponga.

Comprende las actividades necesarias para realizar la gestión de cambios sobre aplicativos ya desarrollados por otros servicios (Desarrollo, Personalización y adecuación de paquetes, y Transferencia) que se encuentran en régimen de producción.

2 ALCANCE


2.2 Tipos El servicio de mantenimiento se clasifica según la naturaleza del cambio.

Mantenimiento Correctivo

Los “cambios correctivos” son aquellos que modifican el comportamiento del sistema pues este es distinto al que se había especificado o al que se esperaba.

Incluye la corrección de defectos presentes en los aplicativos que ya se encuentran operativos, ya sea que fueron introducidos durante el desarrollo del mismo o durante su mantenimiento.

Un defecto es una desviación del comportamiento del sistema con respecto al alcance especificado en los documentos oficiales y/o contractuales.

Dependiendo de la criticidad y urgencia del defecto, el cambio correctivo se clasifica en:

Correctivo Urgente (no planificable): aplica cuando existe un error en el producto software que bloquea la aplicación o el proceso de funcionamiento, y que debe ser resuelto a la brevedad. Corresponden a peticiones que deben ser rápidamente atendidas, y por lo tanto no pueden ser planificadas.

Correctivo No Urgente (planificable): aplica cuando existe un error en el producto software que, aunque no es crítico y será planificado, puede impedir el normal funcionamiento de la aplicación.

Dentro de este tipo de mantenimiento también se incluyen los “cambios preventivos”. Estos se aplican cuando se desea mejorar las características internas de un producto software buscando que en un futuro el esfuerzo de mantenimiento sea menor. Esto es, se introducen cambios para prever fallas.

Mantenimiento Extensivo

Los “cambios extensivos” (también denominados “perfectivos” o “evolutivos”) son aquellos que mejoran o extienden el comportamiento de una funcionalidad que se está comportando correctamente.

Involucra cambios en el aplicativo para mejorar alguna de sus cualidades, lo cual puede deberse a la necesidad de modificar las funcionalidades ofrecidas por la aplicación, agregar nuevas funcionalidades, mejorar la performance, entre otros.

Este tipo de mantenimiento es siempre planificable.

Mantenimiento Adaptativo




Involucran ajustes en la aplicación por cambios en el entorno. En este caso la necesidad del cambio no se origina por una característica misma del software sino que por cambios en el ambiente (ejemplo, hardware, sistema operativo, base de datos). Se aplica cuando el software en explotación va a cambiarse para que continúe funcionado correctamente en un entorno cambiante.

Este tipo de mantenimiento es siempre planificable.

2.3 Modalidades El servicio se brinda en las mismas modalidades que el Servicio de Desarrollo (ver Sección 2.3 Modalidades del Servicio de Desarrollo).

3 PROCESO

3.1 Procesos Integrados A continuación se describe cómo se relacionan e interactúan los procesos de gestión (Planificación y Seguimiento), de elaboración del producto (Ejecución) y de soporte al servicio. La descripción detallada de cada uno de estos procesos se encuentra en la sección 3.1 Procesos Integrados del Servicio de Desarrollo.

PLANIFICACIÓN Y SEGUIMIENTOdel Release/RFC

DE GESTIÓN

DEL PRODUCTO

DE SOPORTE

20%

5%

75%

F0-Reqs

F1-Análisis y Diseño

F2.1-Contrucción

F3-ValidF4-Imp

30%5% 40% 5%10%

PROCESOS

TIEMPO

Procesos de Gestión

Ciclo de Planificación

PLANIFICACIÓNMantenimiento EJECUCIÓN del Release/RFC

Fases del ProductoF2.2-

Verificación

10%

Ciclo del Release

Figura 5-Relación entre los Procesos de Soporte, Gestión y Producto del Servicio de Mantenimiento

La Figura 5 ilustra cómo se integran los diferentes procesos durante el ciclo de vida de un mantenimiento.

Planificación del Mantenimiento (5%)




De manera periódica se realiza la planificación de los cambios que se incluirán en cada uno de los releases o versiones para una aplicación, o para las aplicaciones en el contexto de un determinado negocio.

Ejecución del Release /RFC (75%)

Durante la ejecución del ciclo del producto, se llevan a cabo los cambios planificados para ese release (esto es, se lleva a cabo el proceso del producto), y se ejecutan todas las fases del ciclo (Requerimientos, Análisis y Diseño, Construcción y Verificación, Validación e Implantación).

La coordinación y orquestación de estas actividades están enmarcadas en los procesos de soporte al servicio.

Planificación y Seguimiento del Release/RFC (20%)

Acompañando la ejecución del ciclo del producto, se realiza la planificación gradual y seguimiento de los cambios planificados para ese release.

3.2 Proceso del Producto (RUP) – Mantenimiento estándar El proceso de Mantenimiento es equivalente al ciclo de un release del Servicio de Desarrollo, la diferencia básica está en el alcance del problema a resolver y de los entregables a elaborar y/o ajustar.

Figura 6-Proceso del Producto basado en RUP (Mantenimiento Estándar)

Ejecución del Ciclo del Release

Durante la ejecución del proceso se cumplen las fases que permitirán la implantación de los Cambios y mantener actualizada la Documentación de la Aplicación.

La descripción detallada de cada una de las fases se encuentra descripta en la sección 3.2 Proceso del Producto (RUP) – Desarrollo estándar del Servicio de Desarrollo. A continuación se describe brevemente cada una de las fases con las particularidades que aplican para el Servicio de Mantenimiento.

Fase 0- Requerimientos: se registra el requerimiento de cambio, y se realiza el diagnóstico inicial.

Fase 1- Análisis y Diseño: se realiza el análisis de la solución, y la estimación detallada.


o Fase 2.1: Construcción: implementación del cambio solicitado y testeo interno del mismo.

o Fase 2.2: Verificación: testeo del cambio por parte de un equipo de pruebas independiente.

Fase 3- Validación (Testeo de Aceptación): aceptación del cambio por parte del solicitante.

Fase 4- Implantación: puesta en producción del cambio. Se actualiza la línea base, incluyendo las nuevas versiones de los componentes impactados por el cambio.

Para los mantenimientos de tipo urgente, el proceso del ciclo del release se podría ver reducido y los entregables completarse al finalizar el mismo.

Fase 2 Fase 0-Requeri-mientos

Fase 1-Análisis y Diseño





Ciclo del Release




3.3 Proceso del Producto (Kanban o Scrumban) – Mantenimiento ágil Esta metodología debe ser combinada con las metodologías y marcos de referencias descriptas en este servicio.

La descripción detallada del Proceso de Mantenimiento basado en Kanban o Scrumban se encuentra en el documento Metodologías Ágiles.

A continuación se describen las principales características que conforman el proceso del producto para un mantenimiento ágil. Esto corresponde a la etapa “Ejecución del Release /RFC”.

• Se define un flujo en función a las fases del proceso del producto (F0 a F4).

• Cada requerimiento de cambio se especifica en una tarjeta.

• Existen tantos elementos (tarjetas) en el dashboard como requerimientos de cambios se hayan validado.

• Cada elemento debe pasar por cada una de las fases del proceso del producto.

• Cada fase tiene su propio límite WIP: cantidad máxima de elementos que pueden estar al mismo tiempo en una misma fase.

• Por cada bloque se obtendrá un “Lead Time”: tiempo promedio en que un elemento toma en pasar por todas las fases, se actualiza cada vez que un ítem se finaliza. Esta medida permite mejorar las estimaciones futuras.

La imagen a continuación muestra cómo sería un dashboard utilizado para el proceso de mantenimiento.

3.4 Procesos de Gestión de Soporte al Servicio (ITIL) Los procesos que intervienen durante el Servicio de Mantenimiento son: Gestión de Cambios, Gestión de Configuraciones, Gestión de Liberaciones. Ver: Definiciones de los Procesos.

En particular, la gestión de cambios debe tener en cuenta el cupo de horas disponibles y la prioridad de los pendientes, la evaluación de los impactos y la modalidad de gestión.

3.5 Proceso de Gestión El proceso de gestión aplica tanto para el mantenimiento estándar como el ágil.

Criterio Listo F3 WIP = …

Criterio Listo F2 WIP = 1

RFC 7


RFC 4

RFC 3

RFC 2

RFC 1

Pila / Backlog

F4 – Implantación

F3 – Validación

F2 – Const y Verif

F1 – Análisis y Diseño

F0 – Reqs SISTEMA / NEGOCIO

Convenciones

Convenciones

Nombre Aplicación 2

Nombre Aplicación 1


RFC 5 RFC 6

RFC 8

1

Criterio Listo F4 WIP = …

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Metodologías%20Ágiles.pdf





Planificación del Mantenimiento

Durante esta etapa se planifican los releases o versiones para una aplicación/negocio. Esta planificación en general tiene una periodicidad definida (semanal, mensual, etc), y se lleva a cabo en la reunión de Seguimiento y Planificación para dicha aplicación/negocio.

El objetivo de esta etapa es priorizar/planificar los releases/RFC de una aplicación/negocio conjuntamente con los responsables de Negocio, tomando como input su Log de Pendientes actualizado.

Planificación y Seguimiento del Release/ RFC

Consiste en la planificación y seguimiento de los cambios conjuntamente con los equipos de trabajo, que acompaña la ejecución de cada release/RFC.

A lo largo del Servicio de Mantenimiento se gestionan los cupos de horas. Para cada aplicación se establece un cupo mensual/anual para mantenimiento de la misma y dentro de ese cupo se deben priorizar los pendientes.

Como apoyo a la gestión del mantenimiento y ambiente de trabajo, se utilizan los Sitios de Mantenimiento, los cuales cuentan con una plantilla ya definida y adecuada para este fin.

La documentación correspondiente se encuentra en el documento Definición de Plantillas de Sitios Sharepoint.

4 ROLES



http://intranetbps/sitios/activos_generales/Ambientes%20de%20Trabajo/Definición%20de%20Plantillas%20de%20Sitios%20Sharepoint.pdf







En la Figura 7 se muestra la Estructura de productos entregables (EDT) para el Servicio de Mantenimiento, integrando los entregables correspondientes al proceso del producto y gestión.

La clasificación es la siguiente:

• Documentos mantenibles de la Aplicación: son los entregables que se elaboraron y actualizaron durante el Servicio de Desarrollo (producto nuevo), y que pueden ser impactados en este servicio cuando se ponga en producción un nuevo release/RFC.

• Documentos del Mantenimiento: son los entregables propios de cada cambio, y que se elaboran durante el Servicio de Mantenimiento. Incluye los entregables orientados al producto y a la gestión.

Además se indica para cada entregable si existe un activo general asociado (ver sitio de Activos Generales).

También se cuenta con un diccionario de activos (en elaboración) donde se detalla por cada activo, a qué etapa corresponde, su objetivo/alcance, y los roles asociados.

El listado completo de los activos generales que aplican para el Servicio de Mantenimiento, se encuentran en la lista de Servicio Mantenimiento-Entregables, en el Sitio de Activos Generales. Los activos se encuentran agrupados por Proceso de Gestión, y por Fase del proceso del producto a la que pertenecen.

Entregable orientado al proceso del producto, con Activo General asociado

Entregable orientado al proceso del producto, sin Activo General asociado

Entregable orientado a procesos de gestión, con Activo General asociado

Entregable orientado a procesos de gestión, sin Activo General asociado

Entregable mantenible del producto, con Activo General asociado

Figura 7 – EDT de Entregables Base (Proceso de Mantenimiento Estándar)

http://intranetbps/sitios/activos_generales

http://intranetbps/sitios/sdes/Lists/Servicio%20DesarrolloEntregables%20Pautas%20y%20Lineamient/Servicio%20Mantenimiento%20%20Entregables.aspx





Se incluye la EDT de Entregables Base, en dos versiones diferentes.

EDT-Entregables Base-Completa: integra los entregables de todos los procesos que hacen al Servicio de Mantenimiento (del producto, de gestión y de soporte), e incluye los roles responsables. Esta EDT se incluye a modo de referencia y consulta, en formato solo lectura.

EDT-Entregables Base-Fases: solo contiene las fases del proceso de producto. El contenido de esta EDT constituye la base para la planificación del mantenimiento. También queda habilitado el uso del activo “Informe de Planificación y Seguimiento” (formato Excel) para esta planificación.


En la herramienta EPF (Eclipse Process Framework Composer) se encuentran modeladas las siguientes Vistas para el Servicio de Mantenimiento: por Proceso, por Roles, por Entregables, por EDT (Estructura de Desglose de Trabajo). Las mismas se encuentran descriptas en la Sección 7 Vistas del Servicio para el Servicio de Desarrollo.

8 MÉTRICAS



9 GLOSARIO

RFC: Requerimiento de Cambio (Request For Change)

10 ANEXOS

Definición de Plantillas de Sitios Sharepoint (incluye definición de plantilla para Sitios de Mantenimiento)

http://intranetbps/sitios/sdes/Gestin%20de%20Servicios%20de%20SDES/Servicio%20Mantenimiento-EDT%20Entregables%20Base%20-%20Completa.pdf

http://intranetbps/sitios/sdes/Gestin%20de%20Servicios%20de%20SDES/Servicio%20Mantenimiento-EDT%20Entregables%20Base%20-%20Fases.pdf









SERVICIO DE PERSONALIZACIÓN Y ADECUACIÓN DE PAQUETES

1 PROPÓSITO

Mediante este servicio se realiza la adecuación e implantación de un paquete de software. El objetivo es cubrir las necesidades propias de la organización, tanto a nivel de la integración al contexto tecnológico del BPS, como adecuaciones particulares asociadas a los procesos internos a los que de soporte el paquete.

2 ALCANCE

El alcance de este servicio comprende el ajuste e implantación de paquetes de software, así como la actualización de versiones.

Abarca el diagnóstico de la situación actual en todas las áreas que cubra el paquete, la elaboración de un plan para proponer cambios en los procedimientos actuales, y la selección de la estrategia de implantación más adecuada.

En caso que se requiera se ejecutará la capacitación correspondiente. Para ello, se instancia el Servicio de Capacitación de acuerdo a la estrategia de implantación definida.

Durante la ejecución de este servicio el paquete debe ser personalizado y ajustado conservando siempre su naturaleza, sin llegar a convertirse en un desarrollo a medida. La evolución del paquete debe realizarse de acuerdo al avance que la industria proponga, sin alejarse de su alcance y objetivo fundamental.

Si existen necesidades de negocio que no es posible cubrir con la personalización del paquete, las mismas se realizan instanciado el Servicio de Desarrollo o Mantenimiento, implementando mediante interfaces la interacción con el paquete y respetando los estándares definidos para este caso.


2.2 Tipos N/A


3 PROCESO

Para la ejecución de este servicio se instancian los diferentes procesos que lo soportan. Estos procesos son: Personalización y Adecuación del Paquete, de Actualización de Versiones del Paquete, de Gestión de Soporte al Servicio (ITIL) y de Gestión de Proyectos (PMBOK).

3.1 Proceso de Personalización y Adecuación del Paquete El proceso de personalización y adecuación de paquetes está basado en el proceso del producto del Servicio de Desarrollo. La principal diferencia está en el alcance del problema a resolver y de los entregables a elaborar.




En particular, la ejecución del ciclo de personalización del paquete comienza en la Fase 1 del Ciclo del Release, ya que la mayor parte de las actividades de la “Etapa I. Modelado y Diseño Macro del Negocio” y la “Fase 0-Requerimientos” se ejecutan de forma previa a este proceso. Las entradas al proceso de personalización de paquetes corresponden a los entregables que deben ser elaborados durante las fases mencionadas (Etapa I y Fase 0). Esto se muestra en la Figura 8.

Las entradas al proceso se dividen según:

- Las necesidades y requerimientos que debe satisfacer el paquete, así como todo aquel entregable de la Etapa I y Fase 0 del Servicio de Desarrollo que sea necesario en cada caso.

- La documentación propia del paquete de software (según corresponda).

Figura 8-Proceso del Personalización del Paquete

Ejecución del Ciclo de Personalización y Adecuación del Paquete

Durante la ejecución del proceso se cumplen las fases que permitirán la adecuación e implantación del paquete de software.

A continuación se describe brevemente cada una de las fases con las particularidades que aplican para el Servicio de Personalización de Paquetes.

Planificación de la Personalización y Adecuación del Paquete

Corresponde a las actividades de planificación para la personalización y adecuación del paquete, previo a su ejecución. Estas actividades corresponden a la Etapa I, pero no se pueden ejecutar hasta no conocer cuál es el paquete a implantar (a modo de ejemplo: planificación de la implantación).

Fase 1-Análisis y Diseño:

En base a los requerimientos especificados y las funcionalidades que brinda el paquete, se realiza una matriz que indica en forma detallada cuáles de los requerimientos funcionales y no funcionales especificados son cubiertos por el software y cuáles no.

Para aquellos requerimientos que son cubiertos, se debe detallar de qué forma el paquete de software da solución a los mismos.

En el caso de existir requerimientos no cubiertos por el paquete, la implementación de dichas funcionalidades así como de las interfaces de interacción con el paquete, se regirán por las definiciones del Servicio de Desarrollo o Mantenimiento. En particular, en esta fase se realiza el análisis detallado de los requerimientos funcionales y no funcionales, y se especifica cómo será la integración con el paquete.

En caso de detectarse la necesidad de realizar una carga inicial de datos se deberá definir una estrategia de migración de datos, y un análisis de cuáles datos se podrán cargar de manera automática y cuáles de forma manual.


Fase 2 Fase 1-Análisis y Diseño





Ciclo de Personalización del Paquete

I. Mod Neg y Diseño Macro

Fase 0-Requeri-mientos




o Fase 2.1: Construcción: durante esta fase se realiza la personalización y adecuación del paquete y la integración con las interfaces de otros sub-sistemas. También se incluye el testeo unitario y de integración.

Puede requerir además realizar tareas de carga y/o conversión de los datos (automática o manual).

o Fase 2.2: Verificación: se realiza el testeo del paquete por parte de un equipo de pruebas independiente. Incluye también la verificación de las funcionalidades desarrolladas, y su integración con el paquete.

Si corresponde, se realizan las pruebas de correctitud y completitud de los datos migrados.

Fase 3- Validación (Testeo de Aceptación): comprende el testeo final (aceptación) del paquete de software y del desarrollo específico. Esta fase culmina con la aceptación del paquete de software en su contexto (con la integración de desarrollos personalizados y demás sub-sistemas).

Adicionalmente las pruebas incluirán la aceptación de la carga de datos, si corresponde.

Fase 4-Implantación: consiste en la puesta en producción del paquete de software. Comprende el conjunto de actividades de implantación del software previas a la entrada efectiva en régimen de explotación.

A partir de la documentación del paquete de software (entradas a este servicio), se verifica si es necesario actualizarla en función de la instanciación realizada. El manual resultante de este servicio debe incluir el catálogo de servicios (interfaces) que ofrece el paquete, ya sean nativos del paquete o desarrollados a medida.

Durante esta fase también se incluye la ejecución de la capacitación, de acuerdo al Servicio de Capacitación definido.

3.2 Proceso de Actualización de Versiones del Paquete Este proceso se instancia cada vez que existe una nueva versión del paquete que es necesario o deseable actualizar. Está compuesta por las siguientes dos etapas:

1- Análisis de impacto: se realiza el análisis de impacto de la versión del paquete actual versus la nueva versión del paquete, donde se deberá analizar el gap (diferencias) entre ambas versiones.

2- Instanciación del Proceso de Personalización y Adecuación del Paquete: de acuerdo al resultado obtenido a partir del análisis de impacto, pueden suceder dos cosas:

a. Si el impacto implica hacer modificaciones sobre el paquete de software, ya sea a nivel de la personalización, adecuación o nuevos desarrollos/mantenimientos, se vuelve a instanciar el Proceso de Personalización y Adecuación del Paquete desde la Fase 1, ajustando según corresponda.

b. Si el impacto es menor o no hay impacto, se instancia el Proceso de Personalización y Adecuación del Paquete a partir de la Fase 2.2.

3.3 Procesos de Gestión de Soporte al Servicio (ITIL) Estos procesos serán soportados por herramientas basadas en ITIL. Ver: Definiciones de los Procesos.

Los procesos que intervienen durante el Servicio de Personalización de Paquetes son: Gestión de Cambios, Gestión de Configuraciones, Gestión de Liberaciones.





3.4 Grupos de Proceso de Gestión de Proyectos (PMBOK) Estos grupos de procesos son soportados por la plataforma de gestión de Proyecto, herramienta MS-PWA (Project Web Access). Ver: Definiciones para Gestión de Proyectos.

4 ROLES

Los roles y responsabilidades se encuentran descriptos en el documento SDES-Roles.


Figura 9 – EDT de Entregables Base (Proceso de Personalización y Adecuación del Paquete)







En la Figura 9 se incluye la EDT de Entregables Base, que integra los entregables de todos los procesos que hacen al Servicio de Personalización de Paquetes (del producto, de gestión y de soporte), e incluye los roles responsables. El contenido de esta EDT constituye la base para la elaboración del cronograma de actividades del proyecto.


En la herramienta EPF (Eclipse Process Framework Composer) se encuentran modeladas las siguientes Vistas para el Servicio de Personalización y Adecuación de Paquetes: por Proceso, por Roles, por Entregables, por EDT (Estructura de Desglose de Trabajo). Las mismas se encuentran descriptas en la Sección 7 Vistas del Servicio para el Servicio de Desarrollo.

8 MÉTRICAS



9 GLOSARIO

N/A

10 ANEXOS

Circular de Paquetes ASIT

http://intranetbps/sitios/sdes/Gestin%20de%20Servicios%20de%20SDES/Servicio%20Adecuación%20y%20Personalización%20de%20Paquetes-EDT%20Entregables%20Base.pdf



http://intranet/areasdeintranet/ASIT/Documents/Circulares/Circular%20de%20Paquetes/ASIT%2020020701%20CP%20Paquetes%20Estandar%20v4.pdf






SERVICIO DE EXPLOTACIÓN DE INFORMACIÓN

1 PROPÓSITO

Este servicio tiene como propósito gestionar y dar solución a las necesidades de información que se requieren por parte de los diferentes negocios como soporte a la toma de decisiones.

2 ALCANCE


2.2 Tipos

Solicitud de Información (consulta ad-hoc)

Las solicitudes de información se pueden clasificar a su vez de acuerdo a la frecuencia de ejecución:

o Consulta de ejecución única: cuando se solicita la ejecución de la consulta por única vez.

o Consulta periódica: cuando se solicita la ejecución de la consulta con frecuencia periódica (ejemplo: de forma mensual o trimestral).

Desarrollo BI

Desarrollo Data Mining


3 PROCESO

3.1 Proceso del Producto – Solicitud de Información Durante la ejecución del proceso se cumplen las fases que permitirán dar solución a la solicitud de información requerida.

El proceso aquí descripto corresponde al desarrollo de consultas que requieren intervención técnica (ya sea una consulta nueva o la modificación de una ya existente). Se puede considerar como un proceso de desarrollo ágil, en el que son fundamentales las reuniones que permiten aclarar y simplificar los requerimientos y la solución.

Las fases del proceso son las mismas que se cumplen para el Proceso del Producto del Servicio de Desarrollo, con la diferencia principal en el alcance de la solución y el esfuerzo requerido. A continuación se describe brevemente cada una de las fases con las particularidades que aplican para el Servicio de Solicitud de Información.

Fase 0- Requerimientos: el usuario solicitante completa la sección 1. Solicitud del entregable Formulario de Solicitud de Información especificando el requerimiento de información y la fecha esperada de recepción del resultado. El grupo de Sistemas de Información del Centro correspondiente evalúa el requerimiento e intercambia la información necesaria con el solicitante de forma de clarificar la solicitud.




Fase 1- Análisis y Diseño: se realiza el análisis de la solución y se estima la fecha de entrega.

Si a partir del análisis funcional se desprende que requiere intervención técnica, se sigue con el ciclo de este proceso.

Luego del análisis primario técnico, se determina de qué forma se dará solución a la solicitud de información.

o Si se requiere una solución de BI, se instancia el Servicio de Información – Tipo Desarrollo BI.

o Si se requiere desarrollar una nueva consulta que genera un cambio en un aplicativo (ejemplo: agregar una nueva funcionalidad) o modificar una solución BI existente (ejemplo: agregar un nuevo reporte), se instancia el Servicio de Mantenimiento – Tipo Extensivo.

o Si la solicitud se resuelve con una herramienta que dé soporte a la ejecución de la consulta (Reporte, consulta GCA) u obteniendo el conjunto de datos resultante (directamente sobre datos de producción), se continúa con este tipo del Servicio de Información.

Si la consulta es de ejecución periódica, se dará solución a la misma mediante la herramienta que se defina (consulta de GCA o un Reporte en Cognos, Reporting Services, o la herramienta disponible para este fin).

Si la consulta es de ejecución única, la solución consistirá en la generación de un script con el objetivo de obtener el conjunto de datos que satisfacen el requerimiento de información.

Si la consulta es compleja y requiere la participación de más de un grupo/sector de desarrollo, se establece una reunión de análisis entre todos los sectores involucrados.

Cada grupo participante de la consulta complementa las secciones 2. Análisis y 3. Casos Preliminares de Testeo del entregable Formulario de Solicitud de Información.

Si la fecha estimada de entrega no coincide con la fecha esperada, se debe comunicar al usuario que realizó la solicitud.


o Fase 2.1: Construcción: se implementa la solución a la solicitud de información (de acuerdo a la solución determinada en la fase anterior) y se realiza el testeo interno de la misma.

Luego de construida la consulta se actualiza la sección 4. Construcción del entregable Formulario de Solicitud de Información incluyendo un link al producto de la solución (script, reporte o consulta GCA).

o Fase 2.2: Verificación: se realiza el testeo de la consulta por parte de un equipo de pruebas independiente.

Fase 3- Validación (Testeo de Aceptación): consiste en la aceptación del resultado de la consulta por parte del usuario solicitante.

En la sección 5. Resultado del entregable Formulario de Solicitud de Información se incluye un link al repositorio donde se encuentra el resultado de la consulta o a la consulta publicada.

Fase 4- Implantación: se deja disponible para el usuario solicitante el resultado que da solución a la solicitud de información. El resultado puede ser: la consulta (reporte o GCA) en ambiente operativo, o el conjunto final de datos.




3.2 Proceso del Producto – Desarrollo BI A continuación se describen las fases que conforman el proceso de Desarrollo BI, basadas en RUP y en la metodología BI de referencia (Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications). La Figura 10 ilustra dicho proceso, mostrando cómo se define el Proceso de Desarrollo BI contemplando ambos marcos de referencia. En azul oscuro se presentan las fases del proceso de Desarrollo BI. En azul claro se incluyen las fases del proceso de RUP. En la Figura 11 se muestran los sub-procesos que componen cada una de las fases definidas del Proceso de Desarrollo BI. A su vez se destacan tres carriles o “tracks” diferentes: Datos, Aplicación, Metadatos.

Figura 10-Proceso de Desarrollo BI basado en RUP y Metodología para BI

Figura 11-Sub-procesos por Fase del Proceso de Desarrollo BI

El objetivo y alcance de cada una de las fases del proceso basado en RUP se encuentran descriptos en la sección 3.2 Proceso del Producto (RUP) – Desarrollo estándar del Servicio de Desarrollo. A continuación se describe cada una de las fases definidas para el Proceso de Desarrollo BI.

Las entradas al proceso de Desarrollo BI corresponden a los siguientes entregables.

Definición de Procesos de Negocio: contiene la descripción de los procesos de negocio que generan la información que se analizará como parte de la solución BI.

Modelo Operacional: representa el modelo lógico (componentes de software y su relación) y el modelo físico (nodos físicos e interacciones) de las aplicaciones que generan los datos a analizar.

I. Caso de Negocio

Incluye la Etapa I: Evaluación del Caso de Negocio y Diseño Macro

Esta etapa se analiza y se comprende los procesos de negocio y sistemas actuales que se tomarán como base para elaborar la solución de BI. Se identifican las necesidades de negocio a las que debe dar cumplimiento esta solución, y se realiza un análisis de la situación actual, incluyendo los sistemas OLTP y




sus fuentes de información, así como los procesos y soluciones actuales de análisis de información. A partir de este análisis se definen los requerimientos macro de la solución y las estrategias correspondientes.

Se realiza el refinamiento del modelo conceptual, y se analiza el impacto macro que tendrá la construcción de la solución en los procesos y en la organización. A partir de estos se realiza el diseño macro de la solución, incluyendo entre otros una primera versión de la arquitectura, la definición de los metadatos de la solución, y se planifican los releases que se llevarán a cabo para la construcción de la solución de BI.


Para cada subproducto de la solución (release) incluido en el Plan de Releases, se ejecuta el ciclo completo del release que se detalla a continuación. Por lo tanto, existen tantos ciclos de desarrollo BI como releases se hayan indicado en el Plan correspondiente.

Análisis de Negocio

El objetivo de esta fase es realizar un análisis detallado del problema de negocio u oportunidad de negocio para adquirir una sólida comprensión de los requisitos del negocio para una posible solución (producto).

Incluye las siguientes fases:

- Fase 0- Requerimientos: se especifican los requerimientos de información detallados para la solución BI. Se comienza a construir la matriz de trazabilidad, de forma de conocer la relación entre los componentes de BI y analizar el impacto de los cambios; y se refina los metadatos de la solución.

- Fase 1.1-Análisis: se realiza el análisis de los datos, el prototipo de la solución y el análisis del repositorio de metadatos.

Como resultado de esta fase, se genera el análisis de la solución funcional, incluyendo las fichas para cubos, reportes e indicadores. Se ajusta la matriz de trazabilidad y los metadatos de la solución, de forma de incluir los nuevos componentes que se van definiendo.

Diseño

El objetivo es concebir un producto que resuelve el problema de negocio o habilita una oportunidad de negocio. Incluye:

- Fase 1.2-Diseño: se realiza el diseño de la base de datos y de los procesos ETL, el diseño de la aplicación y el diseño del repositorio de metadatos.

Como resultado de esta fase, se genera el diseño para la solución de BI, el cual incluye el diseño del DW, de ETL y de la aplicación (ajustando las fichas para cubos, reportes e indicadores).

Construcción

Se construye el producto BI, que debe proporcionar un retorno de la inversión dentro de un marco de tiempo predefinido.

Incluye las siguientes fases:

- Fase 2.1: Construcción: se implementa la solución de BI, incluyendo el desarrollo de los procesos ETL, el desarrollo de la aplicación y el desarrollo del repositorio de metadatos. A su vez, se realiza el testeo interno de la solución.

- Fase 2.2: Verificación: se realiza el testeo de la solución por parte de un equipo de pruebas independiente.

Validación

Consiste en la aceptación funcional de la solución por parte del responsable de la solución. Incluye:

- Fase 3- Validación (Testeo de Aceptación).

Implantación




El objetivo es implantar el producto terminado, luego medir su eficacia para determinar si la solución cumple, supera o no cumple con el retorno de la inversión esperado.

Incluye:

- Fase 4- Implantación: consiste en la puesta en producción de la solución de BI. Se genera el manual de la solución para infraestructura, y se ajusta el modelo de metadatos corporativo.

3.3 Proceso de Gestión Para el tipo “Solicitud de Información” (que se ejecuta en modalidad operativa), la gestión del servicio se realizará en la herramienta MantiSITO (ver Procedimiento para Solicitudes de Información en MantiSITO).

Algunas actividades de aseguramiento de la calidad que se recomienda seguir son:

- Verificar que se completen las diferentes secciones del Formulario de Solicitud de Información.

- Verificar que se completen los datos correspondientes en el formulario de MANTISITO.

- Si es una consulta compleja, se recomienda realizar una revisión de código por parte de los analistas responsables de los datos.

- Validación del resultado de la consulta por parte del solicitante.

3.4 Grupos de Proceso de Gestión de Proyectos (PMBOK) Para el tipo “Desarrollo BI” (que se ejecuta en modalidad proyecto), los grupos de procesos son soportados por la plataforma de gestión de Proyecto, herramienta MS-PWA (Project Web Access). Ver: Definiciones para Gestión de Proyectos.

4 ROLES




Para el tipo “Solicitud de Información”:

Formulario de Solicitud de Información: este documento contiene la especificación de la solicitud de información por parte del usuario final, así como el análisis funcional y técnico de la misma completado por todos los grupos que participan en su ejecución. Además se incluye una descripción conceptual de los casos preliminares de testeo y los links correspondientes al script de la consulta así como donde se encuentra almacenado el resultado de la misma.

Solicitud registrada y gestionada en MantiSITO: corresponde al reporte de la solicitud de información registrada en la herramienta MantiSITO. La gestión y seguimiento de la solicitud se realizará a través de esta herramienta.

Ficha de Reporte (ver Tipo Desarrollo BI): si la solución a la solicitud de información es un Reporte, se debe completar la Ficha de Reporte correspondiente.

La Figura 12 muestra la EDT de entregables base para el Proceso de Solicitud de Información.

La Figura 13 muestra la EDT de entregables base para el Proceso de Desarrollo BI.

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Procedimiento%20para%20Solicitudes%20de%20Información.pdf







Figura 12-EDT de Entregable Base: Proceso Solicitud de Información




Figura 13-EDT de Entregables Base: Proceso Desarrollo BI





Las actividades ejecutadas durante el tipo de servicio “Solicitudes de Información” se encuentran especificadas en el Procedimiento para Solicitudes de Información en MantiSITO.

Las actividades ejecutadas durante el tipo de servicio “Desarrollo BI” serán especificadas a partir de los sub-procesos que se muestran en la Figura 11.


En la herramienta EPF (Eclipse Process Framework Composer) se modelarán las siguientes Vistas para el Servicio de Explotación de Información: por Proceso, por Roles, por Entregables, por EDT (Estructura de Desglose de Trabajo). Las mismas se encuentran descriptas en la Sección 7 Vistas del Servicio para el Servicio de Desarrollo.

8 MÉTRICAS



Se obtienen además indicadores específicos para este servicio a partir de las solicitudes de información registradas en MantiSITO, definidos en el Procedimiento para Solicitudes de Información en MantiSITO.

9 GLOSARIO

BI: Business Intelligence

DW: Data Warehouse

ETL: Extracción, Transformación y Carga

10 ANEXOS

Procedimiento para Solicitudes de Información en MantiSITO










SERVICIO DE SOPORTE

Este servicio está definido a nivel de CSEI (ver CSEI-Servicio de Soporte).

En este documento se instancia el servicio con las particularidades que aplican para SDES.

1 PROPÓSITO

Este servicio brinda el apoyo técnico para resolver incidentes y/o problemas con el software que da sustento a la automatización de los procesos de la organización. El mismo alcanza a todo el software ya sean desarrollos a medida (internos o de proveedores) o soluciones comerciales empaquetadas.

2 ALCANCE

2.1 Contexto Comprende a todos los usuarios internos BPS (incluyendo funcionarios y proveedores).

2.2 Tipos N/A

2.3 Modalidades

Interno (Soporte Interno Especializado – Nivel 2)

Es responsable del diagnóstico y resolución de los incidentes de software.

Tercerizado

Derivación y control de las solicitudes e incidentes a terceros.

Control de los SLAs establecidos contractualmente.

3 PROCESO

Este servicio se cumple siguiendo el Procedimiento de Gestión de Incidentes y Solicitudes de Servicio establecido para BPS.

4 ROLES



N/A

6 HITOS

N/A

http://intranetbps/sitios/csei/Servicios%20de%20CSEI/Definición%20de%20los%20Servicios%20de%20la%20Coordinación%20de%20Servicios%20Informáticos.pdf

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Procedimiento%20Gestión%20Incidentes.pdf





7 MÉTRICAS

Registro de esfuerzo en Magma

Definición de indicadores para el CSU y Proceso Gestión de Incidentes

8 GLOSARIO

N/A

http://intranetbps/sitios/activos_generales/Medicin%20y%20Anlisis/CSEI-%20Definiciones%20Indicadores%20%20CSU%20y%20Proceso%20Incidentes.xls




SERVICIO DE INNOVACIÓN Y PROPUESTAS AL NEGOCIO

Este servicio está definido a nivel de CSEI.

Ver: CSEI-Servicio de Innovación y Propuestas al Negocio.

http://intranetbps/sitios/csei/Servicios%20de%20CSEI/Definición%20de%20los%20Servicios%20de%20la%20Coordinación%20de%20Servicios%20Informáticos.pdf