Plan cmmi app delivery

DIPLOMADO EN GERENCIA DE PROYECTOS EN
DESARROLLO DE SOFTWARE

PLAN DE PROYECTO PARA ALCANZAR
EL NIVEL 2 DEL CMMI
MODULO:

GESTION DE REQUERIMIENTOS
INTEGRANTES.Gustavo Tantani Mamani
Alexandro Arauco Sánchez
Hernán Luis Peñafiel Velásquez
José Luis Irala Cárdenas
Alfonsín Pestañas Márquez
Mario Pérez Gonzales

Santa cruz - Bolivia

Contenido
Prefacio ........................................................................................................................................... 1
1.

Descripción de la Empresa ...................................................................................................... 5

1.1.

Organización........................................................................................................................ 5

1.2.

Misión .................................................................................................................................. 6

1.3.

Visión ................................................................................................................................... 6

1.4.

Valores................................................................................................................................. 6

1.5.

Roles y Funciones ................................................................................................................ 7

2.

Organigrama de la Empresa ......................................................Error! Bookmark not defined.

2.1.
2.1.2.

Metodología de Trabajo ...................................................................................................... 2
Proceso y Roles de Scrum .......................................................................................... 4

2.2.

Tecnologías.......................................................................................................................... 9

2.3.

Aspectos Metodológicos del Estudio ................................................................................ 10

3. Áreas de Procesos del CMMI-Nivel 2 ........................................................................................ 11
3.1. Proceso de Gestión de Requisitos (GR) .................................................................................. 12
3.1.1. Introducción ........................................................................................................................ 12
3.1.2. Propósito ............................................................................................................................ 12
3.1.3. Responsables ...................................................................................................................... 12
3.1.4 Entradas ............................................................................................................................... 12
3.1.5. Prácticas específicas ........................................................................................................... 14
3.1.6. Salidas.................................................................................................................................. 17
3.2. Proceso de Planificación del Proyecto (PP) ...............................Error! Bookmark not defined.
3.2.1. Introducción ...........................................................................Error! Bookmark not defined.
3.2.2. Propósito ................................................................................Error! Bookmark not defined.
3.2.3. Alcance ...................................................................................Error! Bookmark not defined.
3.2.4. Responsables ..........................................................................Error! Bookmark not defined.
3.2.5. Entradas ..................................................................................Error! Bookmark not defined.
3.2.6. Prácticas Específicas ................................................................Error! Bookmark not defined.
3.3. Proceso De Seguimiento y Control del Proyecto (SCP) ..............Error! Bookmark not defined.
3.3.1. Introducción ............................................................................Error! Bookmark not defined.
3.3.2. Propósito .................................................................................Error! Bookmark not defined.
3.3.3. Responsables ...........................................................................Error! Bookmark not defined.
1

3.3.6. Salidas .....................................................................................Error! Bookmark not defined.
3.4. Proceso de Gestión de Acuerdos con Proveedores (GAP) .........Error! Bookmark not defined.
3.4.2. Propósito .................................................................................Error! Bookmark not defined.
3.4.3. Responsables .......................................................................Error! Bookmark not defined.
3.4.5.

Prácticas específicas ..........................................................Error! Bookmark not defined.

3.4.6.

Salidas ................................................................................Error! Bookmark not defined.

3.5. Proceso de Medición y Análisis (MA) .........................................Error! Bookmark not defined.
3.5.2. Propósito ...............................................................................Error! Bookmark not defined.
3.5.3. Responsables. ..........................................................................Error! Bookmark not defined.
3.5.5.

Prácticas Específicas ..........................................................Error! Bookmark not defined.

3.5.6 Salidas.......................................................................................Error! Bookmark not defined.
3.6. Proceso de Aseguramiento de la Calidad del Proceso y del Producto (ACPP) .............Error!
Bookmark not defined.
3.6.4 Entradas ...................................................................................Error! Bookmark not defined.
3.6.5 Practicas Específicas ................................................................Error! Bookmark not defined.
3.6.6. Salidas..........................................................................................Error! Bookmark not defined.
3.7 Proceso de Gestión de la Configuración (GC) ............................Error! Bookmark not defined.
3.7.4 Entradas ...................................................................................Error! Bookmark not defined.
4. Formularios del PSP 0 ................................................................................................................ 18
2

4.1 Formulario de Registros de Tiempo ........................................................................................ 18
4.2 Formulario de Defectos ...............................................................Error! Bookmark not defined.
5. Conclusiones.............................................................................................................................. 18
6. Anexos ....................................................................................................................................... 21
6.1. Radar ...................................................................................................................................... 21

3

Prefacio
CMMI – (CapabilityMaturityModelIntegration) Es un enfoque de mejora de
procesos que proporciona a las organizaciones los elementos esenciales de
los procesos eficaces, que mejoran su rendimiento, esta basado en la
mejora del proceso que incluye la identificación de los puntos fuertes del
proceso y los puntos débiles para hacer cambios en el proceso de convertir
las debilidades en fortalezas.

El presente proyecto tomará como ejes conceptuales al modelo CMMI
(Integración deModelos de Madurez de las Capacidades), al control
estadístico de procesos y a las metodologías ágiles de desarrollo de
software, particularmente Scrum.

CMMI ofrece dos alternativas para lograr una mejora en la organización.
Una de ellas permite a las organizaciones mejorar incrementalmente los
procesos correspondientes de un área de proceso (o un grupo de áreas de
proceso) seleccionados por la organización.

El otro camino permite a las organizaciones mejorar incrementalmente a
través de conjuntos de áreas de proceso predefinidos en el modelo.

Un nivel de madurez consiste en prácticas genéricas y específicas
relacionadas para un conjunto predefinido de áreas de proceso. Un nivel de
madurez es un escalón de evolución definido de mejora de proceso
organizacional. Cada nivel de madurez estabiliza una parte importante de
los procesos organizacionales. El logro de cada nivel de madurez trae como
resultado un incremento en las capacidades del proceso de la organización.

1

Los niveles de madurez son medidos a través del logro de las metas
genéricas y específicas asociadas con cada conjunto predefinido de áreas
de proceso.
- No Realizado
Un "proceso No Realizado " es un proceso que, o bien no se ejecuta, o se
ejecuta parcialmente. Al menos una de las metas específicas del área del
proceso no se satisface y no existe metas genéricas para ese nivel, ya que
no hay ninguna razón para institucionalizar un proceso ejecutado
parcialmente.
- Realizado
Un proceso de nivel de capacidad 1 se caracteriza como un "proceso
realizado". Un proceso realizado es un proceso que satisface las metas
específicas del área de proceso. Soporta y permite el trabajo necesario para
producir los productos del trabajo.
Aunque el nivel de capacidad 1 da como resultado mejoras importantes,
esas mejoras pueden perderse en el tiempo si no se institucionalizan. La
aplicación de la institucionalización (las prácticas genéricas de CMMI en los
niveles de capacidad 2 a 5) ayudan a asegurar que las mejoras se
mantendrán.
- Administrado o Gestionado
gestionado". Un proceso gestionado es un proceso realizado (nivel de
capacidad 1) que tiene la infraestructura básica dispuesta para soportar el
proceso. Se planifica y ejecuta de acuerdo a políticas; emplea personal con
habilidades; tiene los recursos adecuados para producir resultados
controlados; involucra a las partes interesadas relevantes; se monitoriza,
controla y revisa; y se evalúa la adherencia a su descripción del proceso. La
disciplina de proceso reflejada por el nivel de capacidad 2 ayuda a asegurar
que las prácticas existentes se mantienen durante tiempo de estrés.
2

- Definido
definido". Un proceso definido es un proceso gestionado (nivel de
capacidad 2) que se adapta a partir de un conjunto de procesos estándar de
la organización, de acuerdo a las guías de adaptación de la organización, y
contribuye a los activos de proceso d ela organización con productos del
trabajo, medidas e información adicional de mejora de procesos.
Una distinción crítica entre los niveles de capacidad 2 y 3 es el alcance de
los estándares, descripciones de proceso y procedimientos. En el nivel de
capacidad 2, los estándares, descripciones de proceso y procedimientos
pueden ser bastante diferentes en cada instancia específica del proceso. En
el nivel de capacidad 3, los estándares, descripciones de proceso y
procedimientos para un proyecto se adaptan a partir del conjunto de
procesos estándar de la organización, para ajustarse a un proyecto o
unidad organizativa particular, y son, por tanto, más consistentes, excepto
para las diferencias permitidas por las guías de adaptación.
Otra distinción crítica es que en el nivel de capacidad 3, los procesos se
describen normalmente de forma más rigurosa que en el nivel de capacidad
2. Un proceso definido establece claramente el propósito, las entradas,
criterios de entrada, actividades, roles, medidas, etapas de verificación,
salidas y criterios de salida. En el nivel de capacidad 3, los procesos se
gestionan de forma más proactiva utilizando una comprensión de las
interralaciones de las actividades dle proceso y de las medidas detalladas
del proceso, de sus productos del trabajo y de sus servicios.
- Cuantitativamente Administrado
gestionado cuantitativamente". Un proceso gestionado cuantitativamente es
un proceso definido (nivel de capacidad 3) que se controla utilizando
técnicas estadísticas y otras técnicas cuantitativas. Se establecen los
objetivos cuantitativos de calidad y de ejecución del proceso, y se utilizan
como criterios para gestionar el proceso. Se comprende la calidad y el
3

rendimiento del proceso en términos estadísticos y se gestionan a lo largo
de la vida del proceso.
- Optimizado
Un proceso de nivel de capacidad 5 se caracteriza como un "proceso en
optimización". Un proceso en optimización es un proceso gestionado
cuantitativamente (nivel de capacidad 4) que se mejora en base a una
comprensión de las causas comunes de variación inherentes al proceso. El
enfoque de un proceso en optimización es mejorar continuamente el rango
de la ejecución del proceso mediante mejoras, tanto incrementales como
innovadoras.

Enfrentarse por primera vez a una auditoría CMMI Nivel 2 supone tener que
superar una gran carga de actividades y enfrentarse a una gran cantidad de
terminología nueva y compleja. A esto se añade que es habitual que las
empresas, inmersas en su rutina diaria, no dispongan de mucho tiempo
para preparar las auditorías.

Bajo estos precedentes, conscientes de la necesidad cada vez mayor por
parte de las empresas de disponer de certificaciones software, pretendemos
con este plan de proyecto para alcanzar el nivel 2 de CMMI facilitar la tarea

4

de preparación de una auditoría CMMI, ayudando a reducir el importante
sobreesfuerzo que supone su realización.

Pretendemos que este plan de proyecto sea un manual a la hora de
enfrentarse a una auditoría de CMMI. Y como tal herramienta, proporciona
lo más básico y esencial para poder afrontar la auditoría.

Comentar también, que este no es un documento de consultoría, y tampoco
está enfocado a implantar CMMI o mejorar los procesos software, Este es
un documento esencialmente de preparación para la auditoría, que
normalmente te será de utilidad si has liderado una mejora CMMI y en
breve te enfrentarás a la auditoría o si te han invitado a participar en el
equipo de auditoría.

1.

Descripción de la Empresa
La empresa App’s&Soft se dedica al desarrollo de software para el servicio
de Deliveryque van desde microempresas a grandes compañías. Esta
Empresa está comprometida a brindar un buen servicio y sobre todo buena
calidad de producto y servicio para la satisfacción de nuestros clientes. La
Empresa App’s&Soft fue creada en el 2009 con el objetivo de desarrollar y
mejorar la calidad del software.

1.1.

Organización
El equipo de trabajo está organizado de la siguiente manera:
 Gustavo Tantani Mamani ( Scrum Master)
 Hernán Luis Peñafiel Velásquez (ProductOwner)
 José Luis Irala Cárdenas(Tester)
 Alexandro Arauco Sánchez (Developer)
 Alfonsín Pestañas Márquez (Developer)
 Mario Pérez Gonzales(Developer)
5

1.2.

Misión
Ser una empresa proveedora de tecnología y software de calidad que
soporte los procesos de negocio de nuestros clientes y apoye la toma
eficiente de decisiones mediante la implementación de soluciones
tecnológicas que satisfaga sus necesidades y permita maximizar su
productividad y recursos, utilizando tecnologías de punta basados en los
pilares de la calidad en lo que hacemos y el cumplimiento a nuestros
clientes.

1.3.

Visión
Ser una empresa de reconocido prestigio nacional e internacional en la
industria de desarrollo de software de calidad basada en la satisfacción y
cumplimiento con nuestros clientes; con el soporte de personal altamente
profesional, ofreciendo productos y soluciones integrales en tecnologías de
información de una manera innovadora, eficiente, rentable, eficaz y
competitiva con un servicio de alta calidad, contribuyendo así en el
desarrollo económico.

1.4.

Valores
En App’s&Soft vivimos una cultura de innovación y calidad en todo lo que
hacemos, buscando satisfacer a nuestros clientes basándonos en el orden,
la creatividad y la especialización permanente.
Los valores que compartimos son:
Trabajo

en

equipo,promoviendo

y

apoyando

un

equipo

homogéneo y multidisciplinar.
Colaboración, trabajamos junto con nuestros proveedores y
clientes para mejorar día a día la calidad con los mismos y
satisfacer sus necesidades.
Servicio, cumplimos con nuestros compromisos y nos hacemos
responsables

de

nuestro

rendimiento

en

todas

nuestras
6

decisiones y acciones, basándonos en una gran voluntad de
servicio por y para nuestros clientes.
Mejora Continua e Innovación,nos damos cuenta de la
importancia de mirar hacia el futuro por tanto ofrecemos lo último
del mercado para dar apoyo y servicio único a nuestros clientes.
Transparencia,la implicación y compromiso del personal no sería
posible sin una absoluta transparencia en los procesos, todo el
personal puede disponer de lo que se hace en la empresa.
Comunicación,promovemos y facilitamos la comunicación entre
todos los niveles de la organización disponiendo de herramientas
eficaces, convocando los foros adecuados y con el compromiso
constante de la dirección.
Integridad y Ética, respetamos y cumplimos nuestra normativa
interna y todo lo que rodea a nuestra empresa.
Modelo de dirección participativo, el personal de la empresa
asume responsabilidades y toma participación en las decisiones.
Especialización y Capacitación,la empresa se preocupa de la
formación continua en todos los ámbitos.

1.5.

Roles y Funciones
Rol

Función

Scrum Master

Persona que lidera al equipo guiándolo para
que cumpla las reglas y procesos de la
metodología.

Gestiona

la

reducción

de

impedimentos del proyecto y trabaja con el
ProductOwner para maximizar el ROL.
ProductOwner

Representa la parte del cliente, y es el
encargado de negociar con el equipo la
prioridad del trabajo a realizar. En conjunto con
7

el Scrum Master actúan como facilitadores del
proceso.
Productowner (PO)

Representante de los accionistas y clientes que
usan el software. Se focaliza en la parte de
negocio y el es responsable del ROL del
proyecto (entregar un valor superior al dinero
invertido). Traslada la visión del proyecto al
equipo, formaliza las prestaciones en historias
a

incorporar

en

el

ProductBacklogy

las

reprioriza de forma regular.
Team

Grupo de profesionales con los conocimientos
técnicos

necesarios

y

que

desarrollan

el

proyecto de manera conjunta llevando a cabo
las historias a las que se comprometen al inicio
de cada sprint.
Developer

Es la persona que escribe, depura y mantiene el
código fuente del software, es decir, del
conjunto

de

instrucciones

que

ejecuta,

conobjetivos del producto final.

Tester
Calidad)

(Encargadode Es el encargado de utilizar una metodología que
en

forma

estructurada,

sistemática,
permita

organizada

detectar

y

y

corregir

diferentes clases de errores y defectos en el
software,

realizando

esto

con

la

mínima

cantidad de tiempo y esfuerzo.

8

2. Organigrama de la Empresa

Gerencia
General

Departamento
de Ventas

Departamento
de Desarrollo

Hernan
Peñafiel
Encargado de
Negocios

Departamento
Tecnico

Alexandro
Arauco
Gestor de
Configuración

Gustavo
Tantani
Gestor de
Proyecto
(Scrum Master)

Departamento
Calidad

Jose Luis Irala
C.
Encargado de
Calidad

Hernan
Peñafiel
Product Owner

Mario Perez G.
Desarrollador

Alexandro
Arauco
Desarrolador

Alfonsin
Pestañas
Desorrallodor

Jose Luis Irala
Tester

1

2.2.

Metodología de Trabajo

El desarrollo del proyecto se realizará con el marco de trabajo SCRUM, un
método ágil de desarrollo, que estará dividido en varias fases semanales, en
las que participarán una serie de roles de desarrolladores y se generarán unos
entregables en forma de software y de documentos.

La MetodologiaScrum define un marco para la gestión de proyectos, que están
cambiando constantemente de requisitos, el desarrollo se realiza mediante
iteraciones llamadas sprints que duran máximo treinta (30) días, en donde el
resultado de cada sprint es un incremento ejecutable que se muestra al
cliente.

Uno de los elementos más usados es la realización de reuniones a lo largo del
proyecto, en especial las reuniones diarias de 15 minutos del equipo de
desarrollo para coordinar e integrar el trabajo realizado.

Define un proceso empírico, iterativo e incremental de desarrollo que intenta
obtener ventajas respecto a los procesos definidos mediante la aceptación de
la naturaleza caótica del desarrollo de software y la utilización de prácticas
tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables.

Es un método iterativo e incremental que enfatiza prácticas y valores de
Project Management por sobre las demás disciplinas de desarrollo.

Al principio del proyecto se define el Project Backlog que contiene todos los
requerimientos funcionales y no funcionales que deberá satisfacer el sistema a
construir, estos puedes ser especificados mediante casos de uso, features,
diagramas de flujo de datos, incidentes, tareas etc. Los cuales se definen en
conjunto con los stakeholders y a partir de estos se definen los sprints en los
que se irá evolucionando la aplicación evolutivamente, cada sprint tiene su
2

propio sprint backlog que será un subconjunto del productbacklog con los
requerimientos a ser construidos en el sprint correspondiente.

Con la metodología Scrum el cliente se entusiasma y se compromete con el
proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en
cualquier momento realinear el software con los objetivos de negocio de su
empresa, ya que puede introducir cambios funcionales o de prioridad en el
inicio de cada nueva iteración sin ningún problema.

Esta metódica de trabajo promueve la innovación, motivación y compromiso
del equipo que forma parte del proyecto, por lo que los profesionales
encuentran un ámbito propicio para desarrollar sus capacidades.

2.1.1. Beneficios
Cumplimento de expectativas:El cliente establece sus expectativas
indicando el valor que le aporta cada requisito / historia del proyecto, el
equipo los estima y con esta información el ProductOwnerestablece su
prioridad. De manera regular, en las demos de Sprint el ProductOwner
comprueba que efectivamente los requisitos se han cumplido y transmite se
feedback al equipo.
Flexibilidad a cambios:Alta capacidad de reacción ante los cambios de
requerimientos generados por necesidades del cliente o evoluciones del
mercado. La metodología está diseñada para adaptarse a los cambios de
requerimientos que conllevan los proyectos complejos.
Reducción del Time toMarket: El cliente puede empezar a utilizar las
funcionalidades más importantes del proyecto antes de que esté finalizado
por completo.
Mayor calidad del software:La metódica de trabajo y la necesidad de
obtener una versión funcional después de cada iteración, ayuda a la
obtención de un software de calidad superior.

3

Mayor productividad:Se consigue entre otras razones, gracias a la
iminación de la burocracia y a la motivación del equipo que proporciona el
hecho de que sean autónomos para organizarse.
Maximiza el retorno de la inversión (ROI):Producción de software
únicamente con las prestaciones que aportan mayor valor de negocio
gracias a la priorización por retorno de inversión.
Predicciones de tiempos: Mediante esta metodología se conoce la
velocidad media del equipo por sprint (los llamados puntos historia), con lo
que consecuentemente, es posible estimar fácilmente para cuando se
dispondrá de una determinada funcionalidad que todavía está en el
Backlog.
Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más
valor en primer lugar y de conocer la velocidad con que el equipo avanza en el
proyecto, permite despejar riesgos eficazmente de manera anticipada.

2.1.2. Proceso y Roles de Scrum
El proceso
El desarrollo se realiza de forma iterativa e incremental. Cada iteración,
denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas,
obteniendo como resultado una versión del software con nuevas prestaciones
listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya
construida y se añaden nuevas prestaciones priorizándose siempre aquellas que
aporten mayor valor de negocio.

4

ProductBacklog:Conjunto de requisitos demoninados historias descritos
en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo
mismo, por retorno de inversión considerando su beneficio y coste. Los
requisitos y prioridades se revisan y ajustan durante el curso del proyecto a
intervalos regulares.
Sprint Planning:Reunión durante la cual el ProductOwner presenta las
historias del backlog por orden de prioridad. El equipo determina la cantidad
de historias que puede comprometerse a completar en ese sprint, para en
una segunda parte de la reunión, decidir y organizar cómo lo va a
conseguir.
Sprint:Iteración de duración prefijada durante la cual el equipo trabaja para
convertir las historias del ProductBackloga las que se ha comprometido,
en una nueva versión del software totalmente operativo.
Sprint Backlog:Lista de las tareas necesarias para llevar a cabo las
historias del sprint.
Daily sprint meeting:Reunión diaria de cómo máximo 15 min. en la que el
equipo se sincroniza para trabajar de forma coordinada. Cada miembro
comenta que hizo el día anterior, que hará hoy y si hay impedimentos.
Demo y retrospectiva:Reunión que se celebra al final del sprint y en la que
el equipo presenta las historias conseguidas mediante una demonstración
del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se
hizo bien, qué procesos serían mejorables y discute acerca de cómo
perfeccionarlos.

Roles
En Scrum, el equipo se focaliza en construir software de calidad. La gestión de un
proyecto Scrum se centra en definir cuáles son las características que debe tener
el producto a construir (qué construir, qué no y en qué orden) y en vencer
cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo.
El equipo Scrum está formado por los siguientes roles:
5

ProductOwner: Representa la parte del cliente, y es el encargado de
negociar con el equipo la prioridad del trabajo a realizar. En conjunto con el
Scrum Master actúan como facilitadores del proceso.
Scrum master: Persona que lidera al equipo guiándolo para que cumpla
las reglas y procesos de la metodología. Gestiona la reducción de
impedimentos del proyecto y trabaja con el ProductOwner para maximizar
el ROL.
Productowner (PO):Representante de lso accionistas y clientes que usan
el software. Se focaliza en la parte de negocio y el es responsable del ROL
del proyecto (entregar un valor superior al dinero invertido). Traslada la
visión del proyecto al equipo, formaliza las prestaciones en historias a
incorporar en el ProductBacklogy las reprioriza de forma regular.
Team:Grupo de profesionales con los conocimientos técnicos necesarios y
que desarrollan el proyecto de manera conjunta llevando a cabo las
historias a las que se comprometen al inicio de cada sprint.

6

2.1.3. Ciclo de vida SCRUM

El ciclo de vida en esta metodología está conformado por las siguientes fases:
Pre-juego planeamiento: Tiene como propósito establecer la visión, definir las
expectativas y asegurar la financiación del proyecto, tiene como principales
actividades:
Escribir la visión.
Escribir el presupuesto.
Escribir el registro de acumulación o retraso (backlog) del producto inicial y los
ítems estimados así como la arquitectura de alto nivel, el diseño exploratorio y los
prototipos.

Los registros de acumulación pueden incluir presentaciones del software,
funciones, corrección de errores, mejoras requeridas y actualizaciones de
tecnología. Hay un registro para el total del producto y otro especifico para cada
corrida de 30 días (sprint), todo a un alto nivel de abstracción.

Pre-juego

Montaje

(Staging):

Tiene

como

propósito

identificar

más

requerimientos y priorizar las tareas para la primera iteración, las actividades son:
Planificación
Diseño exploratorio
Prototipos

Juego o Desarrollo: Tiene como propósito implementar un sistema listo para
entrega en una serie de iteraciones de 30 días llamadas “corridas” (sprints), las
actividades son:
Un encuentro de planeamiento de corridas en cada iteración.
La definición del registro de acumulación de corridas
Los estimados y los encuentros diarios de Scrum. En los encuentro diarios todos
tienen que ser puntuales y se debe responder a las siguientes preguntas

7

¿Qué hice desde la reunión anterior?
¿Qué voy a hacer hasta la siguiente reunión?
¿Qué impide que avance en las tareas?

Pos juego (liberación): El propósito es el despliegue operacional de la iteración,
las actividades a desarrollar son:
Documentación
Entrenamiento
Mercadeo y venta

8

2.2.

Tecnologías
Desde nuestro inicio, tuvimos en claro que la diferenciación a nivel
tecnológico se vería reflejada en el manejo y dominio de herramientas y
lenguajes de última generación. La plataforma de programación Java(Open
Source), es eje y columna vertebral de nuestro trabajo.

Dicha plataforma engloba una gran cantidad de aplicaciones, herramientas,
y tecnologías que nos mantiene en continua formación y descubrimiento.
Actualmente estamos en proceso de certificación de CMMI – Nivel 2, que
nos permitirá mejorar nuestros estándares de desarrollo.

Algunas de las herramientas están reflejadas en el cuadro que a
continuación detallamos:
Lenguaje

de Java, .NET, C++.

desarrollo
EJB,SOAP,WebServices,JDBC,JDNI,Servlet,Hibernate,nHiber
Framework

nate, Crystal Reports, etc.
Zend Studio, NetBeans, Microsoft Visual Studio, Architect

IDE

Enterprise.
MySQL, Oracle, Microsoft SQL Server, PostgreSQL, Microsoft

Motor de bases Access.
de datos
JSP, ASP, PHP, HTML, XML, XHTML, Java Script, Flash.
Desarrollo Web
Apache

HTTP

Server,

Apache

Servidor Web

MS

Internet

Information Services (IIS), JBoss.

Administración

Tomcat,

Assembla, MS Project

9

de Proyecto
Administración
de

código

control

GIT, GitHub
y

de

versiones
SistemaOperativ Linux Fedora, Windows 7, Windows Server 2008.
o

2.3.

Aspectos Metodológicos del Estudio
Utilizaremos los siguientes métodos de investigación para la realización de este
plan:
Método de análisis: Realizando revisiones periódicas a literaturas, información
recibida de técnicos e ingenieros que se encuentran inmersos en los retos diarios
de la corporación, lecturas diarias de los nuevos cambios ocurridos tanto en
herramientas como en implementación de CMMI, y realizar el análisis de toda la
información obtenida para la correcta y óptima implementación.
Método Deductivo: Obteniendo todos los conocimientos necesarios de forma
global y actualizada analizarlos para que estos sean una ayuda al momento de la
obtención de respuestas a los problemas que se presenten.
Métodos Estadísticos: Los mismos que ayudaran a realizar una investigación
más precisa, ya que se podrán identificar con claridad las variables de los
procesos las misma que son indispensables saberlas para esta investigación.
Las técnicas que utilizaremos en la investigación del plan serán las siguientes:
Revisión de Literatura: De esta forma obtener información actualizada y conocer
métodos antes utilizados que han sido efectivos para el levantamiento de procesos
y representación de los mismos.
Revisión de Internet: Con la misma finalidad anterior adicionalmente obtener
diariamente información referente a la implementación de CMMI, nuevos métodos
y técnicas que permitan facilitar esta investigación.

10

3. Áreas de Procesos del CMMI-Nivel 2
Proceso de Gestión de Requisitos(REQM)
Proceso de Planificación del Proyecto(PP)
Proceso De Seguimiento y Control del Proyecto(PMC)
Proceso de Gestión de Acuerdos con Proveedores (SAM)
Proceso de Medición y Análisis (M&A)
Proceso de Aseguramiento de la Calidaddel Proceso y del Producto (PPQA)
Proceso de Gestión de la Configuración(CM)

11

3.1. Proceso de Gestión de Requisitos (GR)
3.1.1. Introducción
El proceso de gestión de requerimientos administrará los requerimientos (funcionales y no
funcionales) generados en cada proyecto. La actividad principal del proceso es documentar y
mantener la trazabilidad bidireccional entre la fuente de los requerimientos (stakeholders,
documentos, estándares, políticas de la empresa) y los productos y componentes generados en el
proyecto.

3.1.2. Propósito
El propósito del proceso de gestión de requerimientos es controlar la documentación referente a
los requerimientos del producto, los cambios que ocurran y también identificar inconsistencias
entre los requerimientos y los productos (documentos y componentes de software) del proyecto
generados en cada fase del ciclo de desarrollo.

3.1.3. Responsables
 Scrum Master.
 ProductOwner.
 Gestor de Configuracion.
 Team.
 Tester/QA.
 Stakeholder.
 Clientes/Ususarios.

3.1.4 Entradas
Información de sistemas existentes
Necesidades de los stakeholders.
Estándares de la organización
Información del dominio del sistema.
Documentación de especificación de requerimientos de software.
Casos de uso.

12

Reglas de negocio del sistema.
Flujos de trabajo.
Peticiones de cambio o inconformidades en los requerimientos

13

3.1.5. Prácticas específicas
PRÁCTICA
ESPECÍFICA

PROPÓSITO

RESPONSABLES

SP1.1 Obtener un Esta práctica se basa en -Scrum Master.
entendimiento de desarrollar una compresión
los requerimientos del significado de los -ProductOwner.
requerimientos con los
-Stakeholder.
proveedores.

ARTEFACTOS
DE ENTRADA

ARTEFACTOS
DE SALIDA

HERRAMIENTAS

-Documento
de -Lista del Conjunto
especificación de de Requerimientos
requerimientos de acordados
software
debidamente llenada
y firmada
-Documentación de
referencia para los -Análisis
de
los
requerimientos
Criterios

-Plantilla de Acuerdo
del conjunto de
Requerimientos.

-Plantilla del Análisis
de los Criterios de
Aceptación de los
Requisitos.
-Assembla

SP1.2 Obtener un Obtener el compromiso de -Scrum Master.
compromiso con los
participantes
de
los requerimientos proyecto
sobre
los -ProductOwner.
requerimientos.
-Gestpor de
Configuracion.
-Tester/QA

-Lista de criterios -Evaluación
para distinguir a los impacto
de
proveedores
de Requerimientos
requerimientos

de -Plantilla de Forma
los de Evaluación de
impacto
de
los
Requerimientos

-Criterios
de
Evaluación
y
Aceptación
de
Requerimientos
-Lista del Conjunto
de Requerimientos
acordados
14

-Scrum Master.
SP1.3
Manejar Gestionar los cambios a los
cambios en los requerimientos a medida -ProductOwner.
requerimientos
que evolucionan durante el -Gestor de
proyecto.
Configuracion.
-Tester/QA.

-Scrum Master.
SP1.4 Mantener Mantener la trazabilidad
un
rastreo bidireccional entre los -ProductOwner.
bidireccional
de requerimientos y el plan -Gestor de
los requerimientos
del
proyecto
y
los Configuracion.
productos de trabajo.
-Tester/QA.

-Scrum Master.
SP1.5 Identificar Identificar
las
Inconsistencia
inconsistencias entre los -ProductOwner.
entre el trabajo de planes del proyecto, los

-Evaluación
de -Estado
de
los
impacto de los Requerimientos
Requerimientos
-Realizar
el
- Línea base del procedimiento para
conjunto
de escoger una base de
requerimientos del datos
de
sistema
a requerimientos
desarrollar

-Plantilla de Reporte
del estado de los
Requerimientos.
-Plantilla
de
Procedimiento para
la Elección de una
Herramienta para el
manejo de la base de
datos
de
los
Requerimientos.

-Lista
de -Sistema
de -Guía
de
requerimientos de seguimiento de los Procedimiento para
la línea base
Requerimientos
el
Sistema
de
Seguimiento de los
-Documentación de -Matriz
de Requerimientos.
la especificación de trazabilidad de los
requerimientos de requerimientos
- Plantilla para la
software
Matriz
de
Trazabilidad de los
-Plantilla del estado
Requerimientos.
de
los
requerimientos

-Plan de Proyecto
-Documento

-Documentación de -Plantilla de Reporte
inconsistencias
de inconsistencias
de incluyendo fuentes,

15

proyecto y los productos de trabajo y los -Gestor de
requerimientos
requerimientos.
Configuracion.
-Tester/QA.
-Stakeholder.

Requisitos
-Matrices
Trazabilidad

condiciones
razones

y

de
- Documentación de -Plantilla de Acciones
las
acciones correctivas
correctivas

-Clientes/Ususarios.

16

3.1.6. Salidas

Resultados de los análisis de los requerimientos frente a los criterios.
Acuerdo con el conjunto de requerimientos del sistema revisado y firmado por las
partes interesadas.
Evaluaciones de impacto sobre los cambios o nuevos requerimientos del sistema.
Reportes de las negociaciones de los cambios o nuevos requerimientos del sistema.
Documentación del estado de los requerimientos.
Base de datos de los requerimientos del sistema.
Matriz de trazabilidad de los requerimientos.
Documentación de las inconsistencias.
Documentación de las acciones correctivas.

17

4. Formularios del PSP 0
4.1 Formulario de Registros de Tiempo
ESTUDIANTE:

App’s&Soft (Grupo3)

FECHA: 08/12/2013

INSTRUCTOR(A):
Producto

Ing. Karen Infantas

PROGRAMA# Reportes

FECHA

INICIO

TERMINO

TIEMPOINTERRUPCION

TIEMPODELTA

FASE

COMENTARIOS

08/12/13

10:00

10:15

10

5

Planeación

08/12/13

10:25

10:45

5

15

Diseño

08/12/13

10:50

12:15

70

15

Codificación

08/12/13

13:20

13:45

10

15

Compilación

08/07/13

13:55

14:30

20

15

Pruebas

Se encontraron
2
requerimientos
funcionales
Se diseña las
consultas para
el respectivo
reporte.
Se codifico 3
reportes y 3
consultas a la
BD.
Se compilo la
capa de
presentación, y
la capa de
datos.
se verifico los
reportes.

65 MINUTOS

1 HORAS,
5MINUTOS

5. Conclusiones
 En

los

últimos

años

la

mejora

de

procesos

software

(Software

ProcessImprovement,SPI) ha ganado una relevancia muy significativa dentro de
la Ingeniería del Software Uno de los objetivos principales de la mejora de
procesos software (SPI)

es producir software de calidad con la funcionalidad

deseada y en el tiempo planificado. SPI se basa en la premisa de que procesos
maduros y capaces generan productos de calidad.
18

 Lo que nos permite CMMI es que de una forma progresiva se puede desarrollar la
madurez de la organización nivel a nivel. El llegar a un nivel superior indica que
hay una serie de prácticas importantes que aumentan la madurez de la
organización a la hora de enfrentarse a problemas más exigentes. Esto nos obliga
a aceptar que la forma para sobrevivir en el mercado actual a largo plazo es
realizar mejores productos, con un coste temporal más corto y que sea más
barato. Para esto es necesario un modelo de mejora que ayude a mejorar ciertos
aspectos de la organización.

Las empresas desean implementar un método

internacional que sea reconocido por la Industria del Software para poder ofrecer a
los clientes la certificación de calidad de los productos.
 El uso del modelo CMMI en una organización originará que en la organización se
obtengan unos productos de más calidad basándose en la mejora de los procesos
con los que se desarrolla.
 Por otro lado hay que ver cuándo es necesario implantar un modelo de calidad tan
exigente como CMMI en una empresa. Se tiene que tener en cuenta que tal vez el
tiempo invertido en documentación y en organización sea demasiado con respecto
a los beneficios que se van a obtener en un tiempo. Cada modelo está dirigido a
un determinado tipo de empresa por lo es necesario analizar si la empresa a la
cual hay que implementar el modelo cumple con los requisitos. En caso contrario o
bien se busca otro modelo menos exigente y que se adapte más al tamaño de la
empresa o bien prescindimos de usar algún modelo.
 La empresa JaSoft puede decirse que es una pequeña empresa en torno a las 7
personas que justifican la implantación del modelo. Este plan sirve como guía para
la empresa de cara a mejorar en sus procesos mediante unos procedimientos bien
detallados.
 Estos modelos de calidad son costosos, tanto en su coste económico como en su
coste temporal. Hay muchas tareas a realizar que hace repartir el tiempo
disponible en varios frentes perdiendo a priori rendimiento. A corto plazo si no hay
un apoyo fuerte desde la dirección de la empresa se suele prescindir del modelo al
perder tiempo y no ver resultados inmediatos, pero la mayoría de resultados
19

beneficiosos se obtienen a medio largo plazo y es cuando se puede recuperar el
tiempo invertido al principio para implantar el modelo.

20

Plan cmmi app delivery

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Plan cmmi app delivery

Similar a Plan cmmi app delivery (20)

Último

Último (20)

Plan cmmi app delivery