Final Presentation

docx

School

Carleton University *

*We aren’t endorsed by this school

Course

313

Subject

English

Date

Apr 3, 2024

Type

docx

Pages

4

Uploaded by ChristyPaul

Report
School of Engineering Technology and Applied Science Information and Communication Engineering Technology Software Development Project II (COMP313) Final Presentation (25%) Due Dates: Sunday of Week 13 by 11:59pm 1.1 INSTRUCTIONS FOR MIDTERM PRESENTATION To demonstrate the 2nd Software Release, your team will need to create a table listing the stories and their associated acceptance tests for the given software release ( Table 1 illustrates a sample table). You will be narrating your story using a narrated PowerPoint r some other narration software of your groups choice. The following steps should be used when demonstrating each story: 1. Indicate the story you will be demonstrating by reading the story out loud (i.e., the 1st column in Table 1 ). 2. For each test (i.e., the 2nd column in Table 1 ), read it out loud, and if applicable, show the initial state of the database table(s) before running the test and the state of the database table(s) after the running the test. 1 3. If the outcome of executing the test is as expected, then highlight the test text in green (passed) , otherwise, the test outcome was not as expected then highlight the test text in red (failed) . 1 For example, to demonstrate adding a new user “jdoe” to a system, show the before state for the database table “User” (“jdoe” should not be in the table) and after executing the test, show the after state of table “User” in which ‘jdoe” is added by the system.
Table 1: Stories, acceptance tests, and contributors for the 2nd Software Release ( Green=Passed ; Red=Failed ). Full description of user story Acceptance test(s) Name(s) of contributing Developer(s) As an User, I can … so that …. 2 Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Susan Smith, Jay Johnson As an Administrator, I can … so that …. 3 Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Susan Smith, Jay Johnson, Shannon Shore, George Gavinson As an User, I can … so that …. Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Jay Johnson, Shannon Shore, George Gavinson As an User, I can … so that …. 4 Test with inputs …. Expected outcome: ... Shannon Shore As a Guest, I can … so that …. Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Test with inputs …. Expected outcome: ... Susan Smith, Jay Johnson, Shannon Shore, George Gavinson, Abbey Appleby, Brian Bolt 2 Green colour code indicates that all tests passed successfully as intended. 3 Red colour code indicates that at least one test unintendedly failed. 4 When all tests for a given story fails, this may suggest that implementation of the story has not even begun and indicates poor planning on the part of the team.
5 What happens in this case? The story simply gets reallocated to the next Iteration and is included in the next software release. Test with inputs …. Expected outcome: ... If all tests for a given story passes (i.e., green ), then the story is considered complete (the first story in Table 1 is such story). However, even if one test fails (i.e., red ), then the story is considered to be incomplete for the given software release (the second story in Table 1 is such story). 5 A story in which all tests failed to pass is also considered incomplete (the fourth and fifth stories in Table 1 are examples of such stories). The fact that all tests failed for these stories may suggest that they have not even been attempted during the Iterations for this software release and give tell tale signs of poor planning on the part of the team. 2.1 DEMO GRADE BREAKDOWN (65 PTS.) 1. Is a table with columns (Story, Acceptance Tests, Contributor) for the current software release submitted? 1 pt. deduction for each non-conformance. [3 pts.] 2. All tests provided per requirements of a story? 2 pt. deduction for each missing test. [10 pts.] 3. Are test input(s) and expected output(s) provided and properly written? 2 pt. deduction for each missing item. [10 pts.] 4. Did the demonstration show the before and after state of the backend database per story? 1 pt. deduction for each occurrence wherein the before and after state is not demonstrated. [15 pts.] 5. Are at least two epics that consists of at least four stories per epic completed (epic scenario)? Alternatively, are there at least eight stories completed (non-epic scenario)? 4 pts. deducted for each incomplete story or failed implementation. NOTE: a story is considered "complete" if and only if all test criteria pass as expected and test coverage is complete per story requirement. [4 x 8 = 32 pts.] 6. Demonstration proceeded at a clear and consistent pace (i.e., clearly state the story, address each test associated with the given story, colour code the story and tests appropriately based on the result of each test)? [5 pts.]
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
  • Access to all documents
  • Unlimited textbook solutions
  • 24/7 expert homework help
6 The information from this section can help me better understand the results of your demonstration as outlined in the earlier sections. 2.2 PRODUCTION CODE GRADE BREAKDOWN (25 PTS.) 1. Source files formatted as required by industry standard. 1 pt. deduction for each instance of non-conformance. [5 pts.] 2. All source code documented according to industry conventions and standards with respect to the programming language(s) and/or framework(s) in question (e.g., Javadocs for Java). 1 pt. deduction for each instance of non-conformance. [10 pts.] 3. Proper coding standards should be adopted. That is, the following principles should be adopted: variables names are intuitive, magic numbers avoided, KISS, SRP, and DRY. 1 pt. deduction for each instance wherein the foregoing principle is violated. [5 pts.] 2.3 TEST CODE GRADE BREAKDOWN (10 PTS.) 1. At least five methods unit tested? [5 pts.] 2. Are the methods unit tested represented core methods (examples of non- core methods are accessor methods)? [3 pts.] 3. Any automated black box testing tool used? [2 pts.] 3.1 CHALLENGES AND SOLUTIONS Although this section does not have any marks allocated to it, it does help me better understand your project. Here, your team can discuss the challenges and the corresponding solutions 6 . Possible challenges and solutions that can be discussed include, but not limited to the following: System setup and configuration of the back-end system (e.g., web server, database server, cloud service, etc.). Complex design and implementation of algorithms. Team conflicts and resolutions.