This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

domingo, 4 de febrero de 2018

TSP

El TSP (Team Software Process – Equipo de Procesos de Software) tiene como propósito integrar un equipo de trabajo que tenga como punto de partida la unificación de procesos, para poder llevar a cabo todos aquellos procedimientos que puedan ayudar a mejorar dichos procesos que desarrollan.


“Todos tenemos una manera particular de trabajar, pero en las Tecnologías de la Información, debemos ser capaces de adaptarnos a estándares que nos permiten desempeñarnos en cualquier ambiente y en cualquier industria. Para ello existen certificaciones como TSP” Jorge Salgado, editor en jefe de developerWorks


Básicamente TSP es un proceso de desarrollo para equipos de ingenieros, basados en CMMI, sobre software de calidad, resuelve problemas como predicción de costo y tiempo, mejora de la productividad y ciclos de desarrollo y mejora de calidad de productos.






Los orígenes de TSP se deben a las restricciones que tiene el PSP (Personal Software Process) dentro del ámbito industrial. PSP terminó siendo altamente efectivo para que los ingenieros pudieran tener el control de su PSP mejorando sus habilidades de estimación y la reducción de los defectos que tenían los productos sin afectar a su productividad. Al igual que cualquier modelo de

administración de proyectos, TSP comienza con un proceso de inicio del proyecto en el que se establecen las estrategias, los objetivos, los roles y responsables de cada uno de esos roles en el proyecto, planes individuales, métricas, etc., y se reparte el trabajo, se ejecuta y se le da seguimiento, al final se determina que tan cerca o que tan lejos se estuvo al ejecutar los planes y que tan buena o que tan mala fue la calidad del trabajo hecho.


TSP provee elementos muy concretos asi como formatos y practicas muy específicas para que cada una de estas cosas suceda de una manera particular y concreta, para que sea correctamente medible, para que sea posteriormente analizable y mejorable. El resultado final de todo esto es que un equipo de trabajo que funciona con TSP y PSP cumple en primera instancia con todos los elementos de una certificación de CMMI.




Blog de David Alejandro Gómez:
Watts Humphrey desarrolló el TSP, el cual consideraba como parte importante, además de lo previsto por el PSP, los requisitos, las pruebas de integración, la documentación y otras actividades típicas en todo proyecto de desarrollo, de igual manera incluía actividades como los roles de equipo, interrelaciones dentro de la organización y la definición de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organización.


Roles

Los Roles (responsabilidades) en los equipos en STP son: 
Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del equipo. 
Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto. 
Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del trabajo. 
Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a establecer y administrar el plan de calidad. Genera estándares para obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto generado. 
Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades de apoyo administrativo. Administra el plan de configuración 


Es necesario que los ingenieros que usan TSP estén formados en PSP. TSP está formado por dos componentes primarios que abarcan distintos aspectos del trabajo en equipo: 
Formación del equipo de trabajo 
Gestión del equipo de trabajo 


Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de manera importante el tiempo de pruebas. Con un testing más corto, el ciclo completo se reduce.


A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como individuos, es disciplinado y ágil, provee beneficios inmediatos y medibles y acelera las iniciativas de mejora de procesos organizacionales.


Ciclo:

En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se realiza:


1. Lanzamiento
2. Estrategia
3. Plan
4. Requisitos
5. Diseño
6. Implementación
7. Pruebas
8. Postmortem

*Referencias:

http://www.ibm.com/developerworks/ssa/podcast/13/tsp-psp.pdf 

http://fernandoarciniega.com/tsp-team-software-process/

lunes, 29 de enero de 2018

Modelo CMMI

El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo.
*El CMMI es el Modelo de Madurez de Capacidades Integrado.
*Fue desarrollado por el SEI (Software Enginnering Institute).
*Mide la madurez del desarrollo del software en una escala del 1 al 5.

Integra disciplinas como sistemas y software en un solo marco de trabajo.  Describe formas efectivas y probadas de hacer las cosas, no es un enfoque radical.
Algunos de los objetivos del CMMI y que son buenos para el negocio.
Producir servicios y Productos de alta calidad.  Crear valor para los accionistas.
Mejorar la satisfacción del cliente.
Incrementar la participación en el mercado.
Ganar reconocimiento en la industria.

El modelo CMMI for Development 
El modelo tiene 4 áreas de conocimiento o disciplinas que incluyen
• Ingeniería de Software (SW)
• Ingeniería de Sistemas (SE)
• Desarrollo Integrado de Productos y Procesos (IPPD)
• Acuerdos con Proveedores (SS).

Disciplinas del Modelo 
Ingeniería de Sistemas: Abarca el desarrollo total del sistema que puede o no incluir el desarrollo de software. Ingeniería de Software: Cubre el desarrollo de software y su mantenimiento.
Desarrollo integrado de Productos y Procesos: Contempla un enfoque sistemático para la colaboración de los involucrados relevantes a través de la vida del producto. Acuerdo con Proveedores: En proyectos complejos se requiere de la incorporación de proveedores para ejecutar funciones o añadir modificaciones a productos.

CMMI Continuo 
Cada nivel de madurez es una plataforma bien definida para evolucionar la mejora.
Existen cinco niveles de madurez.
Cada nivel es una base para la mejora utilizando una secuencia probada desde sus bases.
Continuo Nos centramos en los problemas, mitigación de riesgos y en lo que le interesa a los objetivos de la organización.
Permite la comparación entre áreas de proceso.
Permite una comparación contra el modelo ISO 15504.

Niveles de Madurez (Por Etapas) 
Nivel 1 (Inicial): El proceso es impredecible, es reactivo y pobremente controlado.
Nivel 2 (Administrado): El proceso es reactivo y se caracteriza por su aplicación a proyectos.
Nivel 3 (Definido): El proceso es proactivo y se ve a nivel de la organización.
Nivel 4 (Administrado Cuantitativamente): El proceso es medido y controlado.
Nivel 5 (Optimizado): El proceso se enfoca en la mejora continua.
Por etapas:
Provee una secuencia de las mejoras desde la administración básica hasta niveles de alta madurez. Permite al comparación entre organizaciones por los niveles de madurez.
Provee un solo indicador que permite la comparación entre organizaciones.

Link:
http://www.allsoft.mx/recursos/ElModeloCMMI.pdf