DOC

Introduction

By Alvin Alexander,2014-04-19 05:21
13 views 0
Problems and Programmers is an educational software engineering card game. It is directed at students with a basic to intermediate background in software

Problems and Programmers Instructions

Introduction

     Problems and Programmers is an educational software engineering card game. It

    is directed at students with a basic to intermediate background in software engineering.

    The game would optimally be used with students midway through an introductory course

    and who have been exposed to the discipline’s basic concepts. However, some problem

    cards expose players to ideas that would also be appropriate in a more advanced setting.

    In addition, a future version of this document will include a separate description of the

    rules, designed teach players entirely new to the discipline enough of the basics to play

    and learn from the game.

     The game strives to teach players by simulating the software development process,

    from documentation to delivery, and on to delivery. Generally players following proper

    software engineering practices will be rewarded, while those taking risks and cutting

    corners will be punished. This punishment comes largely in the form of problem cards

    played by opposing players. The workings of the code system also is modeled after the

    real effects of software engineering and will reward wise players. By the end of several

    games, players will learn which courses of action are effective and which are dangerous.

    These lessons will be effective in the game, as well as in reality.

Your Goal

     The goal of Problems and Programmers is simple, to be the first to finish the

    project. Each participant plays as a project manager, competing against the other to

    complete the project satisfactorily first. Each player works for the same company, but

    there is nothing wrong with a little internal competition. Over the course of the game,

    each of you will take a software engineering project from conception to completion,

    while trying to avoid the possible pitfalls of programming through planning, preparation

    and luck.

Setup

    At the start of the game, shuffle each of the decks.

    - The code deck has colored backs, and is the second largest deck.

    - The main deck is the largest deck, and its cards instead have blank backs.

    Place both of these decks between the players. Later in the game, when the time comes to discard any cards belonging to these decks, place them face-up next to them to

    form discard piles (if either of the decks run out you can shuffle the discard piles and re-

    use them).

    The project deck has only 9 cards and is the smallest deck. The documentation deck meanwhile is slightly larger. Place these to the side, they will only be used at the

    beginning of the game and do not require discard piles.

Beginning of the Game

    The first thing that happens at the start of the game is that a project is chosen at random from the projects pile. This represents the program that both players will be

racing to complete. Place this project card in the middle of the play area between the

    players. The card information is repeated and flipped on the card so that both players

    have easy access to the projects properties. These are very important to the game and

    include:

- Complexity: This is how many time points a programmer needs to spend to complete

    one piece of good code. The two possibilities for this value are 2 or 4.

    - Length: This is how many code cards must be completed to integrate and finish this

    project.

    - Quality: This represents how bug-free the client expects the final product to be. In

    game terms, this is how many code cards will be drawn from your final project

    during the product delivery stage. All of these codes must be bug-free or the project

    will have to be partially redone.

    - Budget: This is how much money you will have to spend on the project and will be a

    restriction on the programmers you are able to hire.

    Don’t worry if some of these descriptions don’t make sense yet, they will be

    explained in more detail shortly.

The Main Deck

After every player has their project, each player draws five cards from the main deck (the

    large deck with the cards with blank backs).

Take a quick look at the cards in your hand. The Main Deck contains three types of cards:

    programmers, problems and concepts. Each has several important features, which are

    described in detail below:

Programmers

     Programmers are at the heart of your implementation phase and are necessary for

    coding and generally getting the job done. They have 3 attributes players should look at

    before deciding whether or not to hire them:

    1) Salary: This is how much the programmer must be paid.

    Programmers with higher salaries will take up more of your

    budget.

    2) Skill: This is the number of time points that a programmer

    gets per turn. Every action that a programmer takes requires a

    certain number of time points, and so a programmer with

    more speed can get more done in a turn. Skill is rated on a 1-5

    scale, with 5 of course being the best.

    3) Personality: This is the programmer’s tendency to be a

    good worker, rated on a 1-5 scale. This includes their

    friendliness, professionalness and how well they follow normal software engineering practices. The lower a

    programmer’s personality, the more vulnerable to problem

    cards they are.

    When you play a programmer, place it to the right of any programmers you

    1already have at the bottom of your play area.

    Before you can play any programmer you must make sure that doing so would not

    cause the total of your programmers’ salaries and perks’ costs to exceed the budget for

    your project.

Problems

     Problem cards represent things that go wrong during a software engineering

    project. They are played on an opponent during their implementation stages, but only if

    they meet certain criteria. Players taking proper precautions may be immune to some

    problems. Problem cards have 3 main parts to be considered:

    1) Criteria: This is what conditions must be met for you to be

    able to play this card on a given opponent. This is the card’s

    way of saying, “This card can only be played on a [criteria]”.

    2) Criteria Abbreviation: This acts as a quick reference for

    the card’s criteria.

    3) Effect: This is the effect on the player or programmer that

    this problem is played on. Most problems are used and then

    immediately placed in the discard pile. Persistent problems

    are placed in play and continue to hassle their recipients.

    Also notice that problems are color-coordinated, from green to blue to red, in

    order of increasing severity.

     You may play one problem card on your opponents during their implementation

    phase. But you may only do this if they or their programmers meet the criteria on the

    card. When you play a problem, if the recipient meets the crieria, they are subject to the

    effects of the problem. For example:

    ? This player loses X progress: You may choose X of this players code cards and

    discard them.

    ? Discard [something]: When a card is discarded, place it in the appropriate discard

    pile. Documentation cards should merely be placed on the bottom of the decks they

    came from.

    ? Programmer is fired or quits: This programmer is discarded. Any code they have

    worked on is left behind.

    Persistent problems should be placed as described in the problem. Project

    problems are placed on the side of the project card that is face-up for that player and

    represent effects that only they must deal with. Programmer problems should be placed in

    the area under the programmer they are effecting. If space is tight, the problems can

    actually be placed underneath their victims, as long as the name remains exposed.

    1 See appendix B for comments on this.

Concepts

     These represent optional decisions that may be made during a software lifecycle.

    All remain in play until discarded (placed in the discard pile) and may change how or

    how fast you progress. They have 2 important parts:

    1) Effect: This is what this concept card does.

    2) Cost: Some concepts have a cost. This is treated in the

    same manner as a programmer’s salary and cannot be played

    if it would cause a budget excess.

    Concepts can be placed in any available space; the left side of the play area can be

    convenient. Those concepts with persistent effect effecting projects should be placed

    near them to indicate this.

Game Structure

     Once all players have familiarized themselves with the cards in their hands, they

    can get started. The youngest player goes first. After each player’s turn, the next player

    in clockwise order takes a turn.

The Waterfall Model

     In Problems and Programmers, players follow the well-known waterfall model for

    developing their project. The game uses a five-step version of the waterfall model,

    dividing implementation into two steps. Each step of the waterfall is then represented by

    a represented by a stage of the game.

     Each stage determines the actions that a player can take. Players may move on to

    the next stage in the lifecycle at their own pace, but once a player has moved on, there is

    no going back. The decisions made in each stage greatly effect the player later in the

    game; thus the decision to move on must not be taken lightly.

    In general, each turn a player will take the following actions in this order:

    1) choose whether to move on to the next stage

    2) draw cards

    3) take action based on their stage

    4) play programmer and concept cards

    5) discard cards they don’t need

    It is worth noting that this turn structure can slow your ability to fire and rehire

    programmers. If a programmer is being fired to clear budget room for another

    programmer, the second programmer will not be able to be hired until the turn after the

    firing. Similarly, the new programmer will not be able to take action until the turn after

    they are hired. This is intentional and is used to illustrate the diffculties associated with

    getting new programmers up and running.

    All players start in the requirements stage, the first stage of the waterfall lifecycle

    model. Players in the requirements phase of their project take the following steps during

    their turn:

Requirements Stage

1) Decide: First, you must choose whether to move on to the design phase. If you do,

    you must begin following the steps in the design stage instead of those described

    below. Otherwise:

    2) Draw: If you have less than five cards in your hand, you may draw cards until you

    have five.

    3) Work on Requirements: You take two cards from the documentation deck and place

    them to the far left side of the play area (red area above). You may forego drawing

    one or both of these cards to replace an existing unclear documentation card. In this

    case you may replace one card for each draw you gave up.

    While the number of requirements cards that you need is up to you, a good maximum

    to keep in mind is six. There are problem cards that will target players with less than 1

    requirement card, others that target those with less than 2, and so on. But once you have

    six requirement cards you need only worry about your requirements being unclear.

    Speaking of which, it will often be beneficial to replace unclear documentation, as these

    will make you vulnerable to certain problem cards.

4) Play: You may put any number of programmer and concept cards from your hand

    into play (as long as you do not exceed your budget)

    5) Discard: You may choose and discard any number of cards from your hand. You may also fire any number of your programmers or discard any of your concepts.

    Programmers that are fired leave their code behind and if other programmers wish to

    work on it they must pay a “help penalty” (see below under implementation).

    The next time it is your turn, you will follow these steps once again, starting with

    the decision to move on or not. If you do move on, your new steps are below in the…

Design Stage

    1) Decide: First, you must choose whether to move on to the implementation phase. If

    you do, you must begin following the steps in the implementation stage instead of

    those described below. Otherwise:

    2) Draw: If you have less than five cards in your hand, you may draw cards until you

    have five.

    3) Work on Design: You may take two cards from the documentation deck and place

    them to the far left side of the play area (red area above). You may forego drawing

    one or both of these cards to replace an existing unclear documentation card. In this

    case you may replace one card for each draw you gave up.

    Once again, six design cards should be enough to prevent almost all design-based

    problem cards. It is often beneficial to replace unclear documentation, as it can make you

    vulnerable to problems.

4) Play: You may put any number of programmer and concept cards from your hand

    into play (as long as you do not exceed your budget)

5) Discard: You may choose and discard any number of cards from your hand. You

    may also fire any number of your programmers or discard any of your concepts.

Implementation Stage

    In this stage, you are vulnerable to problem cards, so be careful. Here you may

    find yourself paying the price if you made bad decisions earlier on. This also means that

    when your opponent enters this phase, make sure you are ready to cause them trouble

    with problem cards of your own.

1) Problems: Each other player may play one problem card on you if you meet its

    criteria.

    2) Decide: If you have integrated code cards equal to or greater than the length of your

    project, you may choose to move on to the product delivery phase. Notice that these

    cards may or may not have bugs, and need not even have been inspected. But keep in

    mind that during the product delivery phase, these cards will be checked based on the

    quality requirement of your project, and if any bugs are found there will be

    consequences.

    3) Draw: If you have less than five cards in your hand, you may draw cards until you

    have five.

    4) Implement: Before you can even think about integrating code however, you must

    produce it. In this stage, each programmer that you control may take actions. A

    programmer’s skill determines how many time points they have, and thus how many

    actions they may take. Programmers have 4 options on each turn, each consuming

    time points. They may take any combination of actions as long as they have enough

    time points. The four actions a programmer can take are:

    o Program Good Code (Cost = Complexity of your project)

    Take one code card from the code deck and place it face-down above this

    programmer and above any code cards already above them. Because this is

    good code, place the blue side farthest from the programmer.

    o Program Rush Code (Cost = Half the project’s complexity, rounding up)

    Same as above, but place the red side farthest from the programmer.

    o Inspect Code (Cost = 1 time point)

    Flip over one of this programmer’s face down cards of your choice. Be

    sure that the card’s red/blue facing relative to the programmer is

    maintained. If the card is a bug card this can potentially cause problems

    when the project is completed (remember your quality requirement?). Any

    nasty bugs that are found cause the code card directly above them to be

    discarded and the nasty bug to immediately be replaced with a code card

    of the same quality.

    o Fix a Bug (Cost = 1 time point)

    This programmer can fix a simple bug for one time point, replacing it with

    a card of the same quality from the code deck. A normal bug meanwhile is

    “fixed” by swapping it with the code card above it, or if it is the top code

    card it can be finally replaced. Thus it may be necessary to take several

    bug fixing actions to be rid of a normal bug. Bugs may be addressed and

    fixed in any order that you choose.

    Fixing bugs can work wonders for meeting your quality requirement at the

    end of the game.

So, for example, a programmer with 4 skill and a project with a complexity of 2

    could:

    Program two good code (each costing 2 time points)

    Program one good code and inspect 2 code cards (2 + 1 + 1)

    Inspect 2 code and fix two simple bugs (1 + 1 + 1 + 1)

    Etc…

A programmer need not use all of his time points in a turn.

Finally, instead of taking any normal action, a programmer may help. In this case

    the programmer may work on another programmer’s code as if it was his own,

    with a two point penalty, paid once for all actions taken. So a 4-skill programmer

    could take 2 points-worth of action on another programmer’s code column. These

    points may be combined with other programmers’ points to cooperatively create a

    code card, as long as enough points are available between them.

    This is also the only way that code created by a programmer who no longer works

    for you can be effected. So be sure to hold onto your most productive

    programmers!

     Or you may integrate

If you have completed code cards equal to the project’s length, you may integrate

    this turn instead of taking any programmer actions. In this case you take all of the

    code cards above one of your programmers and put them in a separate column to

    the right of all programmers. This represents your integrated code, which cannot

    be changed, nor effected by any player’s problems. Once you have integrated

    code equal to the length of your project you may move on to your product

    delivery!

Note: Be careful! Do not change the alignment of any of the cards when moving

    them, whether they are good or rushed code is still important.

    5) Play: You may put any number of programmer and concept cards from your hand

    into play (as long as you do not exceed your budget)

    6) Discard: You may choose and discard any number of cards from your hand. You

    may also fire any number of your programmers or discard any of your concepts.

Product Delivery Stage

    This is the final challenge for your project; will it meet with your client’s approval?

    1) Product Use: Take all of your code cards and turn them face-down (again keeping

    them aligned in the same way). You must now mix up their order (careful of the

    facing!) and one opposing player may choose to cut the pile once. Finally, reveal

    cards off of the top of the pile equal to your quality requirement. If they none are bugs,

    you win!

    If any of the card revealed are bugs marked nasty bugs, you lose the game. These are

    bugs so severe that the product is completely unworkable, the customer is appalled and so

    is your boss. In this case the project is cancelled and beyond repair.

    But if there are any simple or normal bugs, the project is flawed but can be fixed. In

    this case, you must place all of your code cards over a single one of your programmers.

    You may choose the programmer, but your opponent chooses the order that the code

    cards are arranged in. You must go back to the implementation stage and proceed as

    normal, attempting to once again finish your project. Keep in mind that you will once

    again be vulnerable to problems as you work out the bugs in your project, and your

    opponent would likely like nothing more than to seize victory from your grasp!

A Brief Glossary

    ? Discard Place in the discard pile of the deck from whence the discarded card came.

    ? Help When one programmer gives his time points to another, with a standard two-

    point penalty.

    ? Lose X Progress Discard X of the targeted players code cards, of your choice. ? Good Code Code that is blue side-up if facedown, or blue-side-up if face-up. ? Phase One of five parts of a single turn.

    ? Rush Code Code that is red side-up if facedown, or red-side up if face-up. ? Stage One of the five parts of the waterfall model, and therefor the game.

This document and all other documents and images packaged with it are Copyright? Alex Baker 2002. All the Problems and Programmers files packaged with this document may be distributed freely, provided they remain unchanged and packaged together.

Report this document

For any questions or suggestions please email
cust-service@docsford.com