What is Software Process? What do you mean by software quality factors? What are different process models?

The factors that affect the quality of the software are called quality factors. The software product quality has three dimensions and each of the dimension deals with a set of quality factors.

PRODUCT OPERATION
- Correctness
- Reliability
- Efficiency
- Integrity
- Usability
PRODUCT TRANSITION
- Portability
- Re usability
- Interoperability
PRODUCT REVISION
- Maintainability
- Flexibility
- Testability

Software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced.
Software process deals with the technical and management issues of software development.
The different process models are:
- Waterfall Model
The phases of the model are organized in a linear order.
- Prototyping
A throw away prototype is built instead of freezing the requirements before design or coding to help understand the requirements.
- Iterative
The software should be developed in increments with each functionality added to each increment.
- Spiral
Software development activities are organized like a spiral that has many cycles. The radial dimension represents the cumulative cost and the angular dimension represents the progress.

Problems with waterfall software development model

Other software development models were developed (such as the Agile model) because it was felt that the sequential process defined in the Waterfall model was argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle in a complete form before the next step is started. As an example, clients are almost never confident of their requirements being in a final form before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested into preparing a comprehensive design. In addition, designers cannot anticipate technical difficulties with their design, and typically these difficulties become clear during development, at which time it is expensive to change design.
Summary of problems:
- Client requirements are never complete at the time of requirement specification. They change, and it is realistic to anticipate that such change would occur
- Each phase needs information from the following phases to be fully complete. For example, requirements phase needs information from design phase as to what is feasible; design phase needs feedback from coding phase as to which design has the best chances of succeeding
- Builds in a waterfall model are typically available much later, but there is a need to have builds much earlier so as to build confidence
- Each phase has people who are specialised for that phase. It is a hard task to get people specialized for each phase, as well as make sure that they are connecting with each other for proper information transfer

Waterfall Development Methodology

What is the Waterfall method?
A classic SDLC model, with a linear and sequential method that has goals for each development phase. The waterfall model simplifies task scheduling, because there are no iterative or overlapping steps. One drawback of the waterfall model is that it does not allow for much revision.
This model has the following activities.
1. System/Information Engineering and Modeling
2. Software Requirements Analysis
3. Systems Analysis and Design
4. Code Generation / Implementation
5. Testing
6. 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 thus discrete, and there is no jumping back and forth or overlap between them.