Beta Release Project Presentation requirements

The beta release project presentation requirements are as follows:

1. Do not use PPT, the information used in the display must be posted on the blog (can have pictures, videos and other multimedia content).
2. Live demo of your release software. If the software is deployed on the server, you must connect to the server for demonstration. Can have more than one person onstage to show, have the team PM lead.
3. Specific reports include: Introduction of your project vision, what you have achieved in your beta release, what you learned in software engineering at the M2 stage, and much more.
4. Evaluation criteria: The quality of all aspects of software engineering, the quality of the field demonstrations, the number of users, whether the use of real data, the amount of data to meet the requirements, teamwork and so on.

Beta Version Project presentation outline

The content of the display blog can be organized according to the following template:

1) Profile of team members and personal blog address

2) We want to do software engineering, it will have a little engineering look:

The target of the team project, the expected typical user, the expected function description, where is the expected number of users?

How does the team's products meet the needs of the users? To see the process and rating of the target user using the product (video or live presentation)?

Have you reached the pre-defined software download volume? Why didn't it reach?

How do the members of the team work together? What lessons do you have?

How does the team balance time/quality/resources to achieve the task as scheduled?

What is the quality of the software engineering of the team code outside the product? How to use data to prove?

1. Where is the final code for the project?
2. Number of test cases, number of code coverage.
3. Run the test case to get the code coverage of the video recording (need to be seen on site.) There are no excuses such as "My computer does not have a test environment", "incomplete files", and so on.
4. Where is the code specification?
5. Where is the complete documentation?
6. Some projects are based on the original improvement, then our team's software project Quality improvement? For example, does code coverage grow from the original x to Y?
7. The original project some code can not be found, the document is not, or no recent code, your project is how to better solve the problem? Next year's students continue to develop the project, will there be similar complaints? If a new student wants to compile and run your project on a new machine, will it be done? What documents are available to guide new students?
8. For the project target user is the general student's project, how do you find the student to do the demand analysis? What kind of feedback do they give you?
9. All projects will collect user data, what kind of analysis do you have on this kind of data, how do these analyses validate or overturn the original hypothesis? How does this data help the project improve the quality of software engineering?

3) The actual progress of the team project (copy the Burndown chart in the scrum process), publish the function (copy publish the document), where to publish the software (3–10 URL), user feedback screenshot. Explains how the Burndown chart for scrum reflects the state of a project in project management? Or does the Burndown chart beautify the state?

4) Role and specific contributions of team members in M2:

Name	Role	specific to ,  measurable ,  Verifiable contributions	Team Contribution points
Little Brother Ma	Pm	How many documents/blogs/campaigns/How many user surveys/How many times have you written?
Brother Niu	Dev	How many lines of code are written, how many comments, how many documents
Board Brick Brother	Test	How many test plans, test cases, and bugs have been written? How many bugs have been fixed
...

Many students on this software engineering class, may hold the soy sauce, hug thigh mentality. Since dare to soy sauce, then we will appear to the people to see, the situation quantified, put in front of everyone. Where the soy sauce is, where the thighs are at a glance. So our team contribution points will be a good decision.

5) What is the most distinctive feature of the software, please focus on the introduction. Live users how to benefit from your software, please show on site.

6) What feedback does the team get from the user and what kind of bugs are there? Is this expected or unexpected?

If the site review members found the system crashes such obvious bug, but our team of testers did not find such a bug, then for each bug, the team's results deducted 10 points, deducted to 0 points, continue to buckle, team project score can be negative points .

7) What progress has the team made in software engineering compared to M1? Want to see the group M2 postmortem blog.

8) Summing up, what did the team learn in the beta phase, the education of software engineering, and what are the critical suggestions for this specific course?

Beta Release Project Presentation requirements