201771010128-Wang Yulan experimento cuatro análisis de caso de proyecto de software

Proyecto	Contenido
Curso Clase Blog Link	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/
Este enlace de solicitud de trabajo	https://www.cnblogs.com/nwnu-daizh/p/12616341.html
Mis objetivos de aprendizaje del curso	Mejore aún más el sistema de notificación de situaciones epidémicas y aprenda a operar Githup
¿De qué manera esta tarea me ayuda a alcanzar mis objetivos de aprendizaje?	Durante el proceso de emparejamiento, la parte de cooperación debe desarrollarse
Nombre de identificación del estudiante	201771010127 — Wang Yan
Enlace a la otra parte a este enlace de asignación de blog	https://www.cnblogs.com/JAVA-729/p/12624399.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: Tres casos pendientes de experimento: Wang Huihe

https://www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html
(1) Lea y comente las asignaciones de blog de casos.

(2) 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, resuma los problemas en la operación del código y experimente si la publicación del blog del caso es útil para la comprensión del código del proyecto.

La persona a cargo del departamento de prevención de epidemias de segundo nivel puede ingresar a sus respectivas universidades para filtrar y ver:

consulta por nombre Situación personal:

consulta por área: consulta

por presencia o ausencia de infección:

visualización de iconos, puede generar gráficos correspondientes en función de los campos que aparecen:

universidad, gráfico circular y Visualización del histograma: relación

profesor-alumno:

ubicación:

situación de infección:

llenado de información:

recordatorio regular:

visualización de datos:

Después de leer las especificaciones de código de la parte del caso, una breve introducción a cada módulo, enumerando los códigos clave involucrados y algunos métodos utilizados, y también resumiendo el estilo de nomenclatura, la definición constante y las disposiciones de formato de código en la especificación de código, ayuda Le prestamos atención durante la programación; después de clonar el código fuente de githup, se ejecuta en su propia computadora. Durante la primera prueba, simplemente volvió a importar los paquetes utilizados en el proyecto y completó la operación con éxito. Al leer el código, el código se escribió de acuerdo con el código Los requisitos en la especificación, debido a que hay comentarios correspondientes, el código también es fácil de entender; luego busque las instrucciones correspondientes en el blog de la parte del caso, y es más fácil comprender la implementación correspondiente de la función en este proyecto, y también experimentar el desarrollo de este La diferencia entre la idea del sistema y la idea de nuestro equipo de desarrollar este sistema, por ejemplo, la función de recordatorio de tiempo que implementan es a través del correo electrónico. En resumen, a través de la comparación, he aprendido mucho.

(3) Resuma los problemas y deficiencias de la operación del blog y el diseño del código en el tercer experimento de este grupo, enumere los errores en el código, las funciones no implementadas, etc.
Enlace del blog de asignación de casos: https://www.cnblogs.com/http-www-whh0601-cnblogs-com/p/12553743.html
enlace del almacén del proyecto de asignación de casos: https://github.com/yy202901582/DieaseSubmitSystem

Resumen de la función del software: el sistema de informe de la situación de la epidemia desarrollado por la parte del caso realiza el informe diario de la situación de la epidemia por parte de los estudiantes o maestros, y la persona a cargo de la prevención y el control de la epidemia de cada departamento secundario puede ver el resumen de la situación de la epidemia del personal de este departamento, realizar el gráfico estadístico visualizado, por nombre Puede verificar la situación específica y las funciones adicionales para completar el informe regularmente de acuerdo con la ubicación; en el módulo para completar la información básica, aparte del nombre que se debe completar, las otras opciones son usar el cuadro desplegable para elegir un nuevo estilo. Este diseño ahorra el tiempo de la persona que completa el informe. Sin embargo, no hay un número de estudiante al completar el informe. Debido a que hay el mismo nombre y apellido en la escuela, es más preciso identificar de forma única a un estudiante o maestro por el número de estudiante o número de trabajo; en el gráfico estadístico, se utilizan una variedad de métodos, como el gráfico circular y la columna. La imagen es muy completa y el diseño de la función del recordatorio regular también es muy bueno, pero hay un error que, una vez que el periodista cierra la ventana, habrá múltiples recordatorios. En este diseño, quiero que un recordatorio de confirmación sea más perfecto; La función no implementada es el archivo EXCEL que se puede [exportar] para consultar la lista.

No hay ningún número de estudiante o número de trabajo al completar el informe, y es imposible confirmar con precisión cuál es porque hay personas con el mismo nombre y apellido, y no es fácil distinguir por nombre.

Se mostrarán varios recordatorios al completar el informe. Después de recibir el recordatorio, la persona que lo completó no puede hacer clic para confirmarlo.

Tarea 2: colabore con los tres socios del experimento para aprender: lea los capítulos 5-6 de "Ingeniería de software moderna: el método de construcción", comprenda y domine las características del equipo de proyecto de software, comprenda el modelo del equipo de software y comprenda la cascada con el contenido teórico Los modelos y sus transformaciones, procesos de entrega progresiva, procesos ágiles y otras características típicas del modelo de proceso de software, entienden y aprecian los principios TSP resumidos por la Escuela de Ingeniería de Software de la Universidad Carnegie Mellon (CMU);

Características del equipo de software.

Los equipos tienen un objetivo colectivo constante: los miembros del equipo deben completar el objetivo juntos y los miembros de un equipo no tienen que trabajar juntos.
Los miembros del equipo tienen su propia división del trabajo, dependen unos de otros y cooperan para completar las tareas.

Modelo de equipo de software

Modo de nido de abeja: el modo de equipo formado en base a la intuición es un modo feliz y casual.
Modelo de médico tratante: cada uno realiza sus propios deberes y atiende al médico tratante. El programador jefe es responsable del diseño y la codificación de los módulos principales, y otros miembros apoyan su trabajo desde todos los ángulos.
Modo estrella: el punto extremo del modo médico tratante. Una comprensión simple es el mejor interés del programador jefe, y todo el trabajo lo realiza una sola persona.
Modelo comunitario: todos participan en la dirección que les interesa. La ventaja de este modelo es que "todas las personas recogen leña con altas llamas". Si todos ejercen sus propias ventajas, obtendrán muy buenos resultados.
Modo de compañía de teatro amateur: cada equipo elegirá diferentes roles en diferentes proyectos, y todos pueden discutir por igual.
Equipo secreto: los proyectos de software se llevan a cabo en condiciones secretas, y otros no saben lo que hacen. La ventaja de este modelo es que el equipo tiene una gran libertad, un gran entusiasmo y ninguna interferencia externa.
Equipo de agentes especiales: profesionales con habilidades especiales, responsables de resolver algunos problemas difíciles y apremiantes.
Modo Orquesta Sinfónica: El modo de actuación de la orquesta sinfónica. Cuando un software se encuentra en una etapa de crecimiento estable, el equipo de desarrollo adoptará este modelo.
Modo Jazz: opuesto al modo banda sinfónica.
Modo de equipo funcional: las personas con diferentes habilidades cooperan por igual y completan una función juntos.
Modelo burocrático: varias personas se reportan a un líder pequeño, y varios líderes pequeños se reportan a un líder medio, uno tras otro.

Modelo de cascada y su deformación

Modelo en cascada: el modelo en cascada es un modelo que estipula las actividades en el ciclo de vida del software como varias etapas conectadas en una secuencia lineal, que incluye análisis de requisitos, diseño, codificación, prueba, operación y mantenimiento. Estipula una secuencia fija de adelante hacia atrás, que está conectada entre sí, como una cascada que cae en pasos:

(1) Limitaciones del modelo de cascada

Los pasos están separados, pero los pasos en el proceso de generación de software no pueden separarse tan estrictamente;
La modificación retrospectiva es difícil o imposible, pero el proceso de producción de software requiere tiempo para retrospectiva;
El producto final aparece solo al final, pero los clientes de software e incluso los ingenieros de software necesitan conocer el prototipo del producto y probarlo lo antes posible.

(2) Ámbito de aplicación del modelo de cascada.

Si la definición del producto es muy estable, pero la corrección del producto es muy importante, debe verificarse en cada paso;
La interfaz entre módulos de producto, entrada y salida puede definirse y verificarse bien por métodos formales;
La tecnología utilizada es muy madura, y los miembros del equipo están familiarizados con estas tecnologías;
Los sub-equipos responsables de cada paso pertenecen a diferentes instituciones, o en diferentes ubicaciones geográficas, y es imposible comunicarse con frecuencia.
Variaciones del modelo en cascada
(1) Modelo Sashimi

Este modelo resuelve las deficiencias de la separación entre los distintos pasos, pero también genera cierta confusión ¿Cuándo terminará la etapa anterior?
(2) Cascada grande con cascada pequeña
Para resolver el problema de que el progreso entre diferentes subsistemas no es fácil, los requisitos técnicos son muy diferentes y deben tratarse de manera diferente, se introduce el modelo de sub-cascada

Proceso de entrega progresivo

Steve Mike Cornell resumió el proceso de entrega progresiva en 1996, pero en realidad está muy cerca del proceso de desarrollo iterativo del que todos hablan ahora. Cuando los requisitos principales y la arquitectura del sistema son claros, el equipo de software ha entrado en un ciclo evolutivo:

MVP: producto mínimo viable, el producto viable más pequeño, también conocido como el conjunto de características mínimas, el conjunto de características más pequeño.
El método específico es realizar (o representar) las funciones centrales del producto con un costo mínimo, y luego solicitar rápidamente opiniones de los usuarios.
MBP: MVP también tiene su ámbito de aplicación. En consecuencia, es la idea de Maximal Beautiful Product (el producto más poderoso y hermoso, MBP). Si comprende las necesidades de los usuarios, o el equipo del producto entiende las necesidades de los usuarios mejor que los usuarios. ¿Por qué no mostrar la forma más completa y hermosa de productos y conquistar a los usuarios de una sola vez? Puede revisar la primera versión de iPhone (2007) y iPad (2010), ¿son MVP? Obviamente no. ¿Cómo se puede lograr MBP? Esto tiene requisitos más altos para el equipo del producto.

Proceso ágil

En el contexto de la ingeniería de software, los procesos ágiles son una colección de valores y metodologías.
Diagrama de flujo ágil:

pasos ágiles:
Paso 1: descubra lo que se debe hacer para completar la cartera de productos y productos.
El trabajo atrasado se traduce como "trabajo atrasado", "problema a resolver", "pedido de producto", todo. La persona a cargo del producto lleva a todos a analizar, refinar, aclarar la relación entre los elementos de este Backlog y estimar la carga de trabajo. La unidad de tiempo estimada para cada trabajo es "días".
Paso 2: Decide qué se debe resolver en el sprint actual (Sprint Backlog).
En unidades de horas, si el tiempo estimado para una tarea es demasiado largo (por ejemplo, más de 16 horas), entonces debe descomponerse aún más. La tarea en la orden es que los miembros del equipo reclamen de acuerdo con su propia situación. Si los miembros del equipo pueden liderar la estimación y asignación de tareas, su iniciativa se ejercerá en gran medida.
Paso 3: Sprint.
Durante el sprint, el equipo lleva a cabo una comunicación cara a cara a través de ScrumMeeting diario, y las reuniones diarias obligan a todos a informar el progreso a sus compañeros, lo que obliga a todos a poner el problema en el lado positivo. Al mismo tiempo, el equipo debe comenzar la compilación diaria, para que todos puedan ver una versión mejorada gradualmente todos los días.

Comprender y apreciar los principios TSP resumidos por la Escuela de Ingeniería de Software de la Universidad Carnegie Mellon (CMU)

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.
Intente utilizar tecnologías y prácticas maduras.
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.
Haga planes y compromisos realistas: el plan del equipo debe ser realizado por la persona responsable de la ejecución específica (no del superior).
Aumentar las capacidades de autogestión del equipo.
Concéntrese en mejorar la calidad y esforzarse 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).
Si bien estos principios son abstractos, cuando cada equipo está haciendo Postmortem (Postmortem se refiere a la revisión del producto después del final del proyecto de software y el análisis del proceso de desarrollo), puede verificarlo y ver qué ha hecho su equipo en la vida pasada del software. ¿Cuánto ha mejorado durante el ciclo?
Chatear con amigos

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 tres socios del experimento para elegir un caso de proyecto de equipo de alta calidad para el aprendizaje colaborativo. Tarea, descargar el código del software del proyecto.

Caso 2019 Spring School of Computer Software Engineering (Universidad de Aeronáutica y Astronáutica de Beijing): https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_LJ/homework/2685
1. Enlace para la cuenta del lanzamiento del trabajo en equipo del proyecto: https: //www.cnblogs. com / PureMan6 / p / 11038754.html
2. Enlace github del repositorio del proyecto del equipo: https://github.com/swearitagain/EduCnblogs2.0
3. Exponga sus razones para elegir este proyecto de equipo para el análisis

Después de examinar todos los proyectos del equipo, finalmente elegí este, porque nuestro curso este semestre es usar el blog park para completar el estudio de ingeniería de software. Esta aplicación de blog park nos brinda conveniencia; y hay un punto más Estudié el desarrollo de Android el semestre pasado, y el requisito final para desarrollar un juego también es ejecutarlo en el terminal móvil. Es precisamente esta aplicación la que también es el terminal móvil. Puedes revisar el aprendizaje anterior. Además, quieres experimentar la aplicación móvil de blog park. Qué funciones, cómo se dio cuenta el otro equipo y finalmente aprendió de ellos para ganar experiencia.

4. Combine los documentos del blog de la serie del proyecto para resumir la división del trabajo y la cooperación de los miembros del equipo del proyecto;
Shao Xuzhe: PM, principal responsable de toda la escritura del blog;
Jiang Feng, Chen Zhiqi, Hu Junsong: desarrolladores;
Wu Feng: probadores;
Wu Hao: desarrollo (las tareas no son Muchos otros desarrolladores), responsables de las reuniones.
Durante el progreso del proyecto, hay diferentes divisiones de trabajo en diferentes etapas:

5. Combine la serie de documentos de blog del proyecto para evaluar las características del proceso del proyecto de software (TSP) del proyecto (5 puntos);
(1) Durante la implementación del proyecto de software, un Al principio, estaba claro qué era el proyecto y qué funciones necesitaba lograr;
(2) El equipo hizo un plan detallado basado en el papel de la implementación específica, y los miembros del equipo fueron muy claros acerca de los objetivos y productos del proyecto;
(3) Además Desarrolló un plan de proyecto y un sistema de recompensa y castigo, que ayuda a aumentar la capacidad de autogestión del equipo;
(4) Al mismo tiempo, cada miembro del equipo debe probar la tarea que ha completado antes de entregársela al siguiente miembro del equipo para que continúe trabajando, de modo que pueda Identifique el problema temprano y corríjalo de manera oportuna. No hará que haga lo suyo. Finalmente, encontrará el problema y lo compensará. Las características del proceso de un proyecto de software de este tipo cumplen los requisitos de la especificación y son muy razonables, que es lo que debemos aprender cuando llevamos a cabo un proyecto de equipo 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? (5 puntos);

no incluye el documento de especificación del código
7. 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 muéstrelos en el blog Captura de pantalla
Después de iniciar sesión, hay tres módulos: "Mi blog, mi clase y yo".
Haga clic en "Mi blog" para ver la lista de blogs personales. Haga clic en cualquier trabajo para reenviar, marcar y comentar.

Haga clic en "Mi clase" para ver anuncios y tareas , Publicaciones de blog y votos

Haga clic en "I" para ver información básica personal, hay algunas operaciones que

pueden configurar recordatorio de programación, modo oscuro, etc.

Error existente1, al iniciar sesión en el jardín del blog, haga clic en "Recordarme". Cuando vuelva a iniciar sesión después de cerrar sesión, debe volver a ingresar su número de cuenta y contraseña, que no funciona como "recordarme".

Hay un error2, después de iniciar sesión, aparecerá el mensaje "Identidad caducada, vuelva a iniciar sesión", pero este acaba de iniciar sesión y el período de validez es corto.

Hay un error 3, el sistema mostrará automáticamente "algunas páginas no son compatibles" al configurar el modo oscuro

8. Evalúe si el proyecto del equipo vale la pena continuar con el desarrollo y explique el motivo.

Creo que vale la pena continuar desarrollando, porque para nosotros, usar la aplicación es muy conveniente para comprender la información relevante del jardín de blogs. Aunque Baidu también puede iniciar sesión en el jardín de blogs en comparación con el lado de la computadora, la interfaz del jardín de blogs en el terminal móvil es pequeña, lo que muestra el blog. Toda la información en el parque tomará mucho tiempo para leer y consultar, lo cual es problemático. Con este apéndice, podemos verificar la información relevante publicada por el profesor del blog garden en cualquier momento, lo cual es muy conveniente de usar. Además, hay un recordatorio de programación en esta aplicación, siempre que las configuraciones relevantes estén establecidas, ya no tendremos que preocuparnos por olvidarnos de entregar nuestra tarea. Es demasiado práctico para nosotros cambiar la función del proyecto del equipo, siempre que perfeccionemos los errores existentes, será más perfecto.

Tarea 4 "Experimento 4 Análisis de caso de proyecto de software" Tiempo real dedicado a cada tarea

Tarea	Mucho tiempo
Tarea 1	1h
Tarea 2	2h
Tarea 3	2h
Tarea 4	0.2h

Resumen:

Al leer el blog de la parte del caso y ejecutar el sistema de informes de brotes de casos, experimenté el sistema de informes de brotes de las partes del caso. En comparación con el sistema desarrollado por nuestro equipo, me sentí muy conmovido. La tarea dos discutió el desarrollo de software de aprendizaje a través de la asociación con socios Los diferentes procesos de desarrollo, tales como: modelo en cascada, entrega progresiva y proceso ágil, proceso de proyecto de software de equipo de software (TSP), requisitos de colaboración de miembros del equipo y otros puntos de conocimiento, siento que este tipo de comunicación entiendo algunos conceptos que no entiendo Tiene un gran efecto y alta eficiencia, la tarea tres es lo que finalmente decidimos hacer en base a la premisa del estudio de desarrollo de Android el semestre pasado después de nuestra discusión. Es muy conveniente para nosotros descargar y experimentar la aplicación a través del terminal móvil.