Plan cmmi  app delivery
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
374
On Slideshare
374
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. 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.3.4. Entradas ..................................................................................Error! Bookmark not defined. 3.3.5. Prácticas Específicas ................................................................Error! Bookmark not defined. 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.1. Introducción ............................................................................Error! Bookmark not defined. 3.4.2. Propósito .................................................................................Error! Bookmark not defined. 3.4.3. Responsables .......................................................................Error! Bookmark not defined. 3.4.4. Entradas ..................................................................................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.1. Introducción ............................................................................Error! Bookmark not defined. 3.5.2. Propósito ...............................................................................Error! Bookmark not defined. 3.5.3. Responsables. ..........................................................................Error! Bookmark not defined. 3.5.4. Entradas ..................................................................................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.1. Introducción ............................................................................Error! Bookmark not defined. 3.6.2. Propósito ................................................................................Error! Bookmark not defined. 3.6.3. Responsables ..........................................................................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.1. Introducción ............................................................................Error! Bookmark not defined. 3.7.2. Propósito ................................................................................Error! Bookmark not defined. 3.7.3. Responsables ..........................................................................Error! Bookmark not defined. 3.7.4 Entradas ...................................................................................Error! Bookmark not defined. 3.7.5. Prácticas Específicas ................................................................Error! Bookmark not defined. 4. Formularios del PSP 0 ................................................................................................................ 18 2
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. - 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. ¿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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. Reglas de negocio del sistema. Flujos de trabajo. Peticiones de cambio o inconformidades en los requerimientos 13
  • 26. 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
  • 27. -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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31.  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
  • 32. beneficiosos se obtienen a medio largo plazo y es cuando se puede recuperar el tiempo invertido al principio para implantar el modelo. 20
  • 33. 6. Anexo 21
  • 34. 22
  • 35. 23