共计 9843 个字符，预计需要花费 25 分钟才能阅读完成。
Subject Name TCS3294 Windows Programming
Topic Windows Programming Assignment
Semester Feb – May 2022
Release Date Tuesday, 1st March 2022
Due Dates
Friday, 1st April 2022 @ 6pm (Stage 1)
Friday, 20th May 2022 @ 6pm (Stage 2 & 3)
Total Marks 100
PLEASE READ ALL INSTRUCTIONS AND INFORMATION CAREFULLY.
This assignment contributes 100% to your final course mark.
- This is a GROUP assignment (maximum of TWO (2) members per group).
- You are required to compile all your work into one folder (ZIP file) and upload the softcopy
on blackboard.
IMPORTANT INFORMATION
You are required to submit your work within the bounds of the University Infringement of
Assessment Regulations. Plagiarism, paraphrasing and downloading large amounts of
information from external sources will not be tolerated and will be dealt with severely. However,
you should make full use of any source material, which would normally be an occasional sentence
and/or paragraph (duly referenced) followed by your own critical analysis/evaluation.
The work must be entirely your own. You will receive ZERO (0) mark for work that is not your
own. The safety of your assessments is your responsibility. You must not permit another student
access to your work. Where referencing is required, APA referencing system must be used.
TCS3294 Windows Programming
2 - Assignment Aims:
The aim of the assignment is to expose students to analyse a variety of problem solutions in terms
of the design concepts and programming constructs. This assignment will allow the students to
produce appropriate system development documentation with complete program using C#.NET
Framework programming language and SQL Server. The students should be able to apply their
knowledge and skills, creativity, and critical thinking in completing the assignment. - Assignment Instructions:
This is a group assignment which carries 100% coursework. Submit your final documentation on
Blackboard (BB) before/by the DUE DATE.
• MS Word Formatting - Font size: 14 points for title/heading, 12 points for contents and 8-9 point for
headers/footers. - Font type: Arial
- Line spacing: 1.5
- Proper alignment of your paragraphs, and necessary page set-up.
- Number all pages sequentially.
- Number all Figures and Tables sequentially and refer to them in the text.
• Report submission should include: - Coursework cover page
- Table of contents
- System design (refer to Stage 1 on page 4)
- User manual
- Justifications for changes made to the system design (if any)
- Test plan
- Source code
- Reference list – APA Style (if necessary)
TCS3294 Windows Programming
3 - Case Study
Design and implement an Inventory Management System for a grocery store. The system includes
two modules: ADMIN and STAFF.
Admin is responsible for maintaining the database containing data regarding the store. Admin
can add, delete, update, and search details of staffs, products, and supplier. Admin can also
generate the reports of staffs, products, and suppliers at a particular time.
For staff, the following information is required to register: staff ID, username, password, date of
birth, phone number, email address, and employment status (part-time or full-time). Staff can
login and can view and update his/her personal details. Staff can also add, delete, update, and
search details of products and supplier.
Product details include product ID, product name, product category, number of units ordered
from the supplier, number of units currently in the store, number of units sold, supplier’s price
for the product, and the store’s selling price.
Supplier details include supplier ID, supplier phone number, address, etc.
The system must be menu-driven, giving the user various choices of functions based on their role
such as ordering a product, selling a product, checking whether a product is in the store, printing
the report, etc. After a product is sold, the appropriate count for that product will be updated.
Initially, the number of units(of a product) in the store is the same as the number of units ordered
from the supplier, and the number of units of a product sold is zero.
The program should also have information on the total inventory value and the total number of
products. The total inventory value is the total cost of all the products currently in the store, while
the total number of products is the sum of the number of units of all the products in the store.
You are required to model your design based on the scenario given above. The quality of your
system will be based on how detailed your system design is and the level of completeness of your
design and your system.
TCS3294 Windows Programming
4
Program requirements:
• The system should have the following:
➢ Insert and modify data accordingly to show functionality of the system.
➢ Save data to the database.
• Validations must also be implemented – your system should be able to handle invalid input
and null values from the users by displaying error message and asking the users to re-enter
the correct input.
• You must follow the naming convention for your forms, controls, and attribute names.
• Your program should be compiled and executed using Visual Studio and SQL Server. - Tasks
PART A – STAGE 1 DESIGN [20%]
• Your DESIGN should include:
✓ Functional and Non-Functional Requirements
✓ Use Case Diagram
✓ Database Design – your database’s tables should have primary keys and foreign keys
wherever required.
✓ Wireframe / Prototype – your system’s initial interface.
• NOTE: You should describe the design process with reasonable justification(s) to support
your design approach. You will get very low marks if you simply dump the entire system
design (diagrams) with no justifications provided.
PART B – STAGE 2 DEVELOPMENT [60%]
• The deliverables of this stage would be IMPLEMENTATION and TESTING of your system.
You are required to implement all functionalities proposed in Stage 1, as well as input
validations.
• You are also required to submit a REPORT detailing the system’s development. The report
should contain:
✓ User Manual to guide the user on how to use your system.
✓ Reasonable justifications for the changes made to the design – if there are any
changes made to the initial design of your system (which was proposed in Stage 1).
✓ Test Plan to test your system. Your test plan should include a set of possible inputs
along with the expected outputs and the results produced by the tests in the test
plan.
✓ Source Code
• NOTE: All files must contain the following information: your name, student id, course, and
date within comments (in the header) in the source code and the report document.
TCS3294 Windows Programming
5
PART C – STAGE 3 DEMONSTRATION [20%]
The DEMONSTRATION session enables the lecturer to access the originality of your work and
test on your understanding of the assignment. - Assignment Timeline
The following is a guideline for completing your assignment.
Task What to do Duration Mode of Submission - Document the design
rationale.
(Stage 1)
Week 3 to week 7
*Submit on 1
st April 2022
Softcopy - Develop a complete
system
(Stage 2)
Week 8 to week 13
*Submit on 20th May 2022
Softcopy - Prepare documentation
of system’s development
(Stage 2)
Week 8 to week 13
*Submit on 20th May 2022
Softcopy - Demonstration of the
complete system.
(Stage 3)
Week 13
*Submit on 20th May 2022
Recorded Demonstration
video, approximately 15 – 30
minutes
IMPORTANT NOTE:
• Please submit your assignment by or before the deadline.
• LATE SUBMISSION will be DEDUCTED 5% penalty A DAY up to a maximum of FIVE (5) days,
where subsequently, the assignment will be awarded ZERO (0) mark.
• ZERO (0) mark will be given if there is any form of copying/plagiarism.
• ZERO (0) mark will be given if you fail to submit your work or fail to submit all the necessary
files.
TCS3294 Windows Programming
Marking Rubric
Stage 1: Design (20%)
Exemplary
(16-20)
Good
(13-15)
Needs Improvement
(10-12)
Unsatisfactory
(0-9) Marks
• Complete 90% and above
functional requirements and use
case diagrams.
• Excellent showing of all the
program design of the system.
• Excellent justifications provided.
• Complete 75% and above
functional requirements and use
case diagrams.
• Good showing of the program
design in the system but some
parts were omitted.
• Reasonable justifications
provided
• Complete 50% and above functional
requirements and use case diagrams.
• Average showing of the program design
in the system, but some parts were
omitted.
• Justifications are provided but not well
justified
• Poor or below 50% functional
requirements and use case
diagrams.
• Average presentation of the
program design with majority
of the parts omitted.
• No justifications provided
Stage 2: Development (60%)
Exemplary
(16-20)
Good
(13-15)
Needs Improvement
(10-12)
Unsatisfactory
(0-9) Marks
SYSTEM (20%)
• The application works well and
meets all the requirements
specifications.
• No errors, program always works
correctly and produces desired
output
• Executes perfectly without errors
• System interface is visually
appealing. Components are laid
out sensibly on the screen.
• Minor details of the program
specification are violated,
program functions incorrectly for
some inputs.
• Executes with one or two minor
errors.
• System interface is pleasant
looking, clean, well-organized.
• Significant details of the specification
are violated, program often exhibits
incorrect behaviour.
• Overly cluttered interface. The workings
of the features are unclear.
• The program performs tasks
that it was not supposed to
perform.
• Program only functions
correctly in very limited cases
or not at all
• System interface seems
inappropriate for problem area.
7
Exemplary
(16-20)
Good
(13-15)
Needs Improvement
(10-12)
Unsatisfactory
(0-9) Marks
CODE (20%)
• The code is extremely efficient
without sacrificing readability
and understanding.
• Excellent implementation of subunits.
• Validations are implemented
correctly.
• Comments for code segments
make the code easy to follow.
• The code is fairly efficient
without sacrificing readability
and understanding.
• Contain some level of subunits
with sufficient documentation.
• Most of the validations are
implemented correctly.
• Comments provide some
assistance with understanding of
the code.
• The code is not that efficient and
unnecessarily long.
• Insufficient implementations of subunits.
• Some validations are implemented
correctly.
• Some parts of the code are commented.
• The code is huge and appears
to be patched together.
• None or very weak
implementation of sub-units.
• Validations are not
implemented / implemented
incorrectly.
• No comments included or other
documentation provided.
REPORT (20%)
• Excellent justifications provided
(if there are any)
• Testing was carried out
extensively. Thorough and
organized testing has been
completed and output from test
cases is included.
• Complete user manual provided
with clear explanation.
• Reasonable justifications
provided (if there are any)
• Testing was carried out.
• Complete user manual provided,
but some explanation can be
quite confusing.
• Justifications are provided but not well
justified (if there are any)
• Testing was carried out, but not
complete.
• User manual provided but not complete
/ not clear.
• Justifications are provided but
not well justified (if there are
any)
• Testing was not done.
• User manual is not provided.
Stage 3: Demonstration (20%)
Exemplary
(16-20)
Good
(13-15)
Needs Improvement
(10-12)
Unsatisfactory
(0-9) Marks
• Excellent effort in planning and
communicating the project idea
effectively.
• Good effort in planning and
communicating the project idea.
• Average effort in planning and
communicating the project idea.
• Very little or no effort in
planning and communicating
the project idea.
