英文論文

Lam etc. [2] proffered a technique to enhance existing trading card game. It used visual device support place’s prototype to increase card game’s reality. According to players’ input command, the system identified it and output response. The game can retain the original playing rules and style. In 2005, Katayose H. and Imanishi K. [3]

developed a trading card game based on ART. Learners can gain experience with the device on their arms.

For educational card game, Alex Baker [4, 5, 6] designed a card game which can help learners gain some experience about software process in class. Learners who studied this course are lacked effective experience in the past. In addition, Carrington, D. [7] devised a physical card game “Problems and Programmers (PnP)” which is a competitive card game in 2002. The game’s rules and methods are based on Waterfall model. Let learners find out about the procedure of Waterfall through the game. The trouble and tool in game can make learners study several different ameliorative methods. Learners gain practical experience from the competitive and interesting game.

Except software engineering, Chandra, N. etc. [8] designed a financial trading market simulating card game in 2002. Learners can use it to simulate trading environment. One player serves as the marketing and sales director role, uses different market tactics, marketing and stock option, regards obtaining the largest profit as the goal.

Another player acts as the businessman in the market, buys products and sells it according to the market manager's market tactics. This game simulates marketing and sales director and businessmen's tactics that aim at market environment and strategy. Another subject is about object-oriented thinking learning, Kim S. B. etc. [9] designed Smalltalk Card Game (SCG) in 2006. Students can experience and understand Object Oriented concepts by expending basic rules of game.

3. Rapid Application Development (RAD)

Rapid Application Development (RAD) [10] is a rapid method to develop systems. With the fast change of commerce and the high performance computer tools appearance, more and more people doubt if it is necessary to build a system in such a long time. For this reason, RAD came out for developing a system in short time. RAD is invented by James Martin, who wrote, “Rapid Application Development (RAD) is a development lifecycle designed to give much faster development and higher-quality results than those achieved with the traditional lifecycle. It is designed to take the maximum advantage of powerful development software that has evolved recently.” in his book.

(See Fig. 1)

In order to focus on the requirements of user interface and system functionalities, RAD sacred systems analysis and systems performance to decrease the time of planning and designing phrase. Most time RAD put more emphasizes on prototyping, it is also possible draw back from designing phase to planning phrase. Generally speaking, the situations are not too bad to fall back previous phrase. The users’ high participance makes the system performance better than the traditional method’s system.

In RAD, there are four main aspects, tools, people, methodology and management. Each one of these is necessary if any one of these ingredients is insufficient, the development speed will not be high. Development lifecycle merged all the components together as effectively as possible. In short, RAD needs proper working methodologies, well trained employees and simplified management with efficiency.

Requirements planning involve planning and analysis. In this stage, high level managers and knowledgeable workers decide the system requirement. However these decisions are made based on commerce environment and problems. After the system is planed, the users and system analyzers will do the requirement analysis to meet the goal. Such kind of developing stage is similar to the traditional method.

In users designing stage, users and system experts will join the meeting together. They applied some tools to assist system prototype planning in high speed. These prototypes will convert to the physical basis in future development. Using the computer tools to plan will shorten developing time.

In construction stage, professional designing workers generate the program codes with some tools, users are also involved at the same time. In some small system, construction phase and user design phase can integrate together.

Cutover stage, also known as the Deployment Stage, this stage involves final user testing and training, data conversion, and the implementation of the application system.

Fig. 1. Rapid Application Development Model

Fig. 2. (a) Project Card Fig. 3. (b). Requirement Card Fig. 4. (c). Plan Card

Fig. 5. (d). Event Card Fig. 6. (e). Approach Card Fig. 7. (f). Employee Card

Fig.3. Plan Stage Fig. 4. User Design Stage (step 1)

Fig. 5. User Design Stage (step 2) Fig. 6. Construction Stage (step 1)

Fig. 7. Construction Stage (step 2) Fig. 8. Construction Stage (step 3)

Fig. 9. Cutover stage Fig. 10. After Cutover Stage

4. RAD Card Game

Our research is to design a card game with RAD as the learning object. With the simple game rules, learners can gain some practical experience in RAD progress. Learners can experience RAD developing progress, tools, methodologies and the possible problems. When learners involve in the game, they will meet the problems, then try to solve them. They even need to modify the methods by themselves.

The game is played by round, each round is separated the following steps.

(1) Decide if the learner will move forward to next stage.

(2) Draw one card.

(3) Play the card depends on the stage the learner involved.

(4) Discard the redundant card.

After all the learners do through the steps, then jump to next round.

According to RAD four aspects, the stage sequence is requirements planning, user designing, construction and implementation. Each player has five cards, no mater how many cards are discarded in one round. Player can draw the cards until each one has five cards. If there are no more cards, then shuffle the cards which are discarded as the prepared cards. In order to reach the equally of the game, each player has the same number and type cards, player who reach the goal win this game.

There are seven kinds of cards; they are project card, plan card, code card, employee card, requirement card and event card.

Project card recorded the system quality, the system budget and the required employee number. Project card is the goal of each player. Player has to consider the budget, employee and system quality. (See Fig. 2 (a))

Plan card is divided into simple plan, normal plan and complete plan. Plan card can be placed five cards on the table at most. The plan card quantity decided how much resource can use. (See Fig. 2 (b))

Requirement card is similar to mission card which presented the mission conditions. Requirement card represent user’s requirement in system development. Player has to reach the requirement to enter next stage. (See Fig. 2 (c))

Employee card describes employees’ information, such as name, ability, skill, personality and salary. Player can replace any employee card if he/she has another better card. At last , employee card is useless for the first round till next round. (See Fig. 2 (d))

Event card has all kinds of events. Some events has to meet some conditions then it will be launched else it is in vain. However if the competitor has enough preparation, then the event cards are useless. (See Fig. 2 (e))

Approach card has opposite function to event card. Approach card helps player with high progress. Method has its active condition, like event cards. (See Fig. 2 (f))

In the beginning, player draws a card from project cards. With the objective, the player who completed all the four stages won the game.

Planning is the basic stage, player draws five cards first. (See Fig. 3) Then player draw a card from plan cards then play a plan card on the table. Plan card level will effect the situation that player will meet. If player got another plan card which is better than the previous card on the table, it can be replaced by another high level plan card. Plan card is the only kind card which can be place in planning stage, the other kinds of cards are not allowed.

After planning stage, then the requirement stage comes. (See Fig. 4, 5 and 6) Make sure each player has five cards on the hand. Then player draw a card from requirement cards then evaluate if the requirement card is reasonable and reachable. If yes, then play the requirement card on the table, else discard the card and finish this round until next round. The same procedure repeats with the rule. Project card recorded the user quantity limitation;

if the user quantity is four then the player has to complete four requirement cards.

Entering construction stage, player follows the requirements of the card to place the employee cards which are allowed to place on the plan cards. (See Fig. 6, 7 and 8) The first round to put the employee card can not work till next round. If the plan card is covered enough employee cards, player can replace other better employee card. And it also follows the rule which means the replace employee card is useless in the first round. All the employee cards can perform four kinds of jobs that are normal construction, rapid construction, check errors and debug. The work efficiency of the employee is depends on the skill. According as the requirement card complexity divided by employee’s skill equals the progress which the employee can do in this round. Meanwhile, player can use approach cards to progress the employee work in high speed or apply the event cards to disturb other players’ progress. When player has filled all the requirements, he/she can back to previous stage to receive another requirement.

Cutover stage is the final stage which player with requirement card’s requirement puts all the code cards on one of the employee cards. (See Fig. 9) Employee cards and approach cards can do the same job but it can’t be replaced in this stage. On the other hand, other players can’t use event cards to affect other players. When player thinks he/she is ready, then it is final stage (See Fig. 10).

In transfer stage, player shuffles the code cards first then draw and turned the same number code cards which the requirement card requested. If there is no bug then the player won the game. If there is serious bug, player has to back the first stage. If it is normal bug, player back to requirement stage then repeat requirement and construction. If there is simple bug, player back to cutover stage and debug until it is finished. The first player completed the transfer stage won the game.

Table 1. . Comparison of [Problems and Programmers] and [System Design]

Problems and Programmers System Design

Background and Designing Model

Software Engineering -Waterfall Model

System analysis and deign -Prototype Model

Player Number 2 or more players 2 or more(Physical) 1(Computer game)

Proceed Type Round Task and Round

Card Category 5 kinds 6 kinds

Game Stages 5 stages 5 stages

Cards in hand 5 cards 5 cards

Conditions of Winning

According to program code to reach the requirements then win the game.

According to task requirement and user requirement to reach the requirements then win the game.

Game Objective Learning waterfall model from this game and players can imitate other players’ tactic.

Learning prototype model from this game and players can imitate other players’ tactic. The player had to realize the users’ requirements then he/she can handle it.

5. Discussion

We found another famous card game [Problems and Programmers] which is also target on software engineering.

We did some comparisons in Table 1. The two games have different teach models as the learning objective. Also our RAD card game will develop to a computer based game. With the comparison, we can develop better card game in the near future.

6. Conclusion

RAD is a card game which can assist learners gain practical experience according different stages from planning stage to cutover stage. Learners fulfill individual’s requirement to complete their mission. Learners must study system analysis and design course as prerequisite. The flexible RAD card game assists students in studying different methods while encountering different problems.

Acknowledgements

We would like to thank National Science Council and Chung Hua University. This research was supported in part by a grant from NSC 96-2520-S-216-001 and CHU 96-2520-S-216-001, Taiwan, Republic of China. This paper owes much to the thoughtful and helpful comments of the reviewers.

References

1. Diaz, M., Alencastre-Miranda, M., Munoz-Gomez, L., Rudomin, I.: Multi-User Networked Interactive Augmented Reality Card Game. pp. 172 –182. International Conference on Cyberworlds, CW '06. (2006)

2. Albert H. T. Lam, Kevin C. H. Chow, Edward H. H. Yau, Michael R. Lyu.: ART: Augmented Reality Table for Interactive Trading Card Game. pp.357—360. VRCIA 2006, Hong Kong (2006)

3. Katayose H., Imanishi K.: ARMS: A Trading Card Game using AR Technology. pp. 354—355. ACE 2005(2005)

4. Baker, A., Navarro, E.O., van der Hoek, A.: An experimental card game for teaching software engineering. Pp. 216—223. Proceedings of 16th Conference on Software Engineering Education and Training (2003)

5. Baker, A., Navarro, E.O., van der Hoek, A.: Problems and Programmers: an educational software engineering card game. pp. 614—619. 25th International Conference on Software Engineering (2003) 6. Baker, Alex, Navarro, Emily Oh, Van Der Hoek, Andre.: An experimental card game for teaching

software engineering processes. Journal of Systems and Software. 75, 3-16 (2005)

7. Carrington, D., Baker, A.,; van der Hoek, A.: It’s All in the Game: Teaching Software Process

'05 (2005)

8. Chandra, N., Herman, B., Yohan Kim, Lau, A., Murad, R., Pascarella, W., Wu, K., Preston White, K.:

A Financial Services Gaming Simulation. pp. 152—155. 2006 IEEE Systems and Information Engineering Design Symposium (2006)

9. Kim S.B., Choi S.K., Jang H.S., Kwon D.Y., Yeum Y.C., Lee W.G.: Smalltalk Card Game for Learning Object-Oriented Thinking in an Evolutionary Way. pp. 683—684. OOPSLA’ 06, Portland, Oregon, USA (2006)

10. Martin J.: Rapid Application Development. Oxford, Maxwell Macmillian International (1991)

11. Callahan, D., B. Pedigo, Educating Experienced IT Professionals by Addressing Industry’s Needs. pp.

57—62. IEEE Software (2002)

12. Conn, R.: Developing Software Engineers at the C-130J Software Factory. pp.25—29. IEEE Software (2002).

13. Kaur, D., Haar, J.: Fuzzy logic based Euchre game design on palm PDA. pp. 693—699. Fuzzy Information Processing Society, NAFIPS 2005. Annual Meeting of the North American (2005) 14. McMillan, W.W. and S. Rajaprabhakaran: What Leading Practitioners Say Should Be Emphasized in

Students Software Engineering Projects. pp. 177—185. Proceedings of the Twelfth Conference on Software Engineering Education and Training, IEEE Computer Society (1999)

15. Wohlin, C., B. Regnell: Achieving Industrial Relevance in Software Engineering Education. pp.

16—25. Proceedings of the Twelfth Conference on Software Engineering Education and Training, IEEE Computer Society (1999)