First-Person Shooter Game
By: Group 3
Adam Lerman
Clement Madya
James Mallon
Timothy Schultz
Drexel University, Philadelphia, PA.
INFO638: Software Project Management.
Assignment 4. December 06, 2010. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 2
Table of Contents 1. Introduction ...... 3 2. Project Analysis and Scope ...... 3 3. Project Overview Statement (POS) ...... 4 4. Requirements Breakdown Structure (RBS) ...... 5 5. High-Level WBS ...... 8 6. Scope Triangle and Prioritization ...... 9 7. Project Features Prioritization ...... 11 8. Mid-/Low-Level WBS and Timeline ...... 12 9. Financial Analysis...... 16 10. Project Status Reporting ...... 18 11. Project Risk Analysis ...... 19
Risk Severity ...... 21
Risk Contingency Planning ...... 22
Discussion ...... 24 12. Project Change Control Processes ...... 25 13. Future Version Scope ...... 29 14. Conclusion ...... 29
References ...... 30
Appendix A ...... 31
Appendix B ...... 33 Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 3
1. Introduction
The goal of this report is to define an Adaptive Project Framework (APF) project plan for developing a video game. We will demonstrate the initial part of the lifecycle, leaving out details of future project development and implementation cycles since these are meant to be covered in depth as the project progresses. Instead, we will outline the entire plan and allow room for additions as the plan gets underway, only focusing in depth on the present tasks. We start with the scope of the project followed by the Project Overview Statement and Requirements Breakdown Structure to provide an analysis of what the project will entail. We then delve further into the project by prioritizing the features and discussing the Work Breakdown Structures and timelines which will detail how to actually complete the project. A short financial analysis will help ensure that the project has the means to be implemented, and risks and change controls will be outlined to help make sure that the project does not go off task and has a means to recover if it does. 2. Project Analysis and Scope
This project is based around a new computer video game to be created by DeathBlow Gamers, a startup video game development company. This is the company’s first project and they are very ambitious and anxious to break into the market. Their vision is to become a recognized leader in gaming and to create enough capital to develop more games. In order to do so, a goal the company has set for itself is to develop a first-person shooter video game that wins at least one prestigious industry award and comes in the top ten in sales for the year.
In order to create the game, the development and project management teams along with a customer focus group brainstormed about what type of game they and their target audience would be most interested in, while attempting to create something new and innovative. Based on the popularity of zombie movies as well as first-person shooter games, the teams decided to merge the two and create a first-person shooter game whose plot is to save the main character from a zombie apocalypse. Since the users wanted a familiar locale, the environment is set in the city of Philadelphia, Pennsylvania, which is a popular city in the United States housing much of the nation’s history. It was deemed to be fitting for this story line since much of the nation’s history started there and the character must keep it from ending there as well. The goal is to get from the center of town to a safe-haven on the outskirts, which the user must determine using reasoning, logic, intuition, and in-game clues. Along the way, he will be challenged by invading armies of zombies in which he must defend himself and other characters he meets along the way. The game is intended to not only be fun and entertaining, but to provide the gamer with decision- making, reasoning, problem solving, and survival skills, as well as game theory and hand-eye coordination without the user being conscious of this. The target audience is intended to be a mature audience, most likely teenage males over the age of 13 and young adults.
The game created by DeathBlow Gamers will be boxed, packaged, shrink wrapped, and sold through local and online retailers. These may include websites such as Buy.com, big box stores such as Best Buy, and gaming stores including Game Stop, for example. The user will then be Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 4
able to download expansion packs once the original version is purchased. The scope of the development of the game will be broken down into cycles, each one providing further and more detailed implementations as will be discussed below. The first version will start by creating and implementing the basic foundations of the game, such as characters, the game environment, basic weapons and means of transportation, and will become increasingly more complex. Initially, the game and its prototypes will be single player only, and will then implement multiplayer and, finally, online multiplayer additions in future versions. The initial version will be developed for the PC but future versions will be developed for gaming stations such as the Xbox 360 and the Sony Playstation. Again, this will be discussed in further detail below. 3. Project Overview Statement (POS) The purpose of this section is to provide the stakeholders of the project with a summary that will briefly state what the project will entail, why it will be conducted in this manner, and what value it will hold for the company when it is complete. This may, in turn, be used to gain approval from senior management and to attain the required resources to carry out the project. Once approved, the POS may serve as the base from which future planning and project execution may take place, acting as a reference with regards to the project’s scope and purpose (Wysocki, 2009).
PROJECT OVERVIEW Project Name Project No. Project STATEMENT First-Person Shooter FPS-001 Manager Game Susan Gasson
Problem / Opportunity DeathBlow Gamers, a startup video game development company, would like to create their first game: a first-person shooter video game that wins at least one prestigious industry award and comes in the top ten in sales.
Goal Break into the industry and become a recognized leader in gaming. Create enough capital to develop more games.
Objectives • Create an award-winning video game with a save-the-world-from-evil-and-destruction theme: provide a realistic and comprehensive backdrop for the story to emerge. • Game objectives will be to survive a zombie apocalypse by killing bad guys and navigating from the character’s home in the center of Philadelphia to a safe-haven on the outskirts of town. • Enhance the customer’s decision making, reasoning, problem solving, game theory, and survival skills, as well as hand eye coordination and quick-thinking. • Target the teenage male/mature audience population. • Provide functionality for multiple operating systems and an infinite number of players.
• Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 5
Success Criteria • The game is understood and able to be navigated without consulting an instruction manual for 90% of customers. • The player is able to control the character in the manner in which he desires. • The player is capable of progressing through the game from the beginning to end. • The game provides the appropriate challenge levels for all players. • The game is entertaining to 90% of customers based on a rating of a minimum of 3.5 out of 5 stars • The game will sell over 8300 units per month after version 1 release. This will allow the business to grow and move towards version 2.* • Limit expenditures to under $100,000 per month during version 1 development to remain viable.*
*See Financial Analysis section for more details.
Assumptions, Risks, Obstacles • The game must be compelling enough for the players to want to complete a session. • Players span multiple age ranges and all must be able to play with little to no instruction. • Being the company’s first game, enough interest and capital must be earned to keep the business in existence
Prepared by Date Approved by Date Group 3 December 06, 2010
4. Requirements Breakdown Structure (RBS) The requirements breakdown structure is meant to provide a hierarchical description of what the video game needs to include in order to successfully meet the customer’s needs. It will help to determine a baseline set of requirements and it reflects what is currently known about the product. Therefore, it is as complete as possible, but may need to be revisited in future cycles as new knowledge is obtained. The RBS is written at the user level from the game player’s perspective, allowing the development team to interpret the desired features during coding and implementation. The RBS contains the vision of the company and the goal which is anticipated to fulfill that vision, as well as the feature sets that deliver a portion of the required outcomes. The feature sets are then broken down into features which depict the operations that the user can perform with the system, and these are then broken down into low-level features which describe the who, what, & why for each feature from the user’s perspective. Figures 1a and 1b depict the RBS in graphical format as a hierarchy of features, and Appendix A provides the same requirements in outline form. The figures were broken out into two images to provide enough room to thoroughly examine each feature set, with figure 1a providing feature sets one through three and figure 1b demonstrating feature sets four through six.
Figure 1a. RBS including Feature Sets 1-3
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 7
Figure 1b. RBS including Feature Sets 4-6 In order to develop the RBS, a user analysis was first performed by conducting research about the market and forming a focus group of individuals in the potential range of target customers. Based on discussions with these users, a core set of features was created to meet their wants and needs. It was determined that they would like a solid storyline based on popular zombie lore and would like it to unfold as a movie would. Therefore, they would like an introductory “trailer” leading up to the point of the story in which the player comes in, and would like to figure out the plot of the game on their own through personal observation and exploration. The user would like to do this by examining a realistic city with accurate roads, buildings, landscapes, and landmarks, and would like to choose the character with whom they play. As will be discussed later, users Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 8
can start with a male or female character and can customize him or her as they desire, and will then use the character to navigate through the game by running and jumping through city streets and buildings and fighting oncoming zombies. Players can interact with other in-game and human-controlled characters and can team up to complete the story together if they so desire. The game provides weapons and other items that can be obtained, as well as vehicles to be confiscated. Additional clues will be provided as the player interacts with different characters and areas of the city map, and users can pull up a list of clues at any time. As will be discussed in later sections of this report, these features will be implemented in an iterative fashion, starting with the most important and critical pieces first and adding the more detailed portions in later cycles and versions. 5. High-Level WBS The high-level WBS (see figure 2) depicts, at a glance, the overall high-level features that will need to be implemented to successfully complete the project. It only shows the first version of the product, but future versions will be discussed later in this report.
Figure 2. High-level WBS In the first cycle of the project, the basic game characters and environment will be created since these are the foundation of the game. Rough sketches will be implemented as opposed to detailed features so that the project team can receive feedback from the customers as to how they should be further developed and customized to meet their tastes. Only a basic male and female player character, three zombie characters, and a few main roads and buildings/landmarks will be provided for review, as well as basic character movements. In addition, a grid layout of the map will be proposed. In Cycle 2 the basic set of weapons will be created including a bat, knife, and handgun, and basic ammunition will be developed for the gun. The shooting perspective of the player character will also be created since this will be needed for the rest of the game. Developing these first will help provide ample opportunity for customers to help design the proper character view that suits them and a full list of weapons they would like to utilize. Next, in Cycle 3, a basic low-level vehicle and its movements and navigation will be developed so that additional vehicles may be based upon them and the movement mechanics can be tweaked. Cycle 4 will provide character details and supplementary weapons based on user feedback, in addition to their placement on the map and the look and feel of the weapon inventory which users can access to choose their current weapon. The next cycle, Cycle 5, will help develop the storyline and sub-plots of the game now that the main tangible portions have been created. Since the storyline may be further changed, developed, or narrowed as necessary and is not quite a crucial element, it was saved for one of the middle cycles, still offering enough time to further assess it but allowing for the foundational aspects to be created first. Cycle 6 will then provide supplemental portions of the game such as clues and dialogs, and users can present their feedback in enough time before the first version is complete. Finally, to tie everything together and complete version 1 of the game, Cycle 7 will create the install package, retail package, and support structure. Until this is complete, further feedback and changes may be accepted, provided they have been reviewed by the change management board as is discussed below. 6. Scope Triangle and Prioritization In order to meet the expectations of the customer and provide the best quality product with the correct scope, it is necessary to prioritize and maintain the scope triangle (shown in Figure 3). This consists of the constraints on time (schedule), cost (budget), and resources available which will, ultimately, affect the scope and quality. On the other hand, if need be, the scope and/or quality may be limited to meet the demands of the triangle’s constraints instead. Based on the market and conversations with potential customers, as well as decisions made by DeathBlow Gamers’ upper management, development, and project management teams, the scope triangle has been prioritized as depicted in Table 1 below. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 10
Figure 3. Scope Triangle Wysocki, 2009
Quality was deemed to be the most important factor of the game since, without it, the game will not be bought and its creation will be undermined. However, since the company is small, the human resources available to create the game will be limited and must be maintained. There will not be much room to hire additional individuals and the team must generally make do with those who have already been hired to work on the project. The scope of the game is important but can be flexible if need be, because the team has a strong vision for what it will entail but can change the story line without drastically affecting the game if it comes down to it. This would be one of the later changes made to the project, however, after cost and time. Time is the most flexible and most easily changed since it is not as important to release the game in a specific timeframe as there is no direct competition and the company is new. They, therefore, have the advantage of being flexible with their schedule if need be, although every effort will be made to release the game in a timely manner. Specific timeframes will be discussed later. Although cost is important as well, this is another area where the company can be flexible since they have a reasonable amount of startup capital from investors. Budget is important in any project and efforts will be made to keep costs down, but this can be one of the first aspects tweaked as necessary.
Priority Critical (2) (3) (4) Flexible Variable (1) (5)
Scope X Quality X
Time X Cost X Resource Availability X Table 1. Scope triangle prioritization Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 11
7. Project Features Prioritization In order to prioritize the features determined necessary to be developed for the game, the project team and their customers both brainstormed and performed a bucket approach to ranking. The features were gathered together and an attempt was made to organize them in order of importance. Factors such as how much of a role each feature plays in the foundation of the game and user preferences were considered. The prioritized features were then used to populate the cycle plan and mid-/low-level WBS, placing the most important ones in early cycles and holding off less crucial ones for future cycles and versions. The following list contains the set of prioritized features, with 1 being the most important and 35 being the least:
1. As a player, choose a male or female character 2. As a player, navigate the roads and landscape 3. As a player, encounter various types of zombies 4. As a player, use character to fight zombies with fists and feet 5. As a player, discover identifiable landmarks 6. As a player, use character to walk or run down streets and thru buildings 7. As a player, jump 8. As a player, navigate buildings and structures 9. As a player, pick up a weapon or ammunition 10. As a player, use character to attack zombies with various weapons 11. As a player, aim and fire weapon 12. As a player, determine a way to gain entry into vehicle 13. As a player, survey surroundings 14. As a player, use character to fend off various attacks from zombies 15. As a player, determine how to drive vehicle 16. As a player, assess the situation 17. As a player, find clues to determine role in the game 18. As a player, use character to manipulate objects in game 19. As a player, use character to pick up and drop items 20. As a player, choose to speak to other human characters 21. As a player, choose to lure zombies by yelling 22. As a player, choose to team up with another human to fight the zombies 23. As a player, choose to kill another human character 24. As a player, discard a weapon or ammunition 25. As a player, scroll thru weapon inventory 26. As a player, select a weapon from inventory 27. As a player, reload weapon from inventory 28. As a player, discard the vehicle 29. As a player, repair damaged vehicle 30. As a player, view text based “tips” 31. As a player, view map area markers 32. As a player, discover in-game “supplemental” clues 33. As a player, converse with in-game characters to progress the story Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 12
34. As a player, choose to customize character 35. As a player, watch introductory trailer
8. Mid-/Low-Level WBS and Timeline As was mentioned above, the mid-/low-level WBS was created based on the set of prioritized features as well as the high-level WBS. The intent was to break down the high-level feature sets into mid-/low-level lists of features and tasks that can be considered the release plan as based on the development schedule. They will then be broken down further during each individual cycle so that there is room for change, and nothing is planned in too much detail in advance since change is inevitable and a crucial part of the APF approach. This report, therefore, will provide a low-level WBS only for the first cycle. Because of this, both the mid- and low-level WBS were combined for brevity’s sake. Figure 4 demonstrates the mid-/low-level WBS for the first-person shooter game in outline form for clarity. Please note the difference in the number of levels between Cycle 1 and the rest of the WBS.
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 13
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 14
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 15
Figure 4. Mid-/low-level WBS
As discussed in section 5 above, each cycle will provide additional features and functionality. Before the development can begin, however, the project was scoped by first conducting market research and forming customer focus groups. This served to help determine the interest in the project and what direction DeathBlow Gamers should take when creating the video game. It was here that the idea for a first-person shooter zombie apocalypse game was born, and the strategy, plot, and target market of the game was detailed and confirmed. The initial requirements and overall scope were determined and the features were prioritized based on customer feedback and interaction. In addition, the number and length of cycles was established, and the mid-level WBS was created to provide the tentative path to follow to begin the development process.
The first cycle, Cycle 1, was then further broken down into low-level tasks so that the development team could begin working, but still at a high enough level where they could interpret the features and requirements and not be constrained. Later cycles will be broken down into low-level tasks as well, but not until they are ready to begin the development process. This is because, with constant feedback from the customer, requirements and features may change. Therefore, room is left for these adjustments so that the project is not restricted and time is not wasted planning aspects that will never come to fruition.
Once the cycles have been completed based on customer feedback and interaction, a post-version review will then be conducted. The intent is to evaluate the overall assessment, creation, and development processes and to compare them to initial intentions, goals, and objectives. A post- mortem review of the project will be done as well as the processes and lessons learned. The scope bank will also be reviewed to help plan for future versions. Questions such as “How successful were we?”, “How close did we meet our budget, scope, and time expectations?”, “Was the customer satisfied?”, “What lessons did we learn?”, Etc. will be answered during this time.
Please see Appendix B for a detailed visual depiction of the timescales for all of version 1 and a complete breakdown of the task sequence as well as the individuals needed to complete them for cycle 1. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 16
9. Financial Analysis DeathBlow Gamers was able to secure $1,500,000 in start-up funds for this project. The cash came from a combination of private investments from the principal owners and investments from angel investors. The short term goals of the company are to keep the burn rate under $100,000 per month, to sell 100,000 copies of the games at a price point of $49 (95% in the year following the release of version 1), and to take the company public with an initial public offering (IPO) within the first 5 years. The leftover cash from release one and the monies secured from sales will drive version 2 of the software title. If cash gets tight, another round of venture funding will be necessary. During the first year the principal owners will not take a salary. To keep labor costs down, full-time employees will be offered future shares of the company once it goes public. The company will also benefit from the start-up gaming culture which requires employees to work long hours without the need to provide additional compensation. Motivation to work long hours will be driven by an opportunity to strike it big if the company produces high quality software that sells extremely well within their target market and the company is able to have a successful IPO.
According to the VGChartz Network (2010), two first person shooter games, Call of Duty: Black Ops and Assassin’s Creed: Brotherhood are at the top of the worldwide top 10 software titles in sales for the week of November, 20, 2010, with each selling almost 2 million copies each. Since Call of Duty: Black Ops was released two weeks ago the title has sold over 10 million copies worldwide. One of the software titles we will be directly competing against is Doom. Doom 3 sold 3.5 million copies for the PC when it was released in late 2009. If DeathBlow Gamers can capture sales from 3% of the Doom 3 PC market, they will be able to reach their sales goals for version 1 of their software title. Since the title will be released in approximately 6 months, the potential to reach this metric is well above average since it will be well over a year since Doom 3 was released and the core audience will be looking for another first-person shooter zombie game for new experiences and new challenges. Once DeathBlow Gamers acquires a name for itself and is able to become self sustaining as a business entity, they can develop their software for game stations such as the Xbox 360 and the Sony Playstation as well as online offerings to establish a well-rounded cross-platform strategy. Below is a breakdown of the finances anticipated to be needed and earned for version 1 of the software:
Startup Cash: $1,500,000 Initial Startup Costs: $250,000 in down payments needed for rent, server hardware, server and software licenses. Cash will be needed for office furniture, office supplies, office PC’s, laptops, telecommunications equipment, wireless technologies, and miscellaneous costs. Burn Rate Per Month : $100,000
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 17
Monthly Breakdown of Costs ($100,000) : Salary: $50,000 Server Hardware: $15,000 Server Software Licenses: $15,000 Rent: $10,000 Overhead: $10,000 Cash remaining after version 1 development: $650,000 Sales Goals for Version 1: 100,000 copies sold in first year. Suggested List Price ofSoftware: $49.95 Total Monthly Sales Goals: 8300 sales at $49.95 each for a total of $414,585. Monthly expenditures are expected to rise to $150,000 per month in months 7-12 (Version 2) after the Version 1 release. The additional $50,000 per month in business costs will be needed to hire new employees, account for general overhead expenses, and the establishment of a well- rounded advertising program. An influx of at least $300,000 in software sales per month will be required to break even, assuming a 50% gross profit margin. This equals to approximately 6000 units sold per month. Sales below 6000 units per month will jeopardize the business model and will eventually require a new round of investment capital.
According to MSN Money (2010), Gross Margins for businesses who only produce gaming software are between 23% (THQ), 35% (Take Two Interactive), 50% (Activision Blizzard), and 58% (Electronic Arts) year to date. All of these companies were well established and had significant leverage before the financial meltdown. Since DeathBlow Gamers has a streamlined business model, we recommend a target of 50% for gross margins.
According to MSN Money (2010), Net Profit Margins year to date are between -11% (THQ), - 2% (Take Two Interactive), 8% (Activision Blizzard) and -4% (Electronic Arts). All of these companies were well established and had significant leverage before the financial meltdown. Since DeathBlow Gamers has a streamlined business model we recommend a target of 10% for net profits. Figure 5 depicts the monthly cash flow diagram for DeathBlow Gamers for months 1 to 12.
Figure 5. Monthly cash flow diagram for months 1 to 12 10. Project Status Reporting During the cycle builds we will have daily stand-up meetings in the conference room to provide brief issues updates. These meetings will be attended by the project manager and developers who have tasks/deliverables for that specific cycle. This will help keep focus on the current cycle and avoid overcrowding and distractions during the meetings. The meetings will be conducted at the beginning of each day and will last about 15 minutes. Project team members will use this status update as a forum to communicate any obstacles they face during the iterations and give the rest of the team an opportunity to help resolve the issues.
A daily status report will be posted on the whiteboard in the conference room and updated at least once per day by the project manager. The purpose of this status update report is to communicate project progress to the project team. This status report will contain technical issues, updates, and suggested enhancements. It will contain information and issues discussed during the daily stand-up meetings and will be updated as significant progress is made in resolving each issue.
At the end of each cycle we will present a status report prepared by the project manager for DeathBlow Gamers’ upper management. This report will be a brief report with a commentary section on the project status that we will use to highlight any major completions and outstanding components. The report will also include key cycle dates, deliverables and changes in the scope bank. A graphical representation of the functionality delivered per cycle against planned developer hours and actual developer hours will also be included. The variance between planned hours and actual hours can be used to more accurately predicate the planned hours per functionality for the next cycles. This estimate will fluctuate from cycle to cycle as this settles into a constant velocity. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 19
At the beginning of the cycle, the project manager will provide a detailed report to all members of the change management board concerning the high priority items to be discussed at the scope bank/issues log review. Once the board has made their decisions concerning the approval of the requirements, the project manager creates a status report for the customers and updates the scope bank and issues log. The project manager also creates a status report for the project team. High priority items that have been approved are highlighted and the appropriate team members are identified to begin modeling.
A Cycle Test Report will also be created by the Customer Focus Groups for the DeathBlow Gamers’ project manager at the end of each cycle. The test report will include an overview of the features and functionality implemented during that cycle. The test report will have a variance section where the Customer Focus Groups will record any variances of the features and functionality from those areas agreed upon between the development team and the customers. The customers will rank the severity of the variances, and give a brief analysis of the impact of any critical feature and functional variances. The report will have a section for an assessment of the actual test process, including the appropriateness of the test scripts and the comprehensiveness of the test scenarios. Any incomprehensive test scenarios will be documented with a brief explanation of the customers’ expectations against the test scripts. A summary of the test results will be presented for each feature highlighting all resolved and unresolved issues. The report will also include an overall summary of the cycle test process including any logistics issues encountered by the customer.
A longer report to the DeathBlow Gamers’ senior management team will be prepared by the project manager at the end of each version. This report will include summary sections for the post-mortem review, process review, change request review, scope bank review and cycle tests. The project manager will also include a customer satisfaction analysis of the product based on reviews from the Customer Focus Groups.
The end of version report will have a financial cost evaluation that includes the cumulative development costs for the team during the version. It will include a forecast for the cost of the next version based on the Actual Cost figures for the current version. 11. Project Risk Analysis
Problem Description
Game Play Risks
Map contains undetected “pitfalls” from Since the large, expansive map proposed in this game should which the character is unable to escape. provide a wide array of structures to explore, numerous instances of game spaces in which the player is unable to Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 20
maneuver his or her character may go undetected, forcing the player to restart the game from the last save point.
Game does not provide a way for all Given a wide range of freedom that a gamer can choose a possible “story paths” to converge to path throughout the game in a non-linear way, all storyline final ending. “paths” must converge on final ending.
Usable vehicles are found within areas Poor planning of vehicle placement within a map reduce their that do not provide suitable map areas importance in the game, and become burdensome features for utilizing them. when they encounter confined areas of game play - especially those created by debris.
Users experience a dearth of Poor planning of gear placement within a map provide weapons/ammunition to appropriately situations where players find a given task to become too fend off enemies in a certain area with difficult to complete. appropriate level of ease.
Damage produced from attack weapons Players may become frustrated when damage issued to game are not appropriate for the proposed set enemies are either too underpowered (too hard) or too of varied game enemies. overpowered (too easy).
Game play does not lend itself to have a The game is perceived by users to be too “linear” and not great deal of “replay value” worth another play-through once the game has been completed.
Computer Requirement Risks
Game requirements do not satisfy those A large, complex map with countless enemies and situations of the present-day average-powered failed to appropriately handle and free computer resources machines. such that the game can reach the widest audience as possible.
Supporting a nearly infinite number of Since each customer’s computer is most likely a “custom” custom computer configurations creates setup in the sense that different applications, libraries, unforeseen installation/game play issues. runtimes, and configurations are present on the system, it is difficult to be definitely certain that the game will behave as tested but to the high variation in environments.
Technical Risks
Saved game files become corrupted and Numerous conditions can occur which render saved-state files are no longer able to be used to retrieve (which contain information about a player’s current progress) a game save state. corrupted, causing frustration and wasted time with the player having to back-track from an older saved file.
Game files are easily accessible on the Giving the users access to tamper with game files opens the system, leaving them open to tampering, possibility for corrupting the game completely, resulting in corruption, or removal. broken installations. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 21
Licensing Risks
The game is easy to pirate due to lacking Mechanisms are not in place which allow users to freely copy licensing schemes. and distribute the game without paying for it.
Game licensing activation mechanism Licensing activation mechanisms for purchased software must does not work properly and thus renders properly authenticate legally-purchased software without any a legitimately purchased game issues; failure to do so will result in an unhappy customer. unplayable.
Game Rating Risks
Game rating review board provides the The appropriate amount of gore and violence is not game with a strict rating, making it implemented with properly such that the game is restricted to difficult for reaching out to the widest a limited older audience and receives scrutiny from parents. audience possible.
Risk Severity
Problem Probability Impact Overall
Game Play Risks
Map contains undetected “pitfalls” from which the character is unable 7 8 56 to escape.
Game does not provide a way for all possible “story paths” to converge 4 8 32 to final ending.
Usable vehicles are found within areas that do not provide suitable 6 6 36 map areas for utilizing them.
Users experience a dearth of weapons/ammunition to appropriately 5 7 35 fend off enemies in a certain area with appropriate level of ease.
Damage produced from attack weapons are not appropriate for the 6 5 30 proposed set of varied game enemies.
Game play does not lend itself to have a great deal of “replay value” 3 7 21
Computer Requirement Risks
Game requirements do not satisfy those of the present-day average- 3 6 18 powered machines.
Supporting a nearly infinite number of custom computer 7 6 42 configurations creates unforeseen installation/game play issues. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 22
Technical Risks
Saved game files become corrupted and are no longer able to be used 7 7 49 to retrieve a game save state.
Game files are easily accessible on the system, leaving them open to 3 4 12 tampering, corruption, or removal.
Licensing Risks
The game is easy to pirate due to lacking licensing schemes. 7 6 42
Game licensing activation mechanism does not work properly and thus 8 8 64 renders a legitimately purchased game unplayable.
Game Rating Risks
Game rating review board provides the game with a strict rating, 5 8 40 making it difficult for reaching out to the widest audience possible.
Risk Contingency Planning
Problem Sev. Contingency Plan Responsibility
Game licensing activation 64 Implement help desk support for handling Software mechanism (server-based) does not such incidents in a manual fashion until Engineer, work properly and thus renders a the issue can be resolved; in the Business legitimately purchased game meantime, the game should provide a 10- Analyst unplayable. day activation grace period so activation is not immediately needed to play the game.
Map contains undetected “pitfalls” 56 While extensive testing of the map with a Map from which the character is unable large contingency of testes should locate Developer to escape. most of these issues, an “unstuck” button should be implemented to transfer character to a very nearby area, effectively freeing the character from the obstacle.
Saved game files become corrupted 49 CRC checks should be computed to Software and are no longer able to be used to determine the integrity of save files on a Engineer, retrieve a game save state. regular basis within the game, taking Programmer incremental snapshots of game progress. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 23
Supporting a nearly infinite number 42 Beta testing on tester’s home computers Game of custom computer configurations can reduce the occurrence of system- Designer creates unforeseen specific issues. Significantly minimizing installation/game play issues. the amount of specialized frameworks and developing the game based on well- known libraries (such as DirectX 11) will avoid the occurrence of this issue.
The game is easy to pirate due to 42 Provide a standard and invasive licensing Software lacking licensing schemes. mechanism to authorize legitimately- Engineer, purchased software. Programmer
Game rating review board provides 40 While the designers will develop the Business the game with a strict rating, game with a specific target rating analyst, making it difficult for reaching out constantly in mind, provide users with an Project to the widest audience possible. option to toggle gore and violence Manager settings, such that the game is appropriate for a somewhat younger audience as well.
Usable vehicles are found within 36 Extensive map testing a vehicle placement Game areas that do not provide suitable should detect these issues, as well as Designer, map areas for utilizing them. purposely placing “natural” game barriers Customer to direct users to areas where vehicles can Focus Group be used freely.
Users experience a dearth of 35 Extensive gear placement and beta testing Game weapons/ammunition to should ensure that weapons and ammo Designer, appropriately fend off enemies in a can be found in ample supply. However, Customer certain area with appropriate level characters are given the ability to carry a Focus Group of ease. sufficient amount of gear with them from area to area, as well as easily locate additional areas to purchase gear.
Damage produced from attack 30 Difficulty settings can be changed Game weapons is not appropriate for the throughout the game should the user feel Designer, proposed set of varied game they are not on the appropriate skill level. Programmer enemies.
Game play does not lend itself to 21 A complex series of storylines in which Customer have a great deal of “replay value” the user may pick throughout the game Focus Group, should ensure replay value, however, Business mission package extension have been Analyst planned for future releases to provide additional survival scenario add-ons. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 24
Game requirements do not satisfy 18 Extensive beta testing should minimize Software those of the present-day average- this risk, however, a comprehensive list of Engineer, powered machines. audio and graphical settings will be Customer provided to ensure that users can alter Focus Group performance of the game according to their specific system.
Game files are easily accessible on 12 Tampering clause and warranty void Programmer the system, leaving them open to statements should be added to the tampering, corruption, or removal. licensing document which users accept during the same installation process. To minimize the occurrence of this issue, game files will be compressed within package files and therefore not directly accessible.
Discussion The risks associated with making a state-of-the-art game, which presents a realistic and expansive landscape of identifiable buildings, structures, and artifacts are vast – covering game play, computer requirements, technical, licensing, and game rating risks. Game play risks, the majority presented here, involve issues experienced by the user while manipulating the character in-game. They generally surface due to the very complex nature of implementing a playable “world” in which the player is free to move in a number of directions rather than in a linear, level-based game. Since the game proposed involves a realistic landscape of a post-apocalyptic situation, chaotic rubble, destroyed buildings, and restricted areas, it is quite difficult to plan for all contingencies for where a user may travel. Consequently, an ample amount of weapons should be dispersed and relatively easy to locate within a given area to complete game tasks, as well as provide ample space for the user to maneuver vehicles.
Technical game risks such as maintaining the integrity of game files from corruption or tampering is another issue to consider to ensure that game installations remain intact and do not cause the customer a great deal of frustration fixing issues or interacting with the help desk. Additionally, computer requirement issues remain a problem due to the high level of uncertainty across non-standard system setups and configurations. The goal is to reach as many customers as possible and, thus, one cannot rely upon game features which require specialized hardware or software which cannot easily be configured with a supplemental installer. This will reduce the amount of variability needed to consider when dispensing the product to customers.
Lastly, due to the proposed gore and mature nature of the game, computer rating risks must be considered. In order to provide a wide array of gamers with access to this game, developers Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 25
must walk a fine line between gore and appropriateness. Additionally, the company wishes to evade any controversy from anti-game-violence groups and parent scrutiny, and instead provide an entertaining game for people to enjoy. Overall, the risks presented cover a wide array of issues that can be encountered with developing a large-scale commercial-grade game, covering both technical and game play problems. 12. Project Change Control Processes Change management for an adaptive project differs from traditional projects because it is based upon responding to change as opposed to following a specific plan with formalized processes. Much like our traditional project approach, we decided to establish a change management board. The members would consist of the different project areas and be represented by artists, graphic designers, programmers, software engineers, and writers. The board would be responsible for deciding how to properly respond to change based on customer feedback. For tracking purposes we decided to create two categories, one for defects (issues log) and one for enhancements (scope bank). Since our game is still in development we do not need an emergency defect remediation process but we will need to consider the impact and risks the defect poses. After version 1 is released, a defect remediation plan will be needed. The change management board, scope bank, and issues log will be created in cycle 1 as our first tasks and this will provide the necessary change infrastructure for the rest of the project. We believe the best feedback from our customers will occur after the prototyping and storyboarding sessions at the end of the cycles. When updating the scope bank and issues log we will ask the customers to rank the items in order of priority. Those with the highest priority will be placed at the top and the remaining work items will descend in value. Once the items have been prioritized the board will convene to determine the relative impact on the system. If a high priority work item cannot be deployed in the next cycle or it needs to be scrapped altogether due to scope, risk, or impact assessment, it will need to be communicated to the customers so further negotiation can begin and updates to the scope bank and issues log can be re-prioritized. High priority items to be implemented in the next cycle will be modeled more thoroughly than the remaining items. Once the items are modeled they will become part of the design process and will be included in the software prototype design. Once the design phase has ended, the items will be placed in the build phase to be developed so they will be included in the software prototype for the customers’ review. The changes will be detailed during prototyping in the client checkpoint phase and the customers will be asked to evaluate the change. The feedback gathered from the customers during the prototype and storyboarding reviews will be placed in the scope bank or issues log, depending on how the requirement is categorized. The requirements will be prioritized and the process will continue through the next cycle.
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 26
Potential Scenarios:
1. During the enemy prototyping and storyboard sessions the customers indicated the enemy was not scary enough and they wanted the enemy to be partially transparent and difficult to kill. We asked them to prioritize their concerns and rank them in order from high to low:
a. Make the zombies more scary. b.Make the zombies partially transparent but once spotted and engaged in fighting have them morph into more fully defined representations. c. Make the zombies difficult to kill and allow some of them to come back to life.
These three changes were identified by the customer and, after working with the project manager, they were added to the scope bank after it was discovered they were not defects. They were discussed in greater detail at the scope bank/issues log review meeting. The change management board decided that a. would be the easiest to provide, approved the change, and communicated to the project team to begin modeling the design in cycle 2. They felt c. could be accomplished but it may have to be incorporated in a later cycle, such as cycle 4, when the enemy specialization design is tentatively set to occur. After much discussion the board decided that the company did not have the proper skill set or experience to develop b. at the present time but are hopeful this can be worked into a later version. The project manager met with the customers to discuss the results of the meeting. They were disappointed that b. would not be made available in version 1. After considerable negotiation in which neither side could agree upon a modified requirement, the customer decided to scrap the feature but expressed intent to revisit the issue in version 2. With this new information the customers reviewed the scope bank with the project manager and re-prioritized their requirements. The project manager brought an artist to the meeting and while the artist sketched, the customers provided input into what a scary enemy should look like. Once the customers agreed to the final rendition, the artist forwarded the sketches to the graphic artists to begin modeling.
2. During the client checkpoint in cycle 3 the storyboard showed plenty of vehicle movement and special effects to the customers’ approval; however, the software prototype revealed movement issues and the customers had problems manipulating the vehicle. The customers placed this issue as a high priority requirement and it was placed in the issues log. After much internal discussion the board could not determine the impact of the issue so they requested a code review. The movement issues were determined to be a defect with limited impact. During the scope bank/issues log review the board approved the defect fix and the request was sent to be modeled. The project manager communicated to the customers that the movement issue would be remediated and available for review in the next cycle during the client checkpoint.
Since we are using an adaptive framework methodology for our development activities, we can utilize the change control process throughout all cycles and all versions. However, once a Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 27
version is released, we will need to incorporate an emergency defect remediation process to account for defects not found during testing. The defects will need to be replicated and prioritized and a plan needs to be established for their removal. Once removed, the fix will need to be made available online for all current users, and forwarded to manufacturing to be incorporated into a new version of the shrink-wrapped packaged product. Please see figure six for the change control process. New Requirement
No Yes Is Requirement a defect?
Scope Bank Issues Log
Prioritize Requirements
Scope Bank/ Issues Log Review
Yes
No Can the Is Requirement Begin negotiation Requirement be Approved by the with the customer re-prioritized board?
Yes No
Begin to model the Requirement Discard Requirement
Implement change in build phase
Add change to prototypes
Customer evaluation of change
No Does change meet customers expectations
Yes
Close change item in scope bank/ issues log
Figure 6. Change control process 13. Future Version Scope While version 1 of the first-person shooter game will provide the foundation of the game and be a completely interactive for-sale item, future versions will add further functionality and will have a two-fold purpose. Version 2 will additionally offer supplementary platforms including Xbox 360 and Sony Playstation, as well as being sold as expansion packs for the PC. The cross- platform games will cost as much as the initial version 1 PC game since they will provide the full equivalency, but the expansion packs will be cheaper since they will be built on top of the existing architecture, and may be downloaded or bought online and in-store. Version 2 intends to implement additional weapons and vehicles, in addition to providing multiplayer capabilities for up to two players. In version 3 which will solely be sold as expansion packs, the player will have the option to customize his character and choose from additional pre-built ones instead of only the generic male or female. This will prove to be useful for the added enhancement of online multiplayer capabilities that will be implemented with this version. Here, players can meet other individuals in the virtual world and choose to interact with them in various ways. This may include exchanging items and clues, teaming up against the zombies or other players, and killing one another to create additional hostile environments. 14. Conclusion Deathblow Gamers is in a unique position to take advantage of the growing first-person shooter market by developing a new title for the mature teen to young adult player. Using adaptive project management methodologies will allow the company to fully engage their perspective customers in the software design and development process. The company has performed a proper financial analysis and risk analysis of their business model to justify moving forward with this project. Providing they manage their risks in an adequate manner and pay close attention to their financial metrics, they should be able to gain enough market share to sustain their vision for success that puts them in a healthy position to plan and develop a subsequent version. Additional financial success will be possible if they are able to achieve a prestigious gaming award and move into the top ten in gaming sales.
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 30
References
MSN Money. (2010). Retrieved December 4, 2010, from
Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 31
Appendix A
Vision : Become a recognized leader in gaming
Goal/Outcome : Develop first-person shooter game that wins at least one prestigious industry award and comes in top ten in sales
• Feature Set #1 : Develop a storyline o Feature #1 : As a player, watch story unfold o Low-level Feature #1: As a player, watch introductory trailer o Feature #2 : As a player, choose story path to follow o Low-level Feature #1 : As a player, assess the situation o Low-level Feature #2 : As a player, find clues to determine role in the game Feature Set #2 : Create an immersive and to-scale accurate representation of a factual city layout and landscape o Feature #1: As a player, view/discover city o Low-level Feature #1 : As a player, survey surroundings o Low-level Feature #2 : As a player, navigate the roads and landscape o Low-level Feature #3 : As a player, navigate buildings and structures o Low-level Feature #4 : As a player, discover identifiable landmarks Feature Set #3 : Develop a compelling set of characters and enemies to bring additional depth to the game. o Feature #1: As a player, choose a character for game play o Low-level Feature #1 : As a player, choose a male or female character o Low-level Feature #2 : As a player, choose to customize character o Feature #2: As a player control playable character with the ability to walk, run, and fight within close and far range. o Low-level Feature #1 : As a player, use character to walk or run down streets and thru buildings. o Low-level Feature #2: As a player, jump. o Low-level Feature #3 : As a player, use character to manipulate objects in game o Low-level Feature #4 : As a player, use character to pick up and drop items o Feature #3: As a player battle enemy characters. o Low-level Feature #1 : As a player, encounter various types of zombies. o Low-level Feature #2 : As a player, use character to fight zombies with fists and feet. Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 32
o Low-level Feature #3 : As a player, use character to attack zombies with various weapons. o Low-level Feature #4 : As a player, use character to fend off various attacks from zombies. o Feature # 4: As a player interact with a comprehensive set of life-like and relateable characters to provide an interactive and humanly experience throughout the course of the game. o Low-level Feature #1 : As a player, choose to speak to other human characters. o Low-level Feature #2 : As a player, choose to lure zombies by yelling. o Low-level Feature #3 : As a player, choose to team up with another human to fight the zombies. o Low-level Feature #4 : As a player, choose to kill another human character. Feature Set #4 : Create a wide array of close and far-range weapons to appropriately counteract enemy attacks. o Feature #1: As a player, discover weapons and ammunition for protection. o Low-level Feature #1: As a player, pick up a weapon or ammunition. o Low-level Feature #2: As a player, discard a weapon or ammunition. o Feature #2: As a player utilize a robust set of weapons. o Low-level Feature #1 : As a player, scroll thru weapon inventory. o Low-level Feature #2 : As a player, select a weapon from inventory. o Low-level Feature #3 : As a player, reload weapon from inventory. o Low-level Feature #4 : As a player, aim and fire weapon. Feature Set #5 : Create a set of vehicles for the user to navigate the city. o Feature #1: As a player, find a vehicle. o Low-level Feature #1 : As a player, determine a way to gain entry into vehicle. o Low-level Feature #2 : As a player, determine how to drive vehicle. o Low-level Feature #3 : As a player, discard the vehicle. o Low-level Feature # 4: As a player, repair damaged vehicle. Feature Set #6 : Provide in-game clues and assistance to guide player to goal locations in a given task. o Feature #1: As a player, request in-game guidance and tips to help advance the game at a reasonable pace o Low-level Feature #1 : As a player, view text based “tips”. o Low-level Feature #2 : As a player, view map area markers. o Low-level Feature #3 : As a player, discover in-game “supplemental” clues. o Low-level Feature #4 : As a player, converse with in-game characters to progress the story . Appendix B The following images depict the project timeline as a Gantt Chart. This allows us to easily see in what order the tasks are completed, as well as by whom.
ID Task Name Duration 2011 November 21 December 1 December 11 December 21 January 1 January 11 January 21 February 1 February 11 11/21 11/28 12/5 12/12 12/19 12/26 1/2 1/9 1/16 1/23 1/30 2/6 1 Pre Development Activities 33 days 2 Version 1 Scoping 33 days 3 Conduct market research 15 days Business Analyst 4 Form customer focus groups 2 days Business Analyst,Project Manager 5 Define game strategy, plot, and target market 1 day Business Developer,Game Designer,Customer Focus groups 6 Create COS 1 day Project Manager 7 Create POS 1 day Project Manager 8 Requirements Breakdown Structure (RBS) 2 days Project Manager 9 Prioritized scope triangle 1 day Project Manager 10 Prioritized features 1 day Project Manager,Customer Focus groups 11 Mid-level work breakdown structure (WBS) and dependencies 2 days Project Manager 12 Cycle timebox 2 days Project Manager 13 Number of cycles 1 day Project Manager 14 Cycle 1 26 days 15 Cycle Plan 5 days 16 Conceptualize team reporting/risk structure 1 day 17 Create Change Management board 1 day Project Manager 18 Create Scope Bank 1 day Change Board 19 Create Issues Log 1 day Change Board 20 Conceptualize basic game characters 4 days ID Task Name Duration January 11 January 21 February 1 February 11 February 21 March 1 March 11 March 21 April 1 1/9 1/16 1/23 1/30 2/6 2/13 2/20 2/27 3/6 3/13 3/20 3/27 21 Conceptualize basic player character 2 days 22 Basic character concept 2 days Artist,Graphic Designer 23 Conceptualize basic enemy character 4 days 24 Basic enemy concept 4 days Artist,Graphic Designer 25 Conceptualize game environment 4 days 26 Conceptualize basic road grid layout 4 days 27 Road surveying/field work 4 days Artist,Graphic Designer 28 Road plotting 4 days Artist,Graphic Designer 29 Conceptualize initial basic building structure/layout 4 days 30 Building surveying/field work 4 days Artist,Graphic Designer 31 Building sketching 4 days Artist,Graphic Designer 32 Terrain surveying 4 days Artist,Graphic Designer 33 Artifact selection and sketching 4 days Artist,Graphic Designer 34 Cycle Build 10 days 35 Develop character 10 days 36 Basic character design development 10 days Programmer,Software Engineer,Graphic Designer 37 Character movement development 10 days Programmer,Software Engineer,Graphic Designer 38 Character rag-doll physics development 10 days Programmer,Software Engineer,Graphic Designer 39 Character attack development 10 days Programmer,Software Engineer,Graphic Designer 40 Develop enemy 10 days Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 34
ID Task Name Duration January 11 January 21 February 1 February 11 February 21 March 1 March 11 March 21 April 1 1/16 1/23 1/30 2/6 2/13 2/20 2/27 3/6 3/13 3/20 3/27 4/3 41 Basic enemy design and development 10 days Programmer,Software Engineer,Graphic Designer 42 Enemy movement development 10 days Programmer,Software Engineer,Graphic Designer 43 Enemy attack development 10 days Programmer,Software Engineer,Graphic Designer 44 Enemy damage design development 10 days Programmer,Software Engineer,Graphic Designer 45 Enemy rag-doll physics development 10 days Programmer,Software Engineer,Graphic Designer 46 Develop game landscape 10 days 47 Road development 10 days Programmer,Software Engineer,Graphic Designer 48 Building development 10 days Programmer,Software Engineer,Graphic Designer 49 Terrain development 10 days Programmer,Software Engineer,Graphic Designer 50 Client Checkpoint 13 days 51 Prototyping 6 days 52 Character prototyping 6 days Customer Focus groups 53 Enemy prototyping 6 days Customer Focus groups 54 Terrain prototyping 6 days Customer Focus groups 55 Artifact prototyping 6 days Customer Focus groups 56 Customer interaction and feedback 13 days 57 Storyboard game simulation (comic book detail of how game would look and basic character3 days interaction) Writer,Artist,Customer Focus groups 58 Customer instructions to properly interact with each prototype 1 day Writer,Customer Focus groups 59 Customer feedback for each prototype and storyboard 2 days Customer Focus groups 60 Update scope bank 13 days Customer Focus groups,Project Manager ID Task Name Duration February 11 February 21 March 1 March 11 March 21 April 1 April 11 April 21 May 1 2/13 2/20 2/27 3/6 3/13 3/20 3/27 4/3 4/10 4/17 4/24 5/1 61 Cycle 2 25 days 62 Cycle Plan 10 days 63 Scope bank/issues log review 2 days 64 Model high priority items approved by the board 2 days 65 Basic weaponry design 4 days 66 Character shooting perspective 4 days 67 Software Prototype design 8 days 68 Cycle Build 12 days 69 High priority items development 2 days 70 Basic weaponry/1st-person shooter perspective development 4 days 71 Initial software prototype development 10 days 72 Client Checkpoint 25 days 73 Review Prototypes 3 days 74 Storyboard game simulation (comic book detail of how game would look and basic character3 days and weapons interaction) 75 Update scope bank 25 days 76 Cycle 3 25 days 77 Cycle Plan 10 days 78 Scope bank/issues log review 2 days 79 Model high priority items approved by the board 2 days 80 Software prototype design 2 days Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 35
ID Task Name Duration March 21 April 1 April 11 April 21 May 1 May 11 May 21 June 1 June 11 3/20 3/27 4/3 4/10 4/17 4/24 5/1 5/8 5/15 5/22 5/29 6/5 81 Basic vehicle and special effects design 4 days 82 Software prototype design 8 days 83 Cycle Build 12 days 84 High priority items development 2 days 85 Vehicle movement and special effects development 4 days 86 Software prototype development 10 days 87 Client Checkpoint 25 days 88 Review Prototypes 3 days 89 Storyboard game simulation (comic book detail of how game would look and basic character,3 days weapons, and vehicle interaction) 90 Update scope bank 25 days 91 Cycle 4 25 days 92 Cycle Plan 10 days 93 Scope bank/issues log review 2 days 94 Model high priority items approved by the board 2 days 95 Character facial and dialog design 2 days 96 Enemy “specialization” design 2 days 97 All weaponry special effects, selection, and map planning design 4 days 98 Software prototype design 8 days 99 Cycle Build 12 days 100 High priority items development 2 days ID Task Name Duration April 21 May 1 May 11 May 21 June 1 June 11 June 21 July 1 July 11 4/24 5/1 5/8 5/15 5/22 5/29 6/5 6/12 6/19 6/26 7/3 7/10 101 Character facial and dialog options development 4 days 102 Enemy “specialization” development 4 days 103 Advanced weaponry development 4 days 104 Software prototype development 10 days 105 Client Checkpoint 25 days 106 Review Prototypes 3 days 107 Update scope bank 25 days 108 Cycle 5 24 days 109 Cycle Plan 10 days 110 Scope bank/issues log review 2 days 111 Model high priority items approved by the board 2 days 112 Main story line creation, sub plot design, and recurring situtation design 4 days 113 Software prototype design 8 days 114 Cycle Build 12 days 115 High priority items development 2 days 116 Main story line creation, sub plot, and recurring situtation development 4 days 117 Software prototype development 10 days 118 Client Checkpoint 24 days 119 Review prototypes 3 days 120 Update scope bank 24 days Assignment 4 Group 3: Lerman, Madya, Mallon, Schultz December 6, 2010 36
ID Task Name Duration July 1 July 11 July 21 August 1 August 11 August 21 September 1 September 11 September 21 7/3 7/10 7/17 7/24 7/31 8/7 8/14 8/21 8/28 9/4 9/11 9/18 121 Cycle 6 25 days 122 Cycle Plan 10 days 123 Scope bank/issues log review 2 days 124 Model high priority items approved by the board 2 days 125 Textual “tips” system design 4 days 126 Software prototype design 8 days 127 Cycle Build 12 days 128 High priority items development 2 days 129 Textual “tips” system development 4 days 130 Software prototype development 10 days 131 Client Checkpoint 25 days 132 Review prototypes 3 days 133 Update scope bank 25 days 134 Cycle 7 25 days 135 Cycle Plan 10 days 136 Scope bank/issues log review 2 days 137 Model high priority items approved by the board 2 days 138 Installer, package, and support design 4 days 139 Software prototype design 8 days 140 Cycle Build 12 days ID Task Name Duration August 11 August 21 September 1 September 11 September 21 October 1 October 11 October 21 8/7 8/14 8/21 8/28 9/4 9/11 9/18 9/25 10/2 10/9 10/16 10/23 141 High priority items development 2 days 142 Installer, package, and support development 4 days 143 Software prototype development 10 days 144 Client Checkpoint 25 days 145 Review version 1 prototype 3 days 146 Installer testing (multiple system configurations) 3 days 147 Customer feedback on configuration, test plan, and support 3 days 148 Update scope bank 25 days 149 Conduct Post-Version Review 1 day 150 Post mortem review 1 day 151 Process review 1 day 152 Change request review 1 day 153 Scope bank review 1 day 154 Lessons learned review 1 day 155 Overall business review 1 day