Final Presentation
docx
keyboard_arrow_up
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
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.