201771010105: estudio de caso del proyecto de software Daragrass experiment 4

Proyecto	Contenido
Curso Clase Blog Connection	https://www.cnblogs.com/nwnu-daizh/
Este enlace de solicitud de trabajo	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
Mis objetivos de aprendizaje del curso	(1) Proceso de proyecto de software (TSP) del equipo de aprendizaje, requisitos de colaboración de los miembros del equipo. (2) Dominar los principios de los procesos ágiles y los conceptos relacionados.
¿De qué manera esta tarea me ayuda a alcanzar mis objetivos de aprendizaje?	Permítanme entender el proceso relevante y las características del proyecto del equipo.
Nombre de identificación del estudiante	201771010104-Di Hui
Conecta a la otra parte con esta conexión de asignación de blog	https://www.cnblogs.com/dhlll/p/12669888.html

1. El propósito y los requisitos del experimento.

(1) Proceso de proyecto de software (TSP) del equipo de aprendizaje, requisitos de colaboración de los miembros del equipo.
(2) Dominar los principios de los procesos ágiles y los conceptos relacionados.

2. Contenido experimental y pasos

Tarea 1. En la tarea con una puntuación de 100 puntos o más en el Experimento 3, elija uno como caso y evalúe los resultados del proyecto del caso

Elija tres casos excelentes de experimento: Wang Zhitai y Han Lamei Group Enlace
del blog de asignación de casos: https://www.cnblogs.com/hanlamei/p/12574378.html
enlace del almacén del proyecto de asignación de casos: https://github.com/YHwzt/Query -sistema-web

Comentarios en publicaciones de blog:
Clone el código fuente del proyecto del caso en la máquina local, lea el documento de especificación del código del proyecto y ejecute el código
- Clone el código fuente del proyecto en la máquina local:
- Código de operación:
  interfaz de registro : interfaz de
  
  inicio de sesión : inicie sesión
  
  como estudiante y miembro de la facultad para completar la información:
  
  inicie sesión como una academia para ver información sobre epidemias:
  
  inicie sesión como una escuela para ver, eliminar y exportar información:
El resumen del caso y las deficiencias y problemas del diseño del código:
la función del código:
- Función de registro e inicio de sesión de tres niveles, y limite el uso de funciones para cada nivel de usuarios.
- Los estudiantes y miembros de la facultad que hayan iniciado sesión en el nivel 1 pueden completar la información.
- El inicio de sesión de segundo nivel puede iniciar sesión como una universidad para ver la información de la epidemia.
- El inicio de sesión de tres niveles puede iniciar sesión como escuela para ver, eliminar, agregar, exportar y otras funciones.
- Hay funciones adicionales para recordar a los usuarios que completen información sobre epidemias.
  Mediante el funcionamiento del código y el uso del sistema, se descubre que la función de este sistema es básicamente integral y, a través del estudio de los proyectos de su grupo, reconocí claramente nuestra brecha. En el último experimento, nuestro grupo no se dio cuenta de la visualización de información y la exportación de Excel, pero no solo se dieron cuenta sino que también realizaron funciones adicionales, por lo que vale la pena aprender.
- Pregunta: Puede eliminar líneas de código innecesarias para hacerlo más conciso.

Tarea dos: colaborar con los socios en el experimento tres para aprender: lea los capítulos 5-6 de "Ingeniería moderna del software: el método de construcción" para comprender y dominar las características de los equipos de proyectos de software, comprender el modelo de los equipos de software y comprender las cascadas junto con las lecciones teóricas Los modelos y sus transformaciones, procesos de entrega progresiva, procesos ágiles y otras características típicas del modelo de proceso de software, comprenden y aprecian los principios de TSP resumidos por la Escuela de Ingeniería de Software de la Universidad Carnegie Mellon (CMU);

Las características del equipo:
- El equipo tiene un objetivo colectivo constante, y es necesario lograrlo juntos, pero los miembros de un equipo no tienen que trabajar al mismo tiempo.
- Los miembros del equipo tienen su propia división del trabajo, se comunican y cooperan entre sí, y completan tareas juntos.
Modo de equipo:
- Hay un programador jefe en un equipo de software como el Equipo Programador Jefe , que es responsable del diseño y la codificación de los módulos principales, y otros miembros son responsables de sus funciones y apoyan su trabajo desde varios ángulos.
- Modelo de super estrella (modelo de super estrella)
  Este modelo es el modelo de supervisión utilizado por el modelo del médico tratante, donde la luz de la estrella eclipsa la suma del resto del equipo.
- La comunidad del modelo comunitario (Modelo comunitario)
  generalmente tiene muchos voluntarios que participan, y todos participan en proyectos en los que están interesados y contribuyen. Comunidad no significa que los proyectos comunitarios aleatorios y exitosos tengan una estricta revisión de código y control de calidad.
- Equipo de teatro aficionado (Equipo de teatro aficionado)
  En dicho equipo, cada persona elegirá un rol diferente, estas personas pueden cambiar un tipo de rol completamente diferente en el próximo proyecto. Todos siguen la disposición de un comando central en el equipo e intercambian y aprenden unos de otros, pero no habrá una atmósfera democrática perfecta en un equipo más competitivo.
- La ventaja de este desarrollo secreto del estado del equipo secreto (Skunk Work Team) es que hay una gran libertad dentro del equipo sin interferencia del mundo exterior (presentar proyectos, seguir instrucciones, etc.). Generalmente, dicho equipo tiene una misión única y mucha libertad. , Por lo tanto, a menudo puede usar una eficiencia súper alta para completar tareas aparentemente imposibles
- Un equipo
  como el equipo SWAT está formado por profesionales con habilidades especiales que son responsables de resolver problemas difíciles y apremiantes, como el equipo del servicio de seguridad.
- Modo de orquesta (Orchestra)
  Cuando un software se encuentra en una etapa de crecimiento constante, muchos equipos de desarrollo usarán este modo, los miembros de este modo son responsables de sus funciones, y las partes responsables son diferentes, y cada miembro está dedicado Enfrentando problemas similares, todos son muy profesionales y el comando controla la situación general.
- En comparación con la orquesta sinfónica, la banda de jazz (Jazz Band) tiene miembros cuyas responsabilidades no son fijas, no abordan específicamente problemas similares, no tienen un director unificado e improvisan de forma independiente. Este modelo enfatiza la expresión personalizada y la interacción fuerte.
- Modelo de equipo de características (Equipo de características)
  Muchos equipos de desarrollo usan este modelo, cada equipo tiene capacidades diferentes y sus colegas en diferentes partes trabajan juntos en una base igual para completar una función. Después de completar esta función, estas personas se reorganizan para completar la siguiente función junto con otros roles. No hay gestión y relación de gestión entre ellos. La comunicación dentro del grupo es relativamente frecuente.
- Modelo burocrático (Modelo burocrático)
  Este modelo aparece en la estructura organizativa de grandes instituciones: varias personas se reportan a un jefe pequeño y varios jefes pequeños se reportan al siguiente nivel. Los miembros de este modelo no solo tienen cooperación técnica, sino también relaciones de liderazgo organizacional, porque diferentes equipos son difíciles de evaluar el desempeño, lo que resulta en muchos cálculos innecesarios.
Modelo de cascada:
este modelo se toma prestado de otras industrias maduras, como la ingeniería de construcción. Una vez que los productos de estas industrias "duras" se producen en masa, es muy difícil volver a modificarlos. Este modelo describe esto unidireccional 3. Proceso de producción irreversible.

Winston también propuso métodos mejorados para las deficiencias de este modelo:
- Winston señaló que cuando se hace un sistema a gran escala, es necesario rastrear los pasos adyacentes para resolver los problemas que no se resolvieron en la etapa anterior.
- Winston señaló que para que el producto sea exitoso, es mejor recorrer el modelo dos veces, primero tener una versión simulada, recopilar comentarios sobre esta base, mejorar varios pasos y entregar una versión final.
Las limitaciones del modelo de cascada:
- Los pasos en el proceso de producción de software están separados.
- La modificación de retroceso es difícil o imposible, pero se requiere retroceso en el desarrollo real.
- El producto final no apareció hasta el final, pero los clientes de software e incluso los propios ingenieros de software necesitaban conocer el prototipo del producto y probarlo lo antes posible.
Deformación del modelo de cascada:
- Modelo de sashimi: los módulos adyacentes de este modelo se superponen parcialmente como el sashimi, resolviendo las deficiencias de separación entre los pasos
- Modelo de subcaídas: resuelve el problema de diferentes progresos entre subsistemas, diferentes requisitos técnicos y la necesidad de ser tratado de manera diferente
Proceso de entrega progresiva (entrega de evolución),
entrega progresiva de MVP y MBP Este modelo está más cerca del proceso de desarrollo iterativo. Cuando los requisitos y la arquitectura son básicamente claros, el equipo de software ha entrado en un ciclo en evolución.
- El núcleo del proceso MVP (producto mínimo viable) es implementar las funciones centrales del producto a un costo mínimo, y luego solicitar rápidamente opiniones de los usuarios, para que la primera versión no se alargue durante mucho tiempo. . La idea de MVP es similar a la entrega progresiva, pero enfatiza los comentarios de los usuarios.
- MBP (Maximal Beautiful Product) es un modelo opuesto al MVP, muestra la forma más completa y hermosa del producto y conquista a los usuarios de una sola vez.
Proceso ágil:
"Proceso ágil" es una colección de valores y metodologías.
Principios de desarrollo ágil:
- Entregue continuamente software valioso para satisfacer las necesidades del cliente;
- Los procesos ágiles agradecen los cambios en la demanda y los utilizan para mejorar la ventaja competitiva de los usuarios;
- Libere regularmente el software disponible, el intervalo de liberación puede ser de unas pocas semanas a varios meses, puede ser lo más corto posible;
- El personal comercial y los desarrolladores deben trabajar juntos diariamente durante el proceso de desarrollo del proyecto;
- Con personas ambiciosas como núcleo del proyecto, apóyelas plenamente y confía en ellas;
- No importa dentro o fuera del equipo, la comunicación cara a cara es siempre la forma más efectiva de comunicación;
- El software disponible es el indicador principal para medir el progreso del proyecto;
- Los procesos ágiles deberían mantener un desarrollo sostenible. Los líderes, los equipos y los usuarios deberían poder seguir cooperando al ritmo actual;
- Solo al centrarnos constantemente en la tecnología y el diseño podemos ser cada vez más ágiles;
- Es muy importante mantener una habilidad concisa para simplificar la carga de trabajo tanto como sea posible;
- Solo un equipo autogestionado puede crear una arquitectura, requisitos y diseño excelentes;
- Siempre resuma cómo mejorar la eficiencia del equipo y ponerlo en práctica.
Principio de TSP: los
modelos y procesos excelentes tienen algunos puntos comunes, que se resumen en los principios de TSP (proceso de software de equipo):
- Utilice procesos bien definidos, donde cada paso del proceso es repetible y medible
- Cada miembro del equipo tiene una comprensión unificada de los objetivos, roles y productos del equipo.
- Intenta utilizar tecnologías y prácticas maduras
- Recopile tantos datos como sea posible y úselos para ayudar al equipo a tomar decisiones racionales
- Haga planes y compromisos realistas. El plan del equipo debe estar determinado por el rol específico de ejecución (no del superior)
- Aumentar la capacidad de autogestión del equipo.
- Concéntrese en mejorar la calidad, luche por encontrar problemas al inicio del ciclo de vida del software y realice un trabajo de diseño exhaustivo y meticuloso
Captura de pantalla de la comunicación con el socio:

Tarea 3: En el parque de blogs de la clase, hay muchos cursos de ingeniería de software en colegios y universidades que requieren que los estudiantes completen proyectos de equipo. Consulte con los socios de emparejamiento experimentales para seleccionar un caso de proyecto de equipo de alta calidad en las siguientes tres clases para el aprendizaje colaborativo. Rastree todas las tareas de blog publicadas por el proyecto del equipo y descargue el código del software del proyecto.

1. Enlace de la cuenta de liberación del trabajo del proyecto del equipo: https://www.cnblogs.com/PureMan6
2. Repositorio del proyecto del equipo Enlace de GitHub: https://github.com/swearitagain/EduCnblogs2.0
3. Exponga sus razones para elegir este proyecto de equipo para el análisis:
- En este estudio, puede tener la oportunidad de ver los proyectos realizados por estudiantes de otras escuelas.
- La aplicación del parque de blogs realizada por este proyecto, que hemos estado usando todo el tiempo, no hay contacto con el desarrollo de la aplicación antes, así que estoy más interesado.
4. Combine los documentos del blog de la serie del proyecto para resumir la división y la cooperación de los miembros del equipo del proyecto.

Miembro del equipo	División del trabajo
Wu Hao	El desarrollador, Scrum Master, es responsable de organizar la reunión regular diaria
Shao Xuzhe	PM, responsable de redacción de blog
Hu Junsong	Desarrollador
Jiang Feng	Desarrollador
Chen Zhiqi	Desarrollador
Wu Feng	Probador

5. Combine la serie de proyectos de documentos de blog para evaluar las características del proceso del proyecto de software (TSP) del
proyecto:
- Usando procesos bien definidos, cada paso del proceso es repetible y los resultados pueden medirse.
- Cada miembro del equipo tiene una comprensión unificada de los objetivos, roles y productos del equipo.
- La capacidad de autogestión del equipo es muy fuerte, básicamente cada etapa tiene reuniones regulares para comunicarse.
- Recopile la mayor cantidad de datos posible (incluidos los datos que son malos para el equipo) y utilícelos para ayudar al equipo a tomar decisiones racionales.
- Esfuércese por descubrir problemas temprano en el ciclo de vida del software. La forma más efectiva de mejorar la calidad es realizar un trabajo de diseño completo y meticuloso (en lugar de apresurarse a solucionar el problema más adelante).
6. Observe la estructura del archivo de código fuente del almacén de github del proyecto de equipo, ¿contiene documentos de especificación de código?

No hay documentación de las especificaciones de codificación del proyecto y las instrucciones de desarrollo en el GitHub del proyecto, por lo que será un poco difícil y problemático para aquellos que se desarrollen más adelante.
Descargue el código del proyecto del equipo, intente implementar el entorno operativo del proyecto y use el software, describa la experiencia de usuario más simple e intuitiva, encuentre al menos dos errores funcionales más serios y muestre capturas de pantalla en el blog.
- De clon a prueba local:
- Descargue la aplicación para obtener experiencia:
  como aplicación para teléfonos móviles, creo que este proyecto es muy bueno, porque me siento muy conveniente de usar, y la interfaz es simple y hermosa, fácil de usar.
  La interfaz de inicio de sesión es la misma que la página web: la
  
  interfaz verificada, la interfaz es simple y hermosa:
  
  varias funciones:
  mi blog:
  
  mi clase:
  
  mi información personal personal:
7. ¿Evaluar si el proyecto del equipo vale la pena continuar con el desarrollo y exponer las razones?
Creo que vale la pena seguir desarrollando el proyecto de este equipo, porque no hay muchas aplicaciones de este tipo en el parque de blogs. Busqué en la tienda de aplicaciones y parece que hay alrededor de 3. Descargué una de ellas y descubrí que hay más empujes de blog que esto. En realidad, personalmente me gusta esto porque tiene un área de blog de clase dedicada, que es muy conveniente de usar. Así que creo que vale la pena seguir desarrollando este proyecto. Sería bueno mejorar estas funciones.

Tarea 4: Registre el tiempo real dedicado a completar las tareas del "Experimento 4 Análisis de casos de proyectos de software"

Tarea	Tiempo gastado (min)
Tarea uno	200
Tarea dos	180
Tarea tres	220
Tarea cuatro	90

Tarea 5: Hable sobre el sentimiento y la experiencia de completar esta tarea.

在这次的实验我测试了上次项目的优秀案例，我还测试了其他高校的软件工程团队的项目。通过这次的实验我了解了软件工程团队项目的流程，有很多值得学习的东西，也认识到了自己与其他人的差距。在任务二的学习过程中与结对同伴一起交流学习了软件项目团队的特点、软件团队的模式、瀑布模型及其变形和TSP原则等。