plan cmmi app delivery
DESCRIPTION
Plan cmmi app deliveryTRANSCRIPT
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
1
Santa cruz - Bolivia
ContenidoPrefacio..........................................................................................................................................1
1. Descripción de la Empresa.....................................................................................................3
1.1. Organización.......................................................................................................................4
1.2. Misión.................................................................................................................................4
1.3. Visión..................................................................................................................................4
1.4. Valores...............................................................................................................................5
1.5. Roles y Funciones...............................................................................................................6
2. Organigrama de la Empresa...................................................................................................9
2.1. Metodología de Trabajo...................................................................................................10
2.1.2. Proceso y Roles de Scrum........................................................................................12
2.2. Tecnologías.......................................................................................................................14
2.3. Aspectos Metodológicos del Estudio................................................................................15
3. Áreas de Procesos del CMMI-Nivel 2........................................................................................16
3.1. Proceso de Gestión de Requisitos (GR).................................................................................16
3.1.1. Introducción.......................................................................................................................16
3.1.2. Propósito...........................................................................................................................16
3.1.3. Responsables.....................................................................................................................17
3.1.4 Entradas..............................................................................................................................17
3.1.5. Prácticas específicas..........................................................................................................18
3.1.6. Salidas................................................................................................................................21
3.2. Proceso de Planificación del Proyecto (PP)...........................................................................22
3.2.1. Introducción......................................................................................................................22
3.2.2. Propósito...........................................................................................................................22
3.2.3. Alcance..............................................................................................................................22
3.2.4. Responsables.....................................................................................................................23
3.2.5. Entradas.............................................................................................................................23
3.2.6. Prácticas Específicas...........................................................................................................24
3.3. Proceso De Seguimiento y Control del Proyecto (SCP)..........................................................30
2
3.3.1. Introducción.......................................................................................................................30
3.3.2. Propósito............................................................................................................................30
3.3.3. Responsables......................................................................................................................30
3.3.4. Entradas.............................................................................................................................30
3.3.5. Prácticas Específicas...........................................................................................................31
3.3.6. Salidas................................................................................................................................37
3.4. Proceso de Gestión de Acuerdos con Proveedores (GAP).....................................................38
3.4.1. Introducción.......................................................................................................................38
3.4.2. Propósito............................................................................................................................38
3.4.3. Responsables..................................................................................................................38
3.4.4. Entradas.............................................................................................................................38
3.4.5. Prácticas específicas.....................................................................................................39
3.4.6. Salidas...........................................................................................................................43
3.5. Proceso de Medición y Análisis (MA)....................................................................................44
3.5.1. Introducción.......................................................................................................................44
3.5.2. Propósito..........................................................................................................................44
3.5.3. Responsables......................................................................................................................44
3.5.4. Entradas.............................................................................................................................44
3.5.5. Prácticas Específicas.....................................................................................................45
3.5.6 Salidas.................................................................................................................................49
3.6. Proceso de Aseguramiento de la Calidad del Proceso y del Producto (ACPP)..................50
3.6.1. Introducción.......................................................................................................................50
3.6.2. Propósito...........................................................................................................................50
3.6.3. Responsables.....................................................................................................................50
3.6.4 Entradas..............................................................................................................................50
3.6.5 Practicas Específicas...........................................................................................................50
3.6.6. Salidas....................................................................................................................................53
3.7 Proceso de Gestión de la Configuración (GC)........................................................................54
3.7.1. Introducción.......................................................................................................................54
3.7.2. Propósito...........................................................................................................................54
3.7.3. Responsables.....................................................................................................................55
3
3.7.4 Entradas..............................................................................................................................55
3.7.5. Prácticas Específicas...........................................................................................................55
4. Formularios del PSP 0...............................................................................................................59
4.1 Formulario de Registros de Tiempo........................................................................................59
4.2 Formulario de Defectos..........................................................................................................60
5. Conclusiones............................................................................................................................62
6. Anexos......................................................................................................................................63
6.1. Radar.....................................................................................................................................59
4
Prefacio
CMMI – (Capability Maturity Model Integration) 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 de Modelos 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
Un proceso de nivel de capacidad 2 se caracteriza como un "proceso
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
Un proceso de nivel de capacidad 3 se caracteriza como un "proceso
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
Un proceso de nivel de capacidad 4 se caracteriza como un "proceso
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 Delivery que 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 (Product Owner)
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
Product Owner para maximizar el ROL.
Product Owner 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.
Product owner (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 Product Backlog y 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, con
objetivos del producto final.
Tester (Encargado de
Calidad)
Es el encargado de utilizar una metodología que
en forma sistemática, organizada y
estructurada, permita detectar 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
1
Gerencia General
Departamento de Ventas
Hernan Peñafiel
Encargado de Negocios
Departamento de Desarrollo
Gustavo Tantani
Gestor de Proyecto
(Scrum Master)
Hernan Peñafiel
Product Owner
Mario Perez G. Desarrollador
Alexandro Arauco
Desarrolador
Alfonsin Pestañas
Desorrallodor
Jose Luis Irala Tester
Departamento Tecnico
Alexandro Arauco
Gestor de Configuración
Departamento Calidad
Jose Luis Irala C.
Encargado de Calidad
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 Metodologia Scrum 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 product backlog 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 Product Owner establece su
prioridad. De manera regular, en las demos de Sprint el Product Owner
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 to Market: 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
Product Backlog: 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 Product Owner 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 Product Backlog a 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
Product Owner: 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 Product Owner para maximizar
el ROL.
Product owner (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 Product Backlog y 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:
9
Lenguaje de desarrollo Java, .NET, C++.
Framework
EJB,SOAP,Web
Services,JDBC,JDNI,Servlet,Hibernate, nHibernate,
Crystal Reports, etc.
IDE
Zend Studio, NetBeans, Microsoft Visual Studio,
Architect Enterprise.
Motor de bases de datos
MySQL, Oracle, Microsoft SQL Server, PostgreSQL,
Microsoft Access.
Desarrollo Web
JSP, ASP, PHP, HTML, XML, XHTML, Java Script,
Flash.
Servidor Web
Apache HTTP Server, Apache Tomcat, MS Internet
Information Services (IIS), JBoss.
Administración de
Proyecto
Assembla, MS Project
Administración de
código y control de
versiones
GIT, GitHub
Sistema Operativo Linux Fedora, Windows 7, Windows Server 2008.
2.3. Aspectos Metodológicos del EstudioUtilizaremos 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.
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)
10
Proceso de Aseguramiento de la Calidad del Proceso y del Producto (PPQA) Proceso de Gestión de la Configuración (CM)
3.1. Proceso de Gestión de Requisitos (GR)
3.1.1. IntroducciónEl 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,
11
documentos, estándares, políticas de la empresa) y los productos y componentes generados en el
proyecto.
3.1.2. PropósitoEl 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.
Product Owner.
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.
Reglas de negocio del sistema.
Flujos de trabajo.
Peticiones de cambio o inconformidades en los requerimientos
12
3.1.5. Prácticas específicas
PRÁCTICA ESPECÍFICA
PROPÓSITO RESPONSABLES ARTEFACTOS DE ENTRADA
ARTEFACTOS DE SALIDA
HERRAMIENTAS
SP1.1 Obtener un entendimiento de los requerimientos
Esta práctica se basa en desarrollar una compresión del significado de los requerimientos con los proveedores.
-Scrum Master.
-Product Owner.
- Stakeholder.
-Documento de especificación de requerimientos de software
-Documentación de referencia para los requerimientos
-Lista del Conjunto de Requerimientos acordados debidamente llenada y firmada
-Análisis de los 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 compromiso con los requerimientos
Obtener el compromiso de los participantes de proyecto sobre los requerimientos.
-Scrum Master.
-Product Owner.
- Gestpor de Configuracion.
-Tester/QA
-Lista de criterios para distinguir a los proveedores de requerimientos
-Criterios de Evaluación y Aceptación de Requerimientos
-Lista del Conjunto de Requerimientos
-Evaluación de impacto de los Requerimientos
-Plantilla de Forma de Evaluación de impacto de los Requerimientos
13
acordados
SP1.3 Manejar cambios en los requerimientos
Gestionar los cambios a los requerimientos a medida que evolucionan durante el proyecto.
-Scrum Master.
-Product Owner.
-Gestor de
Configuracion.
-Tester/QA.
-Evaluación de impacto de los Requerimientos
- Línea base del conjunto de requerimientos del sistema a desarrollar
-Estado de los Requerimientos
-Realizar el procedimiento para escoger una base de datos de requerimientos
-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.
SP1.4 Mantener un rastreo bidireccional de los requerimientos
Mantener la trazabilidad bidireccional entre los requerimientos y el plan del proyecto y los productos de trabajo.
-Scrum Master.
-Product Owner.
-Gestor de
Configuracion.
-Tester/QA.
-Lista de requerimientos de la línea base
-Documentación de la especificación de requerimientos de software
-Plantilla del estado de los requerimientos
-Sistema de seguimiento de los Requerimientos
-Matriz de trazabilidad de los requerimientos
-Guía de Procedimiento para el Sistema de Seguimiento de los Requerimientos.
- Plantilla para la Matriz de Trazabilidad de los Requerimientos.
SP1.5 Identificar Inconsistencia entre el trabajo de
Identificar las inconsistencias entre los planes del proyecto, los
-Scrum Master.
-Product Owner.
-Gestor de
-Plan de Proyecto
-Documento de
-Documentación de inconsistencias incluyendo fuentes,
-Plantilla de Reporte de inconsistencias
14
proyecto y los requerimientos
productos de trabajo y los requerimientos.
Configuracion.
-Tester/QA.
-Stakeholder.
-Clientes/Ususarios.
Requisitos
-Matrices de Trazabilidad
condiciones y razones
- Documentación de las acciones correctivas
-Plantilla de Acciones correctivas
15
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.
16
4. Formularios del PSP 0
4.1 Formulario de Registros de Tiempo
ESTUDIANTE: App’s & Soft (Grupo3) FECHA: 08/12/2013
INSTRUCTOR(A): Ing. Karen Infantas PROGRAMA# Reportes Producto
FECHA INICIO TERMINO TIEMPO INTERRUPCION
TIEMPODELTA FASE COMENTARIOS
08/12/13 10:00 10:15 10 5 Planeación Se encontraron 2 requerimientos funcionales
08/12/13 10:25 10:45 5 15 Diseño Se diseña las consultas para el respectivo reporte.
08/12/13 10:50 12:15 70 15 Codificación Se codifico 3 reportes y 3 consultas a la BD.
08/12/13 13:20 13:45 10 15 Compilación Se compilo la capa de presentación, y la capa de datos.
08/07/13 13:55 14:30 20 15 Pruebas se verifico los reportes.
5. Conclusiones
En los últimos años la mejora de procesos software (Software Process
Improvement,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
17
65 MINUTOS1 HORAS,
5MINUTOS
el tiempo planificado. SPI se basa en la premisa de que procesos maduros y
capaces generan productos de calidad.
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
18
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
beneficiosos se obtienen a medio largo plazo y es cuando se puede recuperar el
tiempo invertido al principio para implantar el modelo.
19
6. Anexo
20
21
22