Deadline：
2018-5-16 10:00PM, subject to the time of submission to the class blog.
5.10 In the experimental class, the project review will be conducted in units of (1, 2, 3, 4 classes). According to the following requirements, complete the review sequence of this team to other teams.
Reference comes from http://www.cnblogs.com/xinz/p/6819371.html
Scoring arrangements for the review stage:
- Each team writes an alpha stage summary presentation blog (no PPT).
- Each reviewer sees the summary and display blogs of all teams, as well as code quality, actual test results, decides the ranking (not tied), and explains the advantages and disadvantages of the project (see the table below)
- Who will be the reviewer: teacher, teaching assistant, each team chooses a representative of the team
- The team blog lists team rankings, and reviews of those teams (excluding this team)
- What reviewers look at:
- Basic requirements: Are all team members present (points will be deducted if they are not there without reason), and how well are they explaining and answering questions on the spot? Does each role have the opportunity to speak and answer questions?
- Software quality: Has the original planned problem been solved, and how is the software running quality? How many users are there and what is the user feedback?
- Quality in software engineering: where is the code? Will the code build successfully on the new machine? How is the software structured (more detailed in the table below)? How maintainable is the code? Is there a daily build? How is the project managed? Do burndown charts reflect the real state? Are there answers or improvements to the comments from teachers and teaching assistants?
- How to do a review:
- Face-to-face concentrated work, the teacher and all the reviewers present asked questions on the spot, ranking second
- Not face-to-face, by looking at blogs and code, blog comment exchanges are averaged and ranked. Everyone has studied software engineering and has done projects. Comments should be a bit professional, not just perceptual knowledge ("The app made by this group looks OK..."), but to comment on this product and Where software engineering is related, the book mentions the following formula:
software = program + software engineering
software (quality) = program (quality) + software engineering (quality)
- Who will be the reviewer: teacher, teaching assistant, each team chooses a representative of the team
We want to test the quality of the program well and give a clear, quantitative assessment. At the same time we will observe the quality of the software engineering of this group (through their daily meeting, burndown charts, and other blogs) and comment on whether their project goals have been achieved? How are project risks addressed? Did you find the user's pain point and solve it? What is the trade-off between primary and secondary needs? If I were to lead this group, what would I do differently?
Group name and link advantage Cons, bug report (minimum 140 words) Final ranking (no tie) team 1 ... What specific bugs does the program have? Have the project goals been achieved? How are project risks addressed? Did you find the user's pain point and solve it? What is the trade-off between primary and secondary needs? How about source control? How about "non-functional quality"? Choose at least 3 areas to measure If I were to lead the group, what would I do differently? team 2 ... ... The teaching assistant collects the ranking information of all the reviewers, arranges them according to the average ranking, and gives the scores (again: the group evaluates the rankings of each other, there is no tie, no score is given, and the teaching assistant scores the final score).
The full score of this demonstration assignment is 100 points, and the rest of the rankings are in descending order