Estable y publicación etapa
Un equipo de planificación con experiencia, el diseño, la fase de desarrollo, finalización de código para alcanzar este objetivo, parece que este último es una cosa natural, pero en las etapas finales del ciclo de vida del software es a menudo el mejor equipo de pruebas, el equipo de prueba de la gestión de proyectos, la adaptabilidad .
Todas las compañías de software quieren corregir todos los defectos antes de publicar el software, pero es casi imposible, sólo lo mejor compañía de software para encontrar un equilibrio, mientras que ser capaz de liberación oportuna del software de manera oportuna la cuestión de la modificación del software.
Cuando se trata de calidad, no mencionamos la gestión de calidad total, porque si hemos de gestión de calidad total, medios de gestión de calidad que no coger el punto.
En la etapa final y estable de liberación, hay algunos términos comunes:
1, Alfa: se refiere a la integración de la primera versión de prueba de las funciones principales, sólo se usa internamente, versión Alpha a los usuarios externos jugará un nombre más bello, como muestra de tecnología (Technical Preview)
2, Beta: función básica del todo, la estabilidad es mejor que Alfa, el usuario puede utilizar el pequeño rango de trabajo real
3, la PBC (Zero Bug Construir): Una versión del día presentado a este (por ejemplo, hace 48 horas) para deshacerse de todos los registros de errores
3, RC (Release Candidate): versión candidata, RC1 / RC2. . Hasta RTM, la versión de los intervalos son más cortos
4, RTM (Release con el fabricante): versión final, la versión final y documentos relacionados a otro equipo para envasado, la litografía de CD.
5, RTW (Soltar a la web): Para aplicaciones de red, tenemos que confiar en la web para publicar la versión final, por lo general para el equipo de operaciones del sitio para gestionar una liberación también se puede llamar RTO (Para la operación de liberación), la presentación de software a cada tienda de aplicaciones puede llegar a ser de lanzamiento de almacenar.
A partir de la finalización del código de publicar
Completar el proceso desde el código a la versión final del software:
grupo de consulta Triage equipo
Equipo de Consulta Software Group es un equipo compuesto por representantes de los diversos roles, lidiar con el impacto de cada versión del producto.
Para cada error, equipo de consulta decidirá cuál tomar las siguientes acciones: Reparación / diseño tenía tan / no reparación / pospuesto
Con el progreso de la fecha del proyecto y la liberación se acerca, el equipo también para asegurar modificaciones no tendrán un impacto negativo en el producto, entonces las reuniones de consulta promotor para que presente errores y modificaciones para que participen en la consulta, debe decidir si la reunión acordó modificar el programa.
de errores y modificaciones presentadas para participar en la consulta, el principal es ser informado:
La reunión se analizaron los resultados son los siguientes:
1, debe: debe ser reparado, la reparación es factible, se pasan las pruebas pertinentes
2, Más información: Para más información, puede afectar el defecto no está claro, las consecuencias no están claras, prueba relevante incompleta o defectuosa Solución
3, No: no puede aceptar, puede ser empujado a la próxima etapa, podría ser la solución propuesta no cumple con los requisitos
4, igual: es posible, pero no tiene que fijar, pero las soluciones son relativamente seguros. Se trata de una especie de estado intermedio, en un proyecto relativamente simple puede no ser un estado tal, si no es obligada en el día de la consulta, a continuación, reparar Al igual que en el estado pueden ser integrados juntos en la base de código, debe si no es así, entonces es sólo Al igual usted puede estar en modo de espera hasta que la ocurrencia de necesidad, si no ha habido necesidad, entonces la reparación sólo puede esperar hasta el siguiente hito. La ventaja de esto es la versión final no se actualizará debido a problemas menores, el consumo excesivo de los recursos de pruebas.
Además, el proyecto llegó a su fin, alcanzando Debe ser estándares cada vez más altos, esto puede dejar de lado algunos errores inocuos, por lo que el proyecto puede ser completado en la fecha prevista. En la etapa alfa, puede obtener inmediatamente una corrección de errores, debemos obtener el consentimiento de todos los miembros de Beta escenario y reparación de entonces, el RC (Release Candidate) etapa, por lo general para decidir si se trata de pasar tiempo valor a través de la consulta.
Si se rechaza la modificación, esto no significa que los esfuerzos fueron en vano, y las modificaciones puede comprobar el código fuente de la otra rama.
Cambios de diseño Diseño de Solicitud de Cambio
Cuando el transcurrido alfa / beta etapa, usted recibirá una gran cantidad de información de los usuarios, el diseño original, hay muchas áreas de mejora, entonces podemos aumentar la DCR.
Cuando se le preguntó DCR, donde debe indicar el problema, el impacto, si no modificar lo que va a pasar, y luego enumera varias modificaciones, así como las ventajas y desventajas de las distintas opciones y costos.
A continuación, la consulta DCR, de acuerdo con el impacto y el costo de la clasificación, de acuerdo a los recursos disponibles, ordenadas según la rediseño.
PBC
PBC nueva construcción para deshacerse de todo error conocido, cuando todo el equipo de corrección de errores, después de la próxima versión, los probadores y los usuarios tienen muchas oportunidades de usar las nuevas características y escena, esta vez en un asombroso número de error rebote de velocidad, se ZBB también se conoce como Zero Bug rebote. Pasar por el sistema varias veces a recuperarse, y finalmente cerca de cero.
En la definición de la PBC no es la búsqueda de la absoluta número de error 0, es debido a que el error se ha añadido, pero el acuerdo algún tiempo antes de que todo el insecto, insecto parece desechar según lo hace 48 horas.
Las pruebas de regresión
Cerca del final del proyecto, todo el personal debe volver a probar todos los errores, todos deben contribuir a garantizar que estos equipos son correcciones de errores, y no dar lugar a la función de regresión.
función de corte
Demasiado tarde para alcanzar los requisitos de diseño deseadas del enfoque es cancelar una función. No a causa de los costos hundidos y no están dispuestos a modificar, no porque en el pasado se llevó costo, es necesario ir después de una tarea debe ser completada.
Poco a poco congelación
Con la mejora de las funciones del programa, queremos que todos los aspectos del programa son un orden de congelación, con el fin de estabilizar el software para el usuario. En general, el programa de interfaz hombre-ordenador se inicia primero para congelar, no se pueden modificar arbitrariamente. Cuando la congelación función, fallo se resuelven, entonces no toque el código asociado a esta función antes de la próxima versión, si hay nuevas características que se añadirán a crear una rama sobre la base del código fuente, por lo que la versión y futuras versiones actuales trabajan por separado llevado a cabo.
liberación progresiva
En la era de Internet, se dio el caso de un producto al mismo tiempo para diferentes usuarios objetivo con diferentes frecuencias liberadas, como el mijo empresa MIUI a de honor a miles de personas al día grupo cerrado de beta actualizada sobre el desarrollo de varios millones de aparatos de un lunes actualizada con decenas de millones de usuarios comunes para lanzar una versión estable. Microsoft está en el proceso de liberación de Windows 10, también se utiliza de la misma manera:
base de usuarios Daily se construye canario prueba, mineros primeros utilizados canarios para detectar fugas de gas, lo que indica canario muy sensible. Si el usuario canario puede identificar las ventanas actuales pasaron las pruebas básicas, entonces esta versión será capaz de empujar a un mayor número de usuarios.
postmortem reunión retrospectiva
Al final de un hito para organizar reuniones para discutir el tema central de la reunión fue que empezar de nuevo si es posible, qué aspectos podrían hacer mejor. Haz una pocas por eso, encontrar la raíz del problema.
Plantilla de reunión:
Al hacer esta reunión para mantener una reunión ambiente relajado, cuando lo mejor es no aparecerá magnifico, que todos dicen lo que piensan, incluso si no hay, sino también de bajo perfil, no puede justificar sus acciones. Insistir en las cosas equivocadas, se centran en la mejora, en lugar de la excavación de la cuenta antigua. Que todos tengan la oportunidad de hablar totalmente, registrando mejoras y voto, el mayor número de votos la aplicación de algunas de las mejores mejoras.
punto de inflexión legendaria
En los proyectos de software, no es tal un punto de inflexión, en este punto antes, el número de mayor recién generado que el número de error de error corregido, después de esto, para resolver el mayor número de errores que el número de error nuevo, la curva de error se mueve hacia abajo. Para el proyecto fecha impulsada, es necesario controlar el punto de tiempo de inflexión, si el aumento del número de error no puede garantizar ese error caerá, entonces usted debe tomar la iniciativa para que se produce un punto de inflexión, como el aplazamiento de algunos errores, cortar algunas de las características, planteado fallo de referencia y así sucesivamente.
Bala de plata Batalla
Con el fin de problemas de evitar para algunos miembros del proyecto discuten sobre, puede utilizar la bala de plata bala de plata, en nombre de cada función en el proyecto se puede utilizar durante un tiempo limitado, la "discusión parada, me dijo la oficina de prensa" del arma, que es la bala de plata. Vamos a escuchar a una bala de plata, bala de plata número es limitado.