Proceso de Gestión de La Configuración de Software

UNIVERSIDAD PRIVADA DE TACNA FACULTAD DE INGENIERIA Escuela Profesional de Ingeniería de Sistemas

PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DE SOFTWARE Curso: Gestión de la Configuración y administración de Software Docente: Ing. Ricardo Valcárcel Alvarado Integrantes: Acero Catacora, Christian César Chama, Nelson

Tacna – Perú 2016

(2008030973)

PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DE SOFTWARE

INDICE GENERAL

INTRODUCCION....................................................................................................... 3 1.

OBJETIVOS....................................................................................................... 4

2.

MARCO TEORICO.............................................................................................. 4 2.1

3.

Ciclo de vida y Modelos de Desarrollo..............................................................4

2.1.1

Modelos tradicionales............................................................................6

2.1.2

Modelos alternativos............................................................................13

2.1.3

Conclusiones...................................................................................... 20

Generación de Plan de Gestión de la Configuración de Software..............................22 3.1

Diseñar el Plan de Gestión de Configuración de Software.................................22

3.1.1

Ciclo de Vida Tradicional......................................................................22

CONCLUSIONES..................................................................................................... 23 RECOMENDACIONES............................................................................................. 24 REFERENCIAS....................................................................................................... 25 ANEXOS................................................................................................................. 26

2


INTRODUCCION Cuando un software se desarrolla con éxito, cuando satisface las necesidades de las personas que lo utilizan; cuando funciona de forma impecable durante mucho tiempo; cuando es fácil de modificar o incluso es más fácil de utilizar, puede cambiar todas las cosas y de hecho cambiar para mejor. Ahora bien, cuando un software falla, cuando los usuarios no quedan satisfechos, cuando es propenso a errores, cuando es difícil de cambiar e incluso más difícil de utilizar, pueden ocurrir y de hecho ocurren verdaderos desastres. Todos queremos desarrollar un software que haga bien las cosas, evitando que esas cosas malas aparezcan. Para tener éxito al diseñar y construir un software necesitaremos disciplina. Es decir, necesitaremos un enfoque de ingeniería. (Software, 2009) Como elemento de clave

al desarrollo de software tenemos la gestión de

configuración de software que básicamente son un conjunto de actividades diseñadas para identificar y definir los elementos. En el sistema que probablemente cambien, controlando el cambio de estos elementos a lo largo de su ciclo de vida. Es por eso que se desarrolló el siguiente trabajo para identificar las acciones que se tomaran en cada etapa del desarrollo del software del modelo cascada. El primero primer apartado del trabajo definiremos los objetivos del trabajo realizado. En el segundo apartado hablaremos más sobre los diferentes modelos de desarrollo, tradicionales y alternativos. En el tercer apartado, la parte de desarrollo, es con los fundamentos aprendidos en el marco teórico serán aplicados para fundamentar en base a fuentes diferentes aspecto que puedan poner en riesgo el desarrollo del proyecto, de acuerdo a modelo cascada.

3


PROCESO DE GESTIÓN DE LA CONFIGURACIÓN DE SOFTWARE 1. OBJETIVOS 1.1. GENERAL: Investigar acerca de lo proceso de gestión de la configuración de software en cada una de las etapas del ciclo de vida tradicional. 1.2. ESPECIFICOS: Argumentar y sustentar diferentes casos que pueden alterar el proceso de gestión de proyecto en un modelo en cascada. Proponer soluciones en el proceso de configuración de software del ciclo de vida en cascada. 2. MARCO TEORICO

2.1

Ciclo de vida y Modelos de Desarrollo Un modelo de proceso es una abstracción de un proceso. Estos modelos representan

los enfoques utilizados en el desarrollo de software dentro de organizaciones. Sobre la base de estos modelos, se han propuesto varios procesos para el desarrollo de software con el fin de construir un mejor producto, con un menor coste y más rápidamente. Un proceso de desarrollo de software es un conjunto de actividades y resultados asociados que generan un software. En general, los procesos de desarrollo se centran en los aspectos técnicos como la especificación, desarrollo, validación y evolución del software y deben proporcionar transparencias y flexibilidad para facilidad de la gestión de los proyectos. (Daniel Ramos, Curso de Ingeniería de Software, 2015)

4


El proceso adoptado por una organización es también una abstracción en relación con el proceso en ejecución en un proyecto determinado. En general, el proceso de la organización se adopta de acuerdo a las necesidades específicas del proyecto. Hay una necesidad de gestionar el proceso de desarrollo de software a través de modelos, procesos, actividades y herramientas específicas. El desarrollo de un software tiene sentido en el contexto de una empresa y una organización. Es importante alinear los requerimientos del negocio con el producto de software y gestionar las actividades de desarrollo, control de tiempo, costos y calidad para que el proyecto no termine en un fracaso en el punto de vista del negocio. (Sommerville, 2011) Los procesos de desarrollo pueden incluir las actividades de gestión tales como el Proceso Unificado, pero existen modelos y proceso específicos para la gestión de proyectos. Es posible adoptar una combinación de procesos complementarios de acuerdo con las necesidades del proyecto y de la organización. La estimación de software es importante para la gestión de un proyecto. Decisiones como la cancelación de un proyecto se pueden hacer sobre la base de estimaciones de coste y tiempo necesario para desarrollar un determinado sistema de software. Las estimaciones adecuadas dan origen a decisiones acertadas, mientras que las estimaciones poco realistas causan prejuicio. Además, dado el esfuerzo real en comparación con el esfuerzo estimado, proporciona una herramienta importante para el ajuste de las estimaciones de los proyectos en curso y de futuros proyectos. La experiencia y los datos agregados a través de esta comparación permiten estimar las actividades futuras con mayor precisión y atenuar de incumplimiento de los plazos acordados. Por ellos, el gerente debe poseer los registros organizados de las actividades completadas. (Daniel Ramos, Curso de Ingeniería de Software, 2015)

5


2.1.1

Modelos tradicionales

Teniendo en cuenta que la estimación debe considerar el proceso como las actividades de desarrollo. Cuando más actividades extra, documentación y precisión fueran exigidos, mayor será el factor de ajuste necesario para las estimaciones. Este proyecto de investigación considera los modelos más burocráticos y con mayor rigor como modelos tradicionales. Modelos con poca burocracia, también llamados modelos o alternativos empíricos, incluyen modelos de procesos agiles. Kroll clasifica algunos modelos en unos gráficos cuyo eje horizontal es el grado de disciplina adoptado y el eje vertical el nivel de interactividad. El autor coloca el proceso de madurez del proceso CMM con un alto grado de burocracia y baja interactividad, mientras que los modelos ágiles con poca burocracia y alta interactividad. El CMMI, una evolución, es más interactivo y menos burocrático. Así los procesos agiles son bastante interactivos y muy poco burocráticos. (MacIsaac, 2013)

Waterfall CMM

Poco burocrático Poca documentaci ón, Procesos ligeros

Pocos riesgos, secuencial, integración y test tardío

CMMI

XP, SCRUM, DESARROLL O ADAPTIVO

Interactivo Riesgoso, continúa integración y testeo

Burocrático Bien documentador. Trazabilidad CCB

6


Grado de burocracia de los modelos tradicionales

Watterfall model: Modelo cascada

El modelo de cascada es un diseño secuencial de procesos, que se utiliza en los procesos de desarrollo de software , en la que se ve que el progreso fluye constantemente hacia abajo (como una cascada ) a través de las fases de concepción, iniciación, análisis , diseño , construcción, pruebas , producción / aplicación y mantenimiento . El modelo de desarrollo en cascada se origina en las de fabricación y construcción industrias: muy estructurado entorno físico en el que después del hecho, los cambios son prohibitivamente costoso, si no imposible. Debido a que no hay metodologías formales de desarrollo de software existían en el momento, este modelo orientado a hardware simplemente estaba adaptado para el desarrollo de software. (Benington, 2011) Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y, luego, los represente como fases separadas del proceso, tal como especificación de requerimientos, diseño de software, implementación, pruebas, etcétera. Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo: 1. Análisis y definición de requerimientos Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema. 2. Diseño del sistema y del software El proceso de diseño de sistemas asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. El diseño del software implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones. 3. Implementación y prueba de unidad Durante esta etapa, el diseño de software se rea liza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación. 4. Integración y prueba de sistema Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se 7


cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente. 5. Operación y mantenimiento Por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.

En principio, el resultado de cada fase consiste en uno o más documentos que se autorizan (“firmaron”). La siguiente fase no debe comenzar sino hasta que termine la fase previa. En la práctica, dichas etapas se traslapan y se nutren mutuamente de información. Durando el diseño se identifican los problemas con los requerimientos. En la codificación se descubren los problemas de diseño, y así sucesivamente. El proceso de software no es un simple modelo lineal, sino que implica retroalimentación de una fase a otra. Entonces, es posible que los documentos generados en cada fase deban modificarse para reflejar los cambios que se realizan. Debido a los costos de producción y aprobación de documentos, las iteraciones suelen ser onerosas e implicar un rediseño significativo. Por lo tanto, después de un 8


pequeño número de iteraciones, es normal detener partes del desarrollo, como la especificación, y continuar con etapas de desarrollo posteriores. Los problemas se dejan para una resolución posterior, se ignoran o se programan. Este freno prematuro de los requerimientos quizá signifique que el sistema no hará lo que el usuario desea. También podría conducir a sistemas mal estructurado conforme los problemas de diseño se evadan con la implementación de trucos. Durante la fase final del ciclo de vida (Operación y mantenimiento) , el software se pone en servicio. Se describen los errores y las omisiones en los requerimientos originales del software. Surgen los errores de programa y diseño, y se detecta la necesidad de nueva funcionalidad. Por lo tanto, el sistema debe evolucionar para mantenerse útil. Hacer tales cambios (Mantenimiento de software) puede implicar la repetición de etapas anteriores de los procesos El modelo en cascada es consecuente con otros modelos de proceso de ingeniería y en cada fase se produce documentación. Esto hace que el proceso sea visible, de modo que los administradores monitoricen el progreso contra el plan de desarrollo. Su principal problema es la partición inflexible del proyecto en distintas etapas. Tienen que establecer compromisos en una etapa temprana del proceso, lo que dificulta respondes a los requerimientos cambiantes del cliente. En principio, el modelo en cascada solo debe usarse cuando los requerimientos se entiendan bien y sea improbable el cambio radical duran el desarrollo del sistema. Sin embargo, el modelo en cascada refleja el tipo de proceso utilizado en otros proyectos de ingeniería. Como es más sencillo emplear un modelo de gestión común durante todo el proyecto, aun son de uso común los procesos de software basado en el modelo en cascada. Una variación importante del modelo en cascada es el desarrollo de sistemas formales, donde se crea un modelo matemático, para una especificación del sistema. Después se corrige este modelo, mediante trasformaciones matemáticas que preservan su consistencia en un código ejecutable. Con base en la suposición de que son correctas sus transformaciones matemáticas, se pueden aseverar, por lo tanto, que un programa generado de esta forma es consecuente con su especificación. Los procesos formales de desarrollo, como el que se basa el método B (Macmillan, 2001) son muy adecuados para el desarrollo de sistemas que cuenten con rigurosos requerimientos de seguridad, fiabilidad o protección. El enfoque formal simplifica la 9


producción de un caso de proyecto o seguridad. Esto demuestra a los clientes o reguladores que el sistema en realidad cumple con sus requerimientos de protección o seguridad. Los procesos basados en transformaciones formales se usan por lo general solo en el desarrollo de sistemas críticos para protección o seguridad. Requieren experiencia especializada. Para la mayoría de los sistemas, este proceso no ofrece costo/beneficio significativos sobre otros enfoques en el desarrollo de sistemas. (Sommerville, 2011)

Rational Unified Process El proceso unificado Rational (RUP) es un marco de trabajo de proceso de desarrollo de software iterativo creado por Rational Software Corporation, una división de IBM desde 2003. RUP no es un proceso preceptivo concreto individual, sino un marco de trabajo de proceso adaptable, con la idea de ser adaptado por las organizaciones de desarrollo y los equipos de proyecto de software que seleccionarán los elementos del proceso que sean apropiados para sus necesidades. RUP fue originalmente desarrollado por Rational Software, y ahora disponible desde IBM. El producto incluye una base de conocimiento con artefactos de ejemplo y descripciones detalladas para muchos tipos diferentes de actividades. RUP resultó de la combinación de varias metodologías y se vio influenciado por métodos previos como el modelo en espiral. Las consideraciones clave fueron el fallo de proyectos usando métodos monolíticos del estilo del modelo en cascada y también la llegada del desarrollo orientado a objetos y las tecnologías GUI, un deseo de elevar el modelado de sistemas a la práctica del desarrollo y de resaltar los principios de calidad que aplicaban a las manufacturas en general al software. Los creadores y desarrolladores del proceso se centraron en el diagnóstico de las características de diferentes proyectos de software fallidos. De esta forma intentaron reconocer las causas raíz de tales fallos. También se fijaron en los procesos de ingeniería del software existentes y sus soluciones para estos síntomas. El fallo de los proyectos es causado por una combinación de varios síntomas, aunque cada proyecto falla de una forma única. La salida de su estudio fue un sistema de mejores prácticas del software al que llamaron RUP.

10


El proceso fue diseñado con las mismas técnicas con las que el equipo solía diseñar software; tenía un modelo orientado a objetos subyacente, usando UML (Unified Modeling Language). (Gibbs, 2009)

Módulos de RUP (building blocks) RUP se basa en un conjunto de módulos o elementos de contenido, que describen qué se va a producir, las habilidades necesarias requeridas y la explicación paso a paso describiendo cómo se consiguen los objetivos de desarrollo. Los módulos principales, o elementos de contenido, son: ‐ Roles (quién): un rol define un conjunto de habilidades, competencias y responsabilidades relacionadas. ‐ Productos de trabajo (qué): un producto de trabajo representa algo que resulta de una tarea, incluyendo todos los documentos y modelos producidos mientras que se trabaja en el proceso. ‐ Tareas (cómo): una tarea describe una unidad de trabajo asignada a un rol que proporciona un resultado significante.

Fases del ciclo de vida del proyecto RUP determina que el ciclo de vida del proyecto consiste en cuatro fases estas fases Permiten que el proceso sea presentado a alto nivel de una forma similar a como sería presentado un proyecto basado en un estilo en cascada, aunque en esencia la clave del proceso recae en las iteraciones de desarrollo dentro de todas las fases. También, cada fase tiene un objetivo clave y un hito al final que denota que el objetivo se ha logrado. Las cuatro fases en las que divide el ciclo de vida del proyecto son: ‐ Fase de iniciación: se define el alcance del proyecto. ‐ Fase de elaboración: se analizan las necesidades del negocio en mayor detalle y se define sus principios arquitectónicos. 11


‐ Fase de construcción: se crea el diseño de la aplicación y el código fuente. ‐ Fase de transición: se entrega el sistema a los usuarios. RUP proporciona un prototipo al final de cada iteración. Dentro de cada iteración, las tareas se categorizan en nueve disciplinas: -

-

Seis disciplinas de ingeniería  Modelaje de negocio  Requisitos  Análisis y diseño  Implementación  Pruebas  Despliegue Tres disciplinas de soporte  Gestión de la configuración y del cambio  Gestión de proyectos  Entorno

12


2.1.2

Modelos alternativos En “Manifiesto para el Desarrollo Ágil de Software”, firmado en 2001 por algunos

desarrolladores de software importantes, dio comienzo a un movimiento emergente que busca formas de desarrollo software más ágilmente. Este documento pone el relieve algunos principios ya conocidos con el fin de superar los retos modernos del desarrollo de software En la siguiente figura se muestra la misma idea de (MacIsaac, 2013), incluyendo el Proceso Unificado. Debido a sus características de adaptación, el Proceso unificado cubre una amplia gama de gráfica.

Dependiendo del proyecto, este puede ser adaptado para ser más o

menos interactivo, (Pressman, 2006)

Waterfall

Poco riesgo, secuencial, tardía integración y testing

Relajado Poca documentaci ón, Procesos ligeros. Poco burocático

SCRUM

RUP

OPENUP/BA SIC

Disciplinado

XP

Bien documentador. Trazabilidad CCB

Interactivo Riesgoso, continúa integración y testeo

Grado de burocracia de los modelos alternativos

13


La mayoría de los modelos alternativos incluyen una comunicación cara a cara rutinaria, diaria y formal entre los miembros del equipo. Esto incluye específicamente al representante del cliente y a cualquier persona involucrada en el negocio interesada como observadores. En una breve sesión, los miembros del equipo informan al resto de lo que hicieron el día anterior, lo que van a hacer hoy y cuáles son sus principales obstáculos. Esta comunicación cara a cara permanente previene problemas que se puedan esconder. No importa qué disciplinas de desarrollo se requieran, cada equipo ágil contendrá un representante del cliente. Esta persona es designada por las personas involucradas en el negocio para actuar en su nombre y hacer un compromiso personal de estar disponible para los desarrolladores para responder preguntas. Al final de cada iteración, las personas involucradas en el negocio y el representante del cliente revisan el progreso y reevalúan las prioridades con vistas a optimizar el retorno de la inversión y asegurando la alineación con las necesidades del cliente y los objetivos de la compañía. Los modelos alternativos enfatizan software operativo como la medida principal del progreso. Combinado con la preferencia de comunicación cara a cara, los métodos ágiles normalmente producen menos documentación escrita que otros métodos

Principios detrás del manifiesto ágil

Los valores anteriores inspiran los doce principios del manifiesto. Son características que diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espíritu ágil. El resto tiene que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto a metas a seguir y organización del mismo.

-

La prioridad más alta es satisfacer al cliente a través de la entrega temprana y continua de software de valor.

-

Los cambios en los requisitos son bienvenidos, incluso tarde en el desarrollo. Los procesos ágiles aprovechan los cambios como ventaja competitiva del cliente.

-

Entregar software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia de escalas de tiempo cortas (con el menor intervalo de tiempo posible). 14


-

Las personas de negocio y los desarrolladores deben trabajar juntos diariamente durante todo el proyecto.

-

Construir proyectos alrededor de individuos motivados. Darles el entorno y el soporte necesario, y confiar en que ellos harán el trabajo.

-

El método más eficiente y efectivo de hacer llegar información a o dentro de un equipo de desarrollo es en una conversación cara a cara.

-

Software que funciona es la medida primaria (principal) del progreso.

-

Los procesos ágiles promueven desarrollo sostenible. Los sponsors, desarrolladores y usuarios deberían ser capaces de mantener un ritmo constante indefinido.

-

La atención continua a la excelencia técnica y los buenos diseños aumentan la agilidad.

-

Simplicidad, el arte de maximizar la cantidad de trabajo no hecho, es esencial.

-

Las mejores arquitecturas, requisitos y diseño surgen de equipos organizados por sí mismos.

-

A intervalos regulares, los equipos reflexionan sobre cómo ser más efectivos, entonces afinan y ajustan su comportamiento de acuerdo con ello.

Extreme Programming La programación extrema (XP) es un enfoque de la ingeniería del software formulado por Kent Beck. Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto y aplicarlo de manera dinámica durante el ciclo de vida del software.

15


XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en la realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes,

simplicidad en las soluciones

implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. A Kent Beck se le considera el padre de XP. (Lainez, 2014) Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. Elementos Las historias de usuario: son la técnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarlas en unas semanas. Las historias de usuario se descomponen en tareas de programación y se asignan a los programadores para ser implementadas durante una iteración

Roles XP: los roles de acuerdo con la propuesta de Beck son: -

Programador: el programador escribe las pruebas unitarias y produce el código del sistema

-

Cliente: escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en apoyar mayor valor al negocio.

-

Encargado de pruebas (tester): ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para las pruebas.

16


-

Encargado de seguimiento (tracker): proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteración.

-

Entrenador (coach): es el responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.

-

Consultor: es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas.

-

Gestor (big boss): es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

‐ Proceso XP: el ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos: -

El cliente define el valor de negocio a implementar

-

El programador estima el esfuerzo necesario para su implementación

-

El programador construye ese valor

-

Vuelve al paso 1

-

En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse de que el sistema tenga el mayor valor de negocio posible.

El ciclo de vida ideal de XP consisten en 6 fases: exploración, planificación de la entrega, iteraciones, producción, mantenimiento y muerte del proyecto. SCRUM Scrum es un proceso ágil que se puede usar para gestionar y controlar desarrollos complejos de software y productos usando prácticas iterativas e incrementales. Scrum es

un proceso incremental iterativo para desarrollar cualquier producto o gestionar cualquier trabajo.

17


Aunque Scrum estaba previsto que fuera para la gestión de proyectos de desarrollo de software, se puede usar también para la ejecución de equipos de mantenimiento de software o como un enfoque de gestión de programas (Keith, 2012)

Características

Scrum es un esqueleto de proceso que incluye un conjunto de prácticas y roles predefinidos. Los roles principales en Scrum son el “ScrumMaster” que mantiene los procesos y trabaja junto con el jefe de proyecto, el “Product Owner” que representa a las personas implicadas en el negocio y el “Team” que incluye a los desarrolladores. Durante cada iteración (sprint- periodos de tiempo), típicamente un periodo de 2 a 4 semanas (longitud decidida por el equipo), el equipo crea un incremento de software operativo. El conjunto de características que entra en una iteración viene del “backlog” del producto, que es un conjunto priorizado de requisitos de trabajo de alto nivel que se han de hacer. Los ítems que entran en una iteración se determinan durante la reunión de planificación de la iteración. Durante esta reunión, el Product Owner informa al equipo de los ítems en el backlog del producto que quiere que se completen. El equipo determina entonces a cuanto de eso puede comprometerse a completar durante la siguiente iteración. Durante una iteración, nadie puede cambiar el backlog de la iteración, lo que significa que los requisitos están congelados para esa iteración. Cuando se completa una iteración, el equipo demuestra el uso del software. Scrum permite la creación de equipos con propia organización fomentando la localización conjunta de todos los miembros del equipo y la comunicación verbal entre todos los miembros del equipo y las disciplinas implicadas en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar sus pensamientos sobre lo que quieren y necesitan, y de que los desafíos que no se pueden predecir no se pueden tratar fácilmente de una forma predictiva o planificada tradicional. Por esto, Scrum adopta un enfoque empírico, aceptando que el problema no se puede entender o definir completamente, centrándose en cambio en maximizar las habilidades del equipo para entregar rápidamente y responder a los requisitos emergentes.

18


Una de las mayores ventajas de Scrum es que es muy fácil de entender y requiere poco esfuerzo para comenzar a usarse. Una parte muy importante de Scrum son las reuniones que se realizan durante cada una de las iteraciones. Hay distintos tipos: Scrum diario: cada día durante la iteración, tiene lugar una reunión de estado del proyecto. A esta reunión se le domina Scrum -

Reunión de planificación de iteración (sprint): se lleva a cabo al principio del ciclo de la iteración.

-

Reunión de revisión de iteración: al final del ciclo de la iteración.

-

Iteración retrospectiva: al final del ciclo de la iteración.

Practicas

A continuación se enumeran algunas de las prácticas de Scrum: -

Los clientes se convierten en parte del equipo de desarrollo.

-

Scrum tiene frecuentes entregables intermedios con funcionalidad que funciona, como otras formas de procesos de software ágiles. Esto permite al cliente conseguir trabajar con el software antes y permite al proyecto cambiar los requisitos de acuerdo con las necesidades.

1

19


-

Se desarrollan planes de riesgos y mitigación frecuentes por parte del equipo de desarrollo, la mitigación de riesgos, la monitorización y la gestión de riesgos se lleva a cabo en todas las etapas y con compromiso.

-

Transparencia en la planificación y desarrollo de módulos, permitir a cada uno saber quién es responsable de qué y cuándo.

-

Frecuentes reuniones de las personas involucradas en el negocio para monitorizar el progreso.

-

Debería haber un mecanismo de advertencias avanzado.

-

Los problemas no se han de barrer a debajo de la alfombra. Nadie es penalizado por reconocer o describir un problema imprevisto.

2.1.3

Conclusiones

Christian Acero No existe una metodología o modelo universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humano, tiempo de desarrollo, tipo de sistema, etc.). Históricamente, las modelos tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Los modelos alternativos

ofrecen una solución casi a medida para una gran cantidad de

proyectos que tienen estas características. Una de las cualidades más destacables en una metodología ágil es su sencillez, tanto en su aprendizaje como en su aplicación, reduciéndose así los costes de implantación en un equipo de desarrollo. Esto ha llevado hacia un interés creciente en los modelos alternativos. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicación, tales como: están dirigidas a equipos pequeños o medianos, el entorno físico debe ser un ambiente que permita la comunicación y colaboración entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prácticas y principios puede llevar al proceso al fracaso, el uso de tecnologías que no tengan un ciclo rápido de realimentación o que no soporten fácilmente el cambio.

20


Nelson Chama La evolución del software

tanto en el desarrollo de software con diferentes

metodologías y modelos tiene lugar cuando cambian los sistemas de software existentes para satisfacer nuevos requerimientos. Los cambios son continuos y el software debe evolucionar para seguir siendo útil. Los procesos deben incluir actividades para lidiar con el cambio. Esto puede implicar una fase de creación de prototipos que ayude a evitar malas decisiones sobre los requerimientos y el diseño. Los procesos pueden estructurarse para desarrollo y entrega iterativos, de forma que los cambios se realicen sin perturbar al sistema como un todo. Los modelos alternativos son métodos de desarrollo incremental que se enfocan en el diseño rápido, liberaciones frecuentes del software, reducción de gastos en el proceso y producción de código de alta calidad. Hacen que el cliente intervenga directamente en el proceso de desarrollo. Conclusiones generales Hemos visto diferentes modelos de desarrollo, específicamente se dividen en dos principales según Kroll, que básicamente están diferenciados por el nivel de burocracia. Aunque los modelos alternativos están siendo más usados por su simplicidad pero hay que tener en cuenta que esto varía mucho de la organización, nivel de madures de la empresa, presupuesto, tiempo, criticidad. Entre otros. Por eso podemos decir que no existe un modelo universal, son situacionales. Pero estos modelos siempre están apoyamos por un factor importante que es la gestión de configuración, que se suele contar en algunos modelos alternativos pero que apoya a que el proyecto se desarrolle.

21


3. Generación de Plan de Gestión de la Configuración de Software

El proceso de planificación y gestión es el primero de los proceso y, como su nombre indica, engloba las tareas de planificación y gestión de los otros cuatro proceso, identificación, control, registro y verificación y auditorias de la configuración. El plan de gestión de la Configuración del Proyecto se elabora una vez se recibe la instrucción de iniciar el proyecto y contempla la planificación de tareas, calendarios, asignación de recursos humanos y materiales así como los costes necesarios para establecer los procesos involucrados, relativos a la gestión de la configuración durante el ciclo de vida del producto. La planificación tendrá en consideración los requisitos contractuales que guarden relación con la gestión de la configuración y que formará parte del Plan de Gestión del Proyecto. Se realizará la planificación, se obtendrá como resultado una lista de requisitos a satisfacer para poder implantar el sistema de configuración. Estos pueden ser recursos humanos, materiales (Software, hardware), económicos, etc. De esta actividad, también resultará la elaboración de los procedimientos operativos del resto de procesos (identificación, control, registro y verificación y auditorias de la configuración). (Rodriguez, Fernandez, & Romero)

3.1

Diseñar el Plan de Gestión de Configuración de Software

ANEXO 1 3.1.1

Ciclo de Vida Tradicional

3.1.1.1 Proyecto de desarrollo que se encuentra en fase de Análisis

22


3.1.1.2 Proyecto de desarrollo que se encuentra en fase de Desarrollo 3.1.1.3 Proyecto de desarrollo que se encuentra en fase de Diseño 3.1.1.4 Proyecto de desarrollo que se encuentra en fase de Codificación y Pruebas 3.1.1.5 Proyecto de desarrollo que se encuentra en fase de Instalación o posterior 3.1.1.6 Consideraciones Finales por cada integrante y una general por Equipo

CONCLUSIONES

23


RECOMENDACIONES

24


REFERENCIAS

Benington, H. (2011). La producción de grandes programas de ordenador. Estadis Unidos. Daniel Ramos, R. N. (2015). Curso de Ingeniería de Software. Daniel Ramos, R. N. (2015). Curso de Ingeniería de Software. En R. N. Daniel Ramos, Curso de Ingeniería de Software (págs. 97-98). Gibbs, R. D. (2009). Project Management with the IBM RUP. Keith, C. (2012). Agile Game Development with Scrum. Estados Unidos. Lainez, J. (2014). Desarrollo de Software Agil, XP y SCRUM. MacIsaac, K. (2013). Agility and Discipline, Made easy. Estados Unidos. Macmillan, P. (2001). The B-Method: An Introduction, Steve Schneider. Estadis Unidos. Pressman, R. (2006). Ingeniería de Software, un enfoque practico. En R. Pressman, Ingeniería de Software, un enfoque practico (pág. 58). España. Software, L. N. (Marzo Comunicación.

de

2009).

Instituto

Nacional

de

Tecnologia

de

Sommerville, I. (2011). Ingeniería de Software. Mexico.

25


ANEXOS i

26


Plan de Configuración Versión Sistema de Gestión y Monitoreo de Proyectos SISGEM

1.

FECHA: 22/05/2016 VERSIÓN: v1.0 ÁMBITO: GRUPO Contenido CÓDIGO: PREQ- SISGEM -01 Introducción............................................................................................................. 3 1.1. Propósito........................................................................................................... 3 1.2. Alcance............................................................................................................. 3

27


1.3. Terminología.....................................................................................................3 1.4. Referencias.......................................................................................................3 2. Gestión de SCM......................................................................................................4 2.1. Organización.....................................................................................................4 2.2. Responsabilidades............................................................................................4 2.3. Políticas, directivas y procedimientos aplicables...............................................4 3. Actividades de SCM................................................................................................5 3.1. Identificación de la configuración......................................................................5 3.1.1. Elementos de configuración.......................................................................5 3.1.2. Nomenclatura de Elementos......................................................................5 3.1.3. Elementos de la Línea Base del Proyecto..................................................8 3.1.4. Recuperación de los Elementos de configuración......................................8 3.2. Control de configuración...................................................................................8 3.2.1. Solicitud de cambios...................................................................................8 3.2.2. Evaluación de cambios o Análisis de Impacto............................................9 3.2.3. Aprobación o desaprobación de cambios...................................................9 3.2.4. Implementación de cambios.......................................................................9 3.3. Estado de la configuración..............................................................................10 3.4. Auditorias y revisiones de configuración.........................................................10 3.5. Control de Interfases.......................................................................................10 3.6. Control de subcontratos y vendedores............................................................11 4. Calendario............................................................................................................. 11 5. Recursos............................................................................................................... 11 6. Mantenimiento del Plan de SCM...........................................................................11

Plan de Configuración Versión 1.

Introducción

El siguiente documentos tiene como objetivo definir los miembros y actividades de la gestión de configuración, así como los pasos que hay que seguir para la evaluación y aceptación de 28


los cambios, se establecen los responsables de la autoridad de cambios, como sus funciones, se muestra el método de nombrado y la estructura de los informes del estado de configuración.

1.1.

Propósito

Este documento describe las actividades de gestión de configuración de software que deben ser llevadas a cabo durante el proceso de desarrollo del proyecto. Aquí se definen tanto los productos que se pondrán bajo control de configuración como los procedimientos que deben ser seguidos por los integrantes del equipo de trabajo. 1.2.

Alcance

El Plan de configuración está basado en algunos supuestos que se detallarán: 

El tiempo de duración del proyecto está limitado a 13 semanas, por lo tanto se busca una rápida respuesta a los cambios, tratando que este procedimiento sea lo menos burocrático posible.



El Modelo de Proceso se basa en un modelo tradicional en cascada, dado por las distintas iteraciones. Resulta importante tener control sobre cada una de las iteraciones y fases, de los productos generados en estas y de los cambios surgidos, evaluados y aprobados.



Se deben incluir en control de configuración la mayor cantidad de productos posibles, tomando en cuenta siempre las restricciones dadas por la duración del proyecto y por la capacidad organizativa del grupo.



La elección de los elementos de configuración se realizará en base a los entregables, siendo ésta responsabilidad del Responsable de SCM, apoyado por los integrantes de cada disciplina.

1.3.

Terminología



CCB

(Configuration Control Board) Comité de Control de Configuración.



CI

(Configuration Item) elemento bajo gestión de Configuración.



SCA

(Software Change Authorization) Autorización de Cambio en el

Software.

29




SCM

(Software Configuration Management) Gestión de Configuración del

Software. 

SCMR (SCM Responsable) Responsable de SCM.



SCR

(System/Software Change Request) Petición de Cambio en el

Sistema/Software. 

SQA

(Software Quality Assurance) Aseguramiento de la Calidad del

Software.  1.4.

SQAR (SQA Responsable) Responsable de SQA. Referencias

[1] ANSI/IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans. [2] 2002, Modelo de Proceso. 2.

Gestión de SCM

NOMBRE

TAREAS

DEFINICIÓN

Christian César Realización del plan de Apoyar el trabajo de los Acero Catacora gestión de Desarrolladores, para que estos configuración tengan espacios de trabajo apropiados para construir y para probar su trabajo, además de llevar un seguimiento y control de los cambios llevados durante el desarrollo.

Realización de los informes. Mostrar el estado actual de todas las solicitudes de cambio, así como el tiempo en el que están en un estado determinado y una evolución de las mismas. Nelson Chama

Control de Cambios

Decide si un cambio se lleva a cabo y lo evalúa.

Almacenamiento de copias Guardar el contenido de seguridad. repositorio, en nuestro

del

servidor de copias, al final de 30


cada semana.

2.1.

Organización

Como empresa desarrollo que divide en las siguientes áreas

Gerencia

Secretaria

Contabilida d

Marketing

Desarrollo

Recursos Humanos

Analisis

Diseño

Programaci ón

Test

Control de Cambios

Se debe identificar: 31




Dentro de la organización el área donde se hace el plan de la configuración es en el área de Desarrollo



Para el desarrollo del producto se considera que se usa un modelo en cascada

2.2.

Responsabilidades

El SCMR debe proveer la infraestructura y el entorno de configuración para el proyecto. Se le asigna al Ing. Christian Acero Catacora como deber de preocuparse porque todos los integrantes del grupo entiendan y puedan ejecutar las actividades de SCM que el Plan les asigna, así como asegurar que éstas sean llevadas a cabo. Seguir la línea base, controlando las versiones y cambios de ella, son tareas correspondientes a el. Debe definir y construir el Ambiente Controlado e informar al resto del equipo sobre la manera de usarlo. El SCMR es un apoyo importante para las decisiones que debe tomar el CCB, debiendo formar parte de éste si lo cree necesario. Otras actividades que conciernen al SCMR son : 

Identificar los elementos de configuración, estableciendo así la línea base del proyecto.



Fijar una política de nomenclatura de los elementos de configuración para facilitar la identificación y ubicación de éstos en el proyecto.



Llevar a cabo el control de la configuración, estableciendo estándares y procedimientos a seguir con respecto a los cambios para permitir un control de los mismos.



Proveer de reportes de estado de la configuración mediante el seguimiento del historial de las revisiones y liberaciones.



Realizar auditorias de la línea base del software para verificar que el Sistema en desarrollo es consistente y la línea base está bien definida.

32


2.3.

Políticas, directivas y procedimientos aplicables

Las directivas que se usan es basado en el resultado de cada fase que básicamente consiste en uno o más documentos se autoricen para continuar con el desarrollo, también llamadas líneas base, en caso contrario, se evaluará el impacto en el retraso de alguna actividad en las fases anteriores antes de continuar. La siguiente fase no debe comenzar sino hasta que termine la fase previa.

3.

Actividades de SCM Identifica todas las actividades y tareas que se requieren para el manejo de la configuración del sistema. Estas deben ser tanto actividades técnicas como de gestión de SCM, así como las actividades generales del proyecto que tengan implicancia sobre el manejo de configuración. 3.1.

3.1.1.

Identificación de la configuración

Elementos de configuración Para este proyecto los elementos de configuración se corresponderán con los entregables definidos en el Modelo de Proceso en Cascada,

aunque no

necesariamente todos los entregables deben ser elementos de configuración ya que pueden existir trabas que alteren el avance del proyecto. La decisión de cuales de los entregables serán elementos de configuración será tomada por el SCMR, quién deberá tomar en cuenta qué productos serán necesarios cuando se quiera recuperar una versión completa del sistema.

Se debe generar una línea base por iteración en cada Fase, de acuerdo a lo siguiente: 

Los eventos que dan origen a la línea base.



Los elementos que serán controlados en la línea base.



Los procedimientos usados para establecer y cambiar la línea base.



La autorización requerida para aprobar cambios a los documentos de la línea base.

3.1.2.

Nomenclatura de Elementos En esta sección se especifican la identificación y descripción única de cada elemento de configuración. 33


Además se especifica como se distinguirán las diferentes versiones de cada elemento. Para todos los elementos de configuración se les deberá agregar, después del nombre del mismo, información acerca del grupo al que corresponde el elemento y la versión del mismo. El formato para esta nomenclatura es: NomenclaturaGXvY.extensión, donde:

· Nomenclatura es la especificada mas abajo para cada elemento. · X es un número de 1 dígito que identifica al grupo. · Y indica la versión del elemento de configuración o entregable. · Extensión indica la extensión del elemento de configuración o entregable.

[Ejemplo: RQALSG1v2.doc, es como se deberá llamar el entregable

"Alcance del

Sistema" correspondiente al grupo 1 y cuya versión del documento es la 2.]

Para los entregables, se deberá identificar a que Fase e iteración corresponden en forma manual. Esto es: para los elementos bajo control de configuración se los almacenará de forma que se puedan recuperar dada la Fase e iteración a la que corresponden, y para los elementos que no se encuentran bajo control de configuración podrán ser almacenados por ejemplo en carpetas que identifiquen la Fase e iteración a la que pertenecen. Se indica la siguiente nomenclatura para cada entregable en el modelo de proceso, según la disciplina (en caso que exista algún elemento de configuración que se agregue a los que se detallan abajo, se deberá incluir en las tablas siguientes de acuerdo a la disciplina a la que pertenece, indicando la nomenclatura usada):

Requerimientos: Nomenclatura

Entregable

RQACT

Acta de Reunión de Requerimientos

RQDRQ

Especificación de Requerimientos

RQMOD

Modelo de Casos de Uso

RQRSU

Requerimientos Suplementarios 34


RQDVC

Documento de Validación con el Cliente

RQPIU

Pautas para Interfase de Usuario

RQRCA

Requerimientos Candidatos

RQALS

Alcance del Sistema

RQGLO

Glosario

RQOOMDO

Modelo de Dominio

RQOODRP

Documento de Requerimientos para el Prototipo

RQGXNOM

Nomenclatura

Diseño: Nomenclatura

Entregable

DSMDI

Modelo de Diseño

DSARQ

Descripción de la Arquitectura

DSOOMDA

Modelo de Datos

DSOODDP

Documento de Diseño del Prototipo

Implementación: Nomenclatura

Entregable

IMEDT

Estándar de Documentación Técnica

IMEI

Estándar de Implementación

IMPR

Prototipo

IMIIN

Informe de Integración

IMDT

Documentación técnica

IMIVU

Informe de Verificación Unitaria

IMOOPII

Plan de Integración de la Iteración

IMOOMIM

Modelo de Implementación

IMOOEJI

Ejecutable de la Iteración

IMOORRP

Reporte de Revisión por Pares

IMOOCVU

Clases de la Verificación Unitaria de Módulo

IMGXICO

Informe de Consolidación 35


IMGXEST

BC Con Estilos

IMGXCON

BC Consolidado

IMGXNUC

BC Núcleo

IMGXMOD

BC Módulo

Verificación: Nomenclatura

Entregable

VRPVV

Plan de Verificación y Validación

VRDAP

Documento de Evaluación y Ajuste del Plan de V & V

VRPVI

Plan de Verificación de la Iteración

VRMCP

Modelo de Casos de Prueba

VRIVD

Informe de Verificación de Documento

VRIVI

Informe de Verificación de Integración

VRIVS

Informe de Verificación del Sistema

VRRPR

Reportes de Pruebas

VREV

Evaluación de la Verificación

VRIFV

Informe Final de Verificación

Implantación (IP): Nomenclatura

Entregable

IPMSU

Materiales para Soporte al Usuario (Se pueden usar sufijos para identificar cada ítem dentro del material Ej. IPMSUMU para Manual de Usuario)

IPMCA

Materiales para Capacitación

IPPS

Presentación del Sistema

IPPLA

Plan de Implantación

IPVPR

Versión del Producto

IPOOEDU

Estándar de Documentación de Usuario

IPOORFPA

Reporte Final de Pruebas de Aceptación

Gestión de Configuración y Control de Cambios (SCM): 36


Nomenclatura

Entregable

SCMPLA

Plan de Configuración

SCMMAC

Manejo del Ambiente Controlado

SCMGC

Gestión de Cambios

SCMRV

Registro de Versiones

SCMILB

Informe de la Línea Base del Proyecto

SCMIF

Informe Final de SCM

Gestión de Calidad (SQA): Nomenclatura

Entregable

SQAPLA

Plan de Calidad

SQADAP

Documento de Evaluación y Ajuste del Plan de Calidad

SQARTF

Informe de RTF

SQAES

Entrega Semanal de SQA

SQAIR

Informe de Revisión de SQA

SQADV

Descripción de la Versión

SQANV

Notas de la Versión

SQAIF

Informe Final de SQA

Gestión de Proyecto (GP): Nomenclatura

Entregable

GPPLA

Plan de Proyecto

GPISP

Informe de Situación del Proyecto

GPEM

Estimaciones y Mediciones

GPDRI

Documento de Riesgos

GPRAC

Registro de Actividades

GPIFP

Informe Final de Proyecto

GPARE

Acta de la Reunión de Equipo

GPPIT

Plan de la Iteración

GPPDE

Plan de Desarrollo 37


GPICF

Informe de Conclusiones de la Fase

GPPDIP

Presentación en Diapositivas del Proyecto

GPPDP

Presentación al Director del Proyecto

GPARD

Acta de la Reunión con el Director del Proyecto

GPOODAP

Documento de Evaluación y Ajuste al Plan de Proyecto

GPIARI

Acta de la Reunión de Integración

Comunicación (COM):

3.1.3.

Nomenclatura

Entregable

COMDI

Documento Informativo

COMENS

Encuesta de Satisfacción del Cliente

COMEVS

Evaluación de Satisfacción del Cliente

Elementos de la Línea Base del Proyecto [En esta sección se debe detallar la Línea Base. Esto es, los elementos que pertenecen a la Línea Base del Proyecto, especificados por Fase del Proyecto y por iteraciones dentro de cada Fase.]

FASE: [Fase] Elemento Documentos Visión

Descripción Fase de Analisis requisitos

Disciplina de Los servicios,

las

restricciones y las metas del sistema se establecen mediante consulta a los usuarios

del

sistema.

Luego, se definen con detalle y sirven como una especificación

del

sistema. Documentos

de Fase de desarrollo

Gestión del Proyecto

Se empieza a hacer un control de calidad y riesgo que asegure la calidad y 38


mitigue e identifique los riesgos que puedan surgir dentro del proyecto Documentos

de Fase de Diseño

El proceso de diseño de

Arquitectura

del

sistemas

sistema

asigna

los

requerimientos,

para

sistemas de hardware o de software, al establecer una

arquitectura

de

sistema global. El diseño del

software

implica

identificar y describir las abstracciones fundamentales

del

sistema de software y sus relaciones.

Documentos

de fase de Codificación y Durante esta etapa, el

Pruebas Unitarias

Pruebas

diseño de software se rea liza como un conjunto de programas o unidades del programa. La prueba de unidad

consiste

en

verificar que cada unidad cumpla

con

su

especificación. Documento de Prueba fase de Integración Documentos

de

posterior

Instalación

o Las

unidades

del

programa o los programas

de

individuales se integran y

satisfacción del cliente

prueban como un sistema completo para asegurarse de que se cumplan los requerimientos

de

software.

de

Después

39


probarlo,

se

libera

el

sistema de software al cliente

3.2.

Control de configuración

En esta sección se detallan las actividades de solicitud, evaluación, aprobación e implementación de cambios a los elementos de la línea base. Los cambios apuntan tanto a la corrección como al mejoramiento. El procedimiento que se describe a continuación es el que se utilizará cada vez que se precise introducir un cambio al sistema. Se entiende por cambio al sistema, las modificaciones que afecten a la línea base del sistema, como pueden ser:



Cambios en los Requerimientos/Analisis.



Cambios en el Desarrollo.



Cambios en el Diseño y Arquitectura



Cambios en las herramientas de desarrollo.



Cambios en la documentación del proyecto. (agregar nuevos documentos o modificar la estructura de los existentes)

3.2.1.

Solicitud de cambios Cuando se realiza la solicitud de un cambio, se actualiza el documento de “Solicitud de cambio” para registrar esta solicitud. Se debe ingresar toda la información necesaria, detallada en el documento.

3.2.2.

Evaluación de cambios o Análisis de Impacto La evaluación del cambio involucra determinar qué es necesario hacer para implementar el cambio y la estimación de sus costos y plazos. Se realiza en 2 pasos:

1. Planificación de la evaluación del cambio que involucra: 40




Revisar la solicitud de cambio para entender su alcance. (Si es necesario se discute con el originador para aclarar el alcance de lo propuesto y los motivos de la solicitud.



Determinar las personas del proyecto que deben realizar el análisis de evaluación del cambio e involucrarlas.



Desarrollar un Plan para la evaluación del cambio.



Si el cambio involucra al Cliente, obtener el acuerdo de éste con el Plan.

2. Evaluar el cambio: Dependiendo de las características del cambio, la evaluación del cambio puede ser realizado por el Administrador o ser delegado a otras personas del proyecto. Se debe determinar el impacto en:

3.2.3.



Los productos técnicos.



Los Planes de proyecto.



Los acuerdos con el Cliente.



Los Riesgos del proyecto.

Aprobación o desaprobación de cambios Se debe formar el “Comité de Control de Configuración” y determinar su autoridad para la aprobación de cambios. La composición de este comité puede variar según el tipo de cambio y las líneas de trabajo involucradas en él. Se sugieren como posibles integrantes: 

Administrador (obligatorio)



Arquitecto (opcional)



Analista (opcional)



Implementador (opcional)



SCM (obligatorio)



Cliente (opcional) 41


Se define un comité de Control de Configuración de nivel superior, compuesto por el Gerente de proyecto, al cual se elevarán las solicitudes de cambios cuya aprobación o desaprobación no se pueda resolver por el primer comité. 3.2.4.

Implementación de cambios Una vez realizada la evaluación del cambio, se decide en qué momento implementarlo. Esta etapa involucra los procesos necesarios para implementar la solicitud y monitorear el progreso del trabajo. Además se especificará el momento de liberación del cambio; así como también los responsables de las actividades que involucra el cambio. Recordando que nos basamos en un proceso de desarrollo incremental e iterativo, donde en cada iteración se realizan tareas de Análisis de requerimientos, Diseño, Implementación y Verificación; se debe introducir el cambio en el área que lo originó y continuar

con

las

actividades

del

ciclo

(Requerimientos,

Análisis,

Diseño,

Implementación, Verificación) que impactarán los elementos de la línea base correspondientes a cada actividad. 3.3.

Estado de la configuración

[Las actividades de control de estado son para reunir información y reportar el estado de los elementos de configuración. Se debe especificar lo siguiente: 

Qué elementos serán revisados de la línea base y por cambios a realizarse.



Qué tipos de reportes de estado serán generados y con qué frecuencia.



Como la información será obtenida, guardada, procesada, y reportada.



Como será controlado el acceso a los datos de estado.

Si se utiliza una herramienta automática deberá ser especificada su funcionalidad y modo de uso explícitamente o por referencia.

En los reportes de estado de los elementos de configuración se debe incluir como mínimo la siguiente información: 

Su primer versión aprobada. 42




El estado de los cambios solicitados.



El estado de implementación de los cambios aprobados.]

3.4.

Auditorias y revisiones de configuración

Se realizarán auditorias de la línea base antes de una liberación de ésta o de una actualización de la versión de un componente prioritario de ésta. Estas auditorias incluirán: 

Objetivo: el objetivo de todas las auditorías es verificar que en un momento dado la línea base se compone de una colección consistente y bien definida de productos.



Elementos de configuración bajo auditoría: se elegirán uno o mas elementos de configuración de mayor prioridad en la línea base.



Agenda de auditorías: antes de la liberación o actualización.



Conducción: las auditorías serán dirigidas por el SCMR.



Participantes: SCMR y los autores de los elementos de configuración a auditar.



Documentos Requeridos: Documentos de SCR y reportes de estado de la configuración generados.



Reportes de Deficiencias y Acciones Correctivas: determinadas por los participantes.



Criterio de Aprobación: lo determina el SCMR.

43


3.5.

Control de Interfases

Las actividades de Control de Interfases controlan los cambios a los elementos de configuración del proyecto, que modifican las interfases con elementos fuera del alcance del Plan. Este control será llevado por el SCMR como parte del control de la configuración. 3.6.

4.

Control de subcontratos y vendedores

Calendario Se debe establecer la secuencia y coordinación de las actividades y eventos que afecten la implementación del Plan en un cronograma. Este debe incluir las actividades de SCM y especificar las dependencias entre estas actividades y los principales hitos en la planificación del proyecto. Los hitos de las actividades de SCM incluyen:

5.



Definición de la línea base.



Implementación de Control de Cambios.



Fechas de comienzo y fin de las auditorias.

Recursos

Para la gestión de la configuración se quiere de una computadora que soporte microsft office 365, tenga acceso a internet, con un sistema operativo Windows 8.1, una impresora. El personal asignado es Ing. Christian Acero Catacora y el Ing. Nelson Chama.

6.

Mantenimiento del Plan de SCM

Este Plan deberá ser revisado al inicio de cada fase, por el Ing. Christian Acero Catacora, que deberá hacer al termino del penúltimo día de la semana laboral o control y monitoreo y los documentos de configuración y avances del proyecto. Un control de

44


los documentos se han modificado de acuerdo a lo necesario, aprobado y distribuido al equipo de proyecto.

45

Proceso de Gestión de La Configuración de Software

Recommend Documents