Starting from:
$35
Warehouse Management (WM) Assignment 1 -Solution- with reports
TASKS
Your tasks are to:
Form and structure your group, allocating roles and responsibilities to your members
Elicit and specify requirements for the system ( see Appendix A ), including:
all detailed functional and non-functional requirements for the new system
the data that the system will need to manage,
interfaces to other systems, and
interfaces and functionalities for different classes of users
The lecturer and tutor will act as clients for this project. You would also need to explore existing similar systems that are available online
Complete the planning and the requirements analysis for the system that is described in the attached informal specification document
Use a versioning system of your choice (e.g. Netbeans subversion, TortiseSVN)
Produce a report detailing the group's work
The book “The rational unified process: an introduction” by P. Kruchten[1] contains explanations of the Rational Unified Process (RUP) roles. Details include lists of artifacts that are the responsibility of a person holding a particular role, and workflow diagrams. Students should check these outlines to gain guidance as to what they are to do in the project.
Each group will hold formal "minut-ed" meetings. The group member holding the "manager" role is responsible for these meetings, in particular preparing agendas and keeping meetings on track, and is also responsible for the reports on meetings. The meeting structure should be along the following lines:
Reports from individuals who were allocated "urgent action items" in the previous meeting; discussion of issues related to these "urgent action items"
Manager reviews his/her perception of the current status of the project; this review is to use data from bug reports and feature tests as created by the systems integrator
Scheduled agenda items are discussed - in the early meetings this will involve resolution of open design issues, later it will involve review of progress on implementation elements and integration
Reports by individual members on progress in their areas of responsibility ("code walkthroughs" may be used) and identification of any problems
Identification of any "urgent action items" and allocation of responsibility for these
Proposals for agenda items for the subsequent meeting
Each group member will maintain a work diary. This should cover: planned work schedule, actual work times, summary of work completed, report on "defects" in own work. The purpose of a work diary is really to provide data that identify ineffective work practices so that remedial action can be taken[2].
Often you will find planned and actual work times differ significantly; such differences may point to poor work management practices. Every developer has his/her own blind spots that lead to defects in code. Analysis of defect patterns can help identify weaknesses and thus lead to a pre-emptive approach where the developer checks for their typical errors prior to running code.
( Note : for further details on RUP, roles and meetings, please refer to Appendix B )
REPORT
The work of the group is to be presented in a report. The report is the basis for your assessment. The report should briefly present the product that you are developing and provide evidence for a competently handled development process.
It should use grammatically correct English and should not contain innumerable spelling errors. You should use the spelling and grammar checkers in your word processor application.
The report should consists of the following:
Business case: What is this system that you are to build? Who will it serve? What will it do for them?
Detailed plans for the whole project (from requirements until implementation)
Risks and counter measures
Software Requirements Specification ( refer to SRS_Template.pdf )
Use cases (including use case diagrams and detailed description for each use case)
A domain model with detailed description of each class
The “meta-report” part should include:
A tabular summary of the group structure identifying group members, the roles that they filled, the artefacts that they successfully delivered
Group meeting records and individual diaries:
There should be a summary detailing the work done at each group meeting
There should be agendas and reports from all group meetings
There should be work diaries of all members of the group
· Provide evidence for the appropriate use of version control software; this would typically take the form of excerpts from subversion’s logs of commit operations. Subversion (or equivalence) statistical reports, showing overall contributions by different members, should be included in the report
For further information on the report and delivery, please refer to Appendix C.
DELIVERABLES & SUBMISSION
Please refer to Appendix D.
MARKING SCHEME
· Overall presentation of report (2 marks)
· Requirements elicitation and analysis efforts as evidenced by your report (9 marks)
· Project management (4 marks)
These marks are based on evidence for the use of an effective software development process. Factors contributing to this part of the assessment will include:
- evidence for an effective group structure and adoption of roles
- effective group collaboration as evidenced by meaningful group meetings
- well-planned and disciplined work processes of individuals and
- effective use of a versioning system
Individual marks are based on the group mark. Individual marks are adjusted in accord with the “member’s contribution assessment” document submitted by the group. Individual marks cannot be greater than the group mark.
APPENDIX A
(Warehouse Management (WM) Tool)
An effective Warehouse Management (WM) Tool is essential for streamlining process, long range planning and optimization. It gives a better understanding of day-to-day operation with its summary information of how a warehouse is performing. The managers could use this data for making critical management decisions.
It is critical for the warehouse management to have an effective system in place due to various reasons such as security, accuracy, availability and so on. Therefore, you are asked to use a test-driven approach to develop the warehouse management tool which needs to meet the following requirements.
Functional Requirements
List of features include:
1) Ability to add/update records on the incoming stock and outgoing stock easily.
2) Track the stock in accordance to their category and sub-category.
3) Ability to search and display available stock for a particular category and/or sub-category.
4) Ability to search and display stock in accordance to price range and quantity in ascending and descending order.
5) Daily, weekly or monthly summary report of total incoming and outgoing stock details.
6) Provide login authentication process.
7) Login security feature with option of encrypting the data stored.
8) If there are three unsuccessful login attempts, the record will be marked as “locked” and one is not allowed to login to the system.
9) The system shall encrypt and decrypt the password.
10) Provide stock item alerts when it drops below a threshold set previously.
The WM may have the following interactive menu:
a) Add new stock
b) Remove stock
c) Edit stock item
d) Search stock item
e) Daily stock summary report
f) Weekly stock summary report
g) Monthly stock summary report
h) Yearly stock summary report
i) Quit
The WM allows new stock item’s details to be individually entered and then stored in a text file as the following format:
[Item ID]:[Item Description]:[Item Category]: [Item Sub-category]:[Amount Per Unit]:[Qty]: [Transacted date]
eg:
023:Samsung Phone XYZ:Electronics:Mobile Phone:300:100:15-Dec-12
053:Dan Sofa:Furniture:Sofa:1200:-10:15-Dec-12
045:Nike ABC:Shoes:Trainers:50:60:22-Dec-12
023:Samsung Phone XYZ:Electronics:Mobile Phone:300:-50:15-Dec-12
045:Nike ABC:Shoes:Trainers:50:-10:22-Dec-12
The colon (:) character is used to separate each piece of information.
Stock item In Out Amount(Per Unit) Total Amount
023 100 0 300 -30,000
053 0 10 1200 12,000
045 60 0 50 -3,000
023 0 50 300 15,000
045 0 10 50 500
A sample of the daily stock transacted is shown below.
You can also provide more information such as the total number of stock items available in the warehouse at any point in time.
Non-Functional Requirements
1. The system is to be implemented in C++ and is to run on a Linux OS.
2. The system is to use a simple textual “menu-select” style of user interface.
You need to elicit further requirements and specify them in much more detail in Software Requirement Specification by doing a further requirement analysis with your supervisor.
Note: The first part of this project (Assignment 1) involves planning and eliciting and analyzing requirements. The second part (Assignment 2) will involve designing, implementing and testing the system.
APPENDIX B
( Requirement / Task – Extra info )
The purpose of this assignment is to simulate the RUP approach to software development, starting with the requirements gathering, all the way to system analysis and design. (Note: for this Assignment, there is no need to implement (i.e. code) your system). However, your team must produce the necessary artifacts (i.e. documents) covering this aspect of your system development.
Form a group of 6 members, adhering to the following criteria:
o group members must come from the SAME class, absolutely no "inter-class" group members
o the no. of members in each group MUST BE EXACTLY THE SAME : 6, except in special situations where (# of students in a class) mod 6 != 0 (i.e. got remainder)
o if possible, try to achieve a balanced gender ratio of 1 : 1, (no boy-bands / girl-generation)
o in the event of special situations, the tutor will step in to assign "remainder students" to registered groups (i.e. some groups will have 7 members)
In general, your team should undergo (at least):
a) Inception phase : 1-2 iterations
b) Elaboration phase : 2-3 iterations
c) Construction phase : 2-3 iterations
d) Transition : 1-2 iterations
However, since this Assignment is mainly focusing on activities from Inception and Elaboration phases only, the iterations in Construction and Transition should be of lower priority
Based on the above, your team should have undergone a total of 3-5 iterations (in Inception + Elaboration phases). Therefore, the min. no. of:
a) formal meeting minutes should be = 3 !
b) formal work diary should be = 3 (for each team member, hence
5 team members x 3 = 15 work diaries for the whole team)
As mentioned in pgs 1-2 of this Qn Paper, each meeting minutes should cover the following points / decisions:
a) Progress status from individual members, who were allocated urgent action items in previous meeting [ 'N' paragraphs ]
b) Manager summarizes the overall progress of the entire system [ 1 paragraph ]
c) Brainstorm and discuss on any un-resolved issues / urgent action items from previous meeting [ 'N' paragraphs ]
d) Brainstorm and discuss on the remaining tasks (e.g. research / exploration /
development / testing / deployment ) to be done [ 'N' paragraphs ]
e) Decide how much time should be allocated to each issue / task [ 1 paragraph of bulleted points ]
f) Allocate tasks to team members [ use a table ]
g) Decide on the agenda (items/issues to discuss) for the next meeting [ 1 paragraph of bulleted points ]
Note : the paragraphs in "[ ]" is just a guideline on the format / usual length of the content!
As mentioned in pgs 1-2 of this Qn Paper, each work diary is like a "personal log" that tracks of a team member's personal progress. The diary should cover the following information:
a) The start + end date the period covers
b) What were the list of tasks allocated to you, (should be smiilar to the tasks allocated to you in the previous formal meeting)
c) For each task, discuss the following:
- how much "actual time" you spent on it
- did you breakdown the task into smaller sub-tasks?
- are all the sub-tasks completed?
- which sub-task(s) you faced difficulties, and how do you resolve it?
- did you discuss your problems with fellow colleagues? What were the remedial actions taken?
The roles required for this group assignment are:
· Manager (1) - the "Team Leader"
· Lead designer / implementer (1) - probably the same person, but the "lead" role could be split;
· Designer / Implementer / Documentation (many)
· Systems Integration and Testing (1)
The designated team leader should take the role of manager or of lead designer / implementer. Each implementer is responsible for unit testing of his/her code.
APPENDIX C
(Report Details)
A document "A1_Sample_Report_Format.doc" has been provided for you. All teams are to follow its recommendations to organize the contents in a structured manner.
Another document "SRS_Template.pdf " has been provided for you. It gives you an idea of the information required produce the Software Requirements Specification. Please adhere to the format and section headings in this template.
For all documentation produced, factors like how you communicate your ideas, how you organize your information and the "professionalism" (i.e. overall presentation) plays an important role in capturing your system's requirements and design.
- In order to communicate better in your report, where applicable, you should make use of visual elements like graphs, diagrams, charts, screen-shots, tables, appendices, glossary, etc. to help clarify your ideas
- In order to make your report content more professional and organized, you should have the following in your documents: Cover page, Table of Contents, Formatted document header and/or footer, proper paragraph indentation and alignment, consistent bulleted points, page numbering, etc.
During lab session, time will be allocated for each team to present their ideas. All teams are to:
- use power-point slides as the main presentation aid (optional : 'other' multi-media elements like video clips, role play, etc)
- ensure all members has "equal exposure" in presentation
- adhere strictly to the allocated time for presentation
( Note : In a real working environment, factors like starting presentation on time, adhering to time limits for presentation, being professionally dressed and not using Notepad to present your ideas, etc are crucial towards creating a good impression in the minds of CEO and senior management towards your project! )
APPENDIX D
Submission Instructions (V. IMPT!!)
1) Deliverables
a) Download "PeerAssess and GrpWrkContributionStmnt.pdf", fill it up and submit in HARDCOPY during the lab session.
b) All other submissions should be in softcopy, unless otherwise instructed
c) For the actual files to be submitted, you need to include the following:
i) MAIN REPORT word document (e.g. A1_MAIN_RPT.doc), save as MS Word 97-2003 format
ii) MAIN REPORT in PDF format (e.g. A1_MAIN_RPT.pdf)
iii) Software Requirements Specifications word document (e.g. SRS_v1.doc), save as MS Word 97-2003 format
iv) Software Requirements Specifications in PDF format (e.g. SRS_v1.pdf)
v) Powerpoint Presentation (e.g. A1_Presentation.ppt), save as MS Powerpoint 97-2003 format
2) How to package
Compress all your assignment files into a single zip file. Please use the following naming format :
<FT/PT_Assn1_<Team Leader's Stud. No._<Team Leader's Name.zip
Example : FT_Assn1_1234567_JohnDoeAnderson.zip
- <FT/PT Use “FT” for Full-Time student, “PT” if you are Part-Time student
- Assn1 if you are submitting assignment 1, Assn2 if submitting assignment 2 etc.
- <Team Leader's Stud. No. refers to team leader's UOW student number (e.g. 1234567)
- <Team Leader's Name refers to team leader's UOW registered name (e.g. JohnDoeAnderson)
3) Where to submit
Please submit your assignment via Moodle eLearning site.
In the event of UNFORSEEN SITUATIONS :
( E.g. Student's moodle account not ready, cannot login to moodle, eLearning site down on submission day, unable to upload assignment, etc )
Please email your single zip file to your tutor at :
csci222uow@yahoo.com for FULL TIME students
(To be announced) for PART TIME students
In your email subject line, type in the following information :
<FT/PT <assignment info <Team Leader's student number and <Team Leader's name
Example:
To : tutor's email (see above)
Subject : FT Assn1 1234567 JohnDoeAnderson
Note 1 : The timestamp shown on tutor’s email Inbox will be used to determine if the assignment is late or not.
Note 2 : After email submission, your mailbox’s sent folder would have a copy (record) of your sent email, please do not delete that copy !! It could be used prove your timely submission, in case the Tutor did not receive your email!
4) When to submit
a) Depending on the time-table, a demo / evaluation for your lab submission may be scheduled during the:
- 3rd - 5th lab session for the semester (i.e. lab 3 - 5), for Full Time (FT) students
- 2nd - 4th lab session for the semester (i.e. lab 2 - 4), for Part Time (PT) students
Please consult your tutor for further details. Some time may be allocated for each student to present / explain your system design during the session.
b) Please refer to the following table on the different submission events and deadlines
Assessment
Component
Submission Deadline
(latest by 2300 hrs)
Assessment
Presentation / Evaluation
Email Evaluation files by :
Lab
01 / 02 / 2017
Lab 2(PT), 3(FT)
End of Lab 2(PT), 3(FT)
Assn 1
20 / 02 / 2017
Lab 3(PT), 4(FT)
End of Lab 3(PT), 4(FT)
Assn 2
27 / 02 / 2017
Lab 4(PT), 5(FT)
End of Lab 4(PT), 5(FT)
Note: (PT) = Part Time Students, (FT) = Full Time Students !
c) Example #1, for Full Time (FT) students submitting Lab Exercises ...
- Submit your zip file to Tutor by 01 / 02 / 2017, 2300 hrs
- Setup your Lab Exercises submission for presentation / evaluation on the date of : Lab 3
- Finish evaluation tasks, email Lab Ex evaluation files by end of : Lab 3
d) Example #2, for Full Time (FT) students submitting Assignment 2 ...
- Submit your zip file to Tutor by 27 / 02 / 2017, 2300 hrs
- Setup your Assn2 submission for presentation / evaluation on the date of : Lab 5
- Finish evaluation tasks, email Assn2 evaluation files by end of : Lab 5
e) Some time will be allocated for each team to present / explain your system design during the session. The tutor will inform you on the presentation schedule as the deadline draws near.
5) Please help by paying attention to the following …
! VERY IMPORTANT !
PLEASE FOLLOW THE GUIDELINES IN ALL ASSIGNMENT APPENDICES !!
PLEASE FOLLOW THE SUBMISSION INSTRUCTIONS FROM 1 TO 4 !!
IF YOU ARE NOT SURE,
PLEASE CHECK WITH YOUR TUTOR DURING LABS / LECTURES !
OR ...
PLEASE EMAIL YOUR ENQUIRIES TO YOUR TUTOR !
MARKS WILL BE DEDUCTED IF YOU FAIL TO FOLLOW INSTRUCTIONS !!
Example :
· Your report document or zip file does not follow naming convention
· Your email address does not include your name (i.e. cannot be used to identify sender)
· You have no email subject
· Wrong naming or misleading information given
(e.g. putting “Assn2” in email subject, when you are submitting “Assn1”)
(e.g. naming “Assn1” in your zip file, but inside contains Assn2 files )
· Your submission cannot be downloaded and unzipped
· Your report cannot be opened by Microsoft Word / Powerpoint / Adobe Acrobat
· Your program cannot be re-compiled and/or executable file cannot run
6) Re-submission administration
After the deadline, (on case-by-case basis), some students / grp may be granted an opportunity for an un-official resubmission by the tutor. If this is so, please adhere to the following instructions carefully:
<Step 1
Zip up for re-submission files according to the following format :
<FT/PT_Assn1_Resubmit_v1_<Team Leader's Stud. No. _<Team Leader's Name.zip
Example : FT _ Assn1_Resubmit_v1_1234567_JohnDoeAnderson. zip
- <FT/PT Use “FT” for Full-Time student, “PT” if you are Part-Time student
- Assn1 if you are submitting assignment 1, Assn2 if submitting assignment 2 etc.
- Resubmit_v1 if this is your 1st re-submission
- Resubmit_v2 if this is your 2nd re-submission
- <Team Leader's Stud. No. refers to team leader's UOW student number (e.g. 1234567)
- <Team Leader's Name refers to team leader's UOW registered name (e.g. JohnDoeAnderson)
- V. IMPT - To prevent Tutor’s Inbox from blowing up in his face, each student is only allowed to re-submit twice, for each assignment only!
<Step 2
Please email your single zip file to your tutor's email (refer to section 3) - Where to submit)
In your email subject line, type in the following information :
<FT/PT <assn info <re-submission ver. <Team Leader's student number and < Team Leader's name
Example:
To : tutor's email (refer to section 3) - Where to submit)
Subject : FT Assn1 Resubmit_v1 1234567 JohnDoeAnderson
[1] The Kruchten book is available as an electronic resource through the University library's subscription to Safari.
[2] Take a look at Humphrey’s Personal Software Process; it will give you helpful suggestions as to what data to record, and how to use such data to improve your work practices.
Your tasks are to:
Form and structure your group, allocating roles and responsibilities to your members
Elicit and specify requirements for the system ( see Appendix A ), including:
all detailed functional and non-functional requirements for the new system
the data that the system will need to manage,
interfaces to other systems, and
interfaces and functionalities for different classes of users
The lecturer and tutor will act as clients for this project. You would also need to explore existing similar systems that are available online
Complete the planning and the requirements analysis for the system that is described in the attached informal specification document
Use a versioning system of your choice (e.g. Netbeans subversion, TortiseSVN)
Produce a report detailing the group's work
The book “The rational unified process: an introduction” by P. Kruchten[1] contains explanations of the Rational Unified Process (RUP) roles. Details include lists of artifacts that are the responsibility of a person holding a particular role, and workflow diagrams. Students should check these outlines to gain guidance as to what they are to do in the project.
Each group will hold formal "minut-ed" meetings. The group member holding the "manager" role is responsible for these meetings, in particular preparing agendas and keeping meetings on track, and is also responsible for the reports on meetings. The meeting structure should be along the following lines:
Reports from individuals who were allocated "urgent action items" in the previous meeting; discussion of issues related to these "urgent action items"
Manager reviews his/her perception of the current status of the project; this review is to use data from bug reports and feature tests as created by the systems integrator
Scheduled agenda items are discussed - in the early meetings this will involve resolution of open design issues, later it will involve review of progress on implementation elements and integration
Reports by individual members on progress in their areas of responsibility ("code walkthroughs" may be used) and identification of any problems
Identification of any "urgent action items" and allocation of responsibility for these
Proposals for agenda items for the subsequent meeting
Each group member will maintain a work diary. This should cover: planned work schedule, actual work times, summary of work completed, report on "defects" in own work. The purpose of a work diary is really to provide data that identify ineffective work practices so that remedial action can be taken[2].
Often you will find planned and actual work times differ significantly; such differences may point to poor work management practices. Every developer has his/her own blind spots that lead to defects in code. Analysis of defect patterns can help identify weaknesses and thus lead to a pre-emptive approach where the developer checks for their typical errors prior to running code.
( Note : for further details on RUP, roles and meetings, please refer to Appendix B )
REPORT
The work of the group is to be presented in a report. The report is the basis for your assessment. The report should briefly present the product that you are developing and provide evidence for a competently handled development process.
It should use grammatically correct English and should not contain innumerable spelling errors. You should use the spelling and grammar checkers in your word processor application.
The report should consists of the following:
Business case: What is this system that you are to build? Who will it serve? What will it do for them?
Detailed plans for the whole project (from requirements until implementation)
Risks and counter measures
Software Requirements Specification ( refer to SRS_Template.pdf )
Use cases (including use case diagrams and detailed description for each use case)
A domain model with detailed description of each class
The “meta-report” part should include:
A tabular summary of the group structure identifying group members, the roles that they filled, the artefacts that they successfully delivered
Group meeting records and individual diaries:
There should be a summary detailing the work done at each group meeting
There should be agendas and reports from all group meetings
There should be work diaries of all members of the group
· Provide evidence for the appropriate use of version control software; this would typically take the form of excerpts from subversion’s logs of commit operations. Subversion (or equivalence) statistical reports, showing overall contributions by different members, should be included in the report
For further information on the report and delivery, please refer to Appendix C.
DELIVERABLES & SUBMISSION
Please refer to Appendix D.
MARKING SCHEME
· Overall presentation of report (2 marks)
· Requirements elicitation and analysis efforts as evidenced by your report (9 marks)
· Project management (4 marks)
These marks are based on evidence for the use of an effective software development process. Factors contributing to this part of the assessment will include:
- evidence for an effective group structure and adoption of roles
- effective group collaboration as evidenced by meaningful group meetings
- well-planned and disciplined work processes of individuals and
- effective use of a versioning system
Individual marks are based on the group mark. Individual marks are adjusted in accord with the “member’s contribution assessment” document submitted by the group. Individual marks cannot be greater than the group mark.
APPENDIX A
(Warehouse Management (WM) Tool)
An effective Warehouse Management (WM) Tool is essential for streamlining process, long range planning and optimization. It gives a better understanding of day-to-day operation with its summary information of how a warehouse is performing. The managers could use this data for making critical management decisions.
It is critical for the warehouse management to have an effective system in place due to various reasons such as security, accuracy, availability and so on. Therefore, you are asked to use a test-driven approach to develop the warehouse management tool which needs to meet the following requirements.
Functional Requirements
List of features include:
1) Ability to add/update records on the incoming stock and outgoing stock easily.
2) Track the stock in accordance to their category and sub-category.
3) Ability to search and display available stock for a particular category and/or sub-category.
4) Ability to search and display stock in accordance to price range and quantity in ascending and descending order.
5) Daily, weekly or monthly summary report of total incoming and outgoing stock details.
6) Provide login authentication process.
7) Login security feature with option of encrypting the data stored.
8) If there are three unsuccessful login attempts, the record will be marked as “locked” and one is not allowed to login to the system.
9) The system shall encrypt and decrypt the password.
10) Provide stock item alerts when it drops below a threshold set previously.
The WM may have the following interactive menu:
a) Add new stock
b) Remove stock
c) Edit stock item
d) Search stock item
e) Daily stock summary report
f) Weekly stock summary report
g) Monthly stock summary report
h) Yearly stock summary report
i) Quit
The WM allows new stock item’s details to be individually entered and then stored in a text file as the following format:
[Item ID]:[Item Description]:[Item Category]: [Item Sub-category]:[Amount Per Unit]:[Qty]: [Transacted date]
eg:
023:Samsung Phone XYZ:Electronics:Mobile Phone:300:100:15-Dec-12
053:Dan Sofa:Furniture:Sofa:1200:-10:15-Dec-12
045:Nike ABC:Shoes:Trainers:50:60:22-Dec-12
023:Samsung Phone XYZ:Electronics:Mobile Phone:300:-50:15-Dec-12
045:Nike ABC:Shoes:Trainers:50:-10:22-Dec-12
The colon (:) character is used to separate each piece of information.
Stock item In Out Amount(Per Unit) Total Amount
023 100 0 300 -30,000
053 0 10 1200 12,000
045 60 0 50 -3,000
023 0 50 300 15,000
045 0 10 50 500
A sample of the daily stock transacted is shown below.
You can also provide more information such as the total number of stock items available in the warehouse at any point in time.
Non-Functional Requirements
1. The system is to be implemented in C++ and is to run on a Linux OS.
2. The system is to use a simple textual “menu-select” style of user interface.
You need to elicit further requirements and specify them in much more detail in Software Requirement Specification by doing a further requirement analysis with your supervisor.
Note: The first part of this project (Assignment 1) involves planning and eliciting and analyzing requirements. The second part (Assignment 2) will involve designing, implementing and testing the system.
APPENDIX B
( Requirement / Task – Extra info )
The purpose of this assignment is to simulate the RUP approach to software development, starting with the requirements gathering, all the way to system analysis and design. (Note: for this Assignment, there is no need to implement (i.e. code) your system). However, your team must produce the necessary artifacts (i.e. documents) covering this aspect of your system development.
Form a group of 6 members, adhering to the following criteria:
o group members must come from the SAME class, absolutely no "inter-class" group members
o the no. of members in each group MUST BE EXACTLY THE SAME : 6, except in special situations where (# of students in a class) mod 6 != 0 (i.e. got remainder)
o if possible, try to achieve a balanced gender ratio of 1 : 1, (no boy-bands / girl-generation)
o in the event of special situations, the tutor will step in to assign "remainder students" to registered groups (i.e. some groups will have 7 members)
In general, your team should undergo (at least):
a) Inception phase : 1-2 iterations
b) Elaboration phase : 2-3 iterations
c) Construction phase : 2-3 iterations
d) Transition : 1-2 iterations
However, since this Assignment is mainly focusing on activities from Inception and Elaboration phases only, the iterations in Construction and Transition should be of lower priority
Based on the above, your team should have undergone a total of 3-5 iterations (in Inception + Elaboration phases). Therefore, the min. no. of:
a) formal meeting minutes should be = 3 !
b) formal work diary should be = 3 (for each team member, hence
5 team members x 3 = 15 work diaries for the whole team)
As mentioned in pgs 1-2 of this Qn Paper, each meeting minutes should cover the following points / decisions:
a) Progress status from individual members, who were allocated urgent action items in previous meeting [ 'N' paragraphs ]
b) Manager summarizes the overall progress of the entire system [ 1 paragraph ]
c) Brainstorm and discuss on any un-resolved issues / urgent action items from previous meeting [ 'N' paragraphs ]
d) Brainstorm and discuss on the remaining tasks (e.g. research / exploration /
development / testing / deployment ) to be done [ 'N' paragraphs ]
e) Decide how much time should be allocated to each issue / task [ 1 paragraph of bulleted points ]
f) Allocate tasks to team members [ use a table ]
g) Decide on the agenda (items/issues to discuss) for the next meeting [ 1 paragraph of bulleted points ]
Note : the paragraphs in "[ ]" is just a guideline on the format / usual length of the content!
As mentioned in pgs 1-2 of this Qn Paper, each work diary is like a "personal log" that tracks of a team member's personal progress. The diary should cover the following information:
a) The start + end date the period covers
b) What were the list of tasks allocated to you, (should be smiilar to the tasks allocated to you in the previous formal meeting)
c) For each task, discuss the following:
- how much "actual time" you spent on it
- did you breakdown the task into smaller sub-tasks?
- are all the sub-tasks completed?
- which sub-task(s) you faced difficulties, and how do you resolve it?
- did you discuss your problems with fellow colleagues? What were the remedial actions taken?
The roles required for this group assignment are:
· Manager (1) - the "Team Leader"
· Lead designer / implementer (1) - probably the same person, but the "lead" role could be split;
· Designer / Implementer / Documentation (many)
· Systems Integration and Testing (1)
The designated team leader should take the role of manager or of lead designer / implementer. Each implementer is responsible for unit testing of his/her code.
APPENDIX C
(Report Details)
A document "A1_Sample_Report_Format.doc" has been provided for you. All teams are to follow its recommendations to organize the contents in a structured manner.
Another document "SRS_Template.pdf " has been provided for you. It gives you an idea of the information required produce the Software Requirements Specification. Please adhere to the format and section headings in this template.
For all documentation produced, factors like how you communicate your ideas, how you organize your information and the "professionalism" (i.e. overall presentation) plays an important role in capturing your system's requirements and design.
- In order to communicate better in your report, where applicable, you should make use of visual elements like graphs, diagrams, charts, screen-shots, tables, appendices, glossary, etc. to help clarify your ideas
- In order to make your report content more professional and organized, you should have the following in your documents: Cover page, Table of Contents, Formatted document header and/or footer, proper paragraph indentation and alignment, consistent bulleted points, page numbering, etc.
During lab session, time will be allocated for each team to present their ideas. All teams are to:
- use power-point slides as the main presentation aid (optional : 'other' multi-media elements like video clips, role play, etc)
- ensure all members has "equal exposure" in presentation
- adhere strictly to the allocated time for presentation
( Note : In a real working environment, factors like starting presentation on time, adhering to time limits for presentation, being professionally dressed and not using Notepad to present your ideas, etc are crucial towards creating a good impression in the minds of CEO and senior management towards your project! )
APPENDIX D
Submission Instructions (V. IMPT!!)
1) Deliverables
a) Download "PeerAssess and GrpWrkContributionStmnt.pdf", fill it up and submit in HARDCOPY during the lab session.
b) All other submissions should be in softcopy, unless otherwise instructed
c) For the actual files to be submitted, you need to include the following:
i) MAIN REPORT word document (e.g. A1_MAIN_RPT.doc), save as MS Word 97-2003 format
ii) MAIN REPORT in PDF format (e.g. A1_MAIN_RPT.pdf)
iii) Software Requirements Specifications word document (e.g. SRS_v1.doc), save as MS Word 97-2003 format
iv) Software Requirements Specifications in PDF format (e.g. SRS_v1.pdf)
v) Powerpoint Presentation (e.g. A1_Presentation.ppt), save as MS Powerpoint 97-2003 format
2) How to package
Compress all your assignment files into a single zip file. Please use the following naming format :
<FT/PT_Assn1_<Team Leader's Stud. No._<Team Leader's Name.zip
Example : FT_Assn1_1234567_JohnDoeAnderson.zip
- <FT/PT Use “FT” for Full-Time student, “PT” if you are Part-Time student
- Assn1 if you are submitting assignment 1, Assn2 if submitting assignment 2 etc.
- <Team Leader's Stud. No. refers to team leader's UOW student number (e.g. 1234567)
- <Team Leader's Name refers to team leader's UOW registered name (e.g. JohnDoeAnderson)
3) Where to submit
Please submit your assignment via Moodle eLearning site.
In the event of UNFORSEEN SITUATIONS :
( E.g. Student's moodle account not ready, cannot login to moodle, eLearning site down on submission day, unable to upload assignment, etc )
Please email your single zip file to your tutor at :
csci222uow@yahoo.com for FULL TIME students
(To be announced) for PART TIME students
In your email subject line, type in the following information :
<FT/PT <assignment info <Team Leader's student number and <Team Leader's name
Example:
To : tutor's email (see above)
Subject : FT Assn1 1234567 JohnDoeAnderson
Note 1 : The timestamp shown on tutor’s email Inbox will be used to determine if the assignment is late or not.
Note 2 : After email submission, your mailbox’s sent folder would have a copy (record) of your sent email, please do not delete that copy !! It could be used prove your timely submission, in case the Tutor did not receive your email!
4) When to submit
a) Depending on the time-table, a demo / evaluation for your lab submission may be scheduled during the:
- 3rd - 5th lab session for the semester (i.e. lab 3 - 5), for Full Time (FT) students
- 2nd - 4th lab session for the semester (i.e. lab 2 - 4), for Part Time (PT) students
Please consult your tutor for further details. Some time may be allocated for each student to present / explain your system design during the session.
b) Please refer to the following table on the different submission events and deadlines
Assessment
Component
Submission Deadline
(latest by 2300 hrs)
Assessment
Presentation / Evaluation
Email Evaluation files by :
Lab
01 / 02 / 2017
Lab 2(PT), 3(FT)
End of Lab 2(PT), 3(FT)
Assn 1
20 / 02 / 2017
Lab 3(PT), 4(FT)
End of Lab 3(PT), 4(FT)
Assn 2
27 / 02 / 2017
Lab 4(PT), 5(FT)
End of Lab 4(PT), 5(FT)
Note: (PT) = Part Time Students, (FT) = Full Time Students !
c) Example #1, for Full Time (FT) students submitting Lab Exercises ...
- Submit your zip file to Tutor by 01 / 02 / 2017, 2300 hrs
- Setup your Lab Exercises submission for presentation / evaluation on the date of : Lab 3
- Finish evaluation tasks, email Lab Ex evaluation files by end of : Lab 3
d) Example #2, for Full Time (FT) students submitting Assignment 2 ...
- Submit your zip file to Tutor by 27 / 02 / 2017, 2300 hrs
- Setup your Assn2 submission for presentation / evaluation on the date of : Lab 5
- Finish evaluation tasks, email Assn2 evaluation files by end of : Lab 5
e) Some time will be allocated for each team to present / explain your system design during the session. The tutor will inform you on the presentation schedule as the deadline draws near.
5) Please help by paying attention to the following …
! VERY IMPORTANT !
PLEASE FOLLOW THE GUIDELINES IN ALL ASSIGNMENT APPENDICES !!
PLEASE FOLLOW THE SUBMISSION INSTRUCTIONS FROM 1 TO 4 !!
IF YOU ARE NOT SURE,
PLEASE CHECK WITH YOUR TUTOR DURING LABS / LECTURES !
OR ...
PLEASE EMAIL YOUR ENQUIRIES TO YOUR TUTOR !
MARKS WILL BE DEDUCTED IF YOU FAIL TO FOLLOW INSTRUCTIONS !!
Example :
· Your report document or zip file does not follow naming convention
· Your email address does not include your name (i.e. cannot be used to identify sender)
· You have no email subject
· Wrong naming or misleading information given
(e.g. putting “Assn2” in email subject, when you are submitting “Assn1”)
(e.g. naming “Assn1” in your zip file, but inside contains Assn2 files )
· Your submission cannot be downloaded and unzipped
· Your report cannot be opened by Microsoft Word / Powerpoint / Adobe Acrobat
· Your program cannot be re-compiled and/or executable file cannot run
6) Re-submission administration
After the deadline, (on case-by-case basis), some students / grp may be granted an opportunity for an un-official resubmission by the tutor. If this is so, please adhere to the following instructions carefully:
<Step 1
Zip up for re-submission files according to the following format :
<FT/PT_Assn1_Resubmit_v1_<Team Leader's Stud. No. _<Team Leader's Name.zip
Example : FT _ Assn1_Resubmit_v1_1234567_JohnDoeAnderson. zip
- <FT/PT Use “FT” for Full-Time student, “PT” if you are Part-Time student
- Assn1 if you are submitting assignment 1, Assn2 if submitting assignment 2 etc.
- Resubmit_v1 if this is your 1st re-submission
- Resubmit_v2 if this is your 2nd re-submission
- <Team Leader's Stud. No. refers to team leader's UOW student number (e.g. 1234567)
- <Team Leader's Name refers to team leader's UOW registered name (e.g. JohnDoeAnderson)
- V. IMPT - To prevent Tutor’s Inbox from blowing up in his face, each student is only allowed to re-submit twice, for each assignment only!
<Step 2
Please email your single zip file to your tutor's email (refer to section 3) - Where to submit)
In your email subject line, type in the following information :
<FT/PT <assn info <re-submission ver. <Team Leader's student number and < Team Leader's name
Example:
To : tutor's email (refer to section 3) - Where to submit)
Subject : FT Assn1 Resubmit_v1 1234567 JohnDoeAnderson
[1] The Kruchten book is available as an electronic resource through the University library's subscription to Safari.
[2] Take a look at Humphrey’s Personal Software Process; it will give you helpful suggestions as to what data to record, and how to use such data to improve your work practices.
1 file (3.7MB)
