Cinco etapas del ciclo de vida del proyecto

1. Fase de inicio del proyecto

(1) Análisis de viabilidad del proyecto

Un producto exitoso debe evaluarse a partir de los siguientes tres aspectos:

Diseño de productos: comportamiento comercial
- Antes del diseño del producto, se debe realizar una investigación y evaluación de mercado, y se debe considerar la puntualidad del producto, la demanda del mercado y la viabilidad técnica;
- Una vez finalizado el diseño del producto, anote las especificaciones detalladas del producto (nivel técnico, recursos humanos, costos de desarrollo, costos del producto)
- Trate de evitar cambiar las especificaciones del producto a mitad de camino;
- Todo está sujeto a las necesidades o experiencia del usuario final.
Proyecto de gestión: comportamiento de la gestión
- El gerente de proyecto debe comprender claramente sus tareas para completar el desarrollo de productos de calidad aceptable dentro del límite de tiempo especificado. Bajo esta premisa, debe medir la mano de obra y otros recursos relacionados, hacer solo lo que se debe hacer y poder actuar en consecuencia.
Sistema de desarrollo: comportamiento técnico
- No busque la perfección, solo necesita diseñar y desarrollar productos "suficientemente buenos" que satisfagan las necesidades dentro del límite de tiempo prescrito y los recursos limitados.
- El trabajo de diseño debe llevarse a cabo de forma precisa y absolutamente documentada. No puede omitir el diseño y escribir el programa directamente por el bien del progreso.

Determinación del administrador de la demanda -> Análisis y revisión de la demanda -> Estimación de la escala del proyecto -> Análisis de riesgo del proyecto -> Plan preliminar de ejecución del proyecto y revisión

(2) Carta de autorización del proyecto

Indique claramente los objetivos del proyecto y la dirección de gestión

Autorizar claramente a PM

Cualquier información relacionada con el proyecto

(3) Aclare las limitaciones necesarias

Confirmar las especificaciones del producto (costo / rendimiento / calidad / ... demanda)

Confirmar restricciones de producto

Confirmar inicialmente las empresas y unidades que participarán en el proyecto

Confirmar el modo de desarrollo (ciclo de vida de desarrollo S / W)

Modelo de cascada

Modelo de prototipo (los requisitos iniciales no están claros)

Modelo en espiral (múltiples iteraciones de Waterfall + Prototype)

。。。

2. Etapa de planificación del proyecto

Planificación inicial: ¿Debe aceptarse este proyecto?

¡No hay plan, debe colgar! Antes de decidirte por el proyecto, debes haber hecho un análisis muy cuidadoso.
¡Completa misiones imposibles! Porque el proyecto entregado por el cliente ciertamente no es demasiado simple.

（1） Alcance / Tiempo / Costo / Plan de calidad

（2） Plan de recursos / comunicación

（3） Plan de riesgos

（4） Plan de configuración

(1) Gestión del alcance

El arte del compromiso: progreso frente a especificaciones

El principio de calidad y balance energético, si el cliente comprime repetidamente el horario, solo puede reducir las especificaciones; si el cliente cambia repetidamente las especificaciones, solo puede retrasar el horario.

Cuando se inicia el proyecto, lo primero es dedicar tiempo a administrar el alcance del proyecto (lo que se debe hacer y lo que no se debe hacer). Solo cuando se define el alcance correcto, el cronograma, los costos y la planificación de la mano de obra que se haga después serán significativos.

Herramientas de gestión de proyectos: estructura de desglose del trabajo, WBS y gestión de cambios

WBS
- Desglose del trabajo, la base más importante para otros planes de proyectos
- Criterios de descomposición:
- Desglose por "composición funcional"
- Desglose por "ciclo de vida del proyecto"
- Descomponer según la "arquitectura del sistema"
- La unidad mínima de descomposición (paquete de trabajo) de WBS debe ser muy específica, al menos dividida en una semana o 40 horas de carga de trabajo.
- Método de representación (diagrama de árbol + lista)
Gestión del cambio
- Todos los cambios deben ser aprobados por CCB (Change Control Board, es decir, una reunión donde los stakeholders involucrados en el cambio participan en la toma de decisiones), y se debe crear un nuevo plan. Está estrictamente prohibido aceptar la solicitud del cliente para cambiar la especificación de forma privada.

(2) Gestión del progreso del proyecto (tiempo / calendario)

El tiempo se diferencia de otros recursos en que es unidireccional, no repetible e insustituible.
Planificación del "plan de programación":
- Obtenga todas las unidades activas más pequeñas (hoja en el diagrama de árbol) de WBS
- Confirmar la relación entre las tareas (duración, relación de pedidos)
- FS (Finish to Start): una vez que finaliza la tarea A, se puede iniciar la tarea B;
- FF (Finish to Finish): una vez finalizada la tarea A, la tarea B puede finalizar;
- SF (de inicio a fin): una vez finalizada la tarea A, la tarea B puede finalizar;
- SS (Start to Start): después de que se inicia la tarea A, la tarea B puede comenzar;
- Diagrama de gestión de progreso (diagrama de Gantt + diagrama de red)
- El diagrama de Gantt describe la hora de inicio y finalización de cada tarea y también se puede utilizar para realizar un "seguimiento del progreso";
- El diagrama de red describe la secuencia de tareas (los nodos representan tareas, las flechas indican el orden de las tareas y los números a los lados de las flechas representan el tiempo requerido), que se utiliza para encontrar la ruta crítica CPM (la ruta con el tiempo más largo en el gráfico) y solo acortar la ruta crítica El tiempo necesario para la tarea puede acortar el ciclo de todo el proyecto.
Gestionar reservas
- Reserve tiempo para todo el proyecto (generalmente del 10 al 15% del ciclo completo del proyecto). No lo use a menos que sea necesario.
- De acuerdo con la ley de Parkinson, no importa cuánto tiempo le dé a un empleado, él siempre tiende a usar el tiempo que se le asigna.
Principios a conocer
- El programa es para cumplimiento más que para modificación. Cuando ocurre un retraso, el PM y el supervisor deben intentar activamente resolver el problema e intentar ponerse al día con el programa en lugar de revisarlo.
- Al planificar el cronograma, debe coordinar e integrar las opiniones de varias unidades, desde las más básicas hasta las detalladas, y recuerde trabajar a puerta cerrada.
- El progreso y el costo son inversamente proporcionales.
- La descomposición de WBS afecta directamente el cronograma del proyecto
- Durante el período de ejecución, debemos verificar constantemente si existe alguna desviación entre el plan del proyecto y el progreso real, y rastrearlo y resolverlo a tiempo.

(3) Gestión de costes (costes) del proyecto

Las estimaciones de costos del proyecto para los sistemas de software nunca serán muy precisas y solo pueden depender de la experiencia o el consenso de la industria para mejorar la precisión.
Los proyectos son actividades comerciales y es mejor no desarrollar un producto que no sea rentable. Todo debe estar comprometido por el costo.
Las principales fuentes de costo:
- Costo de gestión
- Costo de diseño de hardware / estructura
- Costo de producción y material
- Costos de desarrollo de software (líneas de código, puntos de función, meses-hombre ...)
- Estimación de costos del modelo COCOMO
Fuentes de errores de estimación de costos:
- Datos básicos insuficientes, todavía hay muchos factores inciertos en el proyecto
- El costo del proyecto es sensible a la demanda
- Técnicas de estimación de costos deficientes o inexpertas
- Inconsistente antes y después de firmar
Solo después de que se realiza la EDT y cuanto más detallado se divide el trabajo, la estimación puede estar más cerca de la situación real. Pero a menudo es imposible hacer un trabajo real hasta que termine WBS antes de cotizar. Recomendar "Mito hombre-mes: la forma de gestión de proyectos de software". En el proyecto de software integrado, el costo laboral es la parte más importante del costo total;
Gestion del valor ganado

Se utiliza principalmente para el seguimiento de los costos y el progreso del proyecto. Compara el trabajo realizado hasta ahora con el valor estimado en el plan del proyecto para proporcionar una estimación de qué tan lejos está el proyecto de completarse. PM puede obtener el costo del proyecto. Cuantos recursos.

(4) Gestión de la calidad del proyecto (Calidad)

Idea básica
- La calidad se planifica, no se verifica. La prevención es más importante que el tratamiento. Se debe preparar un "plan de calidad" durante la etapa de planificación y anunciarse en texto sin formato; la línea de base se puede establecer con líneas gruesas antes de formular reglas detalladas.
- La calidad del proyecto es producto de la calidad del trabajo de todos los desarrolladores ;
- La gestión de la calidad no es una actividad que se realiza una sola vez, sino que abarca todo el ciclo de vida del proyecto;
- El nivel de calidad es relativo y depende de la demanda y el precio del cliente;
- La gestión de la calidad es un espíritu y los productos de calidad no se pueden fabricar a través de ISO9000 o CMM.
- Sistema de gestión de calidad: ISO9000 o CMMI
QA （Garantía de calidad）

Centrarse en la corrección del proceso es una función de gestión . El objetivo principal de QA es asegurar que el producto pueda alcanzar el nivel de calidad esperado y el objetivo de confiabilidad bajo el cronograma y presupuesto establecidos. La herramienta de QA es la auditoría (auditoría), que debe ser auditada en todas las etapas, incluida la formulación del plan, el diseño del módulo, la revisión del código, el plan de prueba, el proceso de producción y el plan de preparación del material. El producto del trabajo de la etapa de planificación es formular un plan de calidad , aclarar los estándares de calidad adoptados por el proyecto y determinar cómo cumplir con los requisitos de los estándares. especialmente:
- Completó un cierto hito
- Solicitud de cambio
- Cuando el proyecto está a punto de entrar en la siguiente etapa
QC （Control de calidad）

Centrarse en encontrar y rastrear errores de proceso es una función de inspección . QC debe determinar si los resultados del proyecto cumplen con los estándares de calidad y, al mismo tiempo, averiguar las razones de las discrepancias (errores) y realizar un seguimiento de si se han resuelto correctamente (se debe registrar el proceso de manejo de cada error). El producto del trabajo de la fase de planificación es desarrollar un plan de prueba .

(5) Gestión de recursos humanos del proyecto (recursos humanos)

La adecuada organización y gestión del personal es un factor decisivo que afecta a los proyectos de software.
MS tiene una regla clara: no más de 10 personas en el equipo del proyecto.
Estructura de organización:
- Organización funcional (el interés de la organización y el proyecto pueden entrar en conflicto)
- Organización del proyecto (recursos duplicados, incapaz de implementar la estrategia de la empresa)
- Organización matricial (conflicto entre el gerente funcional o de departamento y el gerente de proyecto)
- Fuerte organización matricial
Gestión de equipos
- Crea un equipo de proyecto con presencia real
- Establecer un mecanismo de recompensa
- Establecer buenas relaciones interpersonales
- Configurar sistema de autorización de trabajo
- Teoría de la motivación: adaptarse a los talentos de uno para adaptarse mejor a uno

(6) Gestión de la comunicación del proyecto (comunicación)

El 70% de los errores en la gestión se deben a una mala comunicación y más del 80% del tiempo de PM se dedica a la comunicación.
Plan de comunicación:
- Necesidades de comunicación: ¿quién, cuándo y qué necesidades se necesitan?
- Contenido de la comunicación: formato de comunicación, contenido, nivel de detalle, etc.
- Métodos de comunicación: métodos de comunicación claros y canales de comunicación (conferencias, software de gestión de errores, informes de trabajo)
- Responsabilidades de comunicación: quién envía mensajes y quién los recibe
- Arreglo de comunicación: se debe incluir un cronograma de eventos de comunicación importantes en el plan del proyecto. (Por ejemplo, reunión de revisión)
Cálculo del canal de comunicación: Si hay N personas en el proyecto, entonces es necesario establecer N (N-1) / 2 canales de comunicación, lo que equivale a altos costos de comunicación.

(7) Gestión del riesgo (riesgo) del proyecto

Riesgo de tres elementos:
- Es un evento
- Probabilidad de ocurrencia
- Tendrá un cierto impacto en el proyecto.
La gestión de riesgos es la más pasada por alto y la más difícil de gestionar
Proceso de gestión de riesgos (recurrente):
- Identificación de riesgos: enumere los riesgos
- El proyecto carece de visibilidad
- El atractivo de las nuevas tecnologías
- Riesgo de compatibilidad tecnológica
- Riesgo de rendimiento: aumentar la intensidad de la implementación de la fase de diseño, realizar prototipos (Prototipo), etc.
- Riesgo de prisa online
- Problemas de usabilidad
- Falta de material, aumento de precio de las piezas
- Riesgo del contrato: verifique el contenido del contrato en detalle con los asuntos legales
- Exija el riesgo de cambio: acuerde por adelantado el proceso de gestión de cambios por escrito
- Riesgo de mala comunicación: desarrollo y anuncio del plan de comunicación del proyecto
- Falta de riesgo de soporte de alto nivel
- Riesgo de programación: si la programación no se puede ajustar, intente obtener la mayor cantidad de recursos y presupuesto posible, o entregue los productos por etapas.
- Riesgo de calidad: formule cuidadosamente las estrategias de calidad del proyecto y establezca un equipo de control de calidad.
- Riesgo de habilidad de los miembros del equipo: entrenar o cambiar miembros por adelantado.
- Riesgos del trabajo en equipo: metas claras y sistema de desempeño justo.
- Riesgo de rotación de personal: las tareas principales se asignan a varias personas para su ejecución.
- Ayudar a los fabricantes en situaciones de riesgo: formular procedimientos de revisión y aceptación antes de la cooperación.
- Evaluación de riesgos
- Analisis cualitativo
  - Enumere la matriz de probabilidad / gravedad
  - Tener cierta comprensión de los eslabones débiles del proyecto.
- Análisis cuantitativo: procesamiento matemático y expresión basada en los resultados del análisis cualitativo.
- Enumere las clasificaciones de riesgo (probabilidad X gravedad)
- Planificación de riesgos (tratamiento)
- Evite los riesgos: renuncie activamente o rehúse utilizar el plan que causa el riesgo y busque alternativas
- Transferir riesgo: transferir el riesgo a la empresa subcontratada
- Control de pérdidas: mitigar el grado de daño cuando ocurre el riesgo
- Asumir riesgos: puede optar por no hacer frente a riesgos con baja probabilidad de ocurrencia o bajo impacto
- control de riesgo

(8) Adquisición de proyectos / gestión de contratos

Subcontratación de software: en realidad, entre un 15% y un 20% más que la inversión neta en desarrollo propio
La gestión de proyectos de outsourcing es más complicada que el autodesarrollo:
- dificultad técnica
- Complejidad de la comunicación
- Costo de subcontratación
Nota para proyectos de subcontratación:
- Problema de comunicación
- Haz un plan detallado
- Evite retrasos
- Criterios de aceptación claros (especificaciones de software y API ...)

(9) Gestión de la configuración del proyecto (Configuración)

Realizar todo el proceso de desarrollo, el propósito es establecer y mantener la integridad y trazabilidad del producto.
Correspondiente al proceso de control de versiones maduro en proyectos de desarrollo de software
La gestión de la configuración del software significa simplemente la gestión de activos del proyecto, el proceso de identificación, seguimiento y control de productos en el proceso de desarrollo, que incluye:
- El panorama general del proyecto, incluidas las especificaciones del producto y las especificaciones de diseño.
- El plan original del proyecto y todos los cambios que se han realizado durante la operación del proyecto.
- Cualquier punto de inflexión importante en la fase de diseño y avances tecnológicos importantes durante la operación del proyecto.
- ¿Qué problemas encontró durante el desarrollo de software y cuál fue la solución? ¿Cuál es el código de programa correspondiente?
- Importancia de las versiones de software importantes o los hitos del proyecto, y una instantánea del estado del proyecto en ese evento
- El historial de problemas en la fase de diseño y producción de hardware es la solución.

3. Etapa de ejecución / control del proyecto

¿Cómo funcionan juntas la ingeniería de software y la gestión de proyectos?

La ingeniería de software incluye tres procesos cíclicos:

Definición del proceso de desarrollo: incluye requisitos de software, proceso de desarrollo de software, gestión de configuración de software SCM
Desarrollo de software: incluye diseño de software, construcción de software, pruebas, mantenimiento y actualización.
Garantía de calidad del software: calidad del software

El proceso de gestión de proyectos consta de tres procesos cíclicos:

Planificación de proyectos
Implementacion de proyecto
Seguimiento de proyectos

(1) Diseño de especificación de producto

Después de escribir las especificaciones del producto, el cliente debe confirmar y firmar nuevamente al final. Todo el trabajo de diseño futuro debe usar esto como plantilla. Una vez que el cliente quiere convertir un nuevo requisito en una "especificación", debe cambiar el documento formal que ha pasado la revisión, y este debe ser aprobado por el sistema de gestión de calidad.

En general, las especificaciones del producto incluyen los siguientes aspectos:

Introducción a las especificaciones de hardware
Concepto de diseño de producto, limitación y ámbito de aplicación
Manual de funciones de usuario
Diagrama de flujo de operación
Interfaz de usuario e ilustraciones
Regulaciones de desempeño
Consideraciones Especiales

(2) Diseño de hardware

El trabajo de la etapa de diseño de hardware es el siguiente. Además del diseño de apariencia y estructura, el ingeniero de firmware debe participar tanto como sea posible:

Selección de CPU
Selección de chip principal
Diseño de circuito
Diseño
Gestión de piezas y materiales
Diseño de forma de producto
Diseño estructural
Fabricación de modelos antes de la apertura del molde

Los archivos de salida en esta etapa son:

Especificación de diseño de hardware
BUENO 表
Apariencia 3D
Diagrama de estructura
Diagrama esquemático
Diagrama de distribución

(3) Diseño del sistema

Según el tamaño del proyecto o el entorno de hardware, seleccione el método de diseño adecuado. Si la frecuencia de la CPU es solo decenas de M y la memoria es pequeña, se recomienda elegir un diseño de método estructurado y elegir el lenguaje C para el desarrollo. Si el proyecto es grande, la frecuencia de la CPU es de varios cientos de M y los recursos de almacenamiento son abundantes, elija el método orientado a objetos y elija C ++ o Java como lenguaje.

(4) Diseño del plan de prueba

También existen estándares para las pruebas de software IEEE 829 describe en detalle las disposiciones y precauciones del plan de pruebas, pero la situación real es que las ideas y el espíritu del estándar deben heredarse de acuerdo con las características del proyecto. Antes de realizar la prueba, es necesario centrarse en comprender funciones más complejas, nuevas características, requisitos especiales del cliente o áreas vagas descritas en las especificaciones, y luego diseñar casos de prueba y planes.

(5) Evaluación de riesgos

Los riesgos más comunes son los siguientes :

Retraso en curso
Inflación de demanda
Rotación de personal
Colapso de la especificación
Bajo rendimiento
Brecha tecnológica
diferencia cultural
Integración de software y hardware
Problemas de fabricación

Proceso de identificación de riesgos :

Diagrama de flujo de identificación de riesgos

4 formas de afrontar los riesgos :

Evite: no toque la parte peligrosa
Moderación: prepare suficiente tiempo y dinero para reducir el riesgo cuando tome forma
Mitigación: tome ciertas medidas antes de que el riesgo tome forma
Escapar: no hacer nada, orar por la bendición de Dios

(6) Escriba documentos de diseño antes de codificar

Desde el comienzo del proyecto, se debe preparar un servidor para almacenar y administrar todos los archivos del proyecto, y todos los miembros del proyecto pueden obtener fácilmente los archivos o registros necesarios.

Los archivos que deben registrarse incluyen:

Especificaciones del producto
calendario
Documentos relacionados con el diseño de hardware (diagrama de configuración del PIN de la CPU, diagrama esquemático, diagrama de distribución, etc.)
Documentos técnicos: hoja de datos del chip, API de biblioteca de software de terceros, etc.
Especificación del diseño de la arquitectura del sistema (incluida la API de cada módulo)
Plan de prueba
Informe de prueba y hojas de errores
Documento de calidad
Actas de reuniones importantes
Copia de seguridad de correo electrónico importante
Otros documentos a registrar

(7) Revisión de diseño

Principios de revisión de diseño:

La revisión del diseño debe ser progresiva. Y ejecutar todo el proceso de diseño
Invitar al cliente del diseño a participar en la revisión del diseño.
Cuanto mayor sea el diseño, más se debe llamar a participar a todo el personal del proyecto.

(8) Etapa de implementación

Cuando todos los documentos de diseño hayan pasado la revisión, puede ingresar a la etapa de implementación. Contiene lo siguiente:

Desarrollo y depuración de programas
Desarrollo de hardware (electrónica, estructura)
Pruebas de software y hardware
Ejecución de la misma calidad
Producción de prueba en fábrica

Cada etapa del proyecto debe ciclarse de acuerdo con PDCA (Plan, Do, Chick, Act). Cuando se descubre un problema de diseño durante la compilación del programa, no debe modificarlo usted mismo. Debe detener temporalmente la implementación, buscar contramedidas, confirmar el alcance de influencia y aprobar la revisión del diseño de la unidad relevante antes de poder continuar con la implementación. Cuál es el proceso de "cambio de diseño"

Los resultados del mismo desarrollo integrado eventualmente se comercializarán, por lo que es inevitable tratar con la fábrica.

Los elementos que los ingenieros de software deben entregar a la fábrica son:
- Archivo binario para grabar
- Programa de prueba automático y manual para línea de producción.
- Procedimientos de prueba dedicados a las pruebas ambientales
Los elementos que los ingenieros de hardware y electrónicos deben entregar a la fábrica son:
- circuito electrónico
- Especificaciones de ingeniería eléctrica
- Instrucciones de prueba de especificaciones especiales (funciones no producidas por la fábrica antes)
Los elementos que el ingeniero estructural debe entregar a fábrica son:
- Diagrama de combinación (expanda todas las partes una por una)
- Esquema de piezas especiales.
- Diagrama de combinación de procesamiento especial

4. Etapa de cierre del proyecto

(1) Cierre de contratos externos

(2) Cierre de proyectos internos

Archivo de datos del proyecto

Archivo de datos técnicos

Registrar la experiencia y acumular los activos del proyecto de la empresa

reunión cercana, personal disuelto

Durante la ejecución del proyecto, desarrolle un proceso y utilice herramientas automatizadas para registrar el seguimiento del desarrollo del proyecto (incluidos programas, archivos, gestión de errores, gestión de problemas, gestión de cambios, etc.) y realice copias de seguridad de ellos con regularidad.

Estipule claramente el tiempo de inicio y finalización para la implementación del proceso de cierre del proyecto, preferiblemente no más de una semana, y comuníquese y coordine con los jefes de departamento de los miembros del proyecto y el gerente del proyecto actual, y solicite a estos colegas que ayuden al proyecto en un período de tiempo determinado.

Enfoque general de la gestión de proyectos integrada