Software Tycoon: A Software Development Simulation Game Joseph ABRIGO

Iñigo AMBAS

Jess CHIN

Software Technology Department College of Computer Studies De La Salle University – Manila 2401 Taft Avenue Manila, Philippines [email protected]

Software Technology Department College of Computer Studies De La Salle University – Manila 2401 Taft Avenue Manila, Philippines [email protected]

Software Technology Department College of Computer Studies De La Salle University – Manila 2401 Taft Avenue Manila, Philippines [email protected]

Carlo GAVINO

Rhia TROGO-OBLENA

Software Technology Department College of Computer Studies De La Salle University – Manila 2401 Taft Avenue Manila Philippines [email protected]

Software Technology Department College of Computer Studies De La Salle University – Manila 2401 Taft Avenue Manila, Philippines [email protected]

ABSTRACT Software Tycoon is a software development simulation game that allows the gamer to manage a software development firm. The game applies to the game play software engineering concepts and problems that are inherent in the software development process. The game employed simulation algorithms for generating entities like projects, employees, and software problems. Software models available in the game are based on the software engineering curriculum as recommended by the Association for Computing Machinery. This paper illustrates the formulae used in the software development simulation game. Keywords simulation games, software process models, software engineering, project management, game design

I.

INTRODUCTION

Simulation games provide elaborate role playing in which gamers simulate models of real-life situations. Gamers achieve the game objectives by making decisions. In recent years, simulation games and training simulators have become popular. Many simulation games are being used as training simulators for a variety of fields. An example would be America's Army, which was initially used as a recruitment tool, but is now being used to train future officers at West Point [5]. A popular type of simulation game is the economic simulation game. Economic simulation games fall under simulation games and focus more on the management of business or businesses to gain profits, which could be in terms of money and assets, and control the market. These games simulate a certain

field of business where the objective is to learn about the workings of the business, overcome difficulties, maximize profits and expand the business. Examples of these games are Railroad Tycoon[7], Mall Tycoon [6] and Theme Hospital [4]. The target market of these games is usually the casual gamers, since these simulation games do not require players to have an extensive gaming experience. A unique aspect of economic simulation games is that it allows the players to play a role in a virtual business setting. It makes the player learn concepts important to the business as the player delves into the game. Problems are included in the game to make the game challenging for the player, this in turn increases the player’s capability to analyze, ability to adapt to business situations and decision making competency. Simulating the software development process is a recent topic for research in the field of software engineering. Simulating projects would provide many benefits since it would enable software engineers to reduce risks, predict project behavior and evaluate projects with comparison to simulation. There exists software engineering simulation “games”. For example, SimSE is an educational tool which simulates the software development process [8]. The player’s role in the game is that of a project manager. However, SimSE is focused more on the training aspect of simulation rather than entertainment. As of this document’s time of writing, there are no software that has been released that portray software engineering as a game.

II.

GAME PLAY

The system is a turn-based single-player economic simulation game that simulates software engineering in the software development level. The player is able to create his/her small-scale

software development company along with an initial team of developers. Most of the game play is centered on project management while managing other aspects of the company (such as managing the office, training employees, and applying for accreditation). The goal of the game is for the player to achieve maximum reputation and profit and to do this, the player has to unlock and master process models, master bidding and management techniques and acquire a higher accreditation level.

one corresponding software tool at any given time) is overridden by a newly-purchased tool. The software tool will have a global effect on working employees as long as it exists.

Game To start a new game, the player creates his/her own personal character (the PM) and company. In a new game, the player starts out with 8 employees under him/her, a small amount of cash, and a small office with 10 cubicles.

Rival Companies There are ten rival companies that the players will have to compete against. The scores of the rival companies change during game play to challenge the player. Rival companies are competitors during a bid for a project.

Employees Each employee has a name, wage, personality (defined by MyerBriggs Type Indicator), statistics (the different technical skills in software engineering, as well as process model and project type proficiencies), and morale. Employees are unique, having different maximum values for technical skills, in effect this encourages the player to make the best out of each employee’s specialties.

Bidding When a player decides to take on a project, the player will have to bid for the project. A rival company will attempt to make a better bid against the player’s. Bidding will be done in one, decisive moment, in which the winner is immediately decided. The player will have to choose just the right price for the project; the team he/she fields out for the project will also decide the level of support it can provide for the project. The more support a team can provide, the better. On a successful bid, the player may then choose which process model to use.

Hire When the player chooses to hire an employee, a list showing the available free agents, their skills (i.e. coding skill) and traits (i.e. personality), and starting wage is displayed. The player may then choose a person from the list, and the new hire will then join the team on the next turn. When an employee is fired, that employee is gone forever. Train When the player chooses to train an employee in a skill, he/she is made to choose from either exercises or seminars. Exercises take only one turn to complete, giving a small increase in the skill chosen for training, while seminars take 5 turns to complete, albeit giving a much larger increase compared to 5 exercises in a row. Exercises and seminars cost money. Also, exercises take a small amount of morale from the employee, while seminars take a larger amount of morale from the employee. Wages The player may opt to change an employee's wage. An increase in wage improves morale, while a decrease reduces morale. The player is expected to balance out spending while maintaining productivity. Vacation When sending an employee for a vacation, the player sets the number of turns the employee is away. An employee's morale increases when sent for a vacation, but the employee is inactive for the duration of the vacation. Additionally, the lower an employee's morale is, the greater the chance of the employee getting sick, thus forcing him/her to take a sick break. Sick breaks are automatic and last as long as it takes for the employee to get better. Note that employees are still paid while on vacation, but not on sick breaks. Office Expanding the office costs money, but the result is increased office space, allowing the accommodation of more employees. When the player purchases a software tool, the tool will remain in his/her company until its slot (each technical skill can only have

Team The player may choose to view and manage the team roster. A team has a minimum of five members and a maximum of ten members.

The higher the reputation of a company the more difficult and the more rewarding the projects will be to challenge the player. Process Model The player must choose a process model upon winning the project bid. The player will then have to assign and schedule tasks according to the chosen process model. A variety of software development tasks may be given to employees working on a project, including: requirements, design, coding, testing, or documentation. Other models may have different tasks. Tasks Tasks are assigned to the team members, the process model dictates what type of tasks may be assigned to the members of the team. Problems During project development, problems may occur. The occurrence of these problems is dependent on the game state. The player may choose whether to address them or to ignore them. Ignoring a problem will increase the likelihood of the rejection of the project upon delivery. To address problems, the player can try to remove the problem by triggering a cause that facilitates its disappearance. Table 1 shows the problems that can occur during the game. Problems mentioned in the table are based on the works of [3], [2], [1], [8]. Table 1. Problems that can occur during the game. Problem Pre-condition Bankruptcy and Stagnation Scope Creep Brook’s Law

Negative capital for 10 turns or no projects for 10 turns Sudden change in requirements but player did not meet with the client Adding a new person to a team when the project elapsed time is 80% approaching the deadline

Error Crunch Time Pressure Incomplete Specifications Misunderstood Requirements Spaghetti code

Errors found when the project elapsed time is 80% approaching the deadline Project is less than 70% complete and is 80% approaching the deadline Team did not meet the client for more than 15 turns Detected design error unit of progress is 0.1 Team’s average coding skill is below 65; Design lower than 50% when coding started Team’s average documentation skill is below 65 Team’s average requirements skill is below 65

Erroneous Documents Specification Mistakes Demoralized Team’s average morale is lower than 30 Team Low SPM Team’s average SPM proficiency is lower Proficiency than 4 Low ST Team’s average ST for project is lower than 4 Proficiency Incompetent Any average technical skill of a team is below Team 65 Wage Salary of an employee is lower than hi Dissatisfaction expected salary No Wage Company cannot pay an employee’s wage Syndrome Overworked 30 turns of doing project without vacations , Employee more than 5 consecutive training orders Faulty Employees conducting reviews have low Reviews testing skill; Employees writing documents have low documentation skill Personality A single personality trait takes up most of the Conflict team’s personality makeup

Project The player may view the completeness of his/her projects at any time. Completeness is the amount of work done on the project. After the project has reached a certain level of completeness, it can now be delivered to the customer. Upon delivery, the project is then scored by completeness, correctness, and remaining time and money. The player is then paid bonus money in reference to the of the project score. If the player runs out of the budget money during a project, his/her own capital will be used. If the player runs out of capital and remains in such a state for 30 turns without a project, the player loses the game. When the player succeeds delivering the project, his/her reputation with the commissioning corporation will increase. On failure, the team working on the project will become dejected (from the rejection) and will be unable to work for a turn. The player’s accreditation level will determine the difficulty of projects. Process Model When the player wants to unlock a model, he/she must then invest money on research. The model immediately becomes available after paying the necessary research fee. Certain models may not be appropriate for certain types of projects, hence, some models may cause progress rate to slow down. The process model that is initially available is the Waterfall Model. Other process models are made available in the following order, Spiral, Rapid Prototyping, Incremental, RUP, Extreme Programming and Scrum. Table 2 presents the different models and their phases and rules used in the simulation game.

Table 2. Table of process models, corresponding phases and rules. Process Model Phases Rules Waterfall Requirements Cannot move to the Analysis, Design, next phase without Coding, Testing 70% of current and Documentation phase done Spiral Requirements, Player defines how Design, Coding, to divide project Testing and implementation Documentation time among phases Rapid Prototyping Initial Prototype Progress should be Requirements at least 25% when Design prototype is Coding accepted Testing Incremental Requirements, Projects are divided Design, Coding, by module into Testing and mini-projects Documentation RUP Inception, Phases can overlap Elaboration, Construction and Transition Extreme Requirements, Auto-assign tasks Programming Design, Testing, Coding, Refactoring Scrum Requirements, Project divided into Design, Coding, modules. AutoTesting and assign tasks. Documentation

Software Tools The software tools can be purchased to increase employee productivity. Accreditation To increase his/her company’s accreditation, the player must pay a fee in order to submit an application for higher accreditation. After applying for accreditation, the player must wait 10 turns before the verdict is given. The verdict is based on the company’s project track record. If the application is accepted, the player’s accreditation level increases immediately. Should the application be rejected, the player may apply again. Score Additionally, at any point in the game, the player may view his/her status and score. The player's accreditation, project standings, total earnings, etc. are shown. This allows for selfassessment. Also, the player may check the company rankings, which compares the player’s scores with rival companies. Most actions in the game cost a turn or more to complete. Turns are equivalent to a day in game time.

III.

SYSTEM MODULES

Figure 1 illustrates the system architecture. The succeeding section explains what each module does in the system.

3.1

Company Module

The system stores the player information in the Company module. This module also holds the player’s roster of employees as well as the projects he/she is working on. It also contains the

player’s accreditation level, process models and project track record.

3.2

Where, m = morale t = technical skill level being used in the phase pprocessmodel = proficiency in the process model being used s = proficiency in the software type of the project n = number of ongoing projects bprocessmodel = bonus from software process model bmeeting = bonus from meeting btool = bonus from tool ppenalty = penalty

Roster Module

The system uses the Roster module for employee management. Through the Roster module, the player may hire, terminate, train, send on vacation, and change the wage of employees. The Roster module also handles the creation and disbanding of teams.

3.3

Item Module

The system uses the Item module for item management. Through the Item module, the player will be able to purchase software tools for his/her company.

3.4

Problem Module

The system uses the Problem module for problem generation. Generated problems introduce challenges to the player which must be overcome. Problems may be generated when triggered by certain preconditions.

3.5

Game Data Module

The system uses the Game Data module for management of the player’s game data. Through the Game Data module, the player may save his/her progress and load it at another time.

The system traverses through the list of the employees currently working on the project, acquiring the value of the technical skill of each employee. Bonuses and penalties such as meeting bonuses, tool bonuses, software type proficiencies, model proficiencies and number of ongoing projects are then applied to the skill of the employee. The skill may decrease or increase, depending on the incurred bonuses or penalties. Table 3. Technical Skills range given Accreditation Levels Accreditation Level 0-1 2-3 4-5 6-7

Technical Skills 50-70 60-80 70-90 80-100

Process Model Proficiencies 0-5 5-10 10-15 15-20

Soft Cap Value +6 Value +6 Value +6 Value +6

4.2 Progress

Figure 1. System Architecture

IV.

FORMULAE

Progress (P') is an increasing value which adds all productivity scores of all team members for a phase in the project/module. Some problems and inspections may reduce progress. Progress can never exceed the size of the project (which is defined during generation). Progress is measured in terms of the total amount of work to be done for the project to be completed.

The following formulae were used in the game simulation.

n

P’ = P’ + (

4.1 Productivity Productivity (P) measures how much work an employee contributed in a turn. It is affected by the employee's morale, technical skill, proficiencies, number of ongoing projects, bonuses from software process model, meetings, and tools (if any are applicable), and penalties from problems and software process model (if applicable). The Productivity is measured in terms of the amount of work per turn. P = (((m/100) * (t + pprocessmodel + s) ) / n )+(bprocessmodel + bmeeting + btool) – ppenalty P = P * 1.5 if Software type of project is equal to Employee’s specialization

∑ ei i= 0

(Pn))

Where, Pn = Productivity score for turn n en = Employee (team member) n After traversing through the list of employees to compute their productivity, the system sums up the individual productivity of the employee and adds it to the project’s progress.

4.3 Error Rate Error rate (E) is the number of errors committed by an employee per unit of productivity. Error rate is influenced by technical skill, bonuses from software process model and tools, and penalties (which increase error rate). Error Rate is measured

in terms of the number of errors committed by an employee per turn. E = ((105 – t)+ppenalty – (bprocessmodel + btool))

C = (P’ / S) * 100 Where, P’ = Progress S = Size of Project

Where, t = technical skill being used in the phase bprocessmodel = bonus from software process model btool = bonus from tools ppenalty = penalties Error rate is calculated depending on the employee’s technical skill. As stated in the formula, the chance of an employee committing errors while doing the task is 105 minus the employee’s technical skill. Maximum technical skill is 100 and the technical skill is subtracted from 105 to ensure that even if the technical skill of an employee is 100, the employee can still make a mistake. Additional bonuses that modify the error rate or the number of errors are directly applied after this basic computation. Depending on the bonuses or penalties, the chances of committing an error and the number of errors may increase or decrease.

The computation of the completeness is used mostly in the interface for progress bars to show the progress of the projects.

4.6 Customer Value Customer Value (Cvalue) is a project scoring criteria measuring the importance of the project to the client. It is based primarily on how well the client’s requirements are collected and addressed. It makes up 40% of Customer Acceptance. Customer value is measured in terms of integer values in client acceptance. Cvalue = (P’1 / S) * 100 if Cvalue > 40, Cvalue == 40 Where, P1 = Progress of Requirements Phase S = Size of Project

4.4 Errors Made Errors Made (E’) is the actual number of errors an employee has made during a turn. This value is hidden from the player. Errors Made is measured in terms of the number of errors committed by an employee per turn. E’ = random between [1, 5] The system generates a random amount of errors whenever the process rate of chance is satisfied. Total Errors (Etotal) is an increasing value that adds up all the errors made by all team members for a phase in the project or module. This value is hidden from the player. Total Errors is measured in terms of the total number of errors committed by the team assigned to a project per turn.

The system always uses the first phase, regardless of process model, since the first phase places emphasis on requirements.

3.6 Performance Performance (Pperform) is a project scoring criteria measuring how well the project was carried out, as well as the promptness of its delivery. It takes into account the errors committed throughout the project. It makes up 25% of Customer Acceptance. Performance is measured in terms of integer values in client acceptance. Pperform = (D – Telapsed) + ((P’4 – E) / S) * 100 if Pperform > 25, Pperform = 25 Where,

n

Etotal = (

∑ ei i= 0

(E’n))

Where, en = Employee (team member) n E’n = Errors en made for turn n The system sums up all the errors of all team members after every turn.

D = Deadline of the project (turns) Telapsed = Time elapsed for project (turns) P’4 = Progress of the Testing Phase E = Total Errors S = Size of Project

The system always uses the fourth phase, regardless of process model, since the fourth phase places emphasis on testing.

4.7 Technical Value 4.5 Completeness Completeness (C) is a percentage measuring how close the project is to reaching completion. It is taken from progress and the size of the project (which is defined during generation). Completeness is measured in terms of the amount of work done on a project.

Technical Value (Tvalue) is a project scoring criteria measuring the significance of the project in terms of difficulty, as well as the client’s confidence in the team’s design and implementation skills. It makes up 20% of Customer Acceptance. Technical Value is measured in terms of integer values in client acceptance.

Tvalue = 0 if M else else else else

≥ 10, Tvalue = Tvalue + 5 if M ≥ 8, Tvalue = Tvalue + 4 if M ≥ 6, Tvalue = Tvalue + 3 if M ≥ 3, Tvalue = Tvalue + 2 Tvalue = Tvalue + 1

if Adesign ≥ 90, Tvalue = Tvalue else if Adesign ≥ 80, Tvalue = else if Adesign ≥ 70, Tvalue = else if Adesign ≥ 60, Tvalue = else Tvalue = Tvalue + 1 if Aimplementation ≥ 90, Tvalue else if Aimplementation ≥ 80, + 4 else if Aimplementation ≥ 70, + 3 else if Aimplementation ≥ 60, + 2 else Tvalue = Tvalue + 1

+ 5 Tvalue + 4 Tvalue + 3 Tvalue + 2

= Tvalue + 5 Tvalue = Tvalue

Client/Customer Acceptance (Caccept) measures the probability of the client accepting the delivered product (and thus making the project successfully accomplished). It is based off customer value, performance, technical value, and reviewer’s discretion. Client acceptance is measured in integer values. The higher the integer values, the higher the chances of a project to be accepted by the client. Caccept = Cvalue + Pperform + Tvalue + Rdiscretion + B Where Cvalue = Customer Value Pperform = Performance Tvalue = Technical Value Rdiscretion = Reviewer’s Discretion B = Bonuses (from Process model)

Tvalue = Tvalue Tvalue = Tvalue

if Pmodel ≥ 16, Tvalue = Tvalue + 5 else if Pmodel ≥ 12, Tvalue = Tvalue + 4 else if Pmodel ≥ 8, Tvalue = Tvalue + 3 else if Pmodel ≥ 4, Tvalue = Tvalue + 2 else Tvalue = Tvalue + 1

The system created an object called Evaluation to represent the evaluation of a project upon delivery. Desired Wage (Dwage) is the wage required in order to keep an employee content. It is based off the employee’s capabilities, and has a 10% tolerance level (above and below). An employee with a wage within the desired wage range would not experience a decrease in morale due to being underpaid.

Where, M = Number of modules in the project Adesign = Team’s average design skill Aimplementation = Team’s average implementation skill Pmodel = Team’s average proficiency in the process model used Technical Value is expected to be low in the early stages of the game, as employees will still have low skill and proficiency values, and projects will be simpler, having only a few modules.

4.8 Reviewer’s Discretion Reviewer’s Discretion (Rdiscretion) is a project scoring criteria taking into account the company’s reputation, the overall morale of the employees, and the reviewer/client’s opinion on the company. It makes up 15% of Customer Acceptance. Reviewer’s Discretion is measured in terms of integer values in client acceptance.

Dwage = Askill + Amodel + Asoftware Dwage = (Askill + Amodel + Asoftware) * 100 Where, Askill = average of technical skills Amodel = average of process model proficiencies Asoftware = average of software type proficiencies Every time a game turn ends, the desired wage for each employee is recalculated based on the average of his skills. This value may change depending on the skills of the employee. The new calculated value would then be the employee’s new desired wage. If the employee’s current salary does not match with his desired wage, the employee’s morale decreases. Morale decrease (mdecrease) is the rate at which an employee’s morale decreases each turn.

Rreputation = Company’s Reputation with the client Amorale = Team’s average morale Rdiscretion = Rreputation /100 if Amorale ≥ 90, Rdiscretion = Rdiscretion + 5 else if Amorale ≥ 80, Rdiscretion = Rdiscretion + 4 else if Amorale ≥ 70, Rdiscretion = Rdiscretion + 3 else if Amorale ≥ 60, Rdiscretion = Rdiscretion + 2 else Rdiscretion = Rdiscretion + 1 Rdiscretion = Rdiscretion + (Random value 0 to 5) A random number was used to represent the client’s opinion.

if(employee is working on project) m = m – Tassigned if Dwage > Cwage m = m – 1 Where, Dwage = Desired Wage Cwage = current wage m = employee morale Tassigned = number of projects assigned to team The system decreases the morale of an employee by one every time the employee performs a task on each project. Additional morale calculation include that when the employee’s

desired wage is greater than his current wage, employee’s morale decreases by another point. Morale is measured in terms of integer values that represent an employee’s will to work. Morale is generated through the Employee Generator.

4.9

Skill

Skill (Sxp) gain. Each technical skill requires a certain amount of experience in order to increase. This amount increases the higher the technical skill’s value is. Experience is gained through performing tasks, performing exercises, or attending seminars/workshops. Employee Skill is measured in terms of integer values that represent an employee’s level of skill. Sxp = t + 0.2 if performing exercise Sxp = t + 1.2 if attending seminar/workshop Where, t = employee technical skill

4.10 Proficiency Proficiency (Pxp) gain. Proficiencies (both process model and software type) require the employee to finish a project. Proficiency is measured in terms of integer values that represent an employee’s level of skill in terms of the process models and software types. Pxp = P + 1 Where, P = proficiency x = proficiency being increased

4.11 Bidding Score Bidding score (B) measures how favorable a bid is. This is used to determine which bid is better. Each project prefers some types of support to others, which is decided by the project’s inherent weight of that support. Bidding score is measured in terms of bidding value that is used to calculate for the winner of the project bid.

the support requirements of the project. If the required support was met, the weight of each support will be summed up and this will further be added to the value of the player’s bid subtracted from the project’s price for the Bid value of the project.

4.12 Rival Company Bid Each rival company puts more weight on outbidding either by smaller budget or closer deadline by varying degrees. Rival Company’s Bid = (Rsupport + Dsupport1 + Csupport + Tsupport + Dsupport2) – (Mprice – Bprice) Where, Mprice = coefficient for project max price Bprice = coefficient for budget Rsupport = coefficient for requirements support Tsupport = coefficient for testing support Dsupport1 = coefficient for design support Dsupport2 = coefficient for documentation support Csupport = coefficient for coding support The Rival Company’s bid is decided by two components: project support and budget. This is performed in the method checkBid() in the Project class. The rival company checks if the project’s support weights are nonzero, and bids for those project support types if able. The budget component is decided by a random value, which is calculated by the project’s maximum price divided by 4 as minimum and maximum price as maximum.

4.13 Total Spending Total Spending (S) is the amount of money the company spends in a turn. It is composed of the wages of all employees and an upkeep which is based off the office level (how many times office space has been expanded). Total Spending is measured in terms of the amount of money that the company spends per turn. n

S = (

∑W i= 0 n

B = (Prequirements + Pdesign + Pimplementation + Ptestingl + Pdocumentation) + (Pprice – Pproposed)

Where, Wn = Wage of employee n Olevel = office level

Where, Pproposed = proposed project price Pprice = actual project price Prequirements = project requirements support weight Pdesign = project design support weight Pimplementation = project implementation support weight Ptestingl = project testing support weight Pdocumentation = project documentation support weight Depending on the values generated upon the creation of the project, the project will require support for the different phases of the project. The player will have to choose a team that will meet

+ Olevel (100)

After every end of turn, the system will subtract the summed up wage of all the player’s employees and the daily required upkeep from the capital. Capital will also decrease upon spending money for tools, projects, and accreditations.

V.

DISCUSSION AND CONCLUSION

The system was evaluated by Computer Science Students with backgrounds in software engineering. The developers created a series of questions based on the criteria of simulation games stated above. The evaluators were asked to rate the system from 1 to 5 for each criteria, 1 being the lowest score and 5 being the highest. Table 4. Table of Evaluation Scores 1 2 3 4 5 Realism 10% 0% 20% 30% 40%

Fulfillment 0% 0% 30% 30% 40% Cognitive 0% 0% 60% 25% 15% Interactivity 0% 0% 15% 60% 25% Linear 0% 15% 35% 35% 15% Systems 0% 0% 20% 30% 50% Cyclical 0% 10% 35% 35% 20% Simulation 0% 5% 25% 60% 10% Game 0% 10% 30% 55% 5% Pedagogy 0% 16% 11% 57% 16% Software Tycoon was proven to be engaging and interesting, while still being able to incorporate and simulate aspects of software engineering. The game was able to provide a convincing role of project manager to the player. As a simulation game, there was sufficient freedom given to the player in making decisions on how to run the company and carry out projects. While Software Tycoon based from the evaluation of the students, is engaging and interesting, the game is just a one player game. It does not maximize social dynamics by allowing other players to join the game. The user interface of the system tends to be cumbersome due to the many features of the game. A newer version, Software Tycoon 2 should be able to handle this limitation as it will be a web-based game.

VI.

ACKNOWLEDGMENTS

The developers of Software Tycoon thank the DLSU-CCS faculty and students for extending their support to this project.

VII.

REFERENCES 1.

2.

3.

4.

Abel-Hamid, T., Madnick, S.E. (1991). Software project dynamics. Englwood Cliffs, NJ: Prentice Hall Boehm, B.W. (1989). Tutorial on software risk management. IEEE, Computer Society Press, Los Alamitos, CA. Drappa, A., Ludewig, J. (2000). Simulation in software engineering training. International Conference on Software Engineering, Vol 22, pages 199-208. Electronic Arts. Theme Hospital. 1997.

5.

Fong, G. (2004) Adapting COTS games for military simulation. Proceedings of the 2004 ACM SIGGRAPH international conference on Virtual Reality continuum and its applications in industry, 269-272. 2004.

6.

Microsoft Game Studios. Mall Tycoon. 2001.

7.

Microsoft Game Studios. Railroad Tycoon. 1990.

8.

Navarro, E. and O. van der Hoek (2004). A. SimSE: An interactive simulation game for software engineering education. 2004.