Gifting Knowledge Is Our Basic Goal  
.

 

 


Software Process Models

 To solve actual problems in a software project setting, a software engineer or a team of engineers must incorporate a development strategy that includes methods, tools and procedures. This strategy is referred to as a process model or a software engineering paradigm.

            There are several such paradigms available. Which software paradigm is more suitable depends on lot of factors such as:

1. Nature of the Project
2. Type of Applications
3. Tools proposed to be used
4. Kind of controls and documentation required

 

Code And Fix Life Cycle Model

As the name suggests, this model uses an adhoc approach for the software designing. A very casual study is followed by coding. The issues regarding specification or design are never addressed. Instead, the developers simply build a product that is re-build again and again until the customer is satisfied.

 

Limitations of code-and-fix cycle model

This approach may work well for small systems but is very unsatisfactory for larger systems. As the code size increases, the understandability and maintainability of the system decreases.

 

The Waterfall Model/Linear Sequential Life Cycle Model

The simplest, oldest and most widely used process model for software designing is the waterfall model. It was proposed by Royce in 1970.
The essence of this software paradigm is that the process of software designing consists of linear set of distinct phases.

These phases are:

Stage1: Feasibility Study
The goal of feasibility study is to evaluate alternative systems and to purpose the most feasible and desirable system for designing. Five types of feasibility are addressed in this study.

1. Technical feasibility
2. Economic Feasibility
3. Motivational Feasibility
4. Schedule Feasibility
5. Operational Feasibility

Stage2: Requirement Analysis and Specification

The goal of this phase is to understand the exact requirements of the customers and to document them properly. This activity is usually executed together with the customers, as the goal is to document all functions, performance and interfacing requirements for the software designing and management. The requirements describe “what” of a system. This phase produces a large document containing a description of what the system will do without describing how it will be done. This document is known as software requirement specification (SRS) document.

Stage3: Design

The goal of this phase is to transform the requirement specification produced in the requirement analysis phase into a structure that is suitable for implementation in some programming language, Here, overall software architecture is defined, and the product design and detailed design work is performed. This work is documented and is known as software design description (SDD document).

Stage4: Coding and Unit Testing

The information contained in SDD is sufficient to begin the coding Phase. The coding Phase of software designing involves translation of design specification into a machine readable form. If design is performed in a detailed manner, code generation can be accomplished easily. This phase is also known as the implementation phase. Here, each component of the design is implemented as a program module, and each of these program modules is unit tested. The purpose of unit testing is to determine the correct working of individual modules.

Stage5: Integration and System Testing:

During this phase the different program modules are integrated in a planned way and then tested as a completed system to ensure that the designed system functions according to its requirements as specified in the SRS document. After testing, the software is delivered to the customer.

Stage6: Software Maintenance

This is the last phase of software designing which includes a broad set of activities such as error correction, enhancement of capabilities, deletion of obsolete capabilities and optimization.
Advantages

1. Simple and easy to use
2. Easily manageable
3. The phase of the model are processed and completed one at a time.
4. Works very well for smaller software projects.

Disadvantages

1. It is often difficult for the customer to state all the requirements explicitly.
2. Real projects rarely follow the sequential flow that the software model proposes.
3. The customer must have patience, as the product is delivered very late in this software process.
4. The model is not suitable for long time software projects.

 

The Prototyping Model

Prototyping is a technique that provides a reduced functionality or limited performance version of the eventual software to be delivered to the user in the early stages of the software development process. If used judiciously, this approach helps to solidify user requirements earlier, thereby making the waterfall approach more effective.
What is done is that before proceeding with design and coding, a throw away prototype is built to give user a feel of the system. The development of the software prototype also involves design and coding, but this is not done in a formal manner. The user interacts with the prototype as he would do with the eventual system and would therefore be in a better position to specify his requirements in a more detailed manner. The iterations occur to refine the prototype to satisfy the needs of the user, while at the same time enabling the developer to better understand what needs to be done.

Disadvantages

1. In prototyping, as the prototype has to be discarded, so might argue that the cost involved is higher.
2. At times, while designing a prototype, the approach adopted is “quick and dirty” with the focus on quick development rather than quality.
3. The developer often makes implementation compromises in order to get a prototype working quickly.

 

The Spiral Model

This model proposed by Barry Bohem in 1988, attempts to combine the strengths of various models. It incorporates the elements of the prototype driven approach along with the classic software life cycle. Is also takes into account the risk assessment whose outcome determines taking up the next phase of the designing activity.
Unlike all other models which view designing as a linear process, this model views it as a spiral process. This is done by representing iterative designing cycles as an expanding spiral.
Typically the inner cycles represent the early phase of requirement analysis along with prototyping to refine the requirement definition, and the outer spirals are progressively representative of the classic software designing life cycle.
At every spiral there is a risk assessment phase to evaluate the designing efforts and the associated risk involved for that particular iteration. At the end of each spiral there is a review phase so that the current spiral can be reviewed and the next phase can be planned.

Six major activities of each designing spirals are represented by six major tasks:
1. Customer Communication
2. Planning
3. Risk Analysis
4. Software Designing Engineering
5. Construction and Release
6. Customer Evolution

Advantages

1. It facilities high amount of risk analysis.
2. This software designing model is more suitable for designing and managing large software projects.
3. The software is produced early in the software life cycle.

Disadvantages

1. Risk analysis requires high expertise.
2. It is costly model to use
3. Not suitable for smaller projects.
4. There is a lack of explicit process guidance in determining objectives, constraints and alternatives..
5. This model is relatively new. It does not have many practioners unlike the waterfall model or prototyping model.

 

Fourth Generation Techniques

The term fourth generation technique (4GT) encompasses a broad array of software tools that have one thing in common: each enables the software engineer to specify some characteristics of software at a high level. The tool then automatically generates the source code based on the developer’s specification. The 4GT paradigm for software engineer focuses on the ability to specify software using specialized language forms or a graphic notation that describes the problems to be solved in terms that the customers can understand.
Currently, a software designing environment that supports the 4GT paradigm include some or all the following tools: non procedural languages for database query, report generation, code generation, data manipulation, high level graphics capability, spreadsheet capability and automated generation of HTML and similar languages used for website creation using advanced software tools.
Like other paradigms, 4GT begins with a requirements gathering step. Ideally, the customer would describe requirements and these would be directly translated into an operational prototype. But this is unworkable. The customer may be unsure of what is required, may be ambiguous in specifying facts that are known, and may be unable or unwilling to specify information in a manner that a 4GT tool may consume. For this reason, the customer/developer dialog described for other process models remains an essential part of the 4GT approach.
For some applications, it may be possible to move directly from the gathering step to the implementation phase using a non procedural fourth generation language (4GL) or a model composed of a network of graphical icons. However, for larger efforts, it is necessary to develop a design strategy for the system, even if a 4GT is to be used. The use of 4GT without design will cause difficulties like poor quality, poor maintainability, poor customer acceptance etc. that have been encountered when designing a software project using conventional approaches.
Implementation using a 4GL enables the software developer to represent the desired results in a manner that leads to automatic generation of code to create those results. Obviously, a data structure with relevant information must exist and be readily accessible by the 4GL.
To transform a 4GT implementation into a product, the developer must conduct thorough testing, develop meaningful documentation, and perform all other solution integration activities that are required in other software engineering paradigms. In addition the 4GT designed software must be built in a manner that enables maintenance to be performed expeditiously.
Like all other software designing paradigms, the 4GT model has advantages and disadvantages. Proponents claims dramatic reduction in software designing time and greatly improved productivity for people who built software. Opponents claim that current 4GT tools are not all that much easier to use than programming languages, that the resultant source code produced by such tools is “insufficient”, and that the maintainability of large software systems designed using 4GT is open to question.

Search Engine Optimization We have strong company aims and beliefs to focus on Search Engine Optimisation services geared towards Google, Yahoo, MSN, Miva, and other search engines. SEO Consult believes in thinking out of the box, going beyond the call of duty to provide exception service to our clients.