Software Engineering Paradigm

A paradigm is the model of a process. It defines the flow of activities that occur as the process
progresses from start to end. It is a category of entities that share a common characteristic.

In the aspect of software engineering, software paradigms refer to the methods and steps, which
are taken while designing the software. There are many methods proposed and are in work today, but we
need to see where in the software engineering these paradigms stand. These can be combined into
various categories, though each of them is contained in one another:

1. Software Development Paradigm

This paradigm is known as software engineering paradigms where all the engineering
concepts pertaining to the development of software are applied. It includes various researches and
requirement gathering which helps the software product to build. It consists of:

o Requirement gathering – This step onwards the software development team works to
carry on the project. The team holds discussions with various stakeholders from problem
domain and tries to bring out as much information as possible on their requirements.
o Software design – The software design paradigm is a subset of software development
paradigm.
o Programming – The programming paradigm is also a subset of software development
paradigm
2. Software Design Paradigm
This paradigm is a part of software development paradigm and includes

o Design – After gathering the requirements needed, the developer will start designing the
software product. In comes in two forms; the logical design and the physical design.
o Maintenance – The software is maintained timely by updating the code according to the
changes taking place in user end environment or technology.
o Programming – The programming paradigm is a subset of software design paradigm.
 3. Programming Paradigm
This paradigm is related closely to programming aspect of software development. This
includes

o Coding – The implementation of software design starts in terms of writing program code in
the suitable programming language and developing error-free executable programs efficiently.
o Testing – Software testing is done while coding by the developers and thorough testing is
conducted by testing experts at various levels of code such as module testing, program testing,
product testing, in-house testing, and testing the product at user’s end.
o Integration – Software may need to be integrated with the libraries, databases, and other
program(s).
Need of Software Engineering
The need of software engineering arises because of higher rate of change in user
requirements and environment on which the software is working.

o Large software - It is easier to build a wall than to a house or building, likewise, as the size of
software become large engineering has to step to give it a scientific process.
o Scalability- If the software process were not based on scientific and engineering concepts, it
would be easier to re-create new software than to scale an existing one.
o Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price
of computer and electronic hardware. But the cost of software remains high if proper process is not
adapted.
o Dynamic Nature- The always growing and adapting nature of software hugely depends upon the
environment in which user works. If the nature of software is always changing, new enhancements
need to be done in the existing one. This is where software engineering plays a good role.
o Quality Management- Better process of software development provides better and quality
software product.
o
Software Engineering Systems Analysis and Design Methodologies

1. Waterfall model or Software Development Life Cycle (SDLC) Model

 The waterfall Model illustrates the software development process in a linear sequential
flow. This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.

 Requirements Gathering and Analysis - All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification
document.

 System Design -The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.

 Implementation or Coding - With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase. Each
unit is developed and tested for its functionality, which is referred to as Unit Testing.

 Integration and Testi4ng - All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.

 Deployment of system - Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.

 Maintenance - There are some issues which come up in the client environment. To fix
those issues, patches are released. Also, to enhance the product some better versions
are released. Maintenance is done to deliver these changes in the customer
environment.
The advantages of waterfall development are that it allows for departmentalization and
control. A schedule can be set with deadlines for each stage of development and a product can
proceed through the development process model phases one by one.

The disadvantage of waterfall development is that it does not allow much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in the concept stage.

When to use the Waterfall Model:

 Requirements are very well known
 When it is possible to produce a stable design
 E.g. a new version of an existing product
 E.g. porting an existing product to a new platform
2. 4th Generation Techniques

The term “fourth generation techniques” (4GT) encompasses a broad array of software tools that
have one thing in common. Each enables the software engineer to specify some characteristic of
software at a high level, the tool then automatically generates source code based on the
developer’s specification.

The 4GT paradigm for software engineering focuses on the ability to specify software
using specialized language forms or a graphic notation that describes the problem to be solved in
terms that the customer can understand.

 Requirements Gathering - This is where the definition of requirements necessary in

building SCAN is defined. The developers used different methods in acquiring
information needed such as interviews and observations and researches.

 Design Strategy - The gathered data is translated into set of presentation that
describes data structures, architectures, algorithmic procedures and interphase
characteristic.

 Implementation using 4GL - This is the third 4GT wherein the design presentation is
translated to an artificial language that result in instruction that could be
executed by the computer. The gathered requirements and design are put
into a machine executable form. The developers would implement using 4GL which
enables them to represent desired output in a manner that results to automatic
generation of code to generate the output. Data structure with relevant information
must exist and be ready accessible by the 4GL.

 Testing - In computer hardware and software development testing is used at key

checkpoints in all overall process to determine whether objectives are being met. This
is required to ensure the system’s quality, reliability and availability when being used.

The Advantages of 4th Generation Techniques is that it is simplified the programming

process, uses non-procedural languages that encourage users and programmers to specify
the results they want, while the computers determine the sequence of instruction that will
accomplish those result and uses natural languages that impose no rigid grammatical rules.
 The Disadvantage of 4th Generation Techniques is that it is less flexible that other
languages and programs written in 4GLs are generally far less efficient during program
execution that programs in high-level languages.

3. The Spiral Model

Spiral Model in software testing is the testing strategy which works on

incremental and prototype technique. Generally Spiral Model strategy is followed for
the large and complicated projects where risks are high and development and
testing goes on incremental basis

 Planning - Requirements are gathered during the planning phase. Requirements like
‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’ that is ‘System
Requirement specifications’.

 Risk Analysis - a process is undertaken to identify risk and alternate solutions. A

prototype is produced at the end of the risk analysis phase. If any risk is found during
the risk analysis then alternate solutions are suggested and implemented.

 Engineering -In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.

 Customer Evaluation - This phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral.

The advantages of spiral method are when costs and risk evaluation is important, it is for
medium to high-risk projects, it is for Long-term project commitment unwise because of potential
changes to economic priorities, if users are unsure of their needs, if the requirements are complex
and it is significant changes are expected (research and exploration).

The disadvantages of spiral methods are it can be a costly model to use, risk analysis requires
highly specific expertise, its project’s success is highly dependent on the risk analysis phase and it
doesn’t work well for smaller projects.

When to use the Spiral Model:

 Creation of prototype is appropriate
 Costs and risk evaluation is important
 For medium to high-risk projects
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected

4. Prototyping Model

The Software Prototyping refers to building software application prototypes which displays
the functionality of the product under development, but may not actually hold the exact logic of the
original software.

Prototyping is used to allow the users evaluate developer proposals and try them out
before implementation. It also helps understand the requirements which are user specific and may
not have been considered by the developer during product design
 Requirements Gathering and refinement- A prototyping model begins with
requirements analysis, and the requirements of the system are defined in detail. The
user is interviewed in order to know the requirements of the system.
  Quick Design - When requirements are known, a preliminary design or quick design for
the system is created, it is not a detailed design, however, and includes the important
aspects of the system, which gives an idea of the system to the user.

 Building Prototype - Information gathering from quick design is modified to form a

prototype. It represents a ’rough’ design of the required system.

 Customer Evaluation Prototype - the proposed system is presented to the user for
consideration as part of the development process.

 Refining Prototype - Once the user evaluates the prototype, it is refined according to
the requirements. When the user is satisfied with the developed prototype, a final
system is developed based on the final prototype.

 Engineer Product - The final system is thoroughly evaluated and tested followed by
routine maintenance on a continuing basis to prevent large-scale failures and to
minimize downtime.

The advantages of prototyping model are it provides a working model to the user early in
the process, enabling early assessment and increasing user confidence, the developer gains
experience and insight by developing a prototype, thereby resulting in better implementation of
requirements, it Helps in reducing risks associated with the project and There is a great
involvement of users in software development.

The disadvantages of prototyping model are if the user is not satisfied with the developed
prototype, then a new prototype is developed. This process goes on until a perfect prototype
evolves. Thus, this model is time consuming and expensive, if the developer loses focus of the real
purpose of prototype and compromises on the quality of the product and Prototyping can lead to
false expectations. It often creates a situation where the user believes that the development of the
system is finished when it is not.

5. Rapid Application Development

Rapid application development (RAD) is both a general term used to refer to alternatives to the
conventional waterfall model of software development as well as the name for James Martin's
approach to rapid development. In general, RAD approaches to software development put less
emphasis on planning and more emphasis on process. In contrast to the waterfall model, which
calls for rigorously defined specification to be established prior to entering the development phase,
RAD approaches emphasize adaptability and the necessity of adjusting requirements in response
to knowledge gained as the project progresses. Prototypes are often used in addition to or
sometimes even in place of design specifications.

The techniques used by RAD models push developers to generate as much high‐quality
code as possible as quickly as possible. One of the driving forces behind RAD is the idea that
things always change. As Heraclitus said, “The only thing that is constant is change.”. RAD
methods take iterative ideas to the extreme. Instead of using iterations lasting a year or two, their
iterations last a month, a week, or even less. Some RAD techniques also apply iteration to
everything, not just to programming. They apply iteration to requirement gathering, requirement
validation, and design.

Most common techniques used in RAD development models:

 Small teams (approximately one‐half a dozen people or fewer). That leads to projects of
limited scope. (Six people probably can’t write a million‐line application in a year.)
 Requirement gathering through focus groups, workshops, facilitated meetings, prototyping,
and brainstorming.
 Requirement validation through iterated prototypes, use cases, and constant customer testing
of designs.
 Repeated customer testing of designs as they evolve.
 Constant integration and testing of new code into the application.
 Informal reviews and communication among team members.
 Short iterations lasting between a few months and as little as a week.
 Deferring complicated features for later releases. Doing just enough work to get the job done.
 Timeboxing, which is RADspeak for setting a tight delivery schedule for producing something,
usually the next iteration of the application. The scope can change (for example, you might
defer a feature to the next iteration), but the completion date for the iteration cannot.

James Martin’s original RAD model uses the following four phases:

Requirements planning - During this phase, the users, executive champion,

management, team leaders, and other stakeholders agree on the project’s general goals and
requirements. The requirements should be specified in a general way so that they don’t restrict
later development unnecessarily. When the stakeholders agree on the requirements and the
project receives approval to continue, the user design phase begins.

User design - The users and team members work together to convert the requirements
into a workable design. They use techniques such as focus groups, workshops, prototyping, and
brainstorming to come up with a workable design. The RAD groups or subgroups typically use a
combination of Joint Application Development (JAD) techniques and CASE tools to translate user
needs into working models. User Design is a continuous interactive process that allows users to
understand, modify, and eventually approve a working model of the system that meets their needs.

Construction - The developers go to work building the application. The users continue to
review the pieces of the application as the developers build them to make corrections and
suggestions for improvements.

Cutover - Resembles the final tasks in the SDLC implementation phase, including data
conversion, testing, changeover to the new system, and user training. The developers deliver the
finished application to the users. (You can use the usual cutover strategies such as staged
delivery, gradual cutover, or incremental deployment.)

The user design and construction phases overlap with the users constantly providing
adjustments to the developers in a sort of continuous feedback loop. The project iterates the user
design and construction phases as needed. When the application has met all the requirements, it is
delivered to the users.

General RAD advantages:

 More accurate requirements. The customers can adjust the requirements as needed during
the project.
 The ability to track changing requirements. If requirements must change (within reason), the
project can start tracking the new requirements in the next iteration.
 Frequent customer feedback and involvement. In addition to helping keep the project on track,
this keeps the users engaged with the project.
 Reduced development time. If everything goes smoothly, you don’t spend as much time
writing requirements in excessive detail.
 Encourages code reuse. One of the key RAD ideas is to do whatever it takes to get the
current iteration done. If an existing piece of code does what you need it to do (or even almost
what you need it to do), timeboxing encourages you to use that code instead of writing
something new.
 Possible early releases with limited functionality.
 Constant testing promotes high‐quality code and eases integration issues.
 Risk mitigation. Before each iteration, you can look for potential risks and handle them.
 Greater chance of success. BDUF projects sometimes spend a lot of time following an
incorrect path before discovering they’re heading in the wrong direction and they need to be
radically redone or even canceled. Frequent increments allow RAD projects to detect and
correct problems quickly before they become insurmountable.
General RAD disadvantages:
 Resistance to change. It can be hard to get existing software engineering groups to adopt
new RAD models, particularly given how odd some of their techniques can seem.
 Doesn’t handle large systems well. Big systems require a lot of effort, and that usually means
a lot of people. The communication overhead alone makes it hard to run large projects in a
RAD model. (If you can partition the project into nicely disconnected pieces, you may have a
chance.)
 Requires more skilled team members. Every team member does not need to be a
programming Obi Wan Kenobi, but small RAD teams can’t include too many complete
beginners.
 Requires access to scarce resources. Frequent customer interaction is essential to keep the
project on track. Often that interaction must be with customers who are experts in their fields,
and those people tend to be in high demand.
 Adds extra overhead if the requirements are known completely and correctly in advance.
 Less managerial control. Many managers have trouble allowing a project to head off in its own
ever‐changing direction.
 Sometimes results in a less than optimal design.
 Unpredictability. Some customers just want to know how much and how long, and they really
aren’t interested in shaping the application throughout its development.

6. Joint Application Development

Joint Application Development (JAD) is a development methodology system originally

used for designing a computer-based system, but can be applied to any development process. It
involves continuous interaction with the users and different designers of the system in
development. JAD centers around a workshop session that is structured and focused. Participants
of these sessions would typically include a facilitator, end users, developers, observers, mediators
and experts. The idea behind JAD is to get all of the key knowledge holders into a room and flush
out a suitable design.

JAD allows for a faster development process and minimizes errors at the same time. JAD
also improves the quality of the final product by focusing on the up-front portion of the development
lifecycle, thus reducing the likelihood of errors that are expensive to correct later on.

In general, the following steps are required in order to have an effective JAD:
 Identify project objectives and limitations
 Identify critical success factors
 Define project deliverables
 Define the schedule of JAD workshop activities
 Select the participants
 Prepare the workshop material
 Organize workshop activities and exercises
 Prepare, inform, educate the workshop participants
 Coordinate workshop logistics. As well as having the right JAD participants (i.e. decision
makers and knowledge holders) it is important to nominate a facilitator for the JAD. The
role of the facilitator is to keep the JAD on target for the JADs objectives. The facilitator
should be independent that is not a designer or a systems requirements provider. Often a
JAD can be bogged down with arguments about alternatives etc. and a strong independent
facilitator is required to keep the session moving towards its goals.