Proceso de gestión de proyectos de software
1. Evaluación de riesgos
El riesgo del proyecto de software se refiere también al presupuesto de costos, el progreso del desarrollo, la dificultad técnica, la viabilidad económica, la gestión de la seguridad y otros aspectos involucrados en todo el ciclo del proyecto. ya que estos problemas impactan en el proyecto. El riesgo de un proyecto es inversamente proporcional a su viabilidad. Cuanto mayor es la viabilidad, menor es el riesgo. La viabilidad de un proyecto de software se puede dividir en cuatro aspectos: viabilidad económica, viabilidad empresarial, viabilidad técnica y viabilidad legal. Los riesgos de los proyectos de software se dividen en seis aspectos: riesgo de escala del producto, riesgo de demanda, riesgo de relevancia, riesgo de gestión y riesgo de seguridad;
1.? Riesgo de escala del producto
El riesgo de un proyecto es directamente proporcional a la escala del producto. Generalmente, cuanto mayor es la escala del producto, más destacados son los problemas. En particular, factores como el método de estimación del tamaño del producto, la cantidad de software reutilizable y el número de cambios en la demanda están estrechamente relacionados con el riesgo del producto:
(1)? p>
(2) ?La credibilidad de la estimación del tamaño del producto
(3) ?La desviación del tamaño del producto respecto al tamaño promedio anterior del producto
(4) ? El número de usuarios del producto
(5) ?¿Cuánto software reutilizado hay?
(6) ?¿Cuánto ha cambiado la demanda del producto?
2.? Riesgo de requisitos
Muchos proyectos enfrentan cierta incertidumbre al determinar los requisitos. Cuando estas incertidumbres se toleran en las primeras etapas de un proyecto y no se resuelven a medida que avanza, estos problemas representarán una gran amenaza para el éxito del proyecto. Si no se controlan los factores de riesgo relacionados con la demanda, se puede producir el producto incorrecto o se puede romper el producto previsto. Cada situación puede ser fatal para el producto. Estos factores de riesgo son:
(1) ?Falta de comprensión clara del producto
(2) ?Falta de comprensión de los requisitos del producto <. /p>
(3) ?Participación insuficiente del cliente en el proceso de análisis de la demanda
(4) ?Sin demanda prioritaria
(5) ?Debido a una demanda incierta, nueva El se creó el mercado.
(6) ?Cambios en la demanda
(7) ?Falta de un proceso efectivo de gestión de cambios en la demanda
(8) ?Falta de análisis relevante de los cambios en la demanda , etc. .
3.? Riesgos relevantes
Muchos riesgos son causados por el entorno externo del proyecto o la correlación de factores. Para controlar los riesgos de dependencia externa, las estrategias de mitigación deben incluir la planificación de posibilidades para obtener los componentes necesarios de recursos de trabajo secundarios o colaborativos y detectar problemas potenciales. Los factores relacionados con el entorno externo incluyen:
(1) Artículos o información de suministro del cliente
(2) Dependencias de miembros o grupos que interactúan
(3) ?Relaciones entre subcontratistas internos o externos
(4) ?Disponibilidad de personal experimentado
(5) ?Reutilizabilidad del proyecto
4.? Riesgo técnico
El rápido desarrollo de la tecnología de software y la falta de personal experimentado significa que las habilidades del equipo del proyecto pueden afectar el éxito del proyecto. Desde el principio, identificar los riesgos y tomar medidas preventivas adecuadas es clave para abordar áreas de riesgo, como la capacitación, la contratación de consultores y el reclutamiento del talento adecuado para el equipo del proyecto. En cuanto a la tecnología, existen principalmente los siguientes factores de riesgo:
(1) ?Falta de formación
(2) ?Comprensión insuficiente de los métodos, herramientas y tecnología.
(3) ?Falta de experiencia en el campo de aplicación
(4) ?No familiarizado con la aplicación de nuevas tecnologías y métodos de desarrollo.
5.? Gestión de riesgos
Si bien los problemas de gestión limitan el éxito de muchos proyectos, no se sorprenda si todas las actividades de gestión no están incluidas en un plan de gestión de riesgos. En la mayoría de los proyectos, el director del proyecto suele ser la persona que redacta el plan de gestión de riesgos del proyecto. Tienen un defecto inherente: no pueden comprobar sus propios errores. Como resultado, el éxito del proyecto se vuelve más difícil. Si no abordamos estos difíciles problemas, es probable que afecten al proyecto en algún momento. Cuando definimos el proceso de seguimiento del proyecto y aclaramos las funciones y responsabilidades del proyecto, podemos abordar estos factores de riesgo:
(1) Plan y definición de tareas insuficientes.
(2) ?No conocer el estado real del proyecto
(3) ?Los propietarios del proyecto y quienes toman las decisiones están confundidos.
(4) ?Promesas poco realistas
(5) ?Incapacidad para comunicarse plenamente con los empleados.
6.? Hombre peligroso
El producto de software en sí es un producto creativo y es muy importante mantener en secreto la tecnología central del producto. Sin embargo, durante mucho tiempo, nuestra conciencia de la seguridad en el software ha sido relativamente débil. El desarrollo de productos de software se ha centrado principalmente en la tecnología en sí, descuidando la protección de las patentes. El flujo de personal técnico en la industria del software es un fenómeno muy común. Con la pérdida y los cambios de personal técnico, es probable que se produzcan fugas de productos y nuevas tecnologías, lo que provocará el robo de nuestros productos de software por parte de otras empresas y el fracaso del proyecto. Además, no existe un estándar industrial claro para la identificación de los derechos de propiedad intelectual del software, lo que también supone un riesgo potencial para nuestros proyectos de software.
7.? Métodos para evitar riesgos
(1) ?La orientación de los desarrolladores puede garantizar la integridad de los requisitos y hacer que los requisitos sean altamente consistentes con las expectativas reales de los clientes. Luego, es conveniente formar un documento importante por escrito "requisitos del usuario" para evitar que las pérdidas causadas por omisiones se amplifiquen gradualmente en las etapas posteriores del sistema de software.
(2) Para establecer un sistema de supervisión, cualquier toma de decisiones importante en el desarrollo de un proyecto debe implicar la participación de los clientes. En este proyecto, la supervisión del proyecto la lleva a cabo el equipo de supervisión de calidad en el desarrollo del proyecto.
(3) ?Los cambios de requisitos deben ser propuestos por la persona a cargo unificada y aprobados por el líder del equipo de revisión de requisitos del usuario. Los cambios en los requisitos deben realizarse con regularidad y no en cualquier momento, y los desarrolladores deben mantener registros detallados para que los clientes comprendan la situación real de los cambios en la demanda.
(4) ?La complejidad del sistema de control y la simplicidad de la estructura del sistema reducirán significativamente el número de usuarios e incluso harán que la vida útil del software sea demasiado corta. Por otro lado, si la estructura del software es demasiado flexible y versátil, inevitablemente aumentará la dificultad de la implementación del software y la complejidad del sistema, lo que traerá riesgos durante las fases de implementación y prueba. Un control adecuado de la complejidad del sistema ayuda a reducir los riesgos de desarrollo.
(5) ?Desde la perspectiva de la ingeniería de software, los costos de mantenimiento del software representan aproximadamente entre el 55% y el 70% del costo total. Cuanto más grande es el sistema, mayor es el costo. Ignorar la mantenibilidad del sistema es el mayor riesgo para los sistemas de software grandes. Las reglas comerciales inevitablemente evolucionarán a lo largo de la larga vida útil del software. El método científico para resolver este problema es actualizar continuamente el sistema de software y expandirlo gradualmente mientras se garantiza la mantenibilidad.
(6) ? Desarrollar un plan de emergencia. Cada plan de desarrollo debe desarrollar al menos un plan de emergencia para hacer frente a emergencias y riesgos desconocidos.
2. Presupuesto de costes
1.? Modelo de presupuesto de costos
(1) ?Método de presupuesto de arriba hacia abajo
El método previo de arriba hacia abajo se basa principalmente en la experiencia de gestión de los gerentes de proyectos de nivel medio y superior para estimar los costos generales del proyecto y los costos de los subproyectos y pasar los resultados de estos juicios y estimaciones a los gerentes de nivel inferior. Sobre esta base, los gerentes de este nivel hacen estimaciones para las subtareas y subproyectos que componen el proyecto y luego continúan pasando sus estimaciones de costos a los siguientes niveles hasta alcanzar el nivel más bajo.
Al utilizar este método de presupuestación, cuando las estimaciones de costos basadas en la experiencia de los gerentes de nivel superior se descomponen en niveles inferiores, puede haber situaciones en las que el personal de nivel inferior crea que las estimaciones de nivel superior son insuficientes para completar el presupuesto correspondiente. tareas. En este momento, es posible que el personal de nivel inferior no exprese sus verdaderas opiniones y que no discuta racionalmente con la gerencia de nivel superior para elaborar un plan de asignación presupuestaria más razonable. En la práctica, sólo pueden esperar en silencio a que los altos directivos encuentren problemas y los corrijan, lo que a menudo trae muchos problemas al proyecto.
El método top-down es más adecuado para las primeras etapas de puesta en marcha del proyecto, y la diferencia con el coste real está entre el 30% y el 70%.
Scrum adopta un método de presupuestación de costos de arriba hacia abajo, que no determinará con precisión los costos de inmediato, pero se adaptará a los cambios en los requisitos del cliente para productos futuros en la mayor medida posible.
(2) ?Método de presupuestación ascendente
El método ascendente requiere el uso de WBS (estructura de desglose del trabajo) para examinar cuidadosamente el tiempo y el presupuesto de todas las tareas laborales en el proyecto. El presupuesto inicial es para recursos (tiempo de trabajo de los miembros del equipo, configuración del hardware), el director del proyecto agrega los costos indirectos apropiados (como costos de capacitación, costos de gestión, costos imprevistos, etc.) y el objetivo de ganancias que debe alcanzar el proyecto. formando el presupuesto total del proyecto. El enfoque de presupuestación ascendente requiere una consideración integral de todas las tareas involucradas y es más adecuado para las etapas iniciales y intermedias de un proyecto.
Puede estimar el coste de un proyecto en su fase de preparación, siendo la diferencia con el coste real entre el 5% y el 10%.
Nota: WBS
WBS es un desglose del proyecto enviado. A partir de la lista de confirmaciones, podemos determinar las actividades que cada confirmación debe realizar. Scrum refinará aún más la WBS, descompondrá una iteración en uno o más paquetes de trabajo y luego descompondrá los paquetes de trabajo en pequeñas tareas de desarrollo (el ciclo de desarrollo de las tareas de desarrollo generales es de 15 horas hábiles).
2.? Determinar el gasto del proyecto
El presupuesto de costos total es el costo de desarrollo calculado integralmente con base en los siguientes métodos de presupuestación de costos:
(1) ?Presupuesto base cero
Más allá el presupuesto de costos Inicialmente, se debe adoptar el principio de cálculo de base cero, y el costo del proyecto no se puede calcular aproximadamente como el costo total del año anterior más el 20%.
(2) ?Costos de software y hardware, costos del proyecto
Los costos del proyecto se refieren a cosas como: costo del servidor (RAM, disco duro, CPU, tarjeta NIC, clúster RAID), costo de mantenimiento, sala de computadoras Alquiler, costos de comunicación de fibra óptica, costos de software y otros costos.
Al calcular el costo, debemos considerar muchos factores, como el tiempo necesario para ensamblar el disco duro, la calidad del personal técnico, si el proveedor del producto puede garantizar la calidad y si Se necesita personal de gestión adicional para la gestión.
(3) ?Costos de licencia de software
(4) ?Costos de subcontratación
Cuando se utilizan subproyectos como video, SMS, servicios de telecomunicaciones móviles, portales , etc. , puede considerar la subcontratación para reducir los costos de desarrollo.
(5) ?Costos de recursos humanos
Al calcular los costos de recursos humanos, el costo promedio de los recursos humanos debe calcularse estimando la eficiencia promedio de la eficiencia laboral más alta y más baja.
(6) ?Costos de mantenimiento
En tercer lugar, el proceso de comunicación con el cliente
Desde la perspectiva de la comunicación con el cliente, los proyectos de software se pueden dividir en identificación de requisitos, Hay cuatro etapas diferentes: personalización del plan, implementación del proyecto y finalización del proyecto. Cada etapa tiene diferentes prioridades de comunicación.
1.? Etapa de identificación de requisitos
(1) ?Comunicación de texto
En la etapa inicial de identificación de requisitos, se debe llevar a cabo una investigación exhaustiva a través de cuestionarios, visualización de prototipos, visualización de interfaz, visualización de procesamiento lógico, plantillas de documentos estandarizados, etc. Análisis direccional y multiángulo. Y ambigüedades de retroalimentación a los clientes en cualquier momento, esperando respuestas de los clientes. Y cree un documento de análisis de la demanda en forma de registros escritos y solicite a los clientes que revisen el documento de análisis de la demanda para lograr un resultado que sea altamente consistente con el análisis de la demanda y las verdaderas expectativas del cliente.
(2) ?Comunicación de lógica empresarial
En la comunicación empresarial, es necesario comprender el lenguaje industrial del cliente, promoviendo así el proceso de análisis empresarial y cerrando la brecha entre los requisitos de la aplicación y desarrollo. El proceso de comunicación aboga por bocetos o informatización visual para proporcionar la interfaz operativa más adecuada para los usuarios comerciales en diferentes niveles. Piense desde múltiples perspectivas y capte las necesidades clave, especialmente las necesidades innovadoras y prácticas que preocupan a los líderes de los clientes.
(3) ?Gestión estandarizada de cambios de demanda
Los cambios de requisitos son comprensibles en proyectos de desarrollo de software, pero deben gestionarse de forma estandarizada para evitar demandas interminables Riesgo de cambio. Los cambios en los requisitos deben ser propuestos por la persona a cargo unificada y aprobados por el líder del equipo de revisión de requisitos del usuario. Los cambios en los requisitos deben plantearse periódicamente, no en cualquier momento. Los desarrolladores deben mantener registros escritos detallados para que los clientes comprendan la situación real de los cambios en la demanda y los costos incurridos por los desarrolladores.
2.? Etapa de personalización de la solución
La tarea principal del proyecto en esta etapa es trabajar con el cliente para desarrollar un proyecto operable basado en los requisitos claros en la etapa inicial, los recursos de ambas partes, la etapa inicial de el proyecto, el acuerdo de tiempo de implementación, el límite de costo del proyecto, etc. A partir de esta etapa, el cliente participará plenamente en la gestión del proyecto y considerará los planes específicos para la implementación del proyecto y la prevención de riesgos en función de los intereses de ambas partes.
3.? Fase de implementación del proyecto
En esta fase, el equipo del proyecto de software debe trabajar con el cliente para liderar la implementación del proyecto. Al mismo tiempo, el equipo del proyecto debe evaluar la satisfacción del cliente en tiempo real y mejorar la satisfacción del cliente mediante la mejora continua. También se debe exigir a los clientes que participen en la capacitación necesaria e inspeccionen los productos del proyecto cuando sea necesario. Antes de que cambien las necesidades del cliente, debemos comunicarnos activamente con el cliente para permitirle comprender completamente cada aspecto del proyecto y el impacto de los cambios, a fin de reducir los cambios en la demanda.
Si el cliente necesita un cambio, debemos trabajar con el cliente para resolver los cambios en costo, cronograma y calidad causados por el cambio.
4.? Etapa final
Esta etapa se trata principalmente de la entrega de los resultados del proyecto y la entrega del sistema al personal de mantenimiento para ayudar a los clientes a alcanzar los objetivos comerciales y liquidar diversos pagos. Después de completar estas tareas, se debe evaluar el proyecto, revisar los resultados del proyecto y resumir la experiencia del proyecto.
5.? Notas para el personal de preventas
Cuando los proyectos orientados a productos se consideran resultados de desarrollo, el personal de ventas relevante debe prestar atención: no prometa demasiado la promoción del producto. Si hay demasiadas promesas, causará dificultades en la implementación posterior del proyecto; una vez que las promesas no se cumplan, la satisfacción del cliente también se reducirá y la cooperación futura se verá afectada. Si hay compromisos adicionales, deben documentarse en forma de texto para que el gerente del proyecto de implementación los conozca y los comunique a los miembros del equipo del proyecto.
Nota: En proyectos de software, es necesario definir los siguientes cuatro roles de cliente.
¿A.? Es necesario aclarar los departamentos y usuarios finales, comprender sus métodos de trabajo existentes, informarles el marco de objetivos del proyecto y saber qué dificultades debe resolver el proyecto, pero ciertamente no todas, para que el alcance del el proyecto se puede controlar mejor.
B.? Para identificar al creador de la necesidad, él o ella deben poder representar la base final de clientes. Los clientes que proponen requisitos de producto deben tener ciertas capacidades y autoridad técnicas y comerciales, y pueden representar verdaderamente los deseos e ideas del equipo del cliente final. Es mejor tener una base de TI y poder describir problemas y necesidades en lenguaje de TI. Facilitar la comunicación y la cooperación entre las dos partes y evitar la ambigüedad.
C.? Los líderes de nivel medio responsables de identificar las necesidades deben captar la dirección. Los proyectos de desarrollo de software tienen como objetivo resolver problemas reales de producción o gestión, así como liderar la implementación específica de la construcción del sistema. Como líder de clientes que necesita confirmación, no solo debe comprender las prioridades y direcciones de construcción del sistema de los líderes senior, sino también estar familiarizado con prácticas específicas de gestión comercial y de producción. Si este es el caso, desempeñará un papel extraordinario en el buen progreso de los proyectos de desarrollo de software empresarial.
¿D.? Tenga claro quién comentará sobre el producto terminado y quién lo recibirá. La fase de aceptación del proyecto es la fase de cierre del mismo. Si la persona que acepta el proyecto no comprende los objetivos de demanda originales del proyecto, tendrá un impacto negativo en la aceptación en términos de actitud y uso real del producto, y será muy perjudicial para la empresa que proporciona el producto. cerrar el proyecto. Según un resumen práctico, el lado de la demanda y el lado de confirmación hacen un buen trabajo en la aceptación del proyecto, lo que puede promover la finalización sin problemas del proyecto y evitar retrasos.
Cuarto, análisis de la demanda
1. El proceso de análisis de la demanda
El proceso de la demanda incluye dos partes: desarrollo de la demanda y gestión de la demanda:
(1) ?El desarrollo de requisitos es el proceso de gestión y comunicación con las habitaciones en la etapa inicial de desarrollo. Se divide en cuatro etapas: adquisición de la demanda, análisis de la demanda, redacción de la demanda y verificación de la demanda.
(2) ? Gestión de requisitos: es la actividad de controlar y mantener los acuerdos de requisitos durante el proceso de desarrollo de un proyecto de software. Incluyendo control de cambios, control de versiones, seguimiento de requisitos y seguimiento del estado de los requisitos.
2.? Nivel de necesidades
El nivel de necesidades incluye cuatro aspectos: necesidades comerciales, necesidades del usuario, necesidades funcionales y necesidades no funcionales.
3. Puntos clave en la etapa de desarrollo de requisitos
(1) Extraer objetos de negocio
Los objetos de negocio se refieren a los objetos reales utilizados por el sistema. Por ejemplo, los objetos comerciales de la gestión de la cadena de suministro (SCM) incluyen principalmente: fabricantes, mayoristas, minoristas, proveedores y clientes.
(2) ?Extraer procesos de negocio
En el proceso de comprensión de la lógica de negocios, es necesario enumerar las funciones de los módulos de software desarrollados, refinar cada proceso de trabajo y analizar el Lógica empresarial en profundidad.
(3) ?Requisitos de rendimiento
En la etapa inicial del análisis, los clientes deben prestar atención a los indicadores de rendimiento técnico del software desarrollado, como los límites de capacidad de almacenamiento y los límites de tiempo de ejecución. , seguridad y confidencialidad, etc.
(4) ?Requisitos ambientales
Los requisitos ambientales se refieren a los requisitos del entorno en el que se ejecuta la plataforma de software, como el hardware: modelo, equipo externo, interfaz de comunicación de datos; : software del sistema, incluido el sistema operativo, el software de red y el sistema de gestión de bases de datos Propósito: desde el nivel técnico y del sistema del operador, qué condiciones debe tener el departamento usuario;
(5) ?Requisitos de confiabilidad
La probabilidad de falla después de que el software desarrollado se pone en funcionamiento de acuerdo con los requisitos reales del entorno operativo.
Para software importante o software cuyo fallo de funcionamiento tendrá consecuencias graves, se deben plantear requisitos de confiabilidad más altos.
(6) ?Requisitos de seguridad y confidencialidad
Al realizar un análisis de la demanda, se deben tomar las disposiciones adecuadas al respecto y se deben realizar diseños especiales del software desarrollado para garantizar que Seguridad y confidencialidad en la operación.
(7) ?Requisitos de la interfaz de usuario
Especifique en detalle los requisitos de llegada de la interfaz de usuario.
(8) ?Requisitos de uso de recursos
Varios recursos requeridos por el software desarrollado durante el tiempo de ejecución y desarrollo.
(9) ?Consumo de costos de software y requisitos de progreso de desarrollo
Una vez establecido el proyecto de software, los requisitos de progreso de desarrollo de software y el costo de cada paso se proponen de acuerdo con el contrato como la base para la gestión del desarrollo.
(10) Requisitos de los objetivos de desarrollo
Estime los objetivos que el sistema puede alcanzar de antemano, de modo que sea más fácil realizar las adiciones y modificaciones necesarias al sistema.
4.? Tareas del análisis de requisitos
La tarea principal del análisis de requisitos es derivar el modelo lógico del sistema objetivo con la ayuda del modelo lógico del sistema actual. El proceso es el siguiente:
(1) Determinar la síntesis de los requisitos del sistema (requisitos de función, rendimiento, operación y expansión)
(2) ?Producir el documento de requisitos del producto (PRD)
(3) ?Analizar los requisitos de datos del sistema (modelo conceptual, diccionario de datos, estandarización)
(4) ?Exportar un modelo lógico detallado del sistema de destino (diagrama de flujo de datos, diccionario de datos, descripción de la función principal)
(5) ?Desarrollar un sistema prototipo
(6) ? Extraer y compilar especificaciones de requisitos de software del PRD.
Nota: formato SRS
1. 2Descripción general del sistema (antecedentes del proyecto, objetivos del sistema, procesos comerciales centrales)3. ¿Descripción terminológica? 4. Estructura del sistema (diagrama de arquitectura, diagrama de funciones)
5. Funciones principales y lógica empresarial (puntos clave)6. Requisitos de interfaz (interfaces internas y externas)7. Diseño general de la red (red topológica, host, red)
8 Entorno operativo (Linux, Windows, IIS, WebLogic, Tomcat, OLAP, OLTP, JDK 8.0, .NET Framework 4.0, etc.)
5.Programación orientada a objetos (omitido)
1.? Principios de diseño
(1) ?Cadena de responsabilidad única SRP
Cada clase solo debe ser responsable de hacer una cosa.
(2) ?Principio de apertura y cierre de OCP
Las entidades de software (clases, módulos, funciones, etc.) deben ser extensibles pero no modificables.
(3) ?Principio de sustitución LSP
Las subclases deben poder reemplazar sus tipos base.
(4) ?Principio de inversión relacionado con la inclinación
Los módulos de alto nivel no deberían depender de módulos de bajo nivel, pero ambos deberían depender de interfaces y clases abstractas. Las abstracciones no deberían depender de los detalles, los detalles deberían depender de los objetos.
(5) ?Principio de aislamiento de interfaz ISP
Deberíamos separar las interfaces gruesas en lugar de obligar a los clientes a confiar en interfaces no utilizadas.
2.? Implementar modelado UML
(1) ?Extracción de objetos de negocio
(2) ?Modelado de casos de uso basado en SRS, CRC, etc.
(3) ?Implementar el diagrama de secuencia empresarial
(4) ?Establecer un diagrama de clases y establecer la asociación entre objetos en función del diagrama de casos de uso.
(5) ?Dibujar diagramas de actividad e implementar diagramas de colaboración y diagramas de estado.
Gestión del desarrollo de verbos intransitivos
1.? Establecer un plan de proyecto
(1) ?Diseñar la arquitectura general
Adoptar una estructura marco apropiada y madura basada en las necesidades de implementación del sistema.
(2) ?Control de escalabilidad
La expansión excesiva aumentará la complejidad del sistema y extenderá el tiempo de desarrollo; una escalabilidad demasiado baja afectará directamente el desarrollo secundario y el mantenimiento del sistema. La escalabilidad del sistema de control puede mejorar la eficiencia del desarrollo y reducir la dificultad del mantenimiento del sistema.
(3) ?Establecer infraestructura
Asignar razonablemente el tiempo y los costos necesarios para implementar infraestructura como software y hardware (por ejemplo, solicitar e instalar servidores, acceso a fibra óptica, solicitar software plataformas).
(4) ?Dividir tareas de desarrollo
Utilizar WBS (estructura de desglose del trabajo) para clasificar y dividir los entregables. Cada proyecto se puede dividir en varias fases diferentes, y cada fase se puede dividir en varios paquetes de trabajo. Estos paquetes de trabajo son los entregables más pequeños de la WBS. Finalmente, varias listas de tareas de desarrollo están separadas de los paquetes de trabajo.
(5) ?Progreso de implementación y desarrollo
Un proyecto debe dividirse en varias etapas de desarrollo según el progreso. El ciclo de desarrollo de cada etapa generalmente es de 30 a 60 días hábiles. . En esta etapa, debemos celebrar reuniones de consulta con los clientes, desarrollar una hoja de ruta del producto e invitar a los clientes a participar activamente y dar su opinión durante el proceso de desarrollo. Luego, las tareas de desarrollo en este período se dividen en múltiples ciclos de iteración según condiciones como la dificultad, la dependencia y la importancia del desarrollo.
En los principios del desarrollo ágil de software Scrum, cada tarea de iteración debe dividirse en múltiples listas de tareas de desarrollo, las tareas de redesarrollo deben asignarse a los miembros del equipo y el tiempo de desarrollo debe controlarse dentro de las 15 horas laborales. Si el tiempo de desarrollo excede las 15 horas laborales, considere volver a refinar las tareas de desarrollo. Las sugerencias de tareas de desarrollo deben ser elegidas por los miembros del equipo en lugar de ser asignadas.
(5) ?Resultados del proyecto de prueba
Cada paquete de trabajo debe implementar trabajos de prueba simultáneamente para mejorar la calidad del proyecto. Los evaluadores deben registrar por escrito los paquetes de trabajo con errores y los errores deben mostrarse a los desarrolladores para que puedan realizar modificaciones oportunas.
2.? Administrar el equipo de desarrollo
(1) ?Construir un equipo
Establezca un equipo basado en los requisitos previos de las tareas de trabajo y el tiempo del proyecto, y asigne personal de acuerdo con las responsabilidades del equipo. Generalmente se debe controlar el número de miembros del equipo entre 8 y 12. Cuando el número de personas en el equipo supera las 15, considere dividir el equipo en dos equipos independientes, cada uno responsable de diferentes tareas de desarrollo.
(2) ?Asignar tareas de desarrollo
En cada ciclo de iteración (generalmente de 15 a 30 días hábiles), cada paquete de trabajo debe subdividirse en múltiples tareas de desarrollo, asignar tareas de redesarrollo a miembros del equipo y controlar el tiempo de desarrollo dentro de las 15 horas hábiles. Si el tiempo de desarrollo de una tarea de desarrollo excede las 15 horas hábiles, considere volver a refinar la tarea. Las tareas de desarrollo deben asignarse a cada miembro del equipo de forma libremente elegida.
(3) ?Supervisar el progreso del desarrollo
Convocar una reunión en la etapa inicial de la iteración para permitir que los miembros del equipo comprendan el progreso y el proceso del desarrollo, y asignar tareas de desarrollo de acuerdo con sus necesidades. propia elección. Durante este período, se pueden utilizar herramientas como Microsoft Project para registrar el progreso del proceso de desarrollo. Después de desarrollar cada paquete de trabajo, se debe probar funcionalmente y los resultados de la prueba se deben registrar por escrito.
Celebre una reunión permanente de 15 minutos todos los días para permitir que los miembros del equipo expliquen las tareas de desarrollo completadas ayer, las tareas que se realizarán ese día y los problemas encontrados durante el proceso de desarrollo. Y cada fin de semana se lleva a cabo una reunión ordinaria para explicar el proceso general.
Al final de la iteración, realice una reunión de sprint para resumir el progreso del proyecto, completar tareas, revisar los problemas encontrados durante la iteración y prepararse para la siguiente iteración.
(4) ?Prueba del sistema
Pruebe cada paquete de trabajo completado de manera oportuna para garantizar la calidad y el rendimiento del sistema. Registre los resultados de las pruebas por escrito, vincule los resultados de las pruebas con los ingresos salariales por desempeño y utilice datos reales para calcular los ingresos por desempeño de los miembros del equipo.
(5) ?Resolver problemas encontrados durante el desarrollo
Realizar capacitación preliminar para desarrolladores, asignar tareas de acuerdo con la capacidad laboral y guiar el desarrollo de los miembros del equipo. Cualquier problema encontrado debe plantearse inmediatamente en la reunión ejecutiva del día y los problemas encontrados deben resolverse dentro de las 15 horas hábiles para evitar una mayor expansión del problema.
3.? Supervisar la calidad del producto
(1) ?La calidad requiere planificación y diseño, no revisión. Durante las etapas iniciales del establecimiento del producto, es necesario definir políticas y estándares de calidad apropiados en documentación formal en consulta con el departamento de Garantía de Calidad (QA).
(2) ?Durante el proceso de desarrollo, adopte el modelo TDD (desarrollo basado en pruebas) para mejorar la calidad del desarrollo.
Los evaluadores deben registrar los errores en forma de texto y trabajar con los desarrolladores para demostrar los defectos sobresalientes y mejorar la eficiencia de las modificaciones.
(3) Al final de cada iteración, realice una demostración del efecto del producto y recopile comentarios de clientes, usuarios y líderes senior. Celebre reuniones de revisión dentro del equipo para analizar los resultados de las pruebas, comprender el rendimiento del producto y hacer planes para las mejoras necesarias para la próxima iteración.
4.? Modificar el plan del proyecto
(1) ?Durante la etapa de identificación del producto, se deben documentar las funciones del producto y los procesos de desarrollo. Cuando sea necesario modificar el plan de desarrollo, se debe discutir con el cliente para informarle el impacto de la modificación del plan en el progreso del proyecto.
(2)? Las modificaciones al plan del proyecto deben ser propuestas por la persona a cargo unificada y aprobadas por el líder del equipo de revisión de requisitos del usuario. Los cambios en los requisitos deben plantearse periódicamente, no en cualquier momento.
(3) ?Realizar registros escritos detallados de los cambios planificados para que los clientes puedan comprender la situación real de los cambios en la demanda y los costos incurridos por los desarrolladores.
Siete. Entrega del producto
1.? Auditoría posterior al evento del proyecto
Una vez que finalmente se completa el desarrollo del proyecto, se puede considerar que libera la carga de trabajo para los desarrolladores, pero a menudo es un momento crítico para los gerentes de proyectos. La evaluación temprana de riesgos, el presupuesto de costos, el análisis de la demanda y el diseño del software guiarán el proyecto hasta este momento, cuando todas las miradas estarán puestas en los gerentes del proyecto. Es posible que descubra que muchas tareas menores se pueden completar en unas pocas horas. En este momento, el director del proyecto debe permanecer despierto y tranquilo, y tratar el trabajo final como un microproyecto. Revise cuidadosamente el proyecto en la etapa posterior, analice los resultados del proyecto, la eficiencia del equipo del proyecto y el valor de los productos entregables, y utilice los resultados de la revisión como parte del resumen de la experiencia de gestión de proyectos.
2.? Evaluación de calidad
Antes de la entrega del proyecto, el proyecto debe enviarse al departamento de "Garantía de calidad" (QA) correspondiente para una revisión de calidad, y se debe invitar a los usuarios típicos a experimentar la calidad del producto.
3.? Entrega final del proyecto
En circunstancias normales, el acuerdo de entrega del proyecto se concluirá en la etapa inicial del proyecto y los métodos de entrega del proyecto se dividen en aceptación informal y aceptación formal. Generalmente, una vez completado el proyecto, primero se llevará a cabo una aceptación informal para permitir que el cliente experimente la calidad del proyecto y dé su opinión. Finalmente, la aceptación formal del producto se llevará a cabo mediante un acuerdo escrito después de que el cliente confirme la calidad del producto.
4.? Informe Final del Proyecto
Al finalizar el proyecto se debe realizar un informe final del proyecto, que puede considerarse un registro del proyecto, pero el informe no tiene por qué incluir todos los aspectos del mismo. el proyecto. Generalmente, el informe final debe incluir los siguientes aspectos:
(1) ?Vista inicial del proyecto cuando se presenta el proyecto por primera vez.
(2) ?Evaluación del valor del proyecto e información de respaldo
(3) ?Alcance del proyecto
(4) ?Proceso de desarrollo del proyecto y WBS
(5) ?Actas de la reunión del proyecto
(6) ?Informe de cambio del proyecto y motivos del cambio.
(7) ?Documentos del proceso de comunicación relacionados con el proyecto
(8) ?Informe de auditoría del proyecto e informe de aceptación del cliente
(9) ?Desempeño de los miembros del proyecto Informe
(10) Resultados finales del proyecto