UNIVERSITY OF TECHNOLOGY, SYDNEY
41025 Introduction to Software Development
Project – Implementation & Testing
Assignment 2
Due Date: Softcopy Due by Friday 14/05/2021 11:55 PM AEST
Showcases in Week Commencing from 17/05/2021 –
During Related Workshop: See workshop schedule on UTS Canvas for exact dates/ time slots)
Submission: Each group should assume the role of a Software Start-up Company. Each group will submit the following two items for the IoTBay project:
Working Software: Working software application code will not be submitted via Turnitin. The individually implemented (modules or features) working software application code will be integrated and collated in a single project Zip including single database. Submit ISD project working software code files (source and executable) with readme file (how to deploy and run the software) as a single Zip file in the Canvas Assignment 2/ “Working Software Code Submission” folder using your relevant workshop link before 14/05/2021 11:55 PM AEST. You can submit the software only once. You must not make any changes once the software code is submitted. If you make any changes after the submission due date, then the late assignment rules will be applied.
Report: Each group will submit a softcopy (Microsoft Word File or PDF) of the group report containing individual group member contributions. The individual student contributions or parts will be highlighted (with their names and student ids) and collated in a single group deliverable file for submission and assessment (group submission but individual assessment). Each individual contribution will provide the (1) brief description of the assigned software application feature or module, (2) non-functional aspects, and (3) software testing results with executed tests and (4) defect log including (5) individual contribution logbook/timesheets via Turnitin before 14/05/2021 11:55 PM AEST. Use the Project – Assessment item 2 Turnitin link in the Canvas Assignment 2 folder for submitting your assignment.
Your both software code and report submission files title/name must follow the following naming pattern.
Your workshop activity number–group id
For instance, if your Wrk1 activity number is 02 (see timetable for your activity) and group id is G1 then your submission file title/ name must be worded as 02-G1. From each group only one student (project leader) should submit the assignment on the behalf of the whole group. You do not need to put the student ids of all the group members on the file title/ name. You must check Turnitin report and ensure that your work does not contain plagiarism. You may submit your report to Turnitin many times before the submission due date. Final Turnitin reports can be used as evidence by the teaching staff if plagiarism is suspected in an assignment and will be dealt as per University rules. Do not allow anyone to copy your solution – this is considered misconduct; all miscreants will receive a mark of 0, at best for the assignment and will be dealt as per University rules. You may be required to provide the hard or soft copy of the assignment anytime during the semester.
Marks: 30%
Word Limits: There is no word limit. It is not an essay. Therefore, it is not about the number of words or pages. Assignments in this subject are looking for quality and to-the-point professional work excluding unnecessary information or brain dump. You can express yourself in 20 or 200 pages, it is up to you. No student will be advantaged or disadvantaged by being less or more words or pages. Focus on quality and not on the number of pages and words.
Method: The assignment will be done in a group (preferably in the same workshop and same group as for assignment 1). Group size should be limited to 4 and no more than 6 students (enrolment numbers and situation-specific circumstance will dictate the actual size of the groups). Groups were formed for assignment 1 (during Weeks 1-4) and for any reason(s) you want to change the group for assignment 2, then it is solely your responsibility to make other arrangements and find another alternative group who is willing to accept you. You cannot change the group once you have started the assignment 2 (Week 7 onwards). This is a group assignment, however each student in the group needs to implement (code) and test end-to-end (as per MVC architecture layers) a complete working (free of defects) software feature or module as their individual contribution. If the overall software works but an individual’s implemented software feature or module does not work according to the requirements, then that individual will receive zero mark for this assignment. This way other members in the groups will not be affected by the no or poor performance of an individual. You must respect other students in the same group, different groups and teaching staff. If you have any group issues, then you must inform your workshop tutor as soon as possible and well before (at least 3 weeks or earlier) the assignment submission or due date. Group assignment issues reported on or after the assignment submission date may not be considered. There will be zero tolerance for any academic and non-academic misconduct. See University Rules, Subject Outline and Academic Misconduct section of this brief for details.
Objectives: Subject objectives: 1, 2, 3,4 and 5
1. Investigate and solve software development problems with minimal supervision.
2. Determine and balance the competing goals of software development activities within their constraints
3. Plan and manage a software development task to create, modify or extend a software feature or function to completion within the task constraints.
4. Apply sound software engineering practices to successfully create, modify or extend a software feature or function.
5. Clearly Communicate software and task information to interested stakeholders
Type: Project
Groupwork: Group, individually assessed
Criteria: The assignment will be individually assessed based on the following criteria.
Criteria Items
Objectives
Weight
Working software application implementation and demonstration (35 Marks)
1,2,3,4
70%
Tests of the solution (10 Marks)
1,2,3,4
20%
Overall quality, presentation (5 Marks)
5
10%
Total
–
100%
There are no group marks. This means the individual marks for the Assignment 2 shall be based on individual contributions in all three criteria items across all the layers of the MVC architecture as a full stack developer. Please also note that there will be no negotiation on a wrong answer. An individual’s mark for this group work assessment shall be computed as:
Individual Student Contribution & Mark = Working software application [assigned feature] (all the layers of MVC) + Tests of the solution [assigned feature] + Overall quality, presentation [assigned feature]
Task: You are required to develop a web software application for Online IoTBay. The software should be developed using agile practices and following and MVC architecture designed and planned in assignment 1. You can adjust the above in consultation and approval from your tutor during the assignment 2. This assessment task will require a team of 4-6 students to produce, submit and present a group report (comprises of individual contributions), small working software application (comprises of individually implemented and tested software features or modules) and individual contribution logbooks/ timesheets for release 1 (see minimum viable product section) for Online IoTBay. Based on the plan, software requirements, architecture, and design (submitted for Assessment Items 1) for release 1 (minimum viable product), each individual student in the group shall:
Working Software Application: Each student in a group will implement and test the assigned (as agreed between the group members and approved by the tutor as a product owner) feature or module of the small software application; and
Report: Each student in a group will provide the brief description of the assigned software application feature or module, non-functional aspects, and software testing results with executed tests and defect log.
The individual student contributions or parts will be collated in a group deliverable for submission and assessment (group submission but individual assessment). The deliverables of this assessment task also include a compulsory oral/visual presentation (no PowerPoint slides) of the individually implemented working software application during the scheduled assignment assessment or review session (showcase), individual contribution logbooks/ timesheets and working software code implemented – as per Subject Weekly Schedule. Any whole team or individual student who failed to appear and present in these compulsory assignment assessment and review sessions (Showcase) will receive zero (0) as a final individual mark. Each ISD project team needs to nominate a project manager/ lead who will submit the assignment 2 (software and report) on the behalf of the whole group or team.
Summary
Each group shall explore different ways of ensuring quality outcomes through the agile development and testing approach. This can be supported through a set of software development and testing tools. Please note that the work done in the Assignments 1 is a starting point for students to produce the working software and report in Assignment 2. Working software must be developed and tested for release 1 of IoTBay (minimum viable product). Students must get feedback on their work-in-progress project from their tutors (product owners) during the workshop sessions before formal submission.
Note: It is recommended that the essential functionality of the assignment will be implemented using the web technologies and techniques taught in this subject (e.g. Java, JSP, JDBC, Java DB). You are not allowed to use any other technology or framework. You can use CSS or bootstrap framework for web pages and user interface.
Minimum Viable Product
You have already implemented the initial prototype in assignment 1 (prototype). It was the starting point of the web application and provided the options of login and register to users (without database connectivity). It should provide further implementations, pages and links for other features (see table below) with appropriate navigation between pages (view), controller and model including database tables and sample data. In consultation with your tutor during Assignment 1 Showcase, you should confirm/ finalise the features from the following table (e.g. 1 feature per team member) for the minimum viable product, update the backlog, assign the individual feature to the team member and align the user stories captured in assignment 1. Features 01, 02, 03 and 04 are mandatory and foundational features for the minimum viable product (release 1). If you are 4 people in a group, then you will include these mandatory 4 features for the implementation and testing for release 1. For 6 people in a group, you will select these mandatory 4 features plus any of the other 2 features of your choice from the list to ensure that each student in a group has the responsibility to implement an individual end to end feature using MVC. Special circumstances or group size (<3) may change the group work in consultation with the tutor and subject coordinator. Professional software development and learning requires team effort. The purpose of the following key features table is to teach you and demonstrate how to systematically organise features (e.g. data capturing/data management to BI & reporting). You can apply these learnings to other Industry and University projects.
IoTBay Key Features Table (General Description: CRUD)
IDFeatureCreateRead UpdateDeleteResponsible01Online User Access Management [MVC]
This applies to both customer and staff user.A user (e.g. customer, staff) can sign up online (full name, email [as a username], password, phone)
A registered user access logs (user id, login date/time, logout date/time) are stored in the database.A registered user can view their registration detail.
A registered user can login and logout from the system.
A registered user can list (view) their access logs and search the log records based on the date.A registered user can update their registration details.
A registered user cannot update their user access logs.A registered user can cancel their registration.
A registered user cannot delete their user access logs.e.g. put a name of the team member for the end to end delivery of this feature (MVC).02IoT Device Catalogue (Collection) Management [MVC]Only staff user can create the IoT device (product) details in the database. i.e. device name, type, unit price, quantity (stock).Customer and staff user can list the IoT device records.
Customer and staff users can search and list the devices based on their name and type.Only staff user can update the saved IoT device records.Only staff user can delete the saved IoT device records. 03Order Management [MVC]A customer user (registered or anonymous) can create (save, submit) an order for IoT devices. A customer user can view their saved order details, order history list, and search the orders based on the order number and date.A customer user can update their saved order before final submission.A customer user can cancel their saved order before final submission.04Payment Management [MVC]A customer user can create payment details (payment method, credit card details, amount, date) for their order (payment id linked to order id).A customer user can view their saved order payment details, payment history list and search the specific payment records based on the payment id and date.A customer user can update their saved payment details record before finalising the payment.A customer user can delete their saved payment details record before payment submission05Shipment Management [MVC]A customer user can create shipment details (e.g. shipment method, date and address) for their order (shipment id linked to order id). A customer user can view their saved order shipment details, history list and search the specific shipments based on the shipment id and date. A customer user can update their saved shipment details record before shipment record finalisation for their order.A customer user can delete their saved shipment details record before shipment record finalisation for their order.06User Management [MVC] System admin can create users (both customer and staff type users). *System admin is a built-in user with any software app.System admin can view the created user records, user list and search the users based on their full name and phone number.System admin can update user details and activate/ deactivate their status.System admin staff can delete users.07Customer Information Management [MVC]System admin can create customer records (name, email, type, address).System admin can view the customer record, customer list and search the customer based on their name and type [company or individual].System admin can update customer details and activate/ deactivate their status.System admin can delete customers.08Staff
Information Management [MVC]
System admin can create staff records (name, email, position, address).
System admin can view the created staff record, staff list and search the staff based on their name and position [e.g. salesperson, manager].System admin can update staff details and activate/ deactivate their status.System admin staff can delete staff.09Supplier Information Management [MVC]System admin can create supplier records (contact name, company, email, address).System admin can view the supplier record, supplier list and search the supplier based on their contact name and type [company].System admin can update the supplier details and activate/ deactivate their status.System admin can delete suppliers.10Data Management
[MVC]System admin can create new records (e.g. user, customer, staff) using bulk import to the system (e.g. CSV).System admin can view records while bulk importing to the system for checking the data quality and confirmation.System admin can update records in the system via bulk import.System admin can delete or export records from the system in bulk.11BI & Reporting
[MVC]System admin can create reports and dashboard as requested by the various users (e.g. daily sales report, stock report) Users (e.g. customer, staff) can run and view reports and dashboard as appropriate to their role and needs.Users can customise reports and dashboard as appropriate to their role and needs.System admin can delete reports and dashboard as requested by the users.* User id, customer id, staff, order id, shipment id etc. can be autogenerated in database.
Implementation Guiding Points:
Index page (home page) is the starting point of the web application and should provide the options of login and register to users and links to other feature pages (e.g. Device Catalogue, Order). Allow users to logout (to index page) or go back to your Main page from anywhere. Follow general web application navigation mechanisms.
If a user cancels an order, then the order status is set to “cancelled”. However, the cancelled orders are still stored in database.
If a user cancels their user account, all saved orders made by this user should be automatically cancelled and orders details should be saved in database with their status marked as “cancelled”.
Once a user places an order, the number of devices should decrease accordingly. If a user cancels the order, then the number of devices should be added back accordingly to the relevant device quantity number in the database.
If a device has zero stock/ quantity, then users should not be able to order it.
As you add more pages to your web application, make them available from home page or relevant page. Apply general navigation mechanism for ease of use and access.
As a team create a single database for your software. You must populate your database tables with sample data such as users, devices, orders etc. At least 20 records in each table. You can directly add these sample records through database management system interface. This is to enable the development and testing of the features in parallel. For instance, while one student is working on the order feature then he/she can use the product id and relevant details from the test data stored in the database without waiting for the other student to complete their device catalogue management feature.
Your web application should perform validation of inputs to prevent system crashes. In the case of your web application, you should display an appropriate error message if the user has inputted incorrect data, allowing them to re-enter the data. The data validation should be server-side not client side (do not use client-side Java Script or CSS for data input validation). This is for the purpose of server-oriented web development learning regardless of a good practice. Verify the input data against corresponding data stored in the database, where applicable.
Your user interface should be well thought out, providing a consistent look and feel on all pages, and providing useful navigation links. The user should be able to get to where he or she wants to go without ever having to click the browser's back button. You can use bootstrap framework for user interface.
Your code should be well designed, commented and neatly formatted.
Note: This project will challenge you from different perspectives and develop your professional capability and practical understanding that
“Design is a code” (do you need upfront detailed plan and design? How much upfront plan and design is enough?),
“Collaboratively developing/ synchronising software code is challenging as a part of a team”,
“Adapting to change” and
“What it takes to become a full-stack developer”.
Assignment 2: Consolidated Working Software Deliverables & Report
ITEMS
Maximum Marks
Note
Cover Sheet, Project Title/ Header Page & Individual Student Contribution Page
-
Cover Sheet & Project Header Page: Sign, scan and embed FEIT declaration of originality cover sheet containing correct group name, student id, name and signatures in the report just before the project title/header page.
Individual Student Contribution: At least 1 service/feature per team member covering all the layers of MVC (including database) for the report and working software for release 1 (minimum viable product). Choose the features from for the minimum viable product for release 1 (see Minimum Viable Product Section):
Roles: Registered user (customer, staff), Anonymous user (non-registered customer), System admin (default built-in user for the application)
Each service or feature can be linked to several user stories. Include the individual student contribution page in this report with the following information (see Minimum Viable Product Section):
Student ID, Name, Assigned Feature/Service
If you do not include these pages then assignment will not be marked, and you may receive zero for the whole assignment.
1. Working software application implementation and demonstration
35
Working Software Code (MVC)
View (CRUD)
*Each student to develop view for their assigned feature.
(10)
Working user interface View pages. The View pages should have following items:
Meet feature/ user stories/ requirements (4 Marks)
Clear and consistent page layout, look and feel (1 Mark)
Easy to navigate between pages and main index page (navigation links) (1 Mark)
Provide validation (server side) of inputs (data) to prevent system crashes (2 Marks)
Provide an appropriate error message if the user has inputted incorrect data, allowing them to re-enter the data (2 Marks)
Note: Do not use client-side Java Script or CSS for data input validation.
Controller (CRUD)
*Each student to develop controller for their assigned feature.
(10)
Working Controller(s) to control the data flow between the View and Model. Controller layer acts as an interface between View and Model. It receives requests from the View layer and processes them, including the necessary validations (server-side validations). The requests are further sent to Model layer for data processing, and once they are processed, the data is sent back to update the View. The Controller should have following items:
Meet feature/user stories/ requirements (8 Marks)
Controller classes/pages/ servlets handle the data traffic between the model (DAO) and the view (2 marks)
Model (CRUD)
*Each student to develop model for their assigned feature and connect it to the single/ central database. No individual databases.
(15)
Working Model layer. This layer contains business logic of the system and represents the state of the application. It is independent of the View layer; the Controller fetches the data from the Model layer and sends it to the View layer. Model layer is also connected to the Database. The Model layer including the connected Database should have following items.
Meet feature/ user stories/data requirements (4 Marks)
Reusable Java Beans (4 Marks)
Data Access Object (DAO) & Database Connectivity (2 Marks)
Database Tables & Attributes (2 Marks)
Appropriate Table data constraints & relationships (2 Marks)
Sample data in the database – at least 20 records in each table (1 Mark)
2. Test of the Solution
10
Report
Software Application Feature
*Each student to provide the description of their assigned feature.
(1)
Provide a brief functional description of the assigned software application feature or module and its mapping to user stories (CRUD). Indicate any changes in the user stores/design etc. since assignment 1.
Non-functional Aspects
*Each student to provide the description of their assigned feature.
(1)
Provide a brief description of the non-functional aspects of the assigned software application feature or module. Indicate any changes in the non-functional since assignment 1.
Software Testing Results
*Each student to document acceptance test and testing results for their assigned feature.
(4)
Document 1 acceptance test criteria and 1 Junit for each user story relevant to your feature or service from release 1. Record acceptance test case (linked to a user story), and Junit test case in the test matrix (e.g. excel spread sheet or MS word table).
Defect Log
*Each student to document defect log for their assigned feature.
(4)
Keep a log of the failed Junit test cases in a table or spread sheet.[Each Student must have their own test logs]
Defect log should have at least following items (you can include additional items).
Defect ID (DI001)
Defect Description (e.g. problem and action)
Defect Date
Test Case ID (e.g. Failed test case id)
Tester Name (e.g. who reported the defect)
Responsible (e.g. who will handle the defect)
Status (e.g. identified, assigned, in progress, resolved, unresolved defects)
Comments (any additional comments)
Summary: total defects, % of resolved defects, % of in progress defects.
Appendices –
Project timesheet
-
Each student to complete and submit the timesheet signed by their project lead.
Note: Assuming each student in the ISD project team is working 8-10 hours per week for this project. If a student does not submit timesheets, then he/she will receive zero for their project mark.
Appendices –
Individual Contribution Logbooks
-
Include contents from the Individual Contribution Logbooks. Link your individual contribution to weeks and hours recorded in timesheet.
The individual contribution logbook is mandatory for students to submit with each Assignment: Assessment Items (1-2) to receive individual project marks. If a student does not submit this logbook, then he/she will receive zero for their project mark.
3. Overall Quality, Presentation
5
Quality of visual/oral group report and software demonstration. You are not required to prepare and submit the presentation slides. Launch and present the report submitted via Turnitin. Present software from your laptop or as advised by your marker.
Report is clear and easy to follow (2 Mark)
Software code is commented and neatly formatted (2 Mark)
Overall correctness of answers to the questions (1 Mark)
Total Maximum Marks
50
Note: You must demonstrate (present) working software (from your laptop) during showcase and submit working software code before assignment 2 due date. If as a team member you were not present during the showcase for demonstration, questions, and answers relevant to your software feature or service module then you will receive zero individual marks for this assignment (0 out of 50).
Note: Please note that if the software failed to compile or run during the presentation or you did not present the software during the scheduled showcase time then Zero mark will be given for this assignment.
Assessment Feedback
Feedback on the marked assignments will be within 2 weeks after the assignment due or submission date. You should regularly get feedback on the assignment tasks and deliverables from the tutors during the workshop sessions.
Minimum Requirements
See subject outline for details. NO conceded passes are to be granted due to University Policy.
Referencing Standards
All material derived from other works must be acknowledged and referenced accordingly using the Harvard Referencing Style (see HYPERLINK "http://www.bell.uts.edu.au/referencing/harvard_system" http://www.bell.uts.edu.au/referencing/harvard_system).
Late Penalty
See subject outline for late submission penalty, unless an extension has been approved by the subject coordinator.
Special Consideration
Special consideration, for late submission, must be arranged beforehand with the subject co-ordinator (email: HYPERLINK "mailto:asif.gill@uts.edu.au" asif.gill@uts.edu.au). Please also see the UTS Special Consideration Process: HYPERLINK "http://www.sau.uts.edu.au/assessment/consideration" www.sau.uts.edu.au/assessment/consideration
Special Needs:
Students should email the subject coordinator as soon as possible (and prior to the assessment deadline) to make them aware of the impact on them meeting assessment component/requirements, and that they are seeking assistance through UTS Special Needs as detailed in Section 5.1.3 of Procedures for the Assessment of Coursework Subjects.
Academic Misconduct:
Please see the subject outline for plagiarism and academic integrity in conjunction with UTS policy and procedures for the assessment for coursework subjects.
Querying Marks/Grades and Final Results
See subject outline for details.
Agile Values for Software Development
This subject would help you to reflect and understand the logic/ deep thinking underpinning the agile values.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
41025 ISD Assignment 2 Autumn 2021
PAGE
PAGE 10
31269 BRM Assignment 1 Spring 2102
© Chris S. Johnson 2012