Did some research together about software processes and examples of it, here are the findings.

Software Processes are networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.




Jessica did the research on the Waterfall Process.

The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes "requirements specification" — they set in stone the requirements of the software. When the requirements are fully completed, one proceeds to design. The software in question is designed and a "blueprint" is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs.

Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are discrete, and there is no jumping back and forth or overlap between them.

Serene did the research on the Spiral Process.

While the waterfall methodology offers an orderly structure for software development, demands for reduced time-to-market make its series steps inappropriate. The next evolutionary step from the waterfall is where the various steps are staged for multiple deliveries or handoffs. The ultimate evolution from the water fall is the spiral, taking advantage of the fact that development projects work best when they are both incremental and iterative, where the team is able to start small and benefit from enlightened trial and error along the way.

The spiral methodology reflects the relationship of tasks with rapid prototyping, increased parallelism, and concurrency in design and build activities. The spiral method should still be planned methodically, with tasks and deliverables identified for each step in the spiral.

Truman did the research on the Documentation Model.

The reality is that increased processes usually result in increased documentation. An improved process produces intermediate work products that represent the elaboration of the product design at each step in the development life cycle. Where possible, documentation should be generated using automated tools, so outputs can contribute to generation of code structures or help generate the code itself.

The difference between hacking and software engineering is professional discipline applied with common sense. Software quality, reliability, and maintainability are enhanced by having good documentation for requirements, architecture, interfaces, detailed design, well-commented code, and good test procedures. Requirements documentation practices should facilitate your customer's understanding and review of the real requirements. Software project planning should include estimating the time and resources to produce, review, approve, and manage such documentation products.

Derrick did the research on Unified Process.

The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process or RUP.

The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects.

Iterative and Incremental

The Unified Process is an iterative and incremental development process. The Elaboration, Construction and Transition phases are divided into a series of timeboxed iterations. (The Inception phase may also be divided into iterations for a large project.) Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g. Requirements, Design, Implementation, Testing) the relative effort and emphasis will change over the course of the project.

Use Case Driven

In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.

Architecture Centric

The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. This partial implementation of the system serves to validate the architecture and act as a foundation for remaining development.

Risk Focused

The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.

Hafiz did the research on the V-Model.

The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

Requirements analysis

In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

With some extra time on our hands, we decided to do research on a last model, the Chaos Model as a group.

In computing, the Chaos model is a structure of software development that extends the spiral model and waterfall model.

The chaos model notes that the phases of the life cycle apply to all levels of projects, from the whole project to individual lines of code.

• The whole project must be defined, implemented, and integrated.
• Systems must be defined, implemented, and integrated.
• Modules must be defined, implemented, and integrated.
• Functions must be defined, implemented, and integrated.
• Lines of code are defined, implemented and integrated.

One important change in perspective is whether projects can be thought of as whole units, or must be thought of in pieces. Nobody writes tens of thousands of lines of code in one sitting. They write small pieces, one line at a time, verifying that the small pieces work. Then they build up from there. The behavior of a complex system emerges from the combined behavior of the smaller building blocks.

There are several tie-ins with chaos theory.

• The chaos model may help explain why software tends to be so unpredictable.
• It explains why high-level concepts like architecture cannot be treated independently of low-level lines of code.
• It provides a hook for explaining what to do next, in terms of the chaos strategy.

Comments please, thanks!