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

UNIVERSIDAD PRIVADA DE TACNA
FACULTAD DE INGENIERIA
Escuela Profesional de Ingeniera de Sistemas
PROCESO DE GESTIN DE LA CONFIGURACIN

DE SOFTWARE
Curso: Gestin de la Configuracin y administracin de

Software
Docente: Ing. Ricardo Valcrcel Alvarado
Integrantes:
Acero Catacora, Christian Csar (2008030973)
Chama, Nelson
Tacna Per
2016
PROCESO DE GESTIN DE LA CONFIGURACIN DE SOFTWARE
INDICE GENERAL
INTRODUCCION....................................................................................................... 3
1. OBJETIVOS....................................................................................................... 4
2. MARCO TEORICO.............................................................................................. 4
2.1 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
3. Generacin de Plan de Gestin de la Configuracin de Software..............................22
3.1 Disear el Plan de Gestin de Configuracin 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 fcil de modificar o incluso es ms fcil 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 difcil de cambiar e incluso
ms difcil 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 disear y construir un software necesitaremos disciplina. Es
decir, necesitaremos un enfoque de ingeniera. (Software, 2009)
Como elemento de clave al desarrollo de software tenemos la gestin de

configuracin de software que bsicamente son un conjunto de actividades diseadas 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 ms 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
terico sern aplicados para fundamentar en base a fuentes diferentes aspecto que puedan
poner en riesgo el desarrollo del proyecto, de acuerdo a modelo cascada.
3
1. OBJETIVOS
1.1. GENERAL:
Investigar acerca de lo proceso de gestin de la configuracin 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 gestin de

proyecto en un modelo en cascada.
Proponer soluciones en el proceso de configuracin 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 abstraccin 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 ms rpidamente.
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 tcnicos como la especificacin, desarrollo, validacin y evolucin del software y
deben proporcionar transparencias y flexibilidad para facilidad de la gestin de los proyectos.
(Daniel Ramos, Curso de Ingeniera de Software, 2015)
4
El proceso adoptado por una organizacin es tambin una abstraccin en relacin

con el proceso en ejecucin en un proyecto determinado. En general, el proceso de la
organizacin se adopta de acuerdo a las necesidades especficas del proyecto.
Hay una necesidad de gestionar el proceso de desarrollo de software a travs de

modelos, procesos, actividades y herramientas especficas. El desarrollo de un software
tiene sentido en el contexto de una empresa y una organizacin. 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 gestin tales como el
Proceso Unificado, pero existen modelos y proceso especficos para la gestin de proyectos.
Es posible adoptar una combinacin de procesos complementarios de acuerdo con las
necesidades del proyecto y de la organizacin.
La estimacin de software es importante para la gestin de un proyecto. Decisiones

como la cancelacin 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.
Adems, dado el esfuerzo real en comparacin 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 travs de esta comparacin
permiten estimar las actividades futuras con mayor precisin 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 Ingeniera de Software, 2015)
5
2.1.1 Modelos tradicionales
Teniendo en cuenta que la estimacin debe considerar el proceso como las

actividades de desarrollo. Cuando ms actividades extra, documentacin y precisin fueran
exigidos, mayor ser el factor de ajuste necesario para las estimaciones.
Este proyecto de investigacin considera los modelos ms burocrticos y con mayor

rigor como modelos tradicionales. Modelos con poca burocracia, tambin llamados modelos
o alternativos empricos, incluyen modelos de procesos agiles.
Kroll clasifica algunos modelos en unos grficos 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 evolucin, es
ms interactivo y menos burocrtico. As los procesos agiles son bastante interactivos y muy
poco burocrticos. (MacIsaac, 2013)
Pocos riesgos,
Waterfall secuencial,
integracin y
CMM test tardo
Poco
burocrtico CMMI
Poca
documentaci
n, Procesos XP, SCRUM,
ligeros DESARROLL Burocrtico
O ADAPTIVO
Bien
documentador.
Interactivo Trazabilidad
CCB
Riesgoso, contina
integracin y testeo
6
Grado de burocracia de los modelos tradicionales
Watterfall model: Modelo cascada
El modelo de cascada es un diseo 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 travs de las fases de concepcin, iniciacin, anlisis ,
diseo , construccin, pruebas , produccin / aplicacin y mantenimiento .
El modelo de desarrollo en cascada se origina en las de fabricacin y construccin

industrias: muy estructurado entorno fsico en el que despus del hecho, los cambios son
prohibitivamente costoso, si no imposible. Debido a que no hay metodologas formales de
desarrollo de software existan 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 especificacin, desarrollo,

validacin y evolucin y, luego, los represente como fases separadas del proceso, tal como
especificacin de requerimientos, diseo de software, implementacin, pruebas, etctera.
Las principales etapas del modelo en cascada reflejan directamente las actividades
fundamentales del desarrollo:
1. Anlisis y definicin 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 especificacin del sistema.
2. Diseo del sistema y del software El proceso de diseo de sistemas asigna los
requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de
sistema global. El diseo del software implica identificar y describir las abstracciones
fundamentales del sistema de software y sus relaciones.
3. Implementacin y prueba de unidad Durante esta etapa, el diseo 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 especificacin.
4. Integracin 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. Despus de probarlo, se libera el sistema de

software al cliente.
5. Operacin y mantenimiento Por lo general (aunque no necesariamente), sta es la fase

ms larga del ciclo de vida, donde el sistema se instala y se pone en prctica. El
mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del
ciclo de vida, mejorar la implementacin 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 ms documentos que se

autorizan (firmaron). La siguiente fase no debe comenzar sino hasta que termine la fase
previa. En la prctica, dichas etapas se traslapan y se nutren mutuamente de informacin.
Durando el diseo se identifican los problemas con los requerimientos. En la

codificacin se descubren los problemas de diseo, y as sucesivamente. El proceso de
software no es un simple modelo lineal, sino que implica retroalimentacin 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 produccin y aprobacin de documentos, las iteraciones

suelen ser onerosas e implicar un rediseo significativo. Por lo tanto, despus de un
8
pequeo nmero de iteraciones, es normal detener partes del desarrollo, como la

especificacin, y continuar con etapas de desarrollo posteriores. Los problemas se dejan
para una resolucin posterior, se ignoran o se programan. Este freno prematuro de los
requerimientos quiz signifique que el sistema no har lo que el usuario desea. Tambin
podra conducir a sistemas mal estructurado conforme los problemas de diseo se evadan
con la implementacin de trucos.
Durante la fase final del ciclo de vida (Operacin 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 diseo, 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 repeticin de etapas anteriores de
los procesos
El modelo en cascada es consecuente con otros modelos de proceso de ingeniera y

en cada fase se produce documentacin. 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 particin 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
ingeniera. Como es ms sencillo emplear un modelo de gestin comn durante todo el
proyecto, aun son de uso comn los procesos de software basado en el modelo en cascada.
Una variacin importante del modelo en cascada es el desarrollo de sistemas

formales, donde se crea un modelo matemtico, para una especificacin del sistema.
Despus se corrige este modelo, mediante trasformaciones matemticas que preservan su
consistencia en un cdigo ejecutable. Con base en la suposicin de que son correctas sus
transformaciones matemticas, se pueden aseverar, por lo tanto, que un programa generado
de esta forma es consecuente con su especificacin.
Los procesos formales de desarrollo, como el que se basa el mtodo B (Macmillan,

2001) son muy adecuados para el desarrollo de sistemas que cuenten con rigurosos
requerimientos de seguridad, fiabilidad o proteccin. El enfoque formal simplifica la
9
produccin de un caso de proyecto o seguridad. Esto demuestra a los clientes o reguladores

que el sistema en realidad cumple con sus requerimientos de proteccin o seguridad.
Los procesos basados en transformaciones formales se usan por lo general solo en el

desarrollo de sistemas crticos para proteccin o seguridad. Requieren experiencia
especializada. Para la mayora 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 divisin 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 seleccionarn 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 combinacin de varias metodologas y se vio influenciado por

mtodos previos como el modelo en espiral. Las consideraciones clave fueron el fallo de
proyectos usando mtodos monolticos del estilo del modelo en cascada y tambin la llegada
del desarrollo orientado a objetos y las tecnologas GUI, un deseo de elevar el modelado de
sistemas a la prctica 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 diagnstico de las

caractersticas de diferentes proyectos de software fallidos. De esta forma intentaron
reconocer las causas raz de tales fallos. Tambin se fijaron en los procesos de ingeniera del
software existentes y sus soluciones para estos sntomas.
El fallo de los proyectos es causado por una combinacin de varios sntomas, aunque
cada proyecto falla de una forma nica. La salida de su estudio fue un sistema de mejores
prcticas del software al que llamaron RUP.
10
El proceso fue diseado con las mismas tcnicas con las que el equipo sola disear
software; tena un modelo orientado a objetos subyacente, usando UML (Unified Modeling
Language). (Gibbs, 2009)
Mdulos de RUP (building blocks)
RUP se basa en un conjunto de mdulos o elementos de contenido, que describen qu se va

a producir, las habilidades necesarias requeridas y la explicacin paso a paso describiendo
cmo se consiguen los objetivos de desarrollo. Los mdulos principales, o elementos de
contenido, son:
Roles (quin): 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 (cmo): 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 sera
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. Tambin, 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 iniciacin: se define el alcance del proyecto.
Fase de elaboracin: se analizan las necesidades del negocio en mayor detalle y se define
sus principios arquitectnicos.
11
Fase de construccin: se crea el diseo de la aplicacin y el cdigo fuente.
Fase de transicin: se entrega el sistema a los usuarios.
RUP proporciona un prototipo al final de cada iteracin.
Dentro de cada iteracin, las tareas se categorizan en nueve disciplinas:
- Seis disciplinas de ingeniera

Modelaje de negocio
Requisitos
Anlisis y diseo
Implementacin
Pruebas
Despliegue
- Tres disciplinas de soporte
Gestin de la configuracin y del cambio
Gestin 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 ms 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 caractersticas de adaptacin, el Proceso unificado cubre una amplia
gama de grfica. Dependiendo del proyecto, este puede ser adaptado para ser ms o
menos interactivo, (Pressman, 2006)
Poco riesgo,
secuencial,
Waterfall tarda
integracin y
testing
Relajado
Poca
documentaci
n, Procesos RUP
SCRUM
ligeros.
OPENUP/BA Disciplinado
Poco SIC
buroctico Bien
XP
documentador.
Interactivo Trazabilidad
CCB
Riesgoso, contina
integracin y testeo
Grado de burocracia de los modelos alternativos
13
La mayora de los modelos alternativos incluyen una comunicacin cara a cara

rutinaria, diaria y formal entre los miembros del equipo. Esto incluye especficamente al
representante del cliente y a cualquier persona involucrada en el negocio interesada como
observadores. En una breve sesin, los miembros del equipo informan al resto de lo que
hicieron el da anterior, lo que van a hacer hoy y cules son sus principales obstculos. Esta
comunicacin 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 iteracin, las personas
involucradas en el negocio y el representante del cliente revisan el progreso y reevalan las
prioridades con vistas a optimizar el retorno de la inversin y asegurando la alineacin con
las necesidades del cliente y los objetivos de la compaa.
Los modelos alternativos enfatizan software operativo como la medida principal del
progreso. Combinado con la preferencia de comunicacin cara a cara, los mtodos giles
normalmente producen menos documentacin escrita que otros mtodos
Principios detrs del manifiesto gil
Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que
diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espritu gil. El resto tiene que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto a metas a seguir y organizacin del mismo.
- La prioridad ms alta es satisfacer al cliente a travs 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 harn el trabajo.
- El mtodo ms eficiente y efectivo de hacer llegar informacin a o dentro de un

equipo de desarrollo es en una conversacin cara a cara.
- Software que funciona es la medida primaria (principal) del progreso.
- Los procesos giles promueven desarrollo sostenible. Los sponsors, desarrolladores

y usuarios deberan ser capaces de mantener un ritmo constante indefinido.
- La atencin continua a la excelencia tcnica y los buenos diseos aumentan la

agilidad.
- Simplicidad, el arte de maximizar la cantidad de trabajo no hecho, es esencial.
- Las mejores arquitecturas, requisitos y diseo surgen de equipos organizados por s

mismos.
- A intervalos regulares, los equipos reflexionan sobre cmo ser ms efectivos,

entonces afinan y ajustan su comportamiento de acuerdo con ello.
Extreme Programming
La programacin extrema (XP) es un enfoque de la ingeniera del software formulado

por Kent Beck. Es el ms destacado de los procesos giles de desarrollo de software. Al
igual que stos, la programacin extrema se diferencia de las metodologas tradicionales
principalmente en que pone ms 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
aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del
proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las mejores

metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto y
aplicarlo de manera dinmica durante el ciclo de vida del software.
15
XP es una metodologa gil centrada en potenciar las relaciones interpersonales

como clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo,
preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de
trabajo. XP se basa en la realimentacin continua entre el cliente y el equipo de desarrollo,
comunicacin 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 tcnico. A Kent Beck se le considera el padre de XP. (Lainez, 2014)
Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah

proviene su nombre.
Elementos
Las historias de usuario: son la tcnica utilizada para especificar los requisitos del
software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las
caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El
tratamiento de las historias de usuario es muy dinmico 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
programacin y se asignan a los programadores para ser implementadas durante una
iteracin
Roles XP: los roles de acuerdo con la propuesta de Beck son:

- Programador: el programador escribe las pruebas unitarias y produce el cdigo del
sistema
- Cliente: escribe las historias de usuario y las pruebas funcionales para validar su
implementacin. Adems, asigna la prioridad a las historias de usuario y decide
cules se implementan en cada iteracin centrndose 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 realimentacin 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 iteracin.
- Entrenador (coach): es el responsable del proceso global. Debe proveer guas al

equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente.
- Consultor: es un miembro externo del equipo con un conocimiento especfico en

algn tema necesario para el proyecto, en el que puedan surgir problemas.
- Gestor (big boss): es el vnculo entre clientes y programadores, ayuda a que el

equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial
es de coordinacin.
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 implementacin
- 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 ms trabajo que el estimado, ya que
se perder calidad en el software o no se cumplirn los plazos. De la misma forma el
cliente tiene la obligacin 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: exploracin, planificacin de la entrega,

iteraciones, produccin, 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 prcticas 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 gestin de proyectos de desarrollo
de software, se puede usar tambin para la ejecucin de equipos de mantenimiento de
software o como un enfoque de gestin de programas (Keith, 2012)
Caractersticas
Scrum es un esqueleto de proceso que incluye un conjunto de prcticas 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 iteracin (sprint- periodos de tiempo), tpicamente un periodo de 2 a 4

semanas (longitud decidida por el equipo), el equipo crea un incremento de software
operativo. El conjunto de caractersticas que entra en una iteracin 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 iteracin se determinan durante la reunin de
planificacin de la iteracin. Durante esta reunin, 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 iteracin. Durante
una iteracin, nadie puede cambiar el backlog de la iteracin, lo que significa que los
requisitos estn congelados para esa iteracin. Cuando se completa una iteracin, el equipo
demuestra el uso del software.
Scrum permite la creacin de equipos con propia organizacin fomentando la

localizacin conjunta de todos los miembros del equipo y la comunicacin 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
desafos que no se pueden predecir no se pueden tratar fcilmente de una forma predictiva o
planificada tradicional. Por esto, Scrum adopta un enfoque emprico, aceptando que el
problema no se puede entender o definir completamente, centrndose en cambio en
maximizar las habilidades del equipo para entregar rpidamente y responder a los requisitos
emergentes.
18
Una de las mayores ventajas de Scrum es que es muy fcil 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 da durante la iteracin, tiene lugar una reunin de estado del proyecto. A
esta reunin se le domina Scrum
- Reunin de planificacin de iteracin (sprint): se lleva a cabo al principio del ciclo de

la iteracin.
- Reunin de revisin de iteracin: al final del ciclo de la iteracin.
- Iteracin retrospectiva: al final del ciclo de la iteracin.
Practicas
A continuacin se enumeran algunas de las prcticas 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 mitigacin frecuentes por parte del equipo de

desarrollo, la mitigacin de riesgos, la monitorizacin y la gestin de riesgos se lleva
a cabo en todas las etapas y con compromiso.
- Transparencia en la planificacin y desarrollo de mdulos, permitir a cada uno saber

quin es responsable de qu y cundo.
- Frecuentes reuniones de las personas involucradas en el negocio para monitorizar el

progreso.
- Debera 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 metodologa o modelo universal para hacer frente con xito a cualquier
proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del
proyecto (recursos tcnicos y humano, tiempo de desarrollo, tipo de sistema, etc.).
Histricamente, 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 pequeos y con requisitos muy cambiantes. Los
modelos alternativos ofrecen una solucin casi a medida para una gran cantidad de
proyectos que tienen estas caractersticas. Una de las cualidades ms destacables en una
metodologa gil es su sencillez, tanto en su aprendizaje como en su aplicacin,
reducindose as los costes de implantacin en un equipo de desarrollo. Esto ha llevado
hacia un inters creciente en los modelos alternativos. Sin embargo, hay que tener presente
una serie de inconvenientes y restricciones para su aplicacin, tales como: estn dirigidas a
equipos pequeos o medianos, el entorno fsico debe ser un ambiente que permita la
comunicacin y colaboracin entre todos los miembros del equipo durante todo el tiempo,
cualquier resistencia del cliente o del equipo de desarrollo hacia las prcticas y principios
puede llevar al proceso al fracaso, el uso de tecnologas que no tengan un ciclo rpido de
realimentacin o que no soporten fcilmente el cambio.
20
Nelson Chama
La evolucin del software tanto en el desarrollo de software con diferentes

metodologas 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 creacin de prototipos que ayude a evitar malas decisiones sobre los
requerimientos y el diseo. 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 mtodos de desarrollo incremental que se enfocan en

el diseo rpido, liberaciones frecuentes del software, reduccin de gastos en el proceso y
produccin de cdigo de alta calidad. Hacen que el cliente intervenga directamente en el
proceso de desarrollo.
Conclusiones generales
Hemos visto diferentes modelos de desarrollo, especficamente se dividen en dos

principales segn Kroll, que bsicamente estn diferenciados por el nivel de burocracia.
Aunque los modelos alternativos estn siendo ms usados por su simplicidad pero
hay que tener en cuenta que esto vara mucho de la organizacin, 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 estn apoyamos por un factor importante que es la gestin de
configuracin, que se suele contar en algunos modelos alternativos pero que apoya a que el
proyecto se desarrolle.
21
3. Generacin de Plan de Gestin de la Configuracin de Software
El proceso de planificacin y gestin es el primero de los proceso y, como su nombre indica,

engloba las tareas de planificacin y gestin de los otros cuatro proceso, identificacin,
control, registro y verificacin y auditorias de la configuracin.
El plan de gestin de la Configuracin del Proyecto se elabora una vez se recibe la

instruccin de iniciar el proyecto y contempla la planificacin de tareas, calendarios,
asignacin de recursos humanos y materiales as como los costes necesarios para
establecer los procesos involucrados, relativos a la gestin de la configuracin durante el
ciclo de vida del producto. La planificacin tendr en consideracin los requisitos
contractuales que guarden relacin con la gestin de la configuracin y que formar parte del
Plan de Gestin del Proyecto.
Se realizar la planificacin, se obtendr como resultado una lista de requisitos a satisfacer

para poder implantar el sistema de configuracin. Estos pueden ser recursos humanos,
materiales (Software, hardware), econmicos, etc. De esta actividad, tambin resultar la
elaboracin de los procedimientos operativos del resto de procesos (identificacin, control,
registro y verificacin y auditorias de la configuracin). (Rodriguez, Fernandez, & Romero)
3.1 Disear el Plan de Gestin de Configuracin de Software
ANEXO 1
3.1.1 Ciclo de Vida Tradicional
3.1.1.1 Proyecto de desarrollo que se encuentra en fase de Anlisis
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 Diseo
3.1.1.4 Proyecto de desarrollo que se encuentra en fase de Codificacin y Pruebas
3.1.1.5 Proyecto de desarrollo que se encuentra en fase de Instalacin 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 produccin de grandes programas de ordenador. Estadis

Unidos.
Daniel Ramos, R. N. (2015). Curso de Ingeniera de Software.
Daniel Ramos, R. N. (2015). Curso de Ingeniera de Software. En R. N. Daniel
Ramos, Curso de Ingeniera de Software (pgs. 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). Ingeniera de Software, un enfoque practico. En R. Pressman,
Ingeniera de Software, un enfoque practico (pg. 58). Espaa.
Software, L. N. (Marzo de 2009). Instituto Nacional de Tecnologia de
Comunicacin.
Sommerville, I. (2011). Ingeniera de Software. Mexico.
25
ANEXOS i
26
Plan de Configuracin
Versin
Sistema de Gestin y Monitoreo de
Proyectos SISGEM
FECHA: 22/05/2016
VERSIN: v1.0
Contenido
MBITO: GRUPO
1.
CDIGO: PREQ- SISGEM -01
Introduccin............................................................................................................. 3
1.1. Propsito........................................................................................................... 3
1.2. Alcance............................................................................................................. 3
27
1.3. Terminologa.....................................................................................................3
1.4. Referencias.......................................................................................................3
2. Gestin de SCM......................................................................................................4
2.1. Organizacin.....................................................................................................4
2.2. Responsabilidades............................................................................................4
2.3. Polticas, directivas y procedimientos aplicables...............................................4
3. Actividades de SCM................................................................................................5
3.1. Identificacin de la configuracin......................................................................5
3.1.1. Elementos de configuracin.......................................................................5
3.1.2. Nomenclatura de Elementos......................................................................5
3.1.3. Elementos de la Lnea Base del Proyecto..................................................8
3.1.4. Recuperacin de los Elementos de configuracin......................................8
3.2. Control de configuracin...................................................................................8
3.2.1. Solicitud de cambios...................................................................................8
3.2.2. Evaluacin de cambios o Anlisis de Impacto............................................9
3.2.3. Aprobacin o desaprobacin de cambios...................................................9
3.2.4. Implementacin de cambios.......................................................................9
3.3. Estado de la configuracin..............................................................................10
3.4. Auditorias y revisiones de configuracin.........................................................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 Configuracin Versin
1. Introduccin
El siguiente documentos tiene como objetivo definir los miembros y actividades de la gestin
de configuracin, as como los pasos que hay que seguir para la evaluacin y aceptacin de
28
los cambios, se establecen los responsables de la autoridad de cambios, como sus

funciones, se muestra el mtodo de nombrado y la estructura de los informes del estado de
configuracin.
1.1. Propsito
Este documento describe las actividades de gestin de configuracin de software que

deben ser llevadas a cabo durante el proceso de desarrollo del proyecto. Aqu se
definen tanto los productos que se pondrn bajo control de configuracin como los
procedimientos que deben ser seguidos por los integrantes del equipo de trabajo.
1.2. Alcance
El Plan de configuracin est basado en algunos supuestos que se detallarn:
El tiempo de duracin del proyecto est limitado a 13 semanas, por lo tanto se

busca una rpida respuesta a los cambios, tratando que este procedimiento
sea lo menos burocrtico 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 configuracin la mayor cantidad de productos

posibles, tomando en cuenta siempre las restricciones dadas por la duracin
del proyecto y por la capacidad organizativa del grupo.
La eleccin de los elementos de configuracin se realizar en base a los

entregables, siendo sta responsabilidad del Responsable de SCM, apoyado
por los integrantes de cada disciplina.
1.3. Terminologa
CCB (Configuration Control Board) Comit de Control de Configuracin.
CI (Configuration Item) elemento bajo gestin de Configuracin.
SCA (Software Change Authorization) Autorizacin de Cambio en el

Software.
29
SCM (Software Configuration Management) Gestin de Configuracin del

Software.
SCMR (SCM Responsable) Responsable de SCM.
SCR (System/Software Change Request) Peticin de Cambio en el

Sistema/Software.
SQA (Software Quality Assurance) Aseguramiento de la Calidad del

Software.
SQAR (SQA Responsable) Responsable de SQA.
1.4. Referencias
[1] ANSI/IEEE Std 828-1990, IEEE Standard for Software Configuration Management
Plans.
[2] 2002, Modelo de Proceso.
2. Gestin de SCM
NOMBRE TAREAS DEFINICIN

Christian Csar Realizacin del plan de Apoyar el trabajo de los
Acero Catacora gestin de
Desarrolladores, para que estos
configuracin
tengan espacios de trabajo
apropiados para construir y para
probar su trabajo, adems de
llevar un seguimiento y control de
los cambios llevados durante el
desarrollo.
Realizacin de los informes. Mostrar el estado actual de
todas las solicitudes de
cambio, as como el tiempo
en el que estn en un estado
determinado y una evolucin de
las mismas.
Nelson Chama Control de Cambios Decide si un cambio se lleva a
cabo y lo evala.
Almacenamiento de copias Guardar el contenido del
de seguridad. repositorio, en nuestro
servidor de copias, al final de
30
cada semana.
2.1. Organizacin
Como empresa desarrollo que divide en las siguientes reas
Gerencia
Secretaria
Contabilida Recursos
Marketing Desarrollo
d Humanos
Analisis
Diseo
Programaci
n
Test
Control de
Cambios
Se debe identificar:
31
Dentro de la organizacin el rea donde se hace el plan de la configuracin 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 configuracin 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 lnea
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 configuracin, estableciendo as la lnea base del

proyecto.
Fijar una poltica de nomenclatura de los elementos de configuracin para

facilitar la identificacin y ubicacin de stos en el proyecto.
Llevar a cabo el control de la configuracin, estableciendo estndares y

procedimientos a seguir con respecto a los cambios para permitir un control de
los mismos.
Proveer de reportes de estado de la configuracin mediante el seguimiento del

historial de las revisiones y liberaciones.
Realizar auditorias de la lnea base del software para verificar que el Sistema
en desarrollo es consistente y la lnea base est bien definida.
32
2.3. Polticas, directivas y procedimientos aplicables
Las directivas que se usan es basado en el resultado de cada fase que bsicamente consiste
en uno o ms documentos se autoricen para continuar con el desarrollo, tambin llamadas lneas
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

configuracin del sistema. Estas deben ser tanto actividades tcnicas como de gestin
de SCM, as como las actividades generales del proyecto que tengan implicancia sobre
el manejo de configuracin.
3.1. Identificacin de la configuracin
3.1.1. Elementos de configuracin
Para este proyecto los elementos de configuracin se correspondern con los

entregables definidos en el Modelo de Proceso en Cascada, aunque no
necesariamente todos los entregables deben ser elementos de configuracin ya que
pueden existir trabas que alteren el avance del proyecto.
La decisin de cuales de los entregables sern elementos de configuracin ser

tomada por el SCMR, quin deber tomar en cuenta qu productos sern necesarios
cuando se quiera recuperar una versin completa del sistema.
Se debe generar una lnea base por iteracin en cada Fase, de acuerdo a lo siguiente:
Los eventos que dan origen a la lnea base.
Los elementos que sern controlados en la lnea base.
Los procedimientos usados para establecer y cambiar la lnea base.
La autorizacin requerida para aprobar cambios a los documentos de la lnea

base.
3.1.2. Nomenclatura de Elementos
En esta seccin se especifican la identificacin y descripcin nica de cada elemento

de configuracin.
33
Adems se especifica como se distinguirn las diferentes versiones de cada elemento.

Para todos los elementos de configuracin se les deber agregar, despus del nombre
del mismo, informacin acerca del grupo al que corresponde el elemento y la versin
del mismo.
El formato para esta nomenclatura es: NomenclaturaGXvY.extensin, donde:
Nomenclatura es la especificada mas abajo para cada elemento.

X es un nmero de 1 dgito que identifica al grupo.
Y indica la versin del elemento de configuracin o entregable.

Extensin indica la extensin del elemento de configuracin o entregable.
[Ejemplo: RQALSG1v2.doc, es como se deber llamar el entregable "Alcance del

Sistema" correspondiente al grupo 1 y cuya versin del documento es la 2.]
Para los entregables, se deber identificar a que Fase e iteracin corresponden en

forma manual. Esto es: para los elementos bajo control de configuracin se los
almacenar de forma que se puedan recuperar dada la Fase e iteracin a la que
corresponden, y para los elementos que no se encuentran bajo control de
configuracin podrn ser almacenados por ejemplo en carpetas que identifiquen la
Fase e iteracin a la que pertenecen.
Se indica la siguiente nomenclatura para cada entregable en el modelo de proceso,

segn la disciplina (en caso que exista algn elemento de configuracin 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 Reunin de Requerimientos
RQDRQ Especificacin de Requerimientos
RQMOD Modelo de Casos de Uso
RQRSU Requerimientos Suplementarios
34
RQDVC Documento de Validacin 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
Diseo:
DSMDI Modelo de Diseo
DSARQ Descripcin de la Arquitectura
DSOOMDA Modelo de Datos
DSOODDP Documento de Diseo del Prototipo
Implementacin:
IMEDT Estndar de Documentacin Tcnica
IMEI Estndar de Implementacin
IMPR Prototipo
IMIIN Informe de Integracin
IMDT Documentacin tcnica
IMIVU Informe de Verificacin Unitaria
IMOOPII Plan de Integracin de la Iteracin
IMOOMIM Modelo de Implementacin
IMOOEJI Ejecutable de la Iteracin
IMOORRP Reporte de Revisin por Pares
IMOOCVU Clases de la Verificacin Unitaria de Mdulo
IMGXICO Informe de Consolidacin
35
IMGXEST BC Con Estilos

IMGXCON BC Consolidado
IMGXNUC BC Ncleo
IMGXMOD BC Mdulo
Verificacin:
VRPVV Plan de Verificacin y Validacin
VRDAP Documento de Evaluacin y Ajuste del Plan de V & V
VRPVI Plan de Verificacin de la Iteracin
VRMCP Modelo de Casos de Prueba
VRIVD Informe de Verificacin de Documento
VRIVI Informe de Verificacin de Integracin
VRIVS Informe de Verificacin del Sistema
VRRPR Reportes de Pruebas
VREV Evaluacin de la Verificacin
VRIFV Informe Final de Verificacin
Implantacin (IP):
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 Capacitacin
IPPS Presentacin del Sistema
IPPLA Plan de Implantacin
IPVPR Versin del Producto
IPOOEDU Estndar de Documentacin de Usuario
IPOORFPA Reporte Final de Pruebas de Aceptacin
Gestin de Configuracin y Control de Cambios (SCM):

36
SCMPLA Plan de Configuracin
SCMMAC Manejo del Ambiente Controlado
SCMGC Gestin de Cambios
SCMRV Registro de Versiones
SCMILB Informe de la Lnea Base del Proyecto
SCMIF Informe Final de SCM
Gestin de Calidad (SQA):
SQAPLA Plan de Calidad
SQADAP Documento de Evaluacin y Ajuste del Plan de Calidad
SQARTF Informe de RTF
SQAES Entrega Semanal de SQA
SQAIR Informe de Revisin de SQA
SQADV Descripcin de la Versin
SQANV Notas de la Versin
SQAIF Informe Final de SQA
Gestin de Proyecto (GP):
GPPLA Plan de Proyecto
GPISP Informe de Situacin del Proyecto
GPEM Estimaciones y Mediciones
GPDRI Documento de Riesgos
GPRAC Registro de Actividades
GPIFP Informe Final de Proyecto
GPARE Acta de la Reunin de Equipo
GPPIT Plan de la Iteracin
GPPDE Plan de Desarrollo
37
GPICF Informe de Conclusiones de la Fase

GPPDIP Presentacin en Diapositivas del Proyecto
GPPDP Presentacin al Director del Proyecto
GPARD Acta de la Reunin con el Director del Proyecto
GPOODAP Documento de Evaluacin y Ajuste al Plan de Proyecto
GPIARI Acta de la Reunin de Integracin
Comunicacin (COM):
COMDI Documento Informativo
COMENS Encuesta de Satisfaccin del Cliente
COMEVS Evaluacin de Satisfaccin del Cliente
3.1.3. Elementos de la Lnea Base del Proyecto
[En esta seccin se debe detallar la Lnea Base. Esto es, los elementos que
pertenecen a la Lnea Base del Proyecto, especificados por Fase del Proyecto y por
iteraciones dentro de cada Fase.]
FASE: [Fase]
Elemento Descripcin Disciplina
Documentos Visin Fase de Analisis de Los servicios, las
requisitos restricciones y las metas
del sistema se establecen
mediante consulta a los
usuarios del sistema.
Luego, se definen con
detalle y sirven como una
especificacin del
sistema.
Documentos de Fase de desarrollo Se empieza a hacer un
Gestin del Proyecto 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 Diseo El proceso de diseo de
Arquitectura del sistemas asigna los
sistema requerimientos, para
sistemas de hardware o
de software, al establecer
una arquitectura de
sistema global. El diseo
del software implica
identificar y describir las
abstracciones
fundamentales del
sistema de software y sus
relaciones.
Documentos de fase de Codificacin y Durante esta etapa, el

Pruebas Unitarias Pruebas diseo 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
especificacin.
Documento de Prueba fase de Instalacin o Las unidades del
de Integracin posterior programa o los programas
Documentos de individuales se integran y
satisfaccin del cliente prueban como un sistema
completo para asegurarse
de que se cumplan los
requerimientos de
software. Despus de
39
probarlo, se libera el
sistema de software al
cliente
3.2. Control de configuracin
En esta seccin se detallan las actividades de solicitud, evaluacin, aprobacin e

implementacin de cambios a los elementos de la lnea base.
Los cambios apuntan tanto a la correccin como al mejoramiento.
El procedimiento que se describe a continuacin 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 lnea base del
sistema, como pueden ser:
Cambios en los Requerimientos/Analisis.
Cambios en el Desarrollo.
Cambios en el Diseo y Arquitectura
Cambios en las herramientas de desarrollo.
Cambios en la documentacin 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 informacin necesaria, detallada en el documento.
3.2.2. Evaluacin de cambios o Anlisis de Impacto
La evaluacin del cambio involucra determinar qu es necesario hacer para

implementar el cambio y la estimacin de sus costos y plazos.
Se realiza en 2 pasos:
1. Planificacin de la evaluacin 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 anlisis

de evaluacin del cambio e involucrarlas.
Desarrollar un Plan para la evaluacin del cambio.
Si el cambio involucra al Cliente, obtener el acuerdo de ste con el

Plan.
2. Evaluar el cambio:
Dependiendo de las caractersticas del cambio, la evaluacin del cambio puede ser
realizado por el Administrador o ser delegado a otras personas del proyecto.
Se debe determinar el impacto en:
Los productos tcnicos.
Los Planes de proyecto.
Los acuerdos con el Cliente.
Los Riesgos del proyecto.
3.2.3. Aprobacin o desaprobacin de cambios
Se debe formar el Comit de Control de Configuracin y determinar su autoridad para

la aprobacin de cambios.
La composicin de este comit puede variar segn el tipo de cambio y las lneas 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 Configuracin de nivel superior, compuesto por el

Gerente de proyecto, al cual se elevarn las solicitudes de cambios cuya aprobacin o
desaprobacin no se pueda resolver por el primer comit.
3.2.4. Implementacin de cambios
Una vez realizada la evaluacin del cambio, se decide en qu momento implementarlo.

Esta etapa involucra los procesos necesarios para implementar la solicitud y
monitorear el progreso del trabajo.
Adems se especificar el momento de liberacin del cambio; as como tambin los
responsables de las actividades que involucra el cambio.
Recordando que nos basamos en un proceso de desarrollo incremental e iterativo,
donde en cada iteracin se realizan tareas de Anlisis de requerimientos, Diseo,
Implementacin y Verificacin; se debe introducir el cambio en el rea que lo origin y
continuar con las actividades del ciclo (Requerimientos, Anlisis, Diseo,
Implementacin, Verificacin) que impactarn los elementos de la lnea base
correspondientes a cada actividad.
3.3. Estado de la configuracin
[Las actividades de control de estado son para reunir informacin y reportar el estado
de los elementos de configuracin.
Se debe especificar lo siguiente:
Qu elementos sern revisados de la lnea base y por cambios a realizarse.
Qu tipos de reportes de estado sern generados y con qu frecuencia.
Como la informacin ser obtenida, guardada, procesada, y reportada.
Como ser controlado el acceso a los datos de estado.
Si se utiliza una herramienta automtica deber ser especificada su funcionalidad y

modo de uso explcitamente o por referencia.
En los reportes de estado de los elementos de configuracin se debe incluir como

mnimo la siguiente informacin:
Su primer versin aprobada.
42
El estado de los cambios solicitados.
El estado de implementacin de los cambios aprobados.]
3.4. Auditorias y revisiones de configuracin
Se realizarn auditorias de la lnea base antes de una liberacin de sta o de una

actualizacin de la versin de un componente prioritario de sta.
Estas auditorias incluirn:
Objetivo: el objetivo de todas las auditoras es verificar que en un momento

dado la lnea base se compone de una coleccin consistente y bien definida
de productos.
Elementos de configuracin bajo auditora: se elegirn uno o mas elementos

de configuracin de mayor prioridad en la lnea base.
Agenda de auditoras: antes de la liberacin o actualizacin.
Conduccin: las auditoras sern dirigidas por el SCMR.
Participantes: SCMR y los autores de los elementos de configuracin a

auditar.
Documentos Requeridos: Documentos de SCR y reportes de estado de la

configuracin generados.
Reportes de Deficiencias y Acciones Correctivas: determinadas por los

participantes.
Criterio de Aprobacin: lo determina el SCMR.
43
3.5. Control de Interfases
Las actividades de Control de Interfases controlan los cambios a los elementos de

configuracin 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 configuracin.
3.6. Control de subcontratos y vendedores
4. Calendario
Se debe establecer la secuencia y coordinacin de las actividades y eventos que

afecten la implementacin 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 planificacin del proyecto.
Los hitos de las actividades de SCM incluyen:
Definicin de la lnea base.
Implementacin de Control de Cambios.
Fechas de comienzo y fin de las auditorias.
5. Recursos
Para la gestin de la configuracin 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 penltimo da de la semana laboral o control
y monitoreo y los documentos de configuracin 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

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

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

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD PRIVADA DE TACNA

Escuela Profesional de Ingeniera de Sistemas

PROCESO DE GESTIN DE LA CONFIGURACIN

Curso: Gestin de la Configuracin y administracin de

Docente: Ing. Ricardo Valcrcel Alvarado

Como elemento de clave al desarrollo de software tenemos la gestin de

PROCESO DE GESTIN DE LA CONFIGURACIN DE SOFTWARE

Investigar acerca de lo proceso de gestin de la configuracin de software en cada

Argumentar y sustentar diferentes casos que pueden alterar el proceso de gestin de

Proponer soluciones en el proceso de configuracin de software del ciclo de vida en

2.1 Ciclo de vida y Modelos de Desarrollo

Un modelo de proceso es una abstraccin de un proceso. Estos modelos representan

Un proceso de desarrollo de software es un conjunto de actividades y resultados

El proceso adoptado por una organizacin es tambin una abstraccin en relacin

Hay una necesidad de gestionar el proceso de desarrollo de software a travs de

La estimacin de software es importante para la gestin de un proyecto. Decisiones

Adems, dado el esfuerzo real en comparacin con el esfuerzo estimado, proporciona

2.1.1 Modelos tradicionales

Teniendo en cuenta que la estimacin debe considerar el proceso como las

Este proyecto de investigacin considera los modelos ms burocrticos y con mayor

Grado de burocracia de los modelos tradicionales

Watterfall model: Modelo cascada

El modelo de cascada es un diseo secuencial de procesos, que se utiliza en los

El modelo de desarrollo en cascada se origina en las de fabricacin y construccin

ste toma las actividades fundamentales del proceso de especificacin, desarrollo,

3. Implementacin y prueba de unidad Durante esta etapa, el diseo de software se rea

4. Integracin y prueba de sistema Las unidades del programa o los programas

cumplan los requerimientos de software. Despus de probarlo, se libera el sistema de

5. Operacin y mantenimiento Por lo general (aunque no necesariamente), sta es la fase

En principio, el resultado de cada fase consiste en uno o ms documentos que se

Durando el diseo se identifican los problemas con los requerimientos. En la

Debido a los costos de produccin y aprobacin de documentos, las iteraciones

pequeo nmero de iteraciones, es normal detener partes del desarrollo, como la

Durante la fase final del ciclo de vida (Operacin y mantenimiento) , el software se

El modelo en cascada es consecuente con otros modelos de proceso de ingeniera y

En principio, el modelo en cascada solo debe usarse cuando los requerimientos se

Una variacin importante del modelo en cascada es el desarrollo de sistemas

Los procesos formales de desarrollo, como el que se basa el mtodo B (Macmillan,

produccin de un caso de proyecto o seguridad. Esto demuestra a los clientes o reguladores

Los procesos basados en transformaciones formales se usan por lo general solo en el

Rational Unified Process

El proceso unificado Rational (RUP) es un marco de trabajo de proceso de desarrollo

RUP result de la combinacin de varias metodologas y se vio influenciado por

Los creadores y desarrolladores del proceso se centraron en el diagnstico de las

Mdulos de RUP (building blocks)

RUP se basa en un conjunto de mdulos o elementos de contenido, que describen qu se va

Roles (quin): un rol define un conjunto de habilidades, competencias y

Productos de trabajo (qu): un producto de trabajo representa algo que resulta de

Fases del ciclo de vida del proyecto

Fase de iniciacin: se define el alcance del proyecto.

Fase de construccin: se crea el diseo de la aplicacin y el cdigo fuente.

Fase de transicin: se entrega el sistema a los usuarios.

RUP proporciona un prototipo al final de cada iteracin.

Dentro de cada iteracin, las tareas se categorizan en nueve disciplinas:

- Seis disciplinas de ingeniera

2.1.2 Modelos alternativos

En Manifiesto para el Desarrollo gil de Software, firmado en 2001 por algunos

En la siguiente figura se muestra la misma idea de (MacIsaac, 2013), incluyendo el Proceso

Grado de burocracia de los modelos alternativos

La mayora de los modelos alternativos incluyen una comunicacin cara a cara

No importa qu disciplinas de desarrollo se requieran, cada equipo gil contendr un

Principios detrs del manifiesto gil

- La prioridad ms alta es satisfacer al cliente a travs de la entrega temprana y

- Las personas de negocio y los desarrolladores deben trabajar juntos diariamente