| Projet | Le contenu |
|---|---|
| Lien vers le blog de la classe de cours | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/ |
| Lien sur les exigences d'affectation | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| Objectifs d'apprentissage de mon cours | Processus de projet logiciel de l'équipe d'apprentissage (TSP), exigences de collaboration des membres de l'équipe. Maîtrisez les principes des processus agiles et des concepts associés. |
| De quelle manière ce travail m'aide-t-il à atteindre mes objectifs d'apprentissage | Améliorez-vous en apprenant les projets de paires d'autres personnes, comprenez le modèle en cascade et comprenez les avantages du développement de paires |
| Le nom de l'autre numéro d'étudiant | Zhao Dong-201771010 |
| Liez l'autre partie à ce lien d'affectation de blog |
1. Objectif expérimental et exigences
(1) Processus de projet logiciel de l'équipe d'apprentissage (TSP), exigences de collaboration des membres de l'équipe.
(2) Maîtriser les principes des processus agiles et des concepts associés.
2. Contenu et étapes de l'expérience
Tâche 1:
sélectionnez l'une des affectations avec un score de 100 points ou plus dans l'expérience 3 pour évaluer les résultats du projet de cas. Les exigences spécifiques sont les suivantes:
(1) Lisez et commentez l'affectation du blog de cas. Les principaux points du commentaire incluent: la relation entre la structure de la publication de blog, le contenu de la publication de blog, la structure de la publication de blog et la colonne "contenu de la tâche" dans la PSP, et publier le contenu de la révision ci-dessus dans la zone de commentaire de blog de l'affectation de cas.
(2) Clonez le code source du projet de cas sur la machine locale, lisez le document de spécification du code de projet et exécutez le code, résumez les problèmes dans l'opération de code et découvrez si le billet de blog de cas est utile pour la compréhension du code de projet.
(3) Résumer les problèmes et les lacunes du fonctionnement du blog et de la conception du code dans la troisième expérience de ce groupe, répertorier les bogues dans le code, les fonctions non implémentées, etc.
1. Lien vers le blog de travail de cas
2. Lien entrepôt de projet de travail de cas
3. Commentaire de blog qui répond aux exigences (1)
4. Capture d'écran du fonctionnement du système qui répond aux exigences (2), résumé des fonctions logicielles
En raison des différents environnements lors de l'importation de projets, vous n'êtes pas familier avec cet outil de développement , Résolution de nombreuses erreurs, mais cette erreur ne peut pas être résolue pour le moment:
je n'ai vu aucun problème avec le code. Le blog de l'auteur aide le code à comprendre. Il existe également des notes clés dans le code source du projet.
5. Pour répondre aux exigences de (3), les captures d'écran des problèmes de fonctionnement du code sont la
deuxième tâche:
Collaborez avec des partenaires dans trois expériences: lisez les chapitres 5-6 de "Génie logiciel moderne - La méthode de construction", comprenez et maîtrisez les caractéristiques des équipes de projet logiciel, comprenez le modèle des équipes logicielles et comprenez le modèle en cascade et sa combinaison avec le contenu d'apprentissage théorique Déformation, processus de livraison progressive, processus agile et autres caractéristiques typiques du modèle de processus logiciel, comprendre et expérimenter les principes TSP résumés par l'École de génie logiciel de l'Université Carnegie Mellon (CMU);
parce que je n'ai pas contacté le partenaire, je vais compléter cette dernière partie séparément .
Les caractéristiques de l'équipe projet logiciel:
(1) L'équipe a un objectif collectif cohérent, l'équipe doit réaliser cet objectif ensemble.
(2) Les membres de l'équipe ont leur propre division du travail, dépendent les uns des autres et coopèrent pour effectuer les tâches.
Le mode de l'équipe logicielle:
(1) Mode médecin traitant: Il y a un programmeur en chef et d'autres membres soutiennent son travail sous différents angles.
(2) Modèle en étoile: L'utilisation du modèle du médecin traitant à l'extrême dégénère en modèle en étoile, la clé est de maximiser les avantages de l'équipe plutôt que les avantages maximaux de l'étoile, car la valeur de l'équipe après la chute de l'étoile peut toujours être maintenue.
(3) Modèle communautaire: de nombreux bénévoles participent, la plupart d'entre eux ne sont pas payés et certains projets communautaires réussis sont soumis à un examen strict du code et à un contrôle de la qualité de l'enregistrement.
(4) Mode troupe amateur: dans une telle équipe, différentes personnes choisiront différents rôles dans chaque projet. Ces personnes peuvent changer pour un type de rôle complètement différent, et chaque personne suivra les conseils et la disposition d'un commandement central dans l'équipe.
(5) Équipe secrète: Le projet est réalisé dans un état secret, l'équipe jouit d'une grande liberté et peut souvent accomplir des tâches apparemment impossibles.
(6) Équipe d'agents spéciaux: elle est composée de certains professionnels ayant des compétences spéciales et peut résoudre des problèmes d'un seul coup.
(7) Modèle Symphony Orchestra: lorsqu'un certain domaine logiciel est dans une phase de croissance régulière, l'équipe de développement de nombreuses grandes sociétés de logiciels adoptera ce modèle.
(8) Mode Jazz: il est opposé au "mode orchestre symphonique" à bien des égards, mais les deux modes ont leurs propres avantages.
(9) Mode d'équipe fonctionnel: des collègues de capacités différentes collaborent de manière égale pour remplir une fonction ensemble. Une fois cette fonction terminée, ces personnes sont réorganisées et travaillent avec d'autres personnages pour terminer la fonction suivante.
(10) Le modèle bureaucratique: un modèle de leadership couche par couche, qui présente des dangers cachés de bureaucratie.
Modèle de cascade et sa déformation:
Le modèle original de cascade décrit un processus de production à sens unique et irréversible. Ce type de modèle directement appliqué à l'ingénierie logicielle comportera divers défauts. Winston a proposé une méthode pour améliorer le modèle de cascade. Par exemple, lors de la conception d'un système à grande échelle, il est nécessaire de remonter les étapes adjacentes pour résoudre les problèmes qui n'avaient pas été résolus à l'étape précédente. Comme montré.
Winston a également souligné que pour assurer le succès du produit, il est préférable de parcourir ce modèle deux fois, d'abord d'avoir une version simulée, de collecter des commentaires sur cette base, d'améliorer diverses étapes et de livrer une version finale.
Afin de résoudre le problème du modèle en cascade, de nombreuses variations se sont produites dans la pratique:
(1) Modèle Sashimi: les modules adjacents se chevauchent partiellement comme le sashimi.
(2) Modèle de sous-cascade: afin de résoudre les différents progrès entre les différents sous-systèmes, les exigences techniques sont très différentes et doivent être traitées différemment. Il est très difficile d'unifier chaque sous-système à l'étape finale des tests du système. Et les utilisateurs ne peuvent voir le résultat qu'à la fin.
Caractéristiques des modèles de processus logiciels typiques tels que le processus de livraison progressive et le processus agile:
Le processus de livraison progressive a deux caractéristiques: MVP et MBP. MVP est le plus petit produit viable. Les fonctions essentielles du produit sont réalisées au moindre coût, puis l'avis de l'utilisateur est rapidement sollicité. MBP est le produit le plus solide et le plus beau. Il montre la forme la plus complète et la plus belle du produit pour conquérir les utilisateurs d'un seul coup. Cela a des exigences élevées pour l'équipe.
Par rapport aux méthodes de développement traditionnelles, dans l'ensemble du processus de développement agile, il existe les principales caractéristiques suivantes:
(1) Le processus de développement agile a une adaptabilité plus forte qu'un préréglage.
(2) Dans le processus de développement agile, accordez plus d'attention au facteur humain.
(3) Dans le processus de développement agile, l'ensemble du projet est piloté par les tests plutôt que par les documents.
Les principes du TSP résumés par l'École de génie logiciel de l'Université Carnegie Mellon (CMU):
(1) Utiliser un processus bien défini, et chaque étape du processus peut être répétée et les résultats peuvent être mesurés.
(2) Chaque membre de l'équipe a une compréhension unifiée des objectifs, des rôles et des produits de l'équipe.
(3) Essayez d'utiliser des technologies et des pratiques matures.
(4) Recueillir autant de données que possible (y compris des données qui sont mauvaises pour l'équipe) et utiliser les données pour aider l'équipe à prendre des décisions rationnelles.
(5) Formuler des plans et des engagements réalistes Le plan d'équipe doit être formulé par le rôle responsable de l'exécution spécifique (et non par le supérieur).
(6) Augmenter les capacités d'autogestion de l'équipe.
(7) Se concentrer sur l'amélioration de la qualité et s'efforcer de découvrir les problèmes au début du cycle de vie du logiciel. Le moyen le plus efficace d'améliorer la qualité consiste à effectuer un travail de conception complet et minutieux (au lieu de se précipiter pour résoudre le problème plus tard).
Tâche 3:
Dans le parc de blogs de classe, il existe de nombreux cours de génie logiciel dans les collèges et universités qui exigent que les étudiants complètent les projets d'équipe. Veuillez consulter les partenaires de jumelage expérimentaux pour sélectionner un cas de projet d'équipe de haute qualité dans les trois classes suivantes pour l'apprentissage collaboratif et nécessitent un suivi Le projet d'équipe publie toutes les affectations de blog et télécharge le code logiciel du projet.
- 2016 École d'informatique et d'ingénierie du génie logiciel (Northwest Normal University)
- 2019 Qiufu University Software Engineering Practice Class Z (Université de Fuzhou)
- École de génie informatique du printemps 2019 (Université d'aéronautique et d'astronautique de Pékin)
Ici, je choisis 3. École de génie informatique du printemps 2019 (Université d'aéronautique et d'astronautique de Pékin)
1. Lien vers le compte de publication
du projet d'équipe 2. Lien github entrepôt du projet d'équipe
3. Indiquer que vous choisissez ceci Raisons de l'analyse de projet d'équipe.
L'équipe développe la suite du blog park APP. Le projet de développement est plus pratique. Le langage de développement et les outils de développement que j'utilise sont relativement familiers. Je peux m'améliorer en suivant et en analysant les problèmes rencontrés dans leur processus de développement.
4. Combinez les documents du blog de la série de projets pour résumer la division et la coopération des membres de l'équipe de projet.
L'équipe projet est composée de 2 PM (chefs de produit) (dont l'un est également testeur), 3 développeurs et 2 testeurs. Dans l'ensemble, leur division du travail est relativement claire, et les membres de l'équipe ont de bonnes capacités, et ils ont un bon contrôle sur les progrès du développement. Il y a souvent des réunions pour résumer et discuter les progrès du développement et les difficultés rencontrées pendant le processus de développement.
5. Combiné avec les documents de blog de la série de projets, évaluez les caractéristiques du processus de projet logiciel (TSP) du projet.
L'équipe adopte le modèle de l'orchestre symphonique, l'itération logicielle est stable, la communication est fréquente au sein de l'équipe et l'équipe a une bonne capacité d'autogestion. L’équipe a élaboré des plans et des engagements réalistes depuis le début. Chaque membre de l’équipe a une compréhension unifiée des objectifs, des rôles et des produits de l’équipe. Il utilise des technologies et des pratiques matures et recueille autant de données que possible. .
6. Observez la structure du fichier de code source de l'entrepôt github du projet d'équipe, contient-elle des documents de spécification de code?
Le référentiel github du projet d'équipe ne contient pas de documents de spécification de code.
7. Téléchargez le code du projet d'équipe, essayez de déployer l'environnement d'exploitation du projet et utilisez le logiciel, décrivez l'expérience utilisateur la plus simple et la plus intuitive, trouvez au moins deux bogues fonctionnels plus graves et affichez des captures d'écran dans le blog.
Interface logicielle:
L'expérience logicielle est bonne, la conception et l'interaction de l'interface utilisateur sont plus belles et conviviales, et les fonctions sont plus pratiques, mais de nombreux détails peuvent continuer à être améliorés et optimisés.
Le logiciel n'a pas trouvé de bogues fonctionnels graves. Mais une chose qui a un grand impact sur l'expérience est que le mode sombre ne s'affiche pas après l'ouverture de l'article de blog, et les boutons de fonction en dessous s'éclairciront lorsque le mode sombre sera changé.
8. Évaluez si le projet d'équipe vaut la peine d'être développé et indiquez les raisons?
Le projet d'équipe mérite d'être poursuivi. Parce que c'est un projet très pratique, pour les utilisateurs qui utilisent fréquemment le parc de blogs, il est préférable d'avoir une application mobile de parc de blogs puissante. Vous pouvez continuer à améliorer la conception de l'interface et à améliorer encore les fonctions à l'intérieur. Par exemple, vous pouvez obtenir presque les mêmes fonctions que la version Web du PC. Les bugs doivent encore être modifiés.
3. Le temps réel consacré à diverses tâches dans l '"Analyse des cas de projet logiciel de l'expérience 4"
| Le contenu | Temps prévu (min) | Temps de réalisation réel (min) |
|---|---|---|
| Tâche un | 120 | 240 |
| Tâche deux | 120 | 120 |
| Tâche trois | 480 | 480 |
4. Sentiments et sentiments
L'expérience n'a pas été très bien terminée, principalement en raison du manque de fondement propre, ce qui a conduit à de nombreux problèmes nécessitant beaucoup de temps pour rechercher sur Internet pour résoudre le problème. La lecture du code est également plus difficile. Mais il y a aussi eu des gains dans le processus de l'expérience, consolidant les connaissances apprises en classe de théorie, et en même temps, j'ai aussi vu que mon niveau de connaissance est encore très faible, loin du niveau du cas. J'espère pouvoir continuer à travailler dur.