The purpose of this simulation is to learn through experimentation about a few of the elements in a system development process. Although the simulation has a game like appearance, and you may be competing against others, there is no single "winning" strategy. There are many ways to achieve good (and bad) results. Instead of attempting to "win" with a narrowly focused strategy, you should be focusing upon how the entire system reacts to the many decisions you make.

Task

Your task is to develop an integrated hardware and software system, integrate and test it, and then release it to a market. An example might be a scanning system that has a hardware element - a scanner, and a software element - an ability to modify the image on a CRT once it is scanned. You would begin by building the scanning hardware, proceed to build software as a value added feature, and then do testing of the two components to ascertain that they work together properly.

Resource Balancing

You must control the limited resources available to you. You have a limited amount of time to properly develop the components of your product, and then to integrate and test them. Time pressures may force you to drop some of the planned functionality for your product. Driving your staff too hard may cause them to burn out, and cause your product to be completed even later than you had hoped. As in any product development, there is a trade off between planning and development. Insufficient planning will result in gross inefficiencies later. Too much planning will waste time when resources could be devoted to building the product.

The Market

Your product will compete in the market with other similar products. As in any real market, there is pressure to finish your product ahead of the competition. The attractiveness of your product will be measured against the attractiveness of other similar products on the market, both in features and quality. You will also be subject to demand ceilings.

The entire simulation takes place over a 130 week (2.5 year) period. There are 100 (each) initial hardware, software, and integration tasks to be completed.

Instructions for Basic Operation

1. After starting the ithink runtime engine, click on File, Close Model.

2. Then click on File, Open, and specify the directory where you have stored SysDev.itm. You will see a screen titled Reengineering Decision Rules in a System Development Context.

3. Read the text and click on  to advance to the control panel.

4. While at the control panel click from the menu at the top of the screen click on:

a) Run (NOT the green RUN Button*)

b) Time Specs

c) In the panel appearing, change the Pause Interval box from INF to 8. This means the simulation will stop every 8 weeks to let you check the charts and change the slider bars if you desire. You can also click the PAUSE button at any time to pause the simulation.

d) Click on the OK button

5. Click on the small ? to get information on what the slider bars control, and click on the big ? to get some general guidance about the simulation.

6. After you have pondered a strategy for proceeding (or discussed it with your group) begin the simulation by clicking on the green RUN button.

7. When messages appear, read them and then click on the X on the top right to remove them.

8. Initially you should be clicking on the DETAILS button to monitor your progress. You can monitor what percentage of your overall tasks have been completed by clicking on the SYS DEV PROGRESS button.

* If you accidentally press the green RUN button you must click on Map, Restore, All Devices, to set the system back to it's initial state.

Fraction of Hardware Functionality to Drop - Setting this slider lets you drop functionality from the hardware development plan thus reducing the amount of work to do. Setting the fraction to .5 means that half of the remaining functionality (and therefore half the work) will be dropped immediately.

Fraction of Hardware Functionality to Drop - Setting this slider lets you drop functionality from the hardware development plan thus reducing the amount of work to do. Setting the fraction to .5 means that half of the remaining functionality (and therefore half the work) will be dropped immediately.

Hardware Work Hours per week - This is the average number of hours per week that people on the team are working.

Fraction of Software Functionality to Drop - Setting this slider lets you drop functionality from the hardware development plan thus reducing the amount of work to do. Setting the fraction to .5 means that half of the remaining functionality (and therefore half the work) will be dropped immediately.

Fraction of Software Time Planning - This is the fraction of the software development effort that you wish to allocate to planning. Time not allocated to planning goes to implementation. Planning comprises overall project planning, coordination with other groups, and planning individual tasks.

Software Work Hours per week - This is the average number of hours per week that people on the team are working.

Release - Button to release your product. You can't release until you are at least half way through integration and testing.