| Projet | Le contenu |
| Blog des cours | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| Exigences du poste | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| Objectifs d'apprentissage du cours | Grâce à l'analyse d'excellents cas de devoirs, maîtrisez vos lacunes. Grâce à l'apprentissage coopératif, comprendre l'importance de la coopération |
| De quelle manière ce travail m'aide-t-il à atteindre mes objectifs d'apprentissage | Découvrez la coopération de deux personnes dans le développement de projets logiciels, pratiquez la programmation de paires et maîtrisez la méthode de fonctionnement du programme de développement collaboratif Github. |
| Identifiant étudiant-Nom | 201771010126-Wang Yan |
| Liez l'autre partie à ce lien de blog | <https://www.cnblogs.com/wy201771010126/p/12677569.html> |
Contenu expérimental et étapes:
Tâche un: Expérience trois Excellente recommandation de cas: Wang Zhitai & Han Lamei Group
Lien vers le blog d'affectation de cas: https://www.cnblogs.com/hanlamei/p/12574378.html
Lien vers l'entrepôt du projet Casework: https://github.com/YHwzt/Query-system-web
(1) Lire et commenter les affectations de blog de cas Les principaux points 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 le contenu du commentaire ci-dessus est publié 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 de fonctionnement du code et découvrez si le billet de blog de cas est utile pour la compréhension du code de projet.
Clonez le code côté boîtier pour l'exécuter localement
Exécutez ensuite le code, la capture d'écran est la suivante
Ce qui précède est l'interface de connexion
Ajouter des informations
Statistiques des informations collectées
Affichage d'informations
Fonctions implémentées dans les cas ci-dessus:
1. Il peut recueillir des informations sur l'épidémie de divers enseignants et élèves de l'école;
2. Le responsable de la prévention et du contrôle des épidémies de chaque département secondaire peut consulter le résumé épidémique du personnel de ce département et fournir des fonctions de requête avancées pour les requêtes combinées multi-attributs et les statistiques visuelles;
3. La personne désignée responsable des registres du bureau de prévention et de contrôle de l'école dans le sous-système "Statistiques sur les informations de prévention et de contrôle des épidémies de l'Université normale du Nord-Ouest", peut parcourir tout le personnel pour remplir la liste des données résumées et peut utiliser [Enquête avancée] pour filtrer la combinaison de données et le système affiche tous Le collège a rempli et omis de remplir les statistiques des étudiants et les statistiques des données épidémiques clés. Vous pouvez [exporter] le fichier EXCEL pour interroger la liste;
4. Fonction supplémentaire: rappel de rapport régulier
La fonction de ce cas est complète, et toutes les fonctions sont mises en œuvre conformément aux exigences de l'enseignant. En outre, des fonctions supplémentaires sont mises en œuvre. Il est relativement parfait en comparaison, donc en comparaison, je pense que ce cas en vaut la peine Permettez-moi d'apprendre par référence.
(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.
Je pense que ce cas est parfait et qu'il n'y a pas beaucoup de lacunes, mais il y a aussi quelques imperfections.Par exemple, le code dans l'entrepôt n'a pas de problèmes après le clonage mais il y a quelques problèmes lors de l'importation d'éclipse. Une fois les informations pertinentes ouvertes directement dans l'idée, cela fait que de nombreux référenceurs ont un gros problème, car il ne peut pas être ouvert, ils penseront que leur configuration d'éclipse est incorrecte ou que le code est incorrect.
La spécification du code ne pose pratiquement aucun problème et l'implémentation de la fonction est relativement complète.
Tâche 2: Collaborer avec les trois partenaires de l'expérience pour apprendre: lire les chapitres 5-6 de "Génie logiciel moderne - La méthode de construction", comprendre et maîtriser les caractéristiques de l'équipe de projet logiciel, comprendre le modèle de l'équipe logicielle et comprendre la cascade avec le contenu théorique Les modèles et leurs transformations, les processus de livraison progressive, les processus agiles et d'autres caractéristiques typiques des modèles de processus logiciels, comprennent et apprécient les principes TSP résumés par l'École de génie logiciel de l'Université Carnegie Mellon (CMU);
1. Caractéristiques de l'équipe de projet logiciel
(1) L'équipe devrait avoir un objectif commun;
(2) L'équipe devrait se diviser et collaborer raisonnablement;
(3) Un degré élevé de cohésion est une garantie d'unité;
(4) Information mutuelle entre les membres de l'équipe;
(5) Communication efficace;
2. Le mode de l'équipe logicielle: Il existe de nombreux modes différents de l'équipe logicielle.
(1) Voici plusieurs modes et leurs avantages et inconvénients:
1. Un mode essaim: comme un enfant qui joue au football, où que soit le ballon, les gens suivront l'essaim
Avantages: heureux et décontracté
Inconvénients: ce modèle d'équipe est difficile à survivre, pas un bon modèle d'équipe
2. Mode médecin traitant: comme dans la table d'opération, il y a un avocat, d'autres sont chargés d'aider le médecin traitant
Avantages: L'intention initiale est très bonne. Dans une équipe logicielle, il y a des programmeurs en chef qui sont responsables de la conception et du codage des modules principaux. D'autres soutiennent son travail dans tous les aspects autant que possible
Inconvénients: dans les classes d'école douce de certaines écoles, ce modèle dégénère progressivement en "un élève travaille, d'autres élèves combattent la sauce soja"
3. Le modèle en étoile: le modèle du médecin traitant est appliqué à l'extrême
Avantages: Il peut être utile pour la croissance et le progrès des individus "vedettes"
Inconvénients: Le modèle d'équipe met l'accent sur le rôle de l'équipe, et non sur le one-man show individuel.Ce modèle viole évidemment l'intention initiale du modèle d'équipe, et l'efficacité est également très faible
4. Modèle communautaire: de nombreux bénévoles participent, tout le monde participe à des projets qui les intéressent, contribue au pouvoir, la plupart des gens ne sont pas payés
Avantages: "Les gens ramassent du bois de chauffage avec des flammes élevées", histoires de réussite: communautés qui développent et maintiennent des systèmes d'exploitation Linux, les histoires de réussite nécessitent souvent une révision stricte du code et un contrôle de la qualité de l'enregistrement
Inconvénients: "Rôtir le feu uniquement, pas récupérer le bois de chauffage", "La qualité du bois de chauffage est trop mauvaise"
5. Mode groupe de théâtre amateur: chacun dans l'équipe joue son rôle
Avantages: Dans un environnement où les joueurs jouent aux billets et s'entraînent, tout le monde peut essayer différents rôles et tout le monde peut discuter de manière plus égale
Inconvénients: Dans une équipe hautement compétitive et créative, il n'y aura pas d'atmosphère démocratique de perfectionnisme.
6. Équipe secrète: certains projets logiciels sont exécutés dans un état secret, d'autres ne savent pas ce qu'ils font
Avantages: grande liberté au sein de l'équipe, grand enthousiasme et aucune interférence extérieure.
Inconvénients: Il est impossible de devenir un modèle universel, uniquement pour des projets individuels.
7. Équipe d'agent spécial: L'équipe du logiciel est composée de professionnels ayant des compétences spéciales et est chargée de résoudre certains problèmes difficiles et urgents.
Avantages: haute efficacité
Inconvénients: Les besoins en connaissances des membres sont très larges, ils sont plus ciblés sur le personnel technique et ne peuvent pas être un modèle universel.
8. Mode Orchestre symphonique: Faites leur propre travail, comme l'orchestre symphonique
Avantages: exécuter leurs tâches et se concentrer sur l'exécution
Inconvénients: terne
9. Mode Jazz: Il y a beaucoup d'opposition au mode symphonie
Avantages: Le leader donne un thème, puis les membres sont en pleine floraison, montrant leurs compétences, puis résumant quand ils sont sur le point de terminer.
Inconvénients: pas trop de monde
10. Mode d'équipe fonctionnelle: des collègues de capacités différentes collaborent sur un pied d'égalité pour remplir une fonction
Avantages: haute efficacité
Inconvénients: chaque équipe doit convenir des spécifications de programmation avec les autres équipes
11. Modèle bureaucratique: né de la structure organisationnelle des grandes institutions, plusieurs personnes relèvent d'un petit patron, quelques petits patrons relèvent du patron intermédiaire, à leur tour
Avantages: Contribuer à la technologie alternative et complémentaire
Inconvénients: il est facile de mélanger certains dans la poursuite de la renommée et du profit, ce qui réduit souvent l'efficacité de l'équipe
(2) Discuter du modèle de binôme avec les membres du groupe
3. Caractéristiques d'un modèle de processus logiciel typique
Le soi-disant modèle de processus logiciel est une stratégie de développement qui fournit un ensemble de paradigmes pour chaque étape de l'ingénierie logicielle, afin que l'avancement du projet puisse atteindre l'objectif souhaité. Quelle que soit la taille d'un développement logiciel, nous devons choisir un modèle de processus logiciel approprié, ce choix est basé sur la nature du projet et de l'application, la méthode utilisée, le contrôle requis et les caractéristiques du produit à livrer. Le choix d'un mauvais modèle perdra notre orientation de développement.
| Nom du modèle | Caractéristiques techniques | Champ d'application |
| Modèle en cascade | Simple, échelonné, il existe une relation de cause à effet entre les phases, il y a un examen après l'achèvement de chaque phase, la rétroaction est autorisée, non prise en charge, la participation des utilisateurs, nécessite des exigences prédéterminées | Systèmes logiciels qui nécessitent une définition et une modification faciles |
| Modèle de prototypage rapide | Le modèle ne nécessite pas que les exigences soient entièrement définies à l'avance, prend en charge la participation des utilisateurs, prend en charge l'amélioration progressive et la confirmation des exigences, et peut s'adapter aux changements des besoins des utilisateurs | Systèmes logiciels avec des exigences complexes, difficiles à déterminer et des changements dynamiques |
| Modèle incrémental | Les produits logiciels sont développés progressivement, permettant des activités de développement parallèles et se chevauchant | Système logiciel à haut risque technique et demande utilisateur stable |
| Modèle itératif | Il n'est pas nécessaire de développer un système logiciel complet à la fois et de considérer le développement logiciel comme un processus d'acquisition progressive de besoins étendus et de perfectionnement de produits logiciels. | Systèmes logiciels avec des exigences difficiles à déterminer et en constante évolution |
| Modèle en spirale | Combiner les idées du modèle en cascade, du modèle de prototypage rapide et du modèle itératif, et introduire des activités d'analyse des risques | Systèmes logiciels avec des exigences difficiles à obtenir et à déterminer et un risque élevé de développement logiciel |
| RUP | Peut être modifié, étendu et personnalisé: il peut être conçu, développé, maintenu et publié; accent mis sur le développement itératif | Systèmes logiciels complexes et difficiles à obtenir et à déterminer; l'équipe de projet de développement logiciel possède une vaste expérience en développement et en gestion de logiciels |
Modèle en cascade
Le modèle en cascade (cycle de vie classique) propose une approche systématique et séquentielle du développement logiciel. Le processus commence par la spécification des besoins des utilisateurs, à travers la planification, la modélisation, la construction et le déploiement, et fournit finalement un logiciel complet et un support technique continu.
Avantages:
1. Soulignez le stade de développement, chaque stade a de l'ordre et de la dépendance
2. Mettre l'accent sur la recherche précoce et l'analyse des besoins et reporter la réalisation du codage
3. Un modèle est fourni, qui permet aux méthodes d'analyse, de conception, de codage, de test et de support d'avoir un guide commun sous le modèle
Inconvénients:
1. Poussé par des documents, les utilisateurs ne peuvent pas comprendre le produit à temps
2. En s'appuyant sur les premières recherches et l'analyse des besoins, il est difficile de s'adapter aux incertitudes qui doivent exister au début de nombreux projets.
3. Le processus est unique et les tâches de l'étape précédente doivent être terminées avant de passer à l'étape suivante. L'expérience réussie du processus de développement ne peut pas être utilisée pour ce produit.
4. Le test a été introduit à un stade ultérieur.Si des défauts majeurs existent dans le système, s'ils ne sont pas décelés avant l'examen du programme exécutable, il peut entraîner des pertes importantes.
5. L'organisation est énorme et le personnel est inactif.
Modèle de processus incrémentiel
Les modèles de processus incrémentiels incluent les modèles incrémentiels et les modèles RAD.
(1) Modèle incrémentiel Le modèle de processus incrémentiel utilise le modèle en cascade de manière itérative pour concevoir, coder, intégrer et tester des produits logiciels sous la forme d'une série de composants incrémentiels.
Chaque composant est composé de plusieurs modules en interaction et peut exécuter des fonctions spécifiques. Lors de l'utilisation d'un modèle incrémentiel, le premier incrément est souvent la fonction principale.
Avantages:
1. Un produit qui peut terminer une partie du travail peut être soumis à l'utilisateur dans un court laps de temps.
2. L'augmentation progressive des fonctions du produit peut laisser aux utilisateurs suffisamment de temps pour apprendre et s'adapter aux nouveaux produits, réduisant ainsi l'impact d'un tout nouveau logiciel sur les organisations clientes.
3. Évitez les risques techniques
4. Les composants peuvent être développés en parallèle pour accélérer le processus de développement
Inconvénients:
1. Aucune considération n'est accordée à la qualité globale et à la maintenabilité à long terme du logiciel.
2. Dans la plupart des cas, des algorithmes de fonctionnement inappropriés sont adoptés dans le but de démontrer les fonctions, des outils de développement inappropriés sont adoptés uniquement pour sa commodité, et des systèmes d'exploitation inappropriés sont sélectionnés, etc.
3. Le produit peut être abandonné en raison du non-respect des exigences de qualité, et le nouveau modèle est utilisé pour la refonte
Modèle RA D
Le modèle RAD est un modèle de processus logiciel incrémentiel qui se concentre sur un cycle de développement court. C'est une variante "à grande vitesse" du modèle en cascade qui permet un développement rapide grâce à une méthode de construction basée sur la construction.
L'équipe de développement peut créer un "système complet" en très peu de temps
Avantages:
1. La vitesse de développement est rapide et la qualité est garantie.
2. Particulièrement efficace pour les systèmes d'information.
Inconvénients:
1. Pour les projets évolutifs à grande échelle, RAD a besoin de beaucoup de ressources humaines pour créer plusieurs équipes RAD relativement indépendantes
2. Si les développeurs et les utilisateurs ne sont pas prêts pour l'achèvement rapide de l'ensemble du système en peu de temps, le projet RAD échouera.
3. Si un système ne peut pas être raisonnablement modulaire, il y aura de nombreux problèmes dans la mise en place des composants RAD.
4. Si la configuration système requise est élevée et que vous devez ajuster l'interface du composant pour améliorer les performances, vous ne pouvez pas utiliser le modèle RAD
5. Lorsque le risque technique est élevé
Modèle de processus évolutif
Le modèle de processus d'évolution comprend le développement de prototypes, le modèle en spirale et le modèle de développement collaboratif.
(1) Le développement du prototype commence par la collecte des exigences. Les développeurs et les clients définissent ensemble les objectifs généraux du logiciel, identifient les exigences connues et planifient les domaines qui nécessitent une définition plus approfondie.
Ensuite, il y a la "conception rapide", qui se concentre sur la représentation des parties du logiciel qui sont visibles pour le client, ce qui conduira à la création du prototype, et le client évaluera et affinera davantage les besoins du logiciel à développer.
Le processus d'ajustement progressif du prototype pour répondre aux besoins des clients est un processus itératif. Le processus commence par l'écoute des opinions des clients, suivi de la construction / modification des prototypes, des tests clients et de l'exécution des prototypes, puis des allers-retours jusqu'à ce que le client soit satisfait du prototype.
Parce que ce modèle permet aux clients de ressentir rapidement le système réel (bien que ce système ne dispose d'aucune assurance qualité), les clients et les développeurs préfèrent ce modèle de processus (pour les entreprises qui ne sont utilisées que pour démontrer les fonctions logicielles Ou ne considérez jamais la qualité du logiciel
Volume et entreprises qui n'ont pas peur de la maintenance à long terme).
Avantages:
1. Laissez les gens (développeurs ou clients) voir le produit rapidement et avoir un sentiment d'accomplissement.
2. Peut inciter progressivement les clients à proposer de nouvelles exigences ou tâches.
Inconvénients:
1. La qualité globale et la maintenabilité à long terme du logiciel ne sont pas prises en compte.
2. Dans la plupart des cas, des algorithmes de fonctionnement inappropriés sont adoptés dans le but de démontrer les fonctions, des outils de développement inappropriés sont adoptés uniquement pour sa commodité, et des systèmes d'exploitation inappropriés sont sélectionnés, etc.
3. Le produit peut être jeté en raison du non-respect des exigences de qualité, et un nouveau modèle est adopté pour une nouvelle conception.
Modèle en spirale
Le modèle en spirale est un modèle de processus logiciel évolutif qui combine la nature itérative du prototype avec les caractéristiques systématiques et contrôlables du modèle en cascade. Il a le potentiel de développer rapidement des versions logicielles de plus en plus complètes.
Étapes de développement: De l'intérieur vers l'extérieur le long de la spirale, une nouvelle version logicielle plus complète est développée pour chaque rotation.
Par exemple, au premier tour, après avoir déterminé les objectifs, plans et contraintes préliminaires, tournez-vous vers le quadrant supérieur droit pour identifier et analyser les risques.
Si l'analyse des risques montre que la demande est incertaine, alors dans le quadrant d'ingénierie en bas à droite, le prototype aidera les développeurs et les clients à envisager d'autres modèles de développement et à modifier davantage les exigences. Une fois que le client a évalué les réalisations techniques, il donne des suggestions de correction.
Sur cette base, il est nécessaire de planifier à nouveau et d'effectuer une analyse des risques. À chaque spirale de la spirale, la fin de l'analyse des risques fait un jugement sur l'opportunité de continuer.
Si le risque est trop grand pour les développeurs et les utilisateurs, le projet peut être interrompu. Dans la plupart des cas, les activités le long de la spirale se poursuivront, s'étendant progressivement de l'intérieur vers l'extérieur, et obtiendront finalement le système souhaité.
Avantages:
1. Insistez sur le risque
2. Mettez l'accent sur la qualité de la scène
3. Fournir des opportunités de correction d'erreurs
Inconvénients:
1. A chaque étape, le plan retenu doit être mis en avant, analyse des risques, long cycle de R&D et faible efficacité
2. L'implication des analystes des risques qui doivent changer d'emploi
Modèle de processus unifié
Le modèle de processus unifié est un cadre de processus logiciel "basé sur le cas d'utilisation, centré sur l'architecture, itératif et incrémentiel", pris en charge par les méthodes et outils UML. Il s'agit d'un modèle incrémental qui définit cinq étapes:
a. Phase initiale, y compris la communication avec les utilisateurs et les activités de planification, en mettant l'accent sur la définition et le raffinement des cas d'utilisation
b) Étape de perfectionnement, y compris les activités de communication avec les utilisateurs et de modélisation, en mettant l'accent sur la création de modèles d'analyse et de conception.
c. Étape du composant, conception détaillée du modèle et transformation du modèle de conception en composants logiciels
d. Dans la phase de conversion, le logiciel est transmis du développeur à l'utilisateur final, et l'utilisateur termine le test bêta et le test d'acceptation
e. Pendant la phase de production, surveiller en permanence le fonctionnement du logiciel et fournir un support technique.
Avantages:
1. Entrez dans le processus de test après tout développement de fonction et vérifiez dès que possible
2. Identification précoce des risques et mesures préventives
Inconvénients:
1. Les exigences doivent être bien comprises avant de commencer, s'il existe une possibilité d'erreurs structurelles
2. Il doit y avoir une gestion stricte des processus, afin de ne pas dégrader le processus aux essais et erreurs d'origine → changer le mode
3. Si des utilisateurs non contrôlés sont exposés prématurément sans tests complets, les produits avec des versions instables peuvent affecter négativement les utilisateurs et l'équipe de développement
4. Comprendre et apprécier les principes du TSP résumés par l'École de génie logiciel de l'Université Carnegie Mellon (CMU)
(1) Utilisez un processus bien défini: chaque étape du processus peut être répétée et les résultats 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.
Tâche 3 : veuillez consulter la troisième paire de partenaires de l'expérience, sélectionner un cas de projet d'équipe de haute qualité dans les trois classes suivantes pour l'apprentissage collaboratif, demander de suivre toutes les affectations de blog publiées par le projet d'équipe et télécharger le code du logiciel du projet
1. École d'ingénierie informatique et de génie informatique 2016 (Northwest Normal University)
2. 2019 Qiufu University Software Engineering Practice Class Z (Fuzhou University)
Après discussion, j'ai décidé de choisir Northwest Normal University pour étudier. La principale raison de ce choix est que, en comparaison, la première est ma propre école, l'écart de niveau d'apprentissage n'est pas très grand, il est facile à comprendre, par rapport aux deux autres écoles Est plus compréhensible.
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 (4 points);
On peut voir que la division du travail est déraisonnable et qu'une autre personne est seule responsable de l'édition des documents et que le travail est confié aux camarades de classe qui codent. C'est déraisonnable et certaines tâches doivent être assignées pour réduire la charge des autres membres de l'équipe.
Combiné avec les documents de blog de la série de projets, évaluez les caractéristiques du processus de projet logiciel (TSP) du projet:
软件开发是一个团队活动，而团队的有效性决定了产品的质量，TSP 的过程质量管理对于软件开发日渐重要。要建立和保持团
队的高效率工作，前期的 投入是必须的。从长期看，这种投入并没有增加成本，而是极大地降低成本，提高生产效率。软件开
发过程中积累下来的实际经验，对于团队今后的工作，具有很好的指导意义。
Observez la structure du fichier de code source du référentiel github du projet d'équipe, contient-il des documents de spécification de code? (5 points);
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 montrez des captures d'écran sur le blog (20 points);
Dans le processus de test de la boîte noire, lors du test de génie logiciel, nous avons trouvé les erreurs et les bogues suivants:
1. Fonctions incorrectes ou fonctions manquantes: Dans le module de gestion des congés, la modification du statut de révision des congés a réussi, mais le statut n'a pas changé .
2. Erreur de performance et erreur de connexion de données: une fois que l'enseignant a demandé l'autorisation de passer l'examen, l'élève ne peut pas voir l'état de l'examen.
3. Erreur de performance, les élèves modifient en toute confiance les autorisations.
Évaluer si le projet d'équipe mérite un développement continu et en expliquer les raisons?
Fondamentalement, certains tests de régression apparaîtront. Après avoir terminé certains modules, il y aura toujours des problèmes et le code doit être modifié, mais la structure globale n'a pas changé. J'ai bien peur que des problèmes plus importants se produisent. Il y a moins de tests de régression pour éviter plus d'erreurs. Apparu. Une fois cette version du logiciel terminée, si nécessaire, une deuxième version de révision, plusieurs révisions de code et des tests de régression sont essentiels.
Le test de régression apparaît:
1. Une erreur se produit sur la page et une interface de gestion des exceptions est émise. Afin de rendre la situation de gestion des exceptions plus visible et opérationnelle, ajoutez une interface d'erreur 404. Si une erreur se produit, vous pouvez directement quitter ou retourner à la page d'accueil.
2. La fonction du module est anormale, la connexion de la logique de données est incorrecte, les données sont modifiées dans un module et l'autre module ne peut pas être modifié à temps, etc.
Enregistrez le temps réel passé pour terminer les tâches de «Analyse de cas de projet logiciel expérimental quatre»
| Tâche expérimentale | Prenez le temps |
|---|---|
| Tâche un | 3h |
| Tâche deux | 2h |
| Tâche trois | 5.5h |
| Tâche quatre | 1h |
5. Veuillez parler du sentiment et de l'expérience de la réalisation de cette tâche.
Ces devoirs se concentrent principalement sur d'autres excellents devoirs, et l'apprentissage d'excellents devoirs est aussi une sorte d'amélioration et d'amélioration de ses capacités Le code n'est pas suffisamment complet, et il n'y a pas de norme pour les cas excellents, ce sont donc des domaines qui doivent être renforcés dans la période ultérieure, donc cette excellente analyse de cas m'a également permis de comprendre mes propres lacunes et où travailler .