程序代写代做代考 scheme python database Excel Java flex gui javascript Software Engineering coursework specification

Software Engineering coursework specification

Notes:

Rule 20 updated 19/2 in response to a query from team members.

1) Introduction

Watson Games are a company that produces a range of traditional board games. You have been

appointed as a software contractor to develop a computer game version of their most popular title

Property Tycoon, a property trading game similar to the classic Monopoly. Watson Games have

never commissioned such a system before and so do not have a formal requirements document to

specify how the software should operate. They do however, have over 50 years of experience

developing and marketing board games and have put together a set of user requirements to

describe in their own terms what they want the system to do. This document contains all their user

requirements. It is possible these requirements might evolve as the project progresses, but the core

themes of the requirements will not change. You should, however, design with flexibility in mind.

Working as a team, you will need to:

• Develop a formal set of requirements, expressed as functional requirements, non-functional

requirements and domain requirements to determine more precisely what the software

system should do. This may involve going back to the client to clarify exactly what they want,

or presenting the client with a range of options to help them develop their own ideas.

• Develop a plan for the design, implementation, testing and delivery of the software system.

• Develop an appropriate software design, expressed using an appropriate combination of

high and low level design techniques including, although not limited to, class diagrams,

entity relationship diagrams, use case diagrams, sequence diagrams, state transition

diagrams, activity diagrams, other UML or UML style/derived diagrams.

• Write the software, using whatever tools, development environments and languages you

deem appropriate. Any reasonable set of choices will be accepted, including, although not

limited to, Java, JavaScript, C, C++, Scala, PHP and Python. You may opt for a system using a

database backend for persistent data management if you wish. Whatever you think is

needed and that you are prepared to justify as part of the design process. The software will

include a Graphical User Interface (GUI) component to help you monitor progress of the

software simulation. You should bear in mind that the choice of tools and languages is

something you should justify, and it must be a choice that is inclusive for all members of

your team that will be working on the development of your codebase.

• Develop a test plan for the software, both at a unit testing level and at a system level to

demonstrate that your software meets all the user requirements set for it.

• Write a report to document the work that you have done.

• Give a demonstration of your completed software system.

• Demonstrate that you can work as a coherent team, and show that you understand the

significance of software engineering principles in the development of anon-trivial piece of

software.

Assessment criteria for this team coursework project can be found on Study Direct. No two teams

will produce systems that work exactly the same, so there is no gold standard for the operation of

the software that you will be assessed against. The assessment criteria will focus on the quality of

your software engineering skills, and your ability to function as a team, to plan and execute work in

an appropriate manner and deliver a working and hopefully reliable software system.

You will work in a team of 5 people. You will have a sort initial window to form your own teams. If

you have not formed a team by the end of that window period, your will be assigned to a team. In

that event, there will be no negotiation on who is assigned to your team. Get to know the other

students in your team. The assessors reserve the right to amend team membership (but this would

be in exceptional cases only), and to merge teams if their membership becomes sub-critical, for

example if students drop out from the course for personal reasons.

As this specification represents a set of user requirements, it has been expressed in user-centric

terms. It may be incomplete or contradictory in places. Technical terms may be used inconsistently.

If there is something you do not understand, you can either ask the customer’s representative

(course tutors/teaching assistants) or make reasonable assumptions about what is meant. Note that

in the former case, the customer may or may not have a view on the query, and in the latter case

you should be prepared to justify the choices and decisions you have made.

2) The client: Watson Games

Formed in 1963, Watson Games Ltd are the UK’s leading producer of quality board games. In 1986,

they expanded upon the acquisition of Wadleys after they ran into financial difficulties arising from

the widely reported corporate espionage scandal “Mousetrapgate”. Watson Games design, produce

and market high end board games designed to appeal to a wide range of ages.

The shareholders for Watson Games feel that the company needs to expand its operations to

embrace the digital era and so have decided to develop a computer version of their classic Property

Tycoon game. Property Tycoon was originally designed for up to 6 players and has a reputation as a

real social experience. However, Watson also realise that it is often not possible in an ever complex

world to find 6 players to play the classic game. The head of game development, Quentin Raffles, has

hit upon the idea that the computer version (the “simulation”) could include an option for the

computer program to take the role of one or more of the players, offering an opportunity for a

richer gaming experience for a smaller number of players.

3) The rules of Property Tycoon

Quentin Raffles has provided the rules as they currently exist for classic Property Tycoon.

1) The game is for 2-6 players. Each player is assigned one of the game tokens. The tokens are:

boot, smartphone, goblet, hatstand, cat and spoon. Each player takes a turn by rolling two

dice to determine how they move around the board. At the outset, all players start on the

board space labelled Go and move clockwise around the board.

2) At the outset of the game, each player has £1,500 in cash. One player is designated the

banker and is responsible for distributing the correct amount of cash to each player. The

bank has a total of £50,000 cash. Players may not borrow additional money from the bank,

but they can trade game items with the bank.

3) At the outset of the game, the two packs of cards labelled “pot luck” or “opportunity

knocks” are shuffled and placed on the board. When cards are taken, they must be replaced

at the bottom of the corresponding pile.

4) For each turn, the player rolls the two dice. They move the number of spaces shown on the

dice and arrive at a board space. Players move clockwise around the board.

5) If a player throws a double, then they take another turn. If a player throws another double

at the third turn, then they “go to jail”. When a player goes to jail, they go directly and do

not pass Go.

6) Board spaces may consist of properties, a “pot luck” space, an “opportunity knocks” space,

“free parking”, the jail/just visiting space or a space with specific instructions that must be

followed by the player.

7) If a player lands on a “pot luck” or “opportunity knocks” space, they take a card for the top

of the corresponding pile and carry out the instructions on the card. When this is complete,

the card is replaced at the bottom of the corresponding pile.

8) Players make progress in the game by buying property as they move around the board.

Players may not purchase property until they have completed one complete circuit of the

board by passing the Go space. When a player passes Go, they receive £200 from the bank.

9) All properties are initially the property of the bank. When a player purchases a property, the

card is transferred from the bank to that player and the amount shown on the card is paid to

the bank.

10) Once a player has made their move, if they land on a property that has not yet been

purchased, they have the opportunity to buy that property. If they decide not to buy that

property then the property is auctioned by the bank. Each player makes a bid to the bank.

The bank sells the property to the highest bidder. If there are no bids, then the property

remains unsold. All bidding players must have completed one circuit of the board.

11) If a player lands on a property owned by another player, they must pay the player who owns

the property the value of the rent shown on the card.

12) If a player owns all of the properties in a colour coded group, but the properties are

otherwise not developed further with houses and hotels, then the rent due is doubled.

13) If a property is improved with houses or hotels, then the rent to be paid is as shown on the

card.

14) All rents must be paid for in cash. If a player is unable to pay the rent for a property they

have landed on, they must sell game assets to make good on the rent. If they are unable to

pay the rent after selling all of their game assets, then they are bankrupt and must leave the

game. Their game token is then removed from the board.

15) Players may not borrow or lend money from each other, and may not borrow money from

the bank.

16) When a player has finished moving their token, and has completed any property purchase

activity, they have the option to buy houses and hotels to improve their properties. Players

are not permitted to improve their properties at any other time.

17) Houses and hotels may only be purchased for properties where a player owns all of the

properties in a particular colour coded group.

18) Houses and hotels are purchased for the amount shown on the game card.

19) If a player needs to raise funds, they can sell a property back to the bank for its original value

as shown on the game card. A property can only be sold when there are no houses or hotels

on the property. A player may also sell houses and hotels back to the bank for the original

purchase price.

20) Where a coloured set of properties is owned and developed by a player, there may never be

a difference of more than 1 house between the properties in that set. If a player wishes to

buy a hotel, that is the equivalent of 5 houses in cost. A player may have 4 houses on one set

and a hotel on another in that set.

21) The maximum development permitted on any one property is one hotel.

22) If a player needs to raise funds, they may mortgage a property with the bank. The bank will

pay the player one half of the value of the property as shown on the game card. No rents

may be collected for that property whilst it is under mortgage.

23) If a mortgaged property is then sold back to the bank, it is sold for one half of the property

price as shown on the card.

24) Where fines are to be paid, the proceeds accumulate on the free parking space in the centre

of the board. When a player lands on free parking, they collect all of the funds currently on

the free parking space.

25) If a player is sent to the jail, they may pay £50 to be released from jail. The £50 is added to

the free parking fines. The player token is then moved to “just visiting” and the players turn

ends. The player takes a normal turn in the next round.

26) If a player opts to stay in jail, they give up their turn for the next 2 rounds. Whilst in jail, a

player may not collect any rents from other players. At the end of the next 2 rounds, the

player token is moved to “just visiting” and the players turn ends. The player takes a normal

turn in the next round.

27) If a player has a “get out of jail free” card, then they place the card at the bottom of the “pot

luck” or “opportunity knocks” pile as appropriate, the player token is moved to “just visiting”

and the players turn ends. The player takes a normal turn in the next round.

Versions of the game

The game can be played in two versions:

• The full game: In the full version, the game is played until there is only one player left and all

other players have retired from the game due to bankruptcy, or because they have decided

to leave the game with the agreement of the other players. In the latter case, all of the

player’s property and funds are returned to, and become the property of, the bank.

• The abridged game: In the abridged version, a time limit is agreed at the outset by all

players. When the time limit is reached, and the players have all taken the same number of

turns, the game ends. Each player then calculated the value of their game assets. The player

with the greatest value of game assets is declared the winner.

In the abridged version, the value of a player’s assets is calculated by adding up:

• Cash held.

• The value of properties as shown on the game card, unless the property is mortgaged, in

which case the value is half the value shown on the game card.

• The value of houses and hotels purchased for each property. “Get out of jail” free and

any other card items have no cash value.

4) Other user requirements

As Watson Games have no experience with software developments, all they can do is to provide

some general statements in respect of what they hope to achieve:

• The electronic version should be for desktop machines, and ideally should be playable on

both Mac and PCs. If this is difficult, then PC development should be preferred.

• There are no plans for a mobile version at this stage.

• The game should be fun to play and have a colourful and intuitive interface that reflects the

spirit and character of the original board game.

5) Core elements of the software system

You will need to design and implement a number of key elements to make this simulation work. As

well as all the necessary classes, code, interface GUI and other infrastructure elements, you will

need to create:

• A game player agent: An agent that can take the role of 1 or more of the players. This would

allow for a limited number of human players to enjoy a richer gaming experience. However,

it also provides the possibility for fully autonomous play when all of the players are provided

by the program. This will enable you to investigate various strategies as to how to play the

game to the best advantage. Such simulations could be performed at high speed. Such

simulations also offer a means of testing the performance and correct operation of your

game.

You will not be assessed against how well the autonomous game agent performs in purely financial

terms, but there is a competitive element in terms of the software design team that comes up with

the best performing game player agent. In the first instance the game player agent could just be

based on random decision making.

You will also need to ensure that your simulation has:

• A means of uploading initial data: to get the simulation started you will need a means of

initialising it with data on the board layout, the “pot luck” and “opportunity knocks” cards

and the details about the various properties (the data that is currently on the cards in the

physical version of the game. This data will be provided to you in the form of a set of one or

more Excel spreadsheets. As this data will be loaded on start-up from external files, this

means that the game is easily customised and Watson Games see this as a valuable selling

point of the new electronic version.

• A means of monitoring the performance of the simulation: including the current worth of

each of the players and the property assets that they own. This should be available for all to

see as it is the current board game version.

• A means of being tested: to ensure that the market is operating properly in accordance with

the rules of the game, and to demonstrate that the software is working correctly

It falls to your team to determine the form, structure and means of implementation of any user

interface that your system will need to meet the requirements. It should be noted, however, that a

flashy GUI does not compensate for a poor simulation.

6) The game player agent

The game player agent should be able to play the game to the same extent that a human player

would. The game player agent would roll moves and buy/bid for property. The key point here is that

the game player agent needs to be able to play the game, but it does not necessarily need to be any

good at it, at least in the first instance.

A game player could incorporate some simple rule for making in game decisions, or could feature

relatively sophisticated Artificial Intelligence. But a game player could just operate on purely random

decision making. That would still allow the game to be played. It is suggested that your make the

game player agent perform random decision making initially, and then if time permits, look to

increase the sophistication of the agent. The marking scheme places emphasis on the delivery of a

working agent, and only a small amount of its relative game playing sophistication. If enough teams

deliver an agent with some more developed decision making, then a competition will be organised

to pit player agents against each. But this will depend on there being enough teams with sufficiently

sophisticated game player agents.

A game player agent may not opt to retire from the game. A game player grant only leaves the game

when they are bankrupt.

7) Integrity of the game.

In the board game version, the bank has total resources of £50,000. In practice, there is no reason to

suppose any particular limit in the liquidity of the bank. The bank is always able to pay the players. In

the board game version, the bank can issue IOUs or generate new notes to ensure that game play

can continue.

Player may not borrow or lend money to one another. All assets procured from the bank must be

paid for in cash. The bank does not provide credit.

The range of properties available for sale by the bank, and owned by players, is a matter of public

record and that information must be available to all players at all times.

The dice used in the game must be fair with each dice have an equal probability of landing on one of

its six sides.

8) Deliverables

You are responsible for the delivery of this project as a group. Submission will be via the

Esubmissions system on Study Direct. You will need to produce:

• A requirements document: showing your functional and non-functional requirements, how

you dealt with any domain requirements, and any analysis of features that you sought

clarification for, and any other reasonable assumptions that you made as part of the

requirements analysis process.

• A project plan: showing the tasks that you identified for your team, how much effort you

planned for each task, when it was scheduled to start and complete, and which team

member(s) were responsible for it. This will likely take the form of a PERT style analysis or a

Gantt chart. Bear in mind that the execution of the plan may well up end quite different

from the initial plan. This is quite normal as sometimes things turn out differently to what

you expect. If the variations are small, you don’t need to keep the plan up to date,. If the

execution is widely different from the plan, you should consider updating the plan and

presenting both the initial and revised plans in your submission, together with commentary

to explain why the plan fell apart.

• A design document: documenting both high level and low level designs of your software

systems. Such a document should include, although is not limited to, class diagrams,

sequence diagrams, activity diagrams, state transition diagrams, use case analyses and other

UML style diagrams.

• The code base: including all non-code files or other data necessary to allow your submission

to be compiled and executed by the assessors. The code should be properly documented

(e.g. using Javadocs if you are working in Java), be commented to an appropriate standard,

and most importantly, there should be a clear relationship between the code base and the

design document.

• A testing schedule: showing how you tested the software at both unit test and system test

levels. It is acceptable for bugs and other issues to remain in the software as long as they are

clearly identified, documented and that you have provided appropriate commentary to

explain why they exist and what you would do about them.

• A group report: documenting how the project went for you, with a critical analysis of the

performance of your team, and describing what worked well for your team and what did

not. The report must also contain records of any group meetings that you had, together with

a summary of actions agreed and a weekly log recording your progress.

• A peer assessment: A document where the team agrees the distribution of a pool of marks

to reflect the relative contributions of each team member to the group project as a whole.

Your individual mark for this Software Engineering module will be a composite of your team

score and an individual score determined by your peer assessment. If any individual does not

make a contribution to the group effort, the assessors reserve the right to award an

individual score of 0 for that team member for the module as a whole.

Your team will also be required to attend a progress review meeting with one of the assessors to

ensure that you are keeping on track. You can request additional meetings if you need them and the

assessors will endeavour to provide support as needed. But your first port of call for any problems

should be the scheduled seminar sessions.

When you upload your deliverables, please use Word or PDF formats for text documents. Do not use

Mac Pages files as these are not widely supported. For code deliverables, please remember to

include any project (e.g. Eclipse, BlueJ), initialisation or other external files your code needs to be

run. If assessors cannot run your code, they will likely ask for demonstrations of the operation of key

parts of your code. Do not upload files that are in obscure formats. Assemble all of your documents

together and create a single ZIP file with everything inside. Upload the zip file onto the Esubmissions

system. Check that your ZIP file unpacks correctly before uploading it.

You will be also be required to give a short demonstration of your project at the end of the

semester. This will be an informal demonstration to your lab seminar leaders or the module

convenor.

9) Peer assessment

Each team has 20 points to distribute per member of the group. Each member gets a peer mark,

which is a non-negative integer (including 0) such that the sum of all members’ peer marks is 20 x

the number in the group. The idea is that the peer mark reflects the contributions of each member

to the project. It is perfectly acceptable to give each member the same mark.

Here is an example. Assume the group has members: Alice, Bob, Charles, Diana, Eric, Fiona, George

and Herbert.

• Alice: 25

• Bob: 0

• Charles: 30

• Diana: 20

• Eric: 15

• Fiona: 15

• George: 35

• Herbert: 5

In this case, George contributed most to the group, followed by Charles and Alice, and so on. Bob is a

“ghost” – who never contributed to the group work at all. I take that as a signal from the rest of the

group to that effect, and he will not be awarded the grade for the project the others receive. I think

that’s fair. Note that a ghost’s marks count as some measure of compensation for the others for the

increased workload they are under.

When submissions are graded, each member of the team receive a base mark (except for ghosts)

which reflects the quality of the design process, how well teamwork has gone on, and so on (actual

code, while it inevitably has an influence, is the least important element from the point of view of

this module). The team score will then be combined with the peer mark. A standard peer mark of 20

will count for around 10 percentage points, or about one grade.

Only one submission per team of your agreed marks is required, but it will need to be clear that it is

agreed between you (excluding ghosts). If there is really no agreement, I will make the final decision.

To do so, the team will be called to a follow up meeting to explain the reason(s) for their

disagreement.

10) Final observations

There is no single right way of designing and delivering this Software Engineering assignment. You

will be assessed according to your ability to come up with a coherent set of requirements, project

plan, software design, implementation, testing and production of a final report. A set of marking

criteria will be published on Study Direct.

If you do not understand something, use the Software Engineering seminars to ask questions and

raise discussions on the assignment. You can also discuss ideas with other teams, but do not copy

the work of other teams. If you require clarification on any points arising from this document, any

such clarification will be copies to all students and teams via your Sussex email address. You should

also keep an eye on your Sussex emails in case the Watson Games project manager decides to issue

an updates, amendments or clarifications on their user requirements. The customer is always right,

even when they are changing their mind. As a consequence, you should try to anticipate any

requirements shift that might arise and try to design your software so that changes can be easily

accommodated. This is not always an easy thing to achieve in practice.

You will need to ensure that you team meets often, documents decisions that it makes and that the

workload is spread fairly between team members. The most common cause of problem with team

based assignments such as this is a breakdown in team dynamics. A part of the assessment process

will require teams to submit a peer assessment to evaluate the relative contributions of each team

member to the overall delivery. If a team member does not contribute to the team effort as a whole,

I reserve the right to award that team member a score of 0. Do not leave problems unresolved. If

you are having team issues, you should try to resolve them yourselves first, and take the issue up

with one of the teaching assistants in the seminars, or through a private meeting between one of the

teaching assistants or me as you see appropriate.

So, work together, and have some fun working on this team assignment.

Dr Kingsley Sage
Dept of Informatics and Engineering
Khs20@sussex.ac.uk
February 2018

ENDS.

mailto:Khs20@sussex.ac.uk