Homework #13 - 9/26 (Makeup)

     This reading is all about software life cycle models. Not the most interesting thing to read about, but certainly important. Just as we can model systems and their behavior with UML diagrams for a better understanding of the system and an aid in the development of the system, we, too, can model the development cycle of a piece of software. Also, un-intuitively, software life cycles can be modeled as activity-centered diagrams, where a class in the diagram represents an activity in software development (ie Problem Definition Activity, or System Development Activity). The other way life cycles can be modeled uses an entity-centered view, in which each class in the diagram represents the content and structure of the work product (ie a Requirements Specification Document).

     There are several commonly used life cycle models, most of which are activity-centered. The first, and oldest, being the Waterfall model, in which it describes a sequence of activities that occur. The requirements process leads to the design process, which leads to the implementation process, etc. The thing about the waterfall model is that there is no way to back up, to traverse up the waterfall is impossible. Because of this, the waterfall model is not used in large, costly software development. It is mainly only appropriate for small scale personal or school projects, where one can restart with little consequence. The V-model is a variation on the waterfall model in which with each activity before implementation, there is a paired activity afterward that focuses on the validation of the system through testing and client acceptance. There still is no way to go backwards in the life cycle, or re-iterate on activities. For this reason, the spiral model has become popular. This risk-analysis based model starts at an origin and spirals outward. The farther away from the origin, the greater the cost of the development thus far. Each quadrant of the model represents the type of activity that is taking place along that point in the spiral. This way, as you move along the spiral, you will iterate among the four quadrants, first determine objectives, alternatives, and constraints. Then evaluate the alternatives, identify and resolve risks. Then comes developing and verifying the next component in the system, whether it is designing, or coding. Finally, you plan for the next phase, which could be a requirements plan, or integration plan.

     I cannot say I plan on becoming a project manager at any point in my career, but learning about life cycle models is still important to me. It's all related in the end, really. For example, the spiral model can not only be used in modeling software life cycles, but it can also be used to model a design plan for your code. First, design the general layout of your code - come up with classes and methods, etc. Then write some prototypes and evaluate any alternatives, once you've decided the best way to go about it, write the code. After writing that portion of code, test and debug it before moving on to the rest of the program. This way you write in small increments and each part is tested on its own before you integrate all of the components together for the whole program.