|
|
|
|
Note: This schedule is geared for a cross platform (Mac and Windows), shrink-wrapped, off the rack title that will compete for shelf space at retail consumer software stores. The assumed development time is 8-12 months with a staff of four programmers (2 Mac / 2 Windows) and one part-time manager. Planning Phase 1. If you are developing software for a client with its own or a third part digital art team, you will need to develop a critical path timeline chart showing where all media deliveries occur. If possible, the client should arrange to have demos created with authoring tools to show the software developers the functionality of the product and to use in focus testing (if appropriate). No coding or media preparation should begin until the product is completely storyboarded. Of course, this is the ideal, and things change, but it is a good goal to strive for. Milestone delivery dates for Alpha, Beta and Final are generally established at this point. 2. If you are producing your own product, and you have your own staff of digital media artists (who may be working on more than one project at a time), you will have the luxury of enforcing your own standards for file attributes and other technical details, but also the management headache of enforcing on-time delivery--as opposed to having a client responsible for enforcing other people's deadlines. 3. Because your staff are coding in C++ you will be able to take advantage of new, performance enhancing technologies sooner than if you were using an authoring tool, but you should approach this cautiously. Do not plan to incorporate a new technology unless it is in general release (some people advise waiting until the 1.1 version is available). Many products have failed because they adopted a technology while it was in beta and the product was finished before the new technology it relied upon. 4. Whatever the case (1 or 2 above), you should plan to spend several weeks conducting meetings with artists, programmers and project managers, going over the workings of the project in as much detail as possible. Many of issues that will surface cannot be anticipated by a single person working with project management software. Expectations among programmers, artists and designers will differ wildly, unless they have worked together on several productions previously. This will be even more the case when building a cross platform product. Meetings with QA (Quality Assurance) managers should also be organized at this point to understand their testing procedures in advance. 5. At the end of several weeks of preproduction, you should have: 1) agreement among artists and programmers as to expected performance of media assets, e.g. how many animations or movies can play at once, how much state information can be stored and referenced by the program at run time, exactly how the user will navigate, etc. This should all be carefully documented and distributed to the entire team, with a clearly understood change procedure and feedback mechanism. If any of your digital media assets are being repurposed from earlier works, all permissions should be cleared by now. Production Phase 6. Prior to commencement of coding, the software development environment needs to be established and the specific tools identified. This includes not only the specific IDEs (Integrated Development Environments) for Windows and Macintosh programming, such as Microsoft Visual C++ and Metrowerks CodeWarrior, but also the media processing tools such as DeBabelizer, PalEdit, etc. Late-breaking performance enhancing technologies need to be either adopted or rejected at this point. 7. A team leader for each development platform (Mac and Windows) should be designated and charged with the responsibility of writing and maintaining a design document for the project. This document should be reviewed by the product manager and structured to be meaningful to both artists and programmers, and should be able to serve as a record of the development cycle at the end of the project. Since software design is often dictated by the strengths and weaknesses of the available programming tools and the platforms they run on, the author of this document should justify his or her design decisions accordingly. 8. A version control system should be established at this time, both for software and digital media. This is a common practice in any professional programming environment, and ensures that only one person at a time may work on the most recent version of the code. Failure to implement this can be disastrous down the line. A daily backup system for the entire project, on either DAT tape or CD-ROM should also set in place. 9. Once programming has actually begun, assuming the project is being done in C++, the first job is to establish the basic classes and specify their functionality. Even for experienced software developers, this is often a tricky period and can entail a significant amount of re-thinking despite a solid design document. Paradoxically, some specialized parts of the program are often coded at this point, especially those that need to deliver high performance (such as display and I/O streaming routines). The real day to day work is building the great middle part of the product--adding layers of flesh to the bones of the class structures. 10. The first milestone that will loom is the Alpha deadline (unless contractual interim deadlines were agreed upon). At Alpha, the project is theoretically code complete. In general practice, this means that all of the basic functionality is coded and a master build can be performed on the project. Often, certain areas of the project are simply skeletized at this point, based on the discretion of the client. Traditionally, formal testing can begin at this point, and bug reports submitted to the programmers. All artwork should be final at this point, but it often is not. 11. The period between the Alpha and Beta deadlines is often the most stressful for the programming team. All of the unfinished, glossed over parts of the product must now be completed, as well as Alpha bugs addressed and fixed, which can be quite distracting and requires skilled project management. During this period it becomes apparent whether the final deadline is going to be met or not, which can be a tremendous source of stress for the client since market activities have usually been synched to the development cycle. If things are going to slip, realistic estimates for delivery extensions are crucial. Again, management leadership ability is just as important as programmer expertise during this period.Testing Phase 12. At the Beta milestone, the product is theoretically shippable, although the industry has come to expect (and deliver) far less--especially the multimedia industry. Classically, only bug fixes are performed during this period, although these days unfinished code has become synonymous with bugs. The bottom line is in how well project managers negotiate with QA personnel. Meanwhile, the programmers are still working long hours, even in well-managed shops. 13. QA procedures should be reviewed during all phases of the development cycle so that any potentially unusual behavior that is part of the program design is not mistakenly classified as a bug by the beta testers. This can save days when the product is actually in beta and QA decides that certain behavior does not fit the CUA standards of either Windows or the Mac, resulting in a battle between the designers and the testers which the programmers may have to resolve at the last minute with crisis style patches that could have dangerous side effects. 14. Final delivery, also known as GM (Golden Master--the color of the one-off CD-ROM the final product is delivered on), takes place when the powers that be decide there are few enough bugs to ship with. In a highly professional environment, bugs are categorized by severity, which is based on how likely the bug is to generate a technical support call or cause a customer to return the product. Program hangs, user interface distortion, poor multimedia performance and general unpredictable behavior are all showstoppers. Top selling products have all shipped with lesser bugs, which demonstrates the politics involved during this phase of the cycle. 15. Even when the Golden Master leaves for the CD-ROM pressing plant, the software development job is not completely finished. The code base must be carefully frozen for when the next version of the product commences production. The design documentation must be updated so that the people who inherit the technology can get up to speed on it quickly. Final bug reports must be filed in case management authorizes a so-called "silent revision." If the product is successful, all of these steps will be essential. |
 |
|
|
||
|
