(from Rapid Development, Steve McConnell, 1996)

1. (Rapid Development, p. 133) "Every software development effort goes through a lifecycle, which consists of all the activities between the time that version 1.0 of a system begins life as a gleam in someone's eye and the time that version 6.74b finally takes its last breath on the last customer's machine. A lifecycle model is a prescriptive model of what should happen between first glimmer and last breath."

2. The main function of our lifecycle model is to establish the order in which your project:
   • specifies itself, what you're doing
   • prototypes and designs
   • implements (code)
   • review, test, and analyze
   • any other activities involved in your project's development
   In a lifecycle model, the criteria is established that you use to determine whether to proceed from one task to another.

3. Example lifecycle models (Rapid Development, p. 136) (this is from 1996, but I believe the models continue to be relevant)
   • Pure Waterfall - the "grandaddy" of all lifecycle models. Although it has many problems, it serves as the basis for other, more effective lifecycle models. The project iterates one time through, from beginning to end, progressing through an orderly sequence of steps from the initial software concept through system testing. The project reviews at the end of each phase to determine whether it is ready to advance to the next phase. If the review determines that the project isn't ready to move to the next phase, it stays in the current phase until it is ready to move on.
   • Code and Fix - if you haven't explicitly chosen another lifecycle model, you are probably using code-and-fix by default. "If you haven't done much project planning, you're undoubtedly using code-and-fix. Combined with a short schedule, code-and-fix gives rise to the code-like-hell approach...". When you use code and fix, you start with a general idea of what you want to build. You might have a formal spec or you might not. You then use whatever combination of informal design, code, debug, and test methodologies suits you until you have a product that's ready to release (turn in).
     1. Advantages of Code-and-fix: no overhead, no time necessary for planning, documentation etc - only pure coding is used. You jump right into coding, and show progress immediately. Code and fix requires little expertise - anyone who has written a computer program can use it.
     2. Disadvantages to Code-and-fix: only works well on tiny projects, for larger projects this model can be dangerous. Provides no means of assessing progress, you just code until you're done. It provides no means of assessing quality or identifying risks. If you discover three-quarters of the way through coding that your whole design approach is fundamentally flawed, you have no choice but to throw out your work and start over. Other models would set you up to detect such a fundamental mistake earlier, when it would have been less costly to fix.
   • Spiral Model: a "risk-oriented" lifecycle model that breaks a software project up into miniprojects. Each miniproject addresses one or more major risks until all the major risks have been addressed. The concept of risk is a broad one - it can refer to poorly understood requirements or architecture, problems in underlying technology, how you're going to code a particular piece of your project. Each iteration moves your project to a larger scale. Each iteration has similar steps:
     1. Determine your objectives for this iteration
     2. Identify risks that exist at this level of your project's development
     3. Evaluate or think about alternative paths or methods you could take
     4. Develop deliverables for that iteration and verify they are correct. Analyze your results so far.
     5. Plan for your next iteration, and commit to an approach for the next iteration
   • Evolutionary Prototyping: you develop the system concept as you move through the project. Usually you begin by developing the most visible aspects of the system. Evolutionary prototyping is especially useful when requirements are changing rapidly. It's also useful when you're unsure of the optimal architecture or algorithms to use. Disadvantage - it's impossible to know at the outset of the project how long it will take to create an acceptable project. You don't know how many iterations you'll have to go through. But, steady signs of progress can be seen, that's good.
   • Staged Delivery - you show software to the customer in successively refined stages. Unlike evolutionary prototyping, when you use staged delivery, you know exactly what you're going to build when you set out to build it. With staged delivery, you don't deliver the software at the end of the project in one fell swoop. You deliver it in successive stages throughout the project. (also known as "incremental implementation")
   • Evolutionary Delivery: straddles the ground between evolutionary programming and staged delivery. You develop a version of your product, show it to your customer, and refine the product based on customer feedback. How much evolutionary delivery looks like evolutionary prototyping depends on the extent to which you plan to accommodate customer requests. If you plan to accommodate most requests, evolutionary delivery will look a lot like evolutionary prototyping. If you plan to accommodate few change requests, evolutionary delivery will look a lot like staged delivery.

4. Choosing a lifecycle model for your project. (Rapid Development, p. 154) Different projects have different needs, even if they all need to be developed as fast as possible. To choose the most effective lifecycle model for your project think about your answer to these questions:
   • How well do I and my customer understand the requirements at the beginning of the project? Is our understanding likely to change significantly as we move through the project?
   • How well do I understand the architecture of my program? Am I likely to need to make major architectural/program changes midway through my project?
   • How much reliability do I need?
   • How much do I need to plan ahead and design ahead during this project for future versions?
   • How much risk does this project entail?
   • Am I constrained to a predefined schedule?
   • Do I need to be able to make midcourse corrections?
   • Do I need to provide my customers or management (or teacher) with visible progress throughout the project?
   • How much sophistication do I need to use this lifecycle model successfully?
   • For more detail - see the chart Rapid Development, p. 156