Design

2020S1SEFProjectsV1converted

Software Engineering Fundamentals 2020 Semester 1 Group AssignmentProject ObjectiveSoftware engineering Fundamentals is a hybrid project based course where the group project plays a major role in building student capabilities. It requires you to analyse the requirements of various stakeholders as a team and resolve any conflicts (or vague requirements) with the tutor acting as the product owner, before synthesising your solution iteratively, applying the software engineering principles taught. One major goal of this software engineering assignment is to facilitate teamwork and you will be expected to use  techniques such as CRC cards to effectively distribute responsibilities across classes and individual team members. Your team and technical experience in this project will help to meet the course and the program level objectives as well as act as a cornerstone project. The milestone and face-to-face sessions are designed to improve your communication skills. You will also be exposed to tools common in the industry (Git, Trello, LucidChart, JUnit) that foster teamwork and individual accountability.Overview of Project and AssessmentYou will get both formative (continuous) and summative (final) assessments as part of this project and this section briefly explains the assessment structure and the role it plays in building your capabilities. Assessment Role Marks 1. Weekly progress marks Weeks 3-12 Measuring your progress as an individual and as a team and giving feedback 10 x 1 2. Milestones Week 7 and 12 Present your requirements, design and implementation as a team and as an individual member to get feedback. 2 x 5 3. Face-to-face meetings Week 9 and After submission in Week 12. Designed to give more in depth feedback on your design, implementation and testing. The initial one will focus on the design aspects while the latter one will consider both functional and qualitative aspects such as usability, reusability, extensibility and maintainability. For individual part you will be asked to explain how your individual contribution is aligned with overall group design. 5 + 20 Team Formation (Formed by students)Since SEF is currently common to students from a number of degrees with different pathways we encourage teams to be self-formed reflecting individual competencies and interests and the more experienced student in the team may take a leadership role (such as Scrum Master) facilitating teamwork and the transfer of skills. Multiple assignments are provided in an attempt to match your interests but all of them require you to demonstrate your core competencies in requirements-gathering, analysis, object oriented design, processes, implementation and testing. Note all members of the team should be in the same group.Project WeightThis project is worth 45% of your total grade for this course. You are required to do only one of the seven project options.1. Weekly Progress Marks (10 marks) To get full marks each team is also expected to complete the tutorial working as a team as well as meeting the weekly criteria specified below. Wk Suggested Activities Progress/ Activity Milestone/ Meeting 3 Select the project and form the team – consider the strengths, interests and experiences of team members 1 mark 4 Identify User Stories for Product/ Release Backlog 1 mark 5 Identify main domain classes and add responsibilities such that objects can interact to get the first release done. Distribute classes/responsibilities to members. 1 mark 6 Write Test Cases and start writing code to make them pass (individual) 1 mark 7 Initial Milestone: Present partially completed product and get feedback from tutor and class. Demonstrate working Test cases (individual) and continue integrating code and testing. 1 + 5 marks Initial Milestone 8 Plan second release incorporating feedback. Add classes, extend class responsibilities and distribute work. 1 mark 9 Develop detailed Group UML Diagrams (class, use-case). Initial Face to Face Meeting 1 + 5 marks Initial Face to Face 10 Develop Individual UML Diagrams (sequence, state, object). Demonstrate individual Test cases 1 mark 11 Develop Activity Diagrams. Combine code and run integrations tests. Resolve conflicts. Refactor design and code before final submission. 1 mark 12 Second Milestone: Present final product to tutor and class. 1+5 Final 13 Final Face to Face Marking of design and code by Class Tutor 20 marks Final Face to Face 2. Milestones 1 and 2 (10 marks)A. Milestone 1 (5 marks) in Week 7This first demo/presentation will award marks for both group and individual work. Each individual member is expected to undertake at least two major tasks or responsibilities. Some of these responsibilities can be shared. For example, in the chess-like game “show all valid move destinations for a piece” can be a user- story/responsibility that must be shared by the Piece and the Board classes. The subclasses of Piece such as Rook and Knight may know valid moves but only the Board class knows where the vacant and opponent squares are located. In such a situation, those members writing the Rook and Knight classes may override the method getAllValidMoves():Squares[], while the person developing the Board class may write a method to check which of these squares are free to move using IsValidDestination(square). These two methods from different classes may thus be combined to determine all valid destinations. Students can defer non-model (GUI) aspects until the “core- logic” is fully tested (by using a simple textual interface). Activity Marks Group Part Presenting the Initial Release Backlog (design documents: Class and Use Case diagrams) and demonstrating a partially completed product. 2 marks (4 mins) Individual Part Individual member is expected to explain his or her role/obligation towards carrying out the main user-stories/responsibilities, and any challenges faced. 3 marks (4 x 1.5 mins) B. Milestone 2 (5 marks) in Week 12The second demo/presentation will award marks for both group and individual work though more marks is awarded for group work. Activity Marks Group Part Presenting the Final Release Backlog and demonstrating the final product 2 marks (3 mins) Use a class diagram to present the overall design; use two sequence- diagrams to present the core functionality. Explain the design rationale highlighting usability, maintainability, extensibility etc. 2 marks (3 mins) Individual Part Individual members explaining their role/ contribution and any challenges 1 mark (4 x 1 min) 3. Face to Face Tutor Marking 1 & 2 (Total 25 marks)Face to face marking is designed to give feedback and to award marks for following processes, using industry tools, flexible designs and the use of standard modelling notations.A. Initial Face to Face Demo and Marking (Total 5 marks) in Week 9 Activity: Group Part 2 Marks Model a positive and a negative scenario for 4 main use cases/user stories. You may use the storyboarding technique/screenshots to show the sequence of interactions (1 mark). Design classes/methods that can collaborate to carry out the 4 main user stories/use cases. Your initial class diagram should be extended to show more details of methods (1 mark). 2 marks (6 mins) Activity: Individual Part 3 Marks Each team member has to write two positive and two negative JUnit test cases (exceptions must be thrown for negative ones) for a significant method in an important domain class they are assigned (2 marks). Each individual student has to explain how these tests help implement the different scenarios identified in the group part. (1 mark) 3 marks (2 mins each) No submission required but students are expected to bring their documents (storyboarding, scenarios, class diagrams) and execute the test cases developed by each individual student.B. Final Face to Face Marking (Total 20 marks) Submit in week 12 and Demoed in week 13Group effort will be measured through overall class and use-case diagrams, which should explain the overall requirements and design decisions. Each individual member is expected to demonstrate their individual contribution by detailing their part of the use-case (a use case textual description) and class- diagrams and by coming up with two other UML diagrams (a sequence diagram and one of state/activity/object diagrams). Tutors will check your diagrams are aligned with your code and how group diagrams such as class and use case diagrams are aligned with individual diagrams (sequence and state). Include a table giving contribution of each member, allowing group mark to be adjusted. Activity: Group Part 10 Marks Overall Class Diagram (group) The class diagram must show all the methods, attributes, associations and multiplicities. Name the associations wherever possible. Up to 2 marks for valid class diagram that captures all the main classes, associations (with naming) with the correct multiplicities. Standard UML notation expected. The remaining 1 mark is allocated for consistency with individual sequence diagrams (update the class diagram to reflect the final sequence diagrams). 3 marks Overall Use Case Diagram (group) Up to 2 marks for a valid Use Case diagram capturing all individual use cases. For the remaining 1 mark show all the relationships including extends/includes. 3 marks Group Evaluation (max 1 page report) including: Lessons learnt about project/process management (2 marks) Strengths and weaknesses of your system in terms of reusability, extensibility, maintainability and usability (2 marks). 4 marks Activity: Individual Part Total 10 marks Show detailed methods/attributes/associations relating to individual contribution in the class diagram 2 marks Show detailed explanation relating to individual contribution in use case diagrams – present one use case textual description for a significant use case. 2 marks Sequence Diagram (individual) 2 marks One of state/activity/object diagram 2 marks Code explanation by individuals. The code must be refactored and reflect the design. 2 marks Submission Details: 29th May 2020 4.30 pm (week 12). No late submission allowed.Final Submission (Week 12):All source code and diagrams must be bound together and be submitted as a zip file called FinalSubmission.zip through Canvas by Friday 11.59 Week 12 (29th May).In additional all the design diagrams must be bound and submitted to the Sessional Staff office (14.09.13) by4.30 pm on the last day of the semester (29th May).Assignments: Summary, Rationale and Common AspectsThese assignments are designed to facilitate an agile or test driven approach for the first milestone, and a more rigorous design and implementation for the second milestone using UML notation and design/code refactoring. We have tried hard to come up with interesting and varied projects to match your interests and backgrounds. Your team should consider the strengths and interests of your members when selecting the project. You may also want to do some reading, testing and feasibility studies before finalizing your assignment selection in week 3. The first milestone is designed to enable students to develop some working- software or a prototype as soon as possible and get some feedback during the class presentation in week 7. The second milestone will focus more on the design aspects including extensibility and maintainability of the software. In addition face-to-face feedback will be given to each team in private in weeks 9 and 13. Assignment (Project Options) Description Activity/Flow Diagram Visualiser Diagram tool for creating and executing flow diagrams. S&E Real Estate Agency Buying, selling and renting properties. Student Casual Employment System A system to allow students to specify their availability and skills for casual employment while allowing employers to select and offer jobs to suitable applicants. Project Teams Formation System Software to form well matched teams based on preferences of students, requirements of employer and constraints by project manager. Multiplayer Pacman Interactive Game This fun multiplayer project is suitable for those interested in working with distributed applications. It will require the use of sockets, threads and synchronization or RMI. This is probably one of the most technically challenging assignments. If selecting this project you need very good programming and debugging and design skills. Project Management Software This project will be great for those considering a project management career; it will give you a head start with scheduling and resource allocation, a common problem in project management. This project requires some use of GUI and events. Internal Stock Trading System A client server system for trading company shares between employees. Requires an interest in network programming. Collaborative Snakes & Ladders Game This project requires you to extend the Snakes and Ladders game for which some sample code is provided. Note: Each group member must be from the same Tutelab session.PROJECT OVEVIEW VProject Option 1. Activity/Flow Diagram VisualiserProject OverviewYou are required to analyse, design, implement and test a tool for teaching students about Boolean logic and activity/flow chart design. You will develop a tool that allows the user to add various flow chart elements to a workspace area and to connect them with flows (represented by arrows).Elements consist of branching (represented by diamonds), merging (also represented by diamonds), actions (represented by rounded rectangles), a single start point (represented by a solid black dot) and an end point (represented by a solid black dot with a concentric circle around it).Each branch will represent a decision and will contain a Boolean condition that the user can enter and will have only one arrow coming in, but two or more arrows coming out.A branch represents either an IF statement or a DO-WHILE statement, depending on whether there is a loop back to a previous merge in the flow.Each merge represents the end of an IF statement, or the beginning of a DO-WHILE loop.The user can define variables, assign values and perform arithmetic equations/assignments and do simple input (READ) and output (PRINT) using actions.Below are two examples of Flow Charts with a DO-WHILE loop and an IF-ELSE condition: The system must be able to save the flowchart and allow editing of existing designs.The file format is up to you, but either an XML structure or serialization is recommended.The flow chart must be able to be “executed”. The user can set the delay between steps that are executed, and the program steps through each instruction at the set speed. Alternatively, the user can step through manually one instruction at a time. As each instruction/action/decision is executed it must be highlighted in RED. The system must have a console where input and output is processed. When input is expected, a prompt should appear in the console. Similarly when output is produced, it should be printed to the console.Whenever the user selects the execute option, the system must validate the design first to ensure that it is executable (notifying the user if it is not executable – with some indication of where the error is). If validated successfully, the flow should then be executed.While the flow chart is being executed, the user should be able to stop the execution by selecting stop.All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.Bonus:As a bonus, you should implement the ability to have unlimited undo and redo of changes to the flow diagram. A second bonus is the ability to translate the diagram into equivalent Java code.Project Option 2. S&E Real Estate AgencyProject OverviewYou are required to analyse, design, implement and test a stand-alone prototype for S&E Real Estate Agency, which manages the rental and sale of properties. In this initial stand-alone system you are not required to allow concurrent or web access; however you are required to design the system in a way that allows for extensibility, maintainability and reusability. You should also ensure all user accounts are password protected and can access or edit only the information related to their role and identity. Assume staff are already registered in the system with their e-number and password. The public should be allowed to view and search for Property and Open Day details specifying suburb and price range. You are not required to handle property images at this stage.All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.Requirements:CustomersAll customers must supply their name and email address when they register and specify whether they are vendors (selling), landlords (leasing) or whether they are interested in buying or renting properties. All customers are given a unique ID if registration is successful.Those customers buying or renting properties are to be allowed to add suburbs that are of interest to them. Such customers are to be informed whenever a new property is listed (for rent or sale) in a suburb that is of interest to them. They should also be notified when an inspection is created and cancelled.Those customers selling or leasing properties are allowed to add their properties to the system  and edit the details, however, the properties are not listed until an employee is assigned to sell or rent it.EmployeesThe company currently has a number of full-time and part-time employees. All employees are paid a salary. Part-timers are paid a salary that is proportional to the hours they worked. e.g. a half-time employee gets 50% of the full time salary. Part-timers are required to enter their hours into the system each month and get the branch manager to approve it.When an owner adds a new sale or rental property, the branch manager inspects the necessary documents handed over (physically) before assigning a single employee to it.Sales consultants are tasked with selling a property on behalf of a vendor. They are paid a base salary plus  a bonus which is 40% of the commission S&E receives from the final sale price of each house the consultant sells. Sales consultants advertise the property, liaise with the vendor, organise legal documents, conduct inspections and facilitate negotiations between the vendor and potential buyers.Property managers are tasked with the long term management of rental properties on behalf of a landlord. The tasks of the property manager include advertising the property, conducting inspections, reviewing tenant applications, checking maintenance reports, organising maintenance works, paying bills from property accounts and deducting management fees from property accounts.The branch administrator does various office duties including receiving documents, scanning documents into the system, collecting rent, crediting the branch account with money received, and running the payroll at the end of each month. The payroll includes salaries for all staff, commissions on property sales and payments to landlords.InspectionsEach sales consultant and property manager is required to schedule inspections for the properties assigned to them. They must specify the property, date and time for each inspection that they have arranged.PropertiesAll properties must specify property address, suburb, and the property capacity (number of bedrooms/bathrooms/car spaces)Properties come in various types (house, unit, flat, townhouse, and studio).For Sale PropertiesThe sales commission is negotiated between the sales consultant and the vendors from 2 to 5% of the final selling price. All properties sold by S&E Real Estate Agency are done either through negotiation or auction.Before conducting any inspections a “Section 32” must be compiled by a legal professional. This is scanned into the system and then copies are made available to buyers.Negotiation:The vendors are required to specify the minimum price they are willing to consider. A vendor can increase the minimum amount any time (reflecting the change in property values), unless it is for sale by auction.When a formal offer is made on a property (that exceeds the minimum amount), the vendor has 3 days to either accept or reject the offer. The buyer can withdraw (i.e. undo) the offer at any time during this period and other offers can be taken during this period. An offer is implicitly rejected by the vendor if they do not respond within the 3 day period. During the 3 day period inspections can still be conducted.Whenever an offer is accepted by the vendor, the buyer is required to make a 10% down-payment within 24 hours. No further offers can be taken during this 24 hour period. The buyer making the offer can change their mind on a purchase up until the deposit is paid.When the deposit is received the property is considered “under contract” and all future inspections are then cancelled. If the deposit is not received within 24 hours then the property stays on the market and new offers can be taken. During the 24 hour period inspections can still be conducted.Auction:Vendors are required to select an auction date and properties that are up for auction can only be booked for inspection for dates before the auction date.The vendors may choose to specify the minimum reserve price for the auction (or may choose to have no reserve). Once the bidding process has begun, the minimum reserve can no longer be altered.When a bid is made, it must exceed any previous bid on the property by at least $1000. The auction ends when there have not been any bids for 30 seconds or more.When the auction ends, the bidder with the highest bid (that meets any minimum reserve price) is given 24 hours to give a deposit of 10%. If the highest bidder fails to provide a deposit within 24 hours, then the next highest bid is considered (again assuming it has met any minimum reserve).This process repeats until there are either no valid bids left (or no bids that meet the minimum reserve).A property that fails to sell under auction, can be put up for auction again (however any minimum reserve must be reduced by at least $10,000 or removed all together, no reserve can be added to a property that has previously failed to sell without a reserve).When the deposit is received the property is considered “under contract” and cannot be put up for sale or auction again until the sale is finalised.Rental PropertiesThe management fee for a property is usually a standard 8% of the rental amount. If the same landlord has two or more properties with S&E then a discount rate is automatically given which is 7% for each property. The management fee can also be negotiated down further to a minimum of 7% for a single property and 6% for multiple properties.Landlords offering properties for rent must specify the weekly rental and acceptable contract durations (e.g. 6 months, 1 year or 2 years). Potential renters must make an application specifying the weekly rental and contract duration desired. These may be different from the rent and duration on the offer.There must be at least one applicant on each application. Personal details such as each applicant’s income, occupation, current and past employers/rental contracts, length of current/ past employment/rental etc. are captured in the system. These may be edited at any time by the customer.When an application is received the landlord has 3 days to either accept or reject the application. Any applicant can withdraw (i.e. undo) the offer at any time during this period and other applications can be taken during this period. An application is implicitly rejected by the landlord by not responding within the 3 day period. During the 3 day period inspections can still be conducted.When an application is accepted the applicant(s) have 24 hours to pay one month’s rent in advance plus a once off payment called the “bond”. The bond is calculated as 4 weeks rent and this amount must be immediately paid into the REIV trust account. No further applications can be taken during this 24 hour period. The applicant can change their mind up until the rent and bond is paid.When the rent and bond is received within the 24 hour period the property is considered “let”, the applicant becomes the tenant and all future inspections are cancelled. If the rent and bond is not received within 24 hours then the property stays on the market and new applications can be taken. During the 24 hour period inspections can still be conducted.Scope can be roughly defined as:1. In scope are all system functions related to listing, searching, offering/accepting, and payment of salary, rent, deposits and commissions. Customer details must be captured if they are involved in buying or renting.2. Out of scope – Functionality related to property tax, first home buyers grants and insurance.3. Limited scope – Functionality of external systems with which the new system must interface such as legal services for compiling section 32s, marketing services for advertising properties in papers and with bill boards etc. You may need to show that these tasks are done, but no structural data relating to those aspects are to be maintained in your system.Sales RequirementsAuthorized users (manager, employee assigned) should be allowed to view the current state of any property currently in the market. A property is not considered sold when the deposit is paid. It is only sold when the full sale price has been paid by the buyer to the vendor which is called ‘settlement’. Modelling settlement (i.e. paying parts of the purchase price to creditors such as banks and lawyers) is out of scope.Rental RequirementsAuthorized users (manager, employee assigned) should be allowed to view the current state of any property listed for rental or currently being rented. In the life time of the property there may be many different tenants and applications for tenancy. The rent may only be changed after the term of the lease expires.Bonus: Networked Auction systemThe current auction system is processed centrally with bids being manually recorded in the system by the auctioneer. In the full system, there needs to be networked client applications that can be used to submit bids remotely to the central server where the details of the bid are stored and the current highest bid details are transmitted to all the clients.General RequirementsPersistenceAll data entered must be persisted. The data may be stored as flat files, serialized files or in databases.Design DocumentsDetailed design documents are needed including class, use case, sequence, activity and state diagrams. In the initial stages the UML diagram in sketch mode should be shown to the product owner (tutor). Scenario modelling and storyboarding should also be shown to the product owner before detailed design and implementation commences.TeamworkTeamwork marks will be based on your group and individual contribution during the feedback sessions and your contribution to Trello. Your team contribution will be reflected based on how well your individual contribution (through individual design diagrams such as use case textual descriptions, sequence diagrams and JUnit test cases) are consistent with the overall design and implementation and testing goals. In the final face-to-face marking you will be required to fill a peer review form, which will help determine your group contribution. If your team is using Git your contribution also will be taken into account when determining your group marks.Project Option 3. Student Casual Employment SystemProject OverviewYou are to gather requirements, analyse, design, implement and test a proposal for Student Casual Employment System to facilitate students to find contract and ongoing part-time jobs. In the initial stage you are required to develop a stand-alone system without concurrent or web access; however as a software engineer you are required to design the systems allowing for extensibility, maintainability and reusability. You should also ensure all user accounts are password protected and can access or update only the information related to their role and identity.All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.Project ScopeThis requirements specification applies to the proposed Student Employment System as described below. The scope of the proposed system is restricted to the following functions:Registration of student applicant accountsRegistration of employer accountsCreation and updating of job preference and availabilityAdding and updating Employment Records and References by applicantsUploading of CVs (text files) by applicantsSearching for suitable applicants by employers based on job preference and availabilityShortlisting and Ranking candidates by employers based on availability, experience and CVAutomatic email notification of inviting suitable interview times to highly ranked candidatesSelecting interview times by shortlisted candidatesUpdating candidate based on interview and reference checkCreation of job offers outlining employment details and notification by emailsAccepting or rejecting job offers by applicantsComplaints about applicants by employers and about employers by applicants.Blacklisting of applicants.Requirements:ApplicantsApplicants are restricted to university students but are classified into local and international students. Local students have no restriction on employment hours while some jobs will not be applicable to international students because of hours (maximum 20 hours per week) or other legal or security requirements. Applicants should be allowed to update past employment records, references, qualifications, licenses (driving) and availability. Availability should specify the type (part-time, full-time, internship), period and applicable job-categories (one or more from the predefined list). There can be multiple availabilities, such as a p/t position during semester and an internship during the summer break. The applicant status must be updated to available, pending, unknown or employed based on the employment outcomes and the date of last student update. To avoid employers wasting their time with students already employed or have since become unavailable due to other priorities, their employment status should be changed to unknown automatically, two weeks after the last update and must be regularly updated by students if their availability is still valid.EmployersEmployers should be allowed to search for matching candidates based on availability and other credentials as well as shortlist, rank, mail and set possible interview times for selected applicants. Employers also want to record the results of their interviews and reference checks in case future opportunities arise for unsuccessful applicants. For the successful applicants the details of job offers and responses by applicants must be captured in the system. Students successful in their application and being made an offer should be shown as pending thus avoiding other employers viewing their details and shortlisting them.System Maintenance StaffMaintenance staff have access to all employer and applicant records. Repeated complaints (three or more) should result in employers/student accounts being provisionally blacklisted.During this state, employers cannot offer jobs and students cannot accept roles. Both still have read only access (able to view data but not make any changes).Maintenance staff can view the list of provisionally blacklisted members and either fully blacklist them or remove the provisional blacklist – returning the profile to a regular state.Fully blacklisted employers cannot view availability or offer jobs and cannot make any changes to the state of the system.Fully blacklisted student applicants have their profiles completely disabled – they can log in, but cannot perform any functions or view any details.Maintenance staff can also revert any fully blacklisted account back to normal, but only after 3 months has elapsed from the date of the full blacklist.Maintenance staff also may add new job categories such as “fruit-picking”, “Driver” etc.SecurityThe system will limit access to employer details to prevent students directly contacting them. The system hides phone and other private details about employers so students can’t contact them directly. All users should be allowed to change their username/password.Reporting RequirementsThe following reports are needed to improve and fine tune the system.1. Listing of employers making offers, sorted based on the number of offers made in the specified period2. List of complaints about specific applicant or employer3. Jobs offered and accepted by a given job applicant in the past4. All past offers for a particular category of job.ArchivalArchiving past records is out of scope.PersistenceAll data entered must be persisted. The data may be stored as flat files, serialized files or in databases.Design DocumentsDetailed design documents are needed including class, use case, sequence, activity and state diagrams. In the initial stages the UML diagram in sketch mode should be shown to the product owner (tutor). Scenario modelling and storyboarding should also be shown to the product owner before detailed design and implementation commences.TeamworkTeamwork marks will be based on your group and individual contribution during the feedback sessions and your contribution to Trello. Your team contribution will be reflected based on how well your individual contribution through individual design diagrams (such as use case textual descriptions, sequence diagrams and JUnit test cases) are consistent with the overall design and implementation and testing goals. In the final face-to-face marking you will be required to fill a peer review form, which will help determine your group contribution. If your team is using Git your contribution also will be taken into account when determining your group marks.Project Option 4. Project-Teams Formation SystemProject OverviewYou are required to analyse, design, implement and test a tool for a student-projects manager allowing a fair allocation of students to teams based on preferences, academic records, skills and personality types. The project manager assigns a team of 4 students to work as part of a capstone project team where external clients act as product owners. Students work for 16 weeks on such projects each semester. Currently there are many more clients (project initiators) than project teams, and teams are often formed in an ad hoc manner with a poor match between team members, between teams and projects resulting in poor student and employer satisfaction. Moreover, the university regulation imposes specific constraints when forming teams. Your system design should allow for extensibility, maintainability and reusability as the tool may be made available to other institutions.All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.Requirements:Client representativeThe clients (project initiators) should be invited to make a presentation with the aim of getting a suitable team to undertake their project. Each project initiator specifies the roles required such as Database Administrator (DBA), programmers, leader, UI designer etc. In addition the project initiator specifies a number of frameworks they prefer team members for a specific role to be familiar with. For example, a client may prefer the person assigned the DBA role to be familiar with Oracle and the programmer to be familiar with Java and C++.Student representativeStudents should be asked to state their preferences for the first 4 preferred clients (in the order of preference) even if their preferences cannot always be met. Students should also be allowed to specify their two preferred roles along with frameworks, skills or programming languages relevant to those roles. Students should also be allowed to state up to 3 members they would not like to form a team with.Project ManagerI am required to ensure no more than 1 female student is placed in one team (hard constraints) to ensure gender-balance as less than 20% of our current students are female. I also classify my students into 6 personality types (A to F) based on observation and class tests. For each team formed there must be at least one of personality type A or B. Moreover, no two members of the same personality types can be placed in one team (soft constraint). Every team also should have one member with at least 5 years of previous work experience  (soft constraint). Every team should have at least two or more students with GPA 3, while no team should have an average GPA exceeding 3.5 (hard constraints). I should be allowed to change the values for GPAs as the student cohort may vary from year to year.Stage 1In the initial stage, I want to discard the projects unpopular with students by selecting just those students with the most number of preferences. For example if I have 100 students, I want to select only the 25 most popular projects (assume all teams have exactly 4 students).Stage 2In the second stage, I want to assign students to teams based on preferences and constraints specified by students, clients and myself as the project manager. Some of these constraints are “hard” constraints and cannot be violated. For the “soft” constraints, I would like to be able to specify a weight (say 1 to 4) such that the scheduling algorithm (allowing optimal matching) will give priority to meet the constraints with greater weights first. The system should allow me to change the weight for different constraints thus placing greater emphasis on specific constraints. The scheduling algorithm should come up with a numerical number showing how good the  fit is for each individual team. For example, if there are 6 soft constraints which are met, three of which have weight 3 and 3 of which have weight 2, then the overall satisfaction will be 15 (3×3+3×2). The algorithm should also ensure teams are more or less equally well fitted.Stage 3In the final stage, I want to be able to swap members between teams manually as long as the overall fitness value for swapped teams does not change by more than the specified value (to be input). The tool should facilitate a trial-based approach to ensuring that the teams formed can be effective.Bonus MarksAllow graphical user interface for swapping members Allow visualizing individual and overall fitness PersistenceAll data entered must be persisted. The data may be stored as flat files, serialized files or in databases.Design DocumentsDetailed design documents are needed including class, use case, sequence, activity and state diagrams. In the initial stages the UML diagram in sketch mode should be shown to the product owner (tutor). Scenario modelling and storyboarding should also be shown to the product owner before detailed design and implementation commences.TeamworkTeamwork marks will be based on your group and individual contribution during the feedback sessions and your contribution to Trello. Your team contribution will be reflected based on how well your individual contribution through individual design diagrams (such as use case textual descriptions, sequence diagrams and JUnit test cases) are consistent with the overall design and implementation and testing goals. In the final face-to-face marking you will be required to fill a peer review form, which will help determine your group contribution. If your team is using Git your contribution also will be taken into account when determining your group marks.Project Option 5: Multiplayer Interactive Pacman GameProject OverviewYou are required to analyse, design, implement and test a multiplayer version of the Pacman game where two monsters (controlled by the server) chases and eats up the player pieces moving in the predefined grid shown below. The players and monsters can also move along the arrows shown below to end up along the opposite edge. The aim of the game is for the players to escape from the monsters and for the monsters to block the players’ escape routes and eat up the players. You game should be designed to be extensible, maintainable and reusable.All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.Initial Waiting StageThe first player to login should specify the number of players (between 2 and 4). The game should start when the required number of players login and joins in.Initialization StageEach player should be allowed to specify one of the four remaining corners as the starting cell (top-left, top- right, bottom-left, bottom-right) in the order they join the game. The two monsters should initially be placed in the cell at the centre and be made to move towards the nearest player (least number of cells in between). The two monsters should coordinate to with each other to try and block/trap players escape.Game Play StageWhen two or more players are at equal distance, the monsters may choose to move towards any one of them randomly. A player can block any other player by being stationed along the escape route (with the aim of getting the other player eaten). Each player has a food piece that they can drop to delay the monster. A monster must wait for a period of time for the food to digest before starting the chase again. The game should stop when only one player is left, who is considered to be the winner. You may use either sockets and threads (using your own protocol) or Java RMI (easier) to implement the game.Post-Game StageA protocol should be devised allowing a new game to be played if all player want to continue. Otherwise the current scores should be updated on the server.Bonus: Allow the board grid to be created at run-time (with variations in configuration). Project Option 6: Project Management SoftwareProject OverviewA project manager has approached you to develop a customised project management software. You are required to analyse, design, implement and test this tool using an agile approach. Your system should be made reusable, extensible and maintainable as requirements continue to evolve. All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.Requirements:Jack (the Project Manager)Currently I am allocating staffs to activities in an ad hoc manner resulting in project delays and cost overruns.  I need you to design and develop a Task and Staff Scheduler that assists me to complete the projects I manage within time and budget. The project involves two parts: scheduling activities and allocating staffs to activities. For each activity I can estimate the duration in weeks, the type of skills needed and the number of staff needed. For each such activity I can also specify any dependencies on previous activities (if any). The critical path and the earliest project completion time are computed based on dependencies on previous activities and the duration of activities. My main problem however, is allocating staff to activities as staff may be working on a number of projects in parallel; staff in our companies can be working either 20%, 40%, 60% 80% or 100% on a project reflecting the number of days per week they are engaged in the projects.I select the staffs for an activity based on whether they have all the skills needed. Very often full-time staff are underutilised in specific weeks while in some other weeks we had to hire many contract staffs. I would like to minimise the number of contract staff as they expect premium rates to be paid on an hourly basis. This year, I want a new system that will help me plan all the activities for all the projects at the beginning of the year and maximise the usage of our permanent staff. I want the system to compute the expected project completion date based on the start date for the project (first dummy activity in the project), the duration and dependencies (predecessors) for each activity. For each activity, I also estimate the average number of staff required (can be fractional) and their required competency levels in needed skills. Secondly, I would like to have the option to move the activities not lying along the critical-path and to experiment with assigning different staff with the intention of minimizing the dependencies on external staff.I would like your system to come up with some initial staff assignments using some simple heuristics, such as assigning the least experienced full-time staffs first to activities (as more experienced staff can fit into many different and complex activities). After assigning all the full-time staff, assign inexpensive, less experienced contractors first. I would still like to have an option to change these staffs around manually to do some trial- and-error.The system must be able to determine the total cost of the project based on the allocated staff hours and their hourly rates.Jim a Full-time developerI would like a system where I can specify at the beginning of the year the weeks that are blocked (I am not available due to annual leave or other duties). I would also like to specify weeks where I’m partially blocked off as I have a fair amount of non-project related duties. In such weeks I would like to specify my availability as 20%, 40%, 60%, 80% and 100%. Though I am multi-skilled my level of competency and experience vary significantly. I would like to specify my competency level explicitly for different skills in a scale of 1 to 10, so that the manager can select me for activities where I can be really productive. For example, I am highly competent in Java (10) but I am weak in Python (4) and domain modelling (4).Timothy an External ContractorIn the past we had to charge high rates as there were a number of weeks in a row where we got no work at all followed by intensive periods. Most contractors including myself prefer to work on an activity lasting for at least two weeks or more. We tend to be more productive and happy when working for a longer period, and are even willing to charge less. I would therefore like the system to allow me specify different rates for contracts lasting 1 week, 2 weeks and 4 weeks or more.PersistenceAll data entered must be persisted. The data may be stored as flat files, serialized files or in databases.Design DocumentsDetailed design documents are needed including class, use case, sequence, activity and state diagrams. In the initial stages the UML diagram in sketch mode should be shown to the product owner (tutor). Scenario modelling and storyboarding should also be shown to the product owner before detailed design and implementation commences.TeamworkTeamwork marks will be based on your group and individual contribution during the feedback sessions and your contribution to Trello. Your team contribution will be reflected based on how well your individual contribution through individual design diagrams (such as use case textual descriptions, sequence diagrams and JUnit test cases) are consistent with the overall design and implementation and testing goals. In the final face-to-face marking you will be required to fill a peer review form, which will help determine your group contribution. If your team is using Git your contribution also will be taken into account when determining your group marks.Bonus RequirementsA GUI version of the projectProject Option 7: Internal Stock Trading SystemProject OverviewYou are required to analyse, design, implement and test an internal stock trading system for employees of a group of companies involved in manufacturing. In the initial stage you are required to develop a client server application (RMI or sockets) without web access; however as a software engineer you are required to design the systems allowing for extensibility, maintainability and reusability.This project is a client server application and is therefore better suited to those who have already completed Further Programming or Network Programming.All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.Requirements by Product OwnerI want a stock trading software for a group of companies where employees given bonus shares are allowed to trade their stocks. In the initial development phase the stock trading will run as a separate system (not linked to the employee benefit system).The Stock Trading Server FunctionalityThe server should run continuously allowing new orders to be added and withdrawn until it is brought down at the end of the day. Only six stocks belonging to the group are currently traded (see below). The server must initially start with the following stock prices. The stock prices will vary as trades are completed. Server must reject buy/sell orders that are not within ± 5 cents of the last trade, or are less than 5 cents.OSX (250)Ria (340)NIBC (290)Vienta (170)BHT (260)Cones (470)Separate queues must be created for items waiting to be sold or bought at different prices.Server must verify and only accept buy/sell orders which are within +/- 5 cents of the last trade, down to a minimum of 5 cents. If a buy/sell order is valid, a transaction ID (newly generated) must be assigned (of the form TR080428000001) and client must be notified.Newly ordered items can be traded immediately if there are offers from ready buyers or sellers in the queue with the required quantity of stock and within specified price. If only part of the offer can be traded now, an offer with the remaining quantity must be added to the buy/sell priority queue. For example, if for a new sell order of 5000 BHT shares at 250 cents, only 1000 shares can be traded at that price (or higher) now, the remaining quantity is 4000.Buy or sell orders queued at the same price, must be traded on a first come first served basis. However if the prices are not the same, the queues offering the highest possible price must be traded first when selling, and lowest possible price when buying.The maximum number of shares must be traded whenever an item is offered. Partial trades must be conducted if only partial match can be found for an offer. A trade affects both the client making a new offer and the clients with offers in the queue. All affected clients must be notified of the result of trade. Note a trade may cause offers waiting in the queue to be removed or the remaining quantity to be updated. Two different cases are given below, applicable when a new buy offer is made. (Similar cases apply for sell offers). It is assumed that offers for sell queues are arranged with higher priority for lower price – as lower priced offers will be traded first with a potential buyer. Similarly, buy queues are arranged with higher priority for higher prices as higher priced offers will be traded first with a potential seller.Example 1:Assume only two offers are queuing to sell BHT shares, first one (from client A) for 1000 shares at 270 and the second (from client B) one for 1000 shares at 280. At this stage, if another client (client C) offers to buy 1500 BHT shares at 290, the offer at 270 (from client A) must be removed from the sell queue, and the quantity for the one queuing at 280 (from client B) must be reduced to 500 (resulting in two trades). Also, buyer (client C) gets a trade done with all 1500 shares he/she offered to buy. All three clients (A, B, and C) must be notified of the trade and their trade details must be saved.Example 2:Assume only three offers are queuing to sell BHT shares, first one (Client A)for 1000 shares at 270, second one (client B) for 1000 shares at 280, and third one (client C) for 1000 shares at 295. At this stage if a client (client D) offers to buy 2500 BHT shares at 290, the offers at 270 and 280 (client A and B) must be removed from the sell queue (resulting in two trades) but the offer queuing at 295 (client C) must be left intact as this price is higher than what the buyer is willing to pay. As the buyer (client D) gets only a partial trade done, with 2000 shares, an offer for the remaining quantity, 500 BHT shares at 290 must be placed in the buy queue. All three affected clients (A, B andD) must be notified of the trade and their trade details must be saved.RegistrationBefore clients are allowed to buy and sell shares, a registration process must be completed passing username and password.Server must validate the following:Username must be unique.Username and password must have at least 8 characters.If registration is successful, server must generate a unique account-ID and notify the client. All subsequent transactions including buying, selling withdrawing and viewing must pass valid username and password. Account-ID should be used for all orders and transactions (i.e. database records should be associated with account-IDs rather than usernames).Viewing Stock PricesI need a view option that allow clients to view the following using appropriate GUICurrent Stock price (based on last trade)Current buy/sell orders queued by this customerThe second option must show stock code, remaining quantity, desired price and current price (last traded price).Buy/Sell OptionsYou must provide options for placing buy and sell orders for any of the shares currently traded at specified price. The share price offered must be quoted in cents, in steps of 1 cent. Maximum number of shares purchased in one trade must be limited to 10,000. The server is required to validate the data sent. If the server detects any anomaly and throws an exception, it must be caught and displayed, otherwise the transaction ID generated and returned by the server must be displayed (which may be required for future transactions).When an order is placed the client must be notified of the quantity bought/sold and the quantity being queued. If a queued item is bought/sold at a later time the server must notify all clients affected by the trade using callbacks. A good user interface must alert clients when a queued item is traded (using UI elements such as pop-up).Withdraw OrderThis option must allow clients to withdraw all remaining unsold stocks in any buy/sell orders made earlier, by quoting the transaction ID for the order.Monitoring Unusual PatternsSystem should send notification to management when unusual buy or sell activities are noted possibly indicating some insider trading. The system should allow unusual activities and thresholds to be defined dynamically through the interface.Transaction HistoryAuditors and clients must be allowed query all transactions completed between specific dates by specific clients. The server must access the completed trades to access the required information.Sever ShutdownWhen the server is brought down all queued items must be discarded.PersistenceAll trades done must be persisted. The data may be stored as flat files, serialized files or in databases.Bonus Mark: Chart Option for Premium ClientsThis option offered only to premium clients must allow users to view the specified stock price movement in the last 30 minutes using appropriate graphs. These graphs must be dynamically updated. The stock price data stored must be restricted to last 30 minutes. You must also do the necessary scaling to fit the graph.2.882.70Design DocumentsDetailed design documents are needed including class, use case, sequence, activity and state diagrams. In the initial stages the UML diagram in sketch mode should be shown to the product owner (tutor). Scenario modelling and storyboarding should also be shown to the product owner before detailed design and implementation commences.TeamworkTeamwork marks will be based on your group and individual contribution during the feedback sessions and your contribution to Trello. Your team contribution will be reflected based on how well your individual contribution through individual design diagrams (such as use case textual descriptions, sequence diagrams and JUnit test cases) are consistent with the overall design and implementation and testing goals. In the final face-to-face marking you will be required to fill a peer review form, which will help determine your group contribution. If your team is using Git your contribution also will be taken into account when determining your group marks.Project Option 8: Collaborative Snakes and Ladders GameProject OverviewYou are required to analyse, design, implement and test a collaborative snakes and ladders game, where snakes  are free to roam around while humans (represented by pieces) aim to destroy all the snakes after acquiring special powers (when one piece reaches 100). You are required to design the system allowing for extensibility, maintainability and reusability as the game rules may be changed in the next version. The purpose of this assignment is to create a Collaborative Snakes and Ladders game. This adds many rules and stages to the traditional game, making it more strategic  and  collaborative.  You  will  be  provided  with  the  necessary  methods to  draw  the  board, snakes and ladders allowing you to  focus on the  design and implementation ofthe collaborative version of the game (instead of the low level GUI details).All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board. Note you may also make up your own collaboration game rules or incorporate other objects subject to you getting approval from your tutor.Background: Standard Snakes and Ladders GameSnakes and Ladders Game is an ancient game created to depict the struggle faced by humans through good and evil forces as they go through life. The ladders represent moving up to a higher moral plane with the help of benevolent beings, while going down the snakes represent being dragged down to a more immoral level through evil powers. Snakes and Ladders game was designed for 2 or more players and is played on a board with 100 squares numbered 1 to 100. Play begins on square 1 and finishes on square 100. Players take turns to roll a dice and move along the number rolled. If a player rolls a 6, the player may, after moving, immediately take another turn; otherwise play passes to the next player in turn. If a player lands on a square that has the bottom of a ladder upon it, the position is automatically advanced to the top of the ladder. Similarly, if a player lands on a square, which has the head of a snake upon it, then the player must automatically follow down to the tail of the snake. The winner is the player who is first to land on the square numbered 100. You must roll the exact number needed to land on 100.Actors in the proposed electronic version: Admin, Human Controller, Snake ControllerThe first actor playing the role of admin creates the board layout before commencement of the game in stage1. The other two actors are the ones controlling the placement of snakes (snake controller) and pieces (human controller) take turns to move as the game is played in stages 2 and 3.Overview of Main Stages and ActorsIn the first stage the 5 snake and 5 ladder objects are laid on the board by the admin. The 4 pieces representing the location of humans are initially all placed in position 1.In the second stage the human controller try to overcome the snakes (evil) by getting one of the pieces representing humans to reach the location 100 within 50 turns (subject to throwing a dice each time and adhering to specific constraints outlined below). Snakes are moved by the snake controller by moving a snakehead diagonally one unit at time (subject to specific constraints). In the 2nd stage if one of the pieces managed to get to 100 within the stipulated number of times, the 3rd stage commences.In the third stage the remaining pieces (all excluding the one reaching 100) are given special powers to move and to destroy the snakes by landing on their tails (there is no need to throw a dice in the 3rd stage). Snakes can also destroy a piece, if the snakehead moves to the location of any piece or if a piece lands on top of a snakehead.Detailed Requirements by Game Designer:Initial StageThe Board layout controller should be allowed to lay 5 snakes and 5 ladders with the specified end points. The difference between snakes and ladder end-points (Snake head and tail or ladder top and base) cannot be more than 30.The ladder top or base cannot be placed on a snake’s head location and a ladder base cannot be placed on top of another ladder’s head. There should be no ladder base at location 1 and no ladder top at location 100.A snake’s head cannot be placed on top of an existing ladder head, ladder base or next to another snake’s head (to prevent all the snakes clinging together). Only one snake (head) can be in locations 81 to 100 at any one time.Once all the snakes and ladders are placed four pieces (representing humans) should be placed in the initial position of 1.Second StageIn this stage the main aim is for the human controller to get one piece representing human to reach 100 having already climbed 3 distinct ladders, while the snake’s controller attempts to prevent this happening. (Note: no piece representing a human should be allowed to reach 100, without having climbed at least 3 ladders before). Only one snakehead can be in locations 81 to 100 at any one time.When a snake’s head moves over a player or a player moves over a snake’s head the player is pulled down to the tail position and the player remains in a paralysed state for 2 moves. A player can prevent a snake from moving to a specific location by placing a snake guard (losing a turn), and the location will be guarded until the end of the stage. The number of snake guards is limited to 3.Whenever it is the turn of the snake, the snake’s head can be moved diagonally by 1 unit (in any direction) subject to snake endpoints remaining within the board. When the snakehead moves to a new location the difference between the top and the base of the snake (snake length) remain constant.When a dice is thrown, the human controller must move one of the pieces by the dice value unless all humans are in a paralysed state or cannot move by that value. A piece can only climb a given ladder only once. Moreover, a player can land at 100 only if that piece had already climbed at least 3 distinct ladders before. At this stage the final stage commences.Final StageIn this stage the human controller has to destroy all the snakes without losing any piece, within 20 moves. Players can use the new acquired powers to move along the path of a knight piece in a chessboard or to the adjacent diagonally placed element.A snake can be made to destroy a player in this stage by placing a snakehead on the player or by getting the player to land on a snakehead. Both pieces and snakes take turns to move.Moving the snakehead diagonally results in relocating the snake (the head and tail of the snake must remain within the board).If all the snakes are destroyed without any loss of a human piece the humans are the winners but if even if a single human piece is destroyed the snakes are considered the winners and the game comes to an end.Who is this Project suitable for?This project is suitable for those having an interest in graphics and multimedia but lacking the knowledge of underlying graphics (sample code provided for drawing the entities snakes, ladders, pieces and the board). This project therefore allows students to focus on the OO design instead of the underlying GUI constructs (Swing). You will be expected to pick up some basic Java Swing but the sample code should be adequate for most of the functionality.Other RequirementsAllow a login feature for the players controlling the human and snake characters.Bonus: (both of the following)• The strategy for the ladders and snakes must be automated allowing the game to be played without inputs for moves of ladders and snakes with the objective of making the players win and lose the game respectively.• Allow the game state to be saved and retrieved. Design DocumentsDetailed design documents are needed including class, use case, sequence, activity and state diagrams. In the initial stages the UML diagram in sketch mode should be shown to the product owner (tutor). Scenario modelling and storyboarding should also be shown to the product owner before detailed design and implementation commences.TeamworkTeamwork marks will be based on your group and individual contribution during the feedback sessions and your contribution to Trello. Your team contribution will be reflected based on how well your individual contribution through individual design diagrams (such as use case textual descriptions, sequence diagrams and JUnit test cases) are consistent with the overall design and implementation and testing goals. In the final face-to-face marking you will be required to fill a peer review form, which will help determine your group contribution. If your team is using Git your contribution also will be taken into account when determining your group marks.

Back To Top