INTRODUCTION TO SOFTWARE ENGINEERING :

SOFTWARE:

The term software engineering is composed of two words, software and engineering. Software is more
than just a program code. A program is an executable code, which serves some computational purpose.
Software is considered to be a collection of executable programming code, associated libraries and
documentations. Software, when made for a specific requirement is called software product.

ENGINEERING:

Engineering on the other hand, is all about developing products, using well-defined, scientific principles
and methods

So, we can define software engineering as an engineering branch associated with the development of
software product using well-defined scientific principles, methods and procedures. The outcome of
software engineering is an efficient and reliable software product.

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.

 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.

 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.

 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.

 Dynamic Nature- The always growing and adapting nature of software hugely depends upon the
environment in which the 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.

 Quality Management- Better process of software development provides better and quality software
product.

CHARACTERESTICS OF GOOD SOFTWARE

A software product can be judged by what it offers and how well it can be used. This software must
satisfy on the following grounds:

 Operational

 Transitional

 Maintenance
Well-engineered and crafted software is expected to have the following characteristics: Operational This
tells us how well software works in operations. It can be measured on:

 Budget

 Usability

 Efficiency

 Correctness

 Functionality

 Dependability

 Security

 Safety

Transitional This aspect is important when the software is moved from one platform to another:

 Portability

 Interoperability

 Reusability

 Adaptability

Maintenance

This aspect briefs about how well a software has the capabilities to maintain itself in the everchanging
environment:

 Modularity

 Maintainability

 Flexibility

 Scalability

In short, Software engineering is a branch of computer science, which uses well-defined engineering
concepts required to produce efficient, durable, scalable, in-budget and on-time software products.

THE EVOLVING ROLE OF SOFTWARE :

Today, software takes on a dual role.

It is a product and, at the same time, the vehicle for delivering a product.

1. Product
2. Vehicle
As a product, it delivers the computing potential embodied by computer hardware or, more broadly, a
network of computers that are accessible by local hardware. Whether it resides within a cellular phone
or operates inside a mainframe computer, software is an information transformer—producing,
managing, acquiring, modifying, displaying, or transmitting information that can be as simple as a
single bit or as complex as a multimedia presentation.

As the vehicle used to deliver the product, software acts as the basis for the control of the computer
(operating systems), the communication of information (networks), and the creation and control of
other programs (software tools and environments).

Software delivers the most important product of our time—information. Software transforms personal
data (e.g., an individual’s financial transactions) so that the data can be more useful in a local context;
it manages business information to enhance competitiveness;

it provides a gateway to worldwide information networks (e.g., Internet) and provides the means for
acquiring information in all of its forms. The role of computer software has undergone significant change
over a time span of little more than 50 years.

Dramatic improvements in hardware performance, profound changes in computing architectures, vast

increases in memory and storage capacity, and a wide variety of exotic input and output options have all
precipitated more sophisticated and complex computer-based systems.

The lone programmer of an earlier era has been replaced by a team of software specialists, each
focusing on one part of the technology required to deliver a complex application.

THE CHANGING NATURE OF SOFTWARE

• Seven Broad Categories of software are challenges for software engineers

1. System Software
2. Application software
3. Engineering/scientific software
4. Embedded software
5. Product-line software
6. Web Application
7. Artificial intelligence software

System Software: It is a collection of programs written to service other programs. Some system
software are compilers, editors, file management utilities. They process complex but determinate
information structure. Other system applications can be operating system components, drivers,
networking software. They process largely indeterminate data. In either case the system software area
is characterized by heavy interaction with computer hardware, heavy usage by multiple users,
concurrent operation that requires scheduling, resource sharing, and sophisticated process
management, complex data structure, and multiple external interfaces.

2. Application software: These consist of standalone programs that solve a specific business need.
Applications in this area process business or technical data in a way that facilitates business
operations or management/technical decision making. These are used to control business functions
in real time.
3.: Engineering/scientific software These software range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics and from molecular biology to automated
manufacturing.

4. Embedded software: These software resides within a product or system and is used to implement
and control features and functions for the end user and for the system itself. These software can
perform limited and esoteric functions or provide significant function and control capability.

Product-line software focus on a limited marketplace to address mass consumer market. (word
processing, graphics, database management)

Web Application: It is a client-server computer program which the client runs on the web browser. In
their simplest form, Web apps can be little more than a set of linked hypertext files that present
information using text and limited graphics. However, as e-commerce and B2B application grow in
importance. Web apps are evolving into a sophisticate computing environment that not only provides a
standalone feature, computing function, and content to the end user.

Artificial intelligence software- Artificial intelligence (AI) software makes use of nonnumeric algorithms
to solve complex problems. Application within this area include robotics, pattern recognition, game
playing

Software Engineering | Software Process Framework

Software Process Framework is an abstraction of the software development process.
It details the steps and chronological order of a process. Since it serves as a foundation
for them, it is utilized in most applications. Task sets, umbrella activities, and process
framework activities all define the characteristics of the software development process.

Software process includes:

 Tasks – focus on a small, specific objective.

 Action – set of tasks that produce a major work product.
 Activities – group of related tasks and actions for a major objective.
Software Process Framework

Process Framework Activities:

The process framework is required for representing common process activities. Five
framework activities are described in a process framework for software engineering.
Communication, planning, modeling, construction, and deployment are all examples of
framework activities. Each engineering action defined by a framework activity comprises a
list of needed work outputs, project milestones, and software quality assurance (SQA)
points.

 Communication: By communication, customer requirement gathering is done.

Communication with consumers and stakeholders to determine the system’s
objectives and the software’s requirements.
 Planning: Establish engineering work plan, describes technical risk, lists
resources requirements, work produced and defines work schedule.
 Modeling: Architectural models and design to better understand the problem and
for work towards the best solution. The software model is prepared by:
 o Analysis of requirements
o Design
 Construction: Creating code, testing the system, fixing bugs, and confirming that
all criteria are met. The software design is mapped into a code by:
o Code generation
o Testing
 Deployment: In this activity, a complete or non-complete product or software is
represented to the customers to evaluate and give feedback. On the basis of their
feedback, we modify the product for the supply of better products.

Umbrella activities:
Umbrella Activities are that take place during a software development process for
improved project management and tracking.

1. Software project tracking and control: This is an activity in which the

team can assess progress and take corrective action to maintain the schedule.
Take action to keep the project on time by comparing the project’s progress
against the plan.
2. Risk management: The risks that may affect project outcomes or quality
can be analyzed. Analyze potential risks that may have an impact on the
software product’s quality and outcome.
3. Software quality assurance: These are activities required to maintain
software quality. Perform actions to ensure the product’s quality.
4. Formal technical reviews: It is required to assess engineering work
products to uncover and remove errors before they propagate to the next
activity. At each level of the process, errors are evaluated and fixed.
5. Software configuration management: Managing of configuration
process when any change in the software occurs.
6. Work product preparation and production: The activities to create
models, documents, logs, forms, and lists are carried out.
7. Reusability management: It defines criteria for work product reuse.
Reusable work items should be backed up, and reusable software components
should be achieved.
8. Measurement: In this activity, the process can be defined and collected.
Also, project and product measures are used to assist the software team in
delivering the required software.

SOFTWARE ENGINEERING PRACTICES:

The Essence of Practice

1. Understand the problem

2. Plan a solution

3. Carry out the plan

4. Examine the result for accuracy

1) Understand the Problem:

1. Who has a stake in the solution to the problem?

2. What are the unknowns?
3. Can the problem be compartmentalized?
4. Can the problem be represented graphically?

2) Plan the Solution

1. Has a similar Have you seen similar problems before?

2. problem been solved? If so, are elements of the solution reusable?
3. Can sub problems be defined? If so, are solutions readily apparent for the sub problems?
4. Can you represent a solution in a manner that leads to effective implementation? Can a design
model be created?

3) Carry Out the Plan

Does the solution conform to the plan? Is source code traceable to the design model? Is each
component part of the solution provably correct? Has the design and code been reviewed, or better,
have correctness proofs been applied to algorithm?

4) Examine the Result

1. Is it possible to test each component part of the solution? Has a reasonable testing
strategy been implemented?
2. produce results that conform to the data, functions, and Does the solution features that
are required?
3. Has the software been validated against all stakeholder requirements?

Software Engineering Principles:

1) The Reason It All Exists- A software system exists for one reason: to provide value to its users. All
decisions should be made with this in mind. Before specifying a system requirement, before noting a
piece of system functionality, before determining the hardware platforms or development processes,
ask yourself questions such as: “Does this add real value to the system?” If the answer is “no,” don’t
do it.
2) The Second Principle: KISS (Keep It Simple, Stupid!) - All design should be as simple as possible, but
no simpler. This is not to say that features, even internal features, should be discarded in the name of
simplicity. Simple also does not mean “quick and dirty”.

3) The Third Principle: Maintain the Vision - A clear vision is essential to the success of a software
project. Without one, a project almost unfailingly ends up being “of two [or more] minds” about itself.
Without conceptual integrity, a system threatens to become a patch work of incompatible designs,
held together by the wrong kind of screws Compromising the architectural vision of a software
system
weakens and will eventually break even the well-designed systems. Having an empowered architect who
can hold the vision and enforce compliance helps ensure a very successful software project.

4) The Fourth Principle: What You Produce, Others Will Consume –In some way, someone else will use,
maintain, document, or otherwise depend on being able to understand your system. So, always specify,
design, and implement knowing someone else will have to understand what you are doing. Making user
job easier adds value to the system.

5) The Fifth Principle: Be Open to the Future - A system with a long lifetime has more value. In today’s
computing environments, where specifications change on a moment’s notice and hardware platforms
are obsolete just a few months old, software lifetimes are typically measured in months instead of
years. However, true “industrial-strength” software systems must endure far longer. To do this
successfully, these systems must be ready to adapt to these and other changes. Systems that do this
successfully are those that have been designed this way from the start. Never design yourself into a
corner. Always ask “what if,” and prepare for all possible answers by creating systems that solve the
general problem, not just the specific one. This could very possibly lead to the reuse of an entire
system.

6) The Sixth Principle: Plan Ahead for Reuse - Reuse saves time and effort. The reuse of code and
designs has been major benefit of using object-oriented technologies. However, the return on this
investment is not automatic. To leverage the reuse possibilities that object-oriented [or conventional]
programming provides requires forethought and planning. There are many techniques to realize
reuse at every level of the system development process Planning ahead for reuse reduces the
cost and
increases the value of both the reusable components and the systems into which they are incorporated.

7) The Seventh principle: Think! - Placing clear, complete thought before action almost always produces
better results. When you think about something, you are more likely to do it right. You also gain
knowledge about how to do it right again. If you do think about something and still do it wrong, it
becomes a valuable experience. A side effect of thinking is learning to recognize when you don’t know
something, at which point you can research the answer. When clear thought has gone into a system,
value comes out. If every software engineer and every software team simply followed Hooker’s seven
principles, many of the difficulties we experience in building complex computer based systems would be
eliminated.

Software Myths:
Most, experienced experts have seen myths or superstitions (false beliefs or interpretations) or
misleading attitudes (naked users) which creates major problems for management and technical
people. The types of software-related myths are listed below.
 `Types of Software Myths

(i) Management Myths:

Myth 1:
We have all the standards and procedures available for software development.
Fact:
 Software experts do not know all the requirements for the software development.
 And all existing processes are incomplete as new software development is based on new and
different problem.
Myth 2:
The addition of the latest hardware programs will improve the software development.
Fact:
 The role of the latest hardware is not very high on standard software development; instead
(CASE) Engineering tools help the computer, they are more important than hardware to produce
quality and productivity.
 Hence, the hardware resources are misused.
Myth 3:
 With the addition of more people and program planners to Software development can help
meet project deadlines (If lagging behind).
Fact:
 If software is late, adding more people will merely make the problem worse. This is because the
people already working on the project now need to spend time educating the newcomers, and
are thus taken away from their work. The newcomers are also far less productive than the
existing software engineers, and so the work put into training them to work on the software
does not immediately meet with an appropriate reduction in work.
(ii)Customer Myths:
The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customer has myths leading to false expectations (customer) &
that’s why you create dissatisfaction with the developer.
Myth 1:
A general statement of intent is enough to start writing plans (software development) and details of
objectives can be done over time.
Fact:
 Official and detailed description of the database function, ethical performance, communication,
structural issues and the verification process are important.
 Unambiguous requirements (usually derived iteratively) are developed only through effective
and continuous
communication between customer and developer.
Myth 2:
Software requirements continually change, but change can be easily accommodated because
software is flexible
Fact:
 It is true that software requirements change, but the impact of change varies with the time at
which it is introduced. When requirements changes are requested early (before design or code
has been started), the cost impact is relatively small. However, as time passes, the cost impact
grows rapidly—resources have been committed, a design framework has been established, and
change can cause upheaval that requires additional resources and major design modification.

Different Stages of Myths

(iii) Practitioner’s Myths:

Myths 1:
They believe that their work has been completed with the writing of the plan .
Fact:
 It is true that every 60-80% effort goes into the maintenance phase (as of the latter software
release). Efforts are required, where the product is available first delivered to customers.
Myths 2:
There is no other way to achieve system quality, until it is “running”.
Fact:
 Systematic review of project technology is the quality of effective software verification method.
These updates are quality filters and more accessible than test.
Myth 3:
An operating system is the only product that can be successfully exported project.
Fact:
 A working system is not enough, the right document brochures and booklets are also required
to provide guidance & software support.
Myth 4:
Engineering software will enable us to build powerful and unnecessary document & always delay us.
Fact:
 Software engineering is not about creating documents. It is about creating a quality product.
Better quality leads to reduced rework. And reduced rework results in faster delivery times

Introduction to Generic Process Model

Generic Process Model is a definitive description of processes. Generic Processes are designed to run

outside a normal component or on an application processor. These processes are not specific to any

particular component, can be used in any number of applications. Generic Process Model consists of 5

activities which will be discussed in this article. The software process is a collection of various activities.

These activities include communication, planning, modeling, construction, and deployment. Each of

these activities includes a set of engineering actions and each action defines a set of tasks that

incorporate work products, project milestones, and SQA, Software Quality Assurance points. Let us dig

deeper into this Generic Process Model and will go through the working process, its advantages, and

disadvantages.

How does the Generic process model work?

Generic Process model includes the below five framework activities,

 Communication: This is the first step in the software development

process which starts with the communication between the

customer and the developer.

  Planning: This step consists of a complete estimation of the

project, scheduling for development of the project, and tracking.

 Modeling: This step consists of complete requirement analysis

and project design like algorithm, flowchart, etc.

The algorithm is a step-by-step process of the problem and the

flowchart will show the flow of the program.

 Construction: This step consists of code generation and

its testing. Coding will implement the design details

using appropriate programming languages.

Testing checks if the program or the code provides expected output,

and also checks whether the flow of the code is correct or not.

 Deployment: This step consists of delivering the final product to

the customer and take feedback. If there are any suggestions or

addition of other capabilities, then this change is required for

improvement in software quality.

These five framework activities are used for all software developments

independent of the application domain, the size of the project,

complexity or the efforts, etc. For most of the software projects, these

framework activities are applied iteratively where each of the iterations

produces a subset of the overall functionality and features of the

software

There are Types of Process flow available such as,

 Linear process flow: It executes each activity listed above

in sequence form
 Iterative Process flow: This flow repeats one or more activities

that are listed above before starting the next activity.

 Evolutionary Process flow: This flow carries out the activities

listed above in a circular manner. Each circle leads to the more

complete version of the software
 Parallel process flow: This flow executes the activities listed

above in parallel with each other i.e. modeling for one aspect of

the software in parallel to another aspect of the software.

 PROCESS ASSESMENT AND IMPROVEMENT
 A number of different approaches to software process assessment and improvement have
been proposed
 over the past few decades:
 ➢ Standard CMMI Assessment Method for Process Improvement (SCAMPI) — provides
 a five step process assessment model that incorporates five phases: initiating, diagnosing,
 establishing, acting and learning.
 ➢ CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a
 diagnostic technique for assessing the relative maturity of a software organization; uses
 the SEI CMM as the basis for the assessment.
 ➢ SPICE—The SPICE (ISO/IEC15504) standard defines a set of requirements for
 software process assessment. The intent of the standard is to assist organizations in
 developing an objective evaluation of the efficacy of any defined software process.
 ➢ ISO 9001:2000 for Software—a generic standard that applies to any organization that
 wants to improve the overall quality of the products, systems, or services that it provides.
 Therefore, the standard is directly applicable to software organizations and companies.
Process model
Software life cycle Models

What are software life cycle models?

A software life cycle model (also termed process model) is a pictorial and diagrammatic representation
of the software life cycle. A life cycle model represents all the methods required to make a software
product transit through its life cycle stages

Software Development Life Cycle (SDLC)

SDLC is a process followed for a software project, within a software organization. It consists of
a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
The following figure is a graphical representation of the various stages of a typical SDLC.
A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by
the senior members of the team with inputs from the customer, the sales department, market
surveys and domain experts in the industry. This information is then used to plan the basic
project approach and to conduct product feasibility study in the economical, operational and
technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the
project is also done in the planning stage. The outcome of the technical feasibility study is to
define the various technical approaches that can be followed to implement the project
successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product
requirements and get them approved from the customer or the market analysts. This is done
through an SRS (Software Requirement Specification) document which consists of all the
product requirements to be designed and developed during the project life cycle.
Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best architecture for the product
to be developed. Based on the requirements specified in SRS, usually more than one design
approach for the product architecture is proposed and documented in a DDS - Design Document
Specification.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming
code is generated as per DDS during this stage. If the design is performed in a detailed and
organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming
tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high
level programming languages such as C, C++, Pascal, Java and PHP are used for coding. The
programming language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing
activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing
only stage of the product where product defects are reported, tracked, fixed and retested, until the
product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate
market. Sometimes product deployment happens in stages as per the business strategy of that
organization. The product may first be released in a limited segment and tested in the real
business environment (UAT- User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested enhancements
in the targeting market segment. After the product is released in the market, its maintenance is
done for the existing customer base.

SDLC Models
There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred as Software
Development Process Models". Each process model follows a Series of steps unique to its type
to ensure success in the process of software development.
Following are the most important and popular SDLC models followed in the industry −

 Waterfall Model
 Incremental process models
 Evolutionary process model
  Concurrent model

The Waterfall Model was the first Process Model to be introduced. It is also referred to
as a linear-sequential life cycle model. It is very simple to understand and use. In a
waterfall model, each phase must be completed before the next phase can begin and
there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software
development.

Waterfall Model - Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of
software development is divided into separate phases. In this Waterfall model, typically,
the outcome of one phase acts as the input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall
Model.

The sequential phases in Waterfall model are −

 Requirement 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 − 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 Testing − 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.

Waterfall Model - Application

 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the
product.
 The project is short.

Waterfall Model – Advantages

 Simple and easy to understand and use

 Works well for smaller projects where requirements are very well
understood.
 Clearly defined stages.
  Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

Waterfall Model - Disadvantages

The major disadvantages of the Waterfall Model are as follows −
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.

Incremental Model

Incremental Model is a process of software development where

requirements divided into multiple standalone modules of the software
development cycle. In this model, each module goes through the
requirements, design, implementation and testing phases. Every
subsequent release of the module adds function to the previous release.
The process continues until the complete system achieved.
The various phases of incremental model are as
follows:
1. Requirement analysis: In the first phase of the incremental model, the
product analysis expertise identifies the requirements. And the system
functional requirements are understood by the requirement analysis team.
To develop the software under the incremental model, this phase performs
a crucial role.

2. Design & Development: In this phase of the Incremental model of SDLC,

the design of the system functionality and the development method are
finished with success. When software develops new practicality, the
incremental model uses style and development phase.
3. Testing: In the incremental model, the testing phase checks the
performance of each existing function as well as additional functionality. In
the testing phase, the various methods are used to test the behavior of
each task.

4. Implementation: Implementation phase enables the coding phase of the

development system. It involves the final coding that design in the
designing and development phase and tests the functionality in the testing
phase. After completion of this phase, the number of the product working is
enhanced and upgraded up to the final system product

When we use the Incremental Model?

o When the requirements are superior.

o A project has a lengthy development schedule.

o When Software team are not very well skilled or trained.

o When the customer demands a quick release of the product.

o You can develop prioritized requirements first.

Advantage of Incremental Model

o Errors are easy to be recognized.

o Easier to test and debug

o More flexible.

o Simple to manage risk because it handled during its iteration.

o The Client gets important functionality early.

Disadvantage of Incremental Model

o Need for good planning

o Total Cost is high.

 o Well defined module interfaces are needed.

RAD (Rapid Application Development)

Model
RAD is a linear sequential software development process model that
emphasizes a concise development cycle using an element based
construction approach. If the requirements are well understood and
described, and the project scope is a constraint, the RAD process enables a
development team to create a fully functional system within a concise time
period.

RAD (Rapid Application Development) is a concept that products can be

developed faster and of higher quality through:

o Gathering requirements using workshops or focus groups

o Prototyping and early, reiterative user testing of designs

o The re-use of software components

o A rigidly paced schedule that refers design improvements to the next

product version

o Less formality in reviews and other team communication

The various phases of RAD are as follows:
1. Business Modelling: The information flow among business functions is
defined by answering questions like what data drives the business process,
what data is generated, who generates it, where does the information go,
who process it and so on.
2. Data Modelling: The data collected from business modeling is refined
into a set of data objects (entities) that are needed to support the
business.
The attributes (character of each entity) are identified, and the relation
between these data objects (entities) is defined.

3. Process Modelling: The information object defined in the data

modeling phase are transformed to achieve the data flow necessary to
implement a
business function. Processing descriptions are created for adding, modifying,
deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate

construction of the software; even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have

already been tested since RAD emphasis reuse. This reduces the overall
testing time. But the new part must be tested, and all interfaces must be
fully exercised.

When to use RAD Model?

o When the system should need to create the project that modularizes in a
short span time (2-3 months).

o When the requirements are well-known.

o When the technical risk is limited.

o When there's a necessity to make a system, which modularized in 2-3

months of period.

o It should be used only if the budget allows the use of automatic code
generating tools.
Advantage of RAD Model
o In this model, changes are adoptable.

o Each phase in RAD brings highest priority functionality to the customer.

o It reduced development time.

o It increases the reusability of features.

Disadvantage of RAD Model

o All application is not compatible with RAD.

o For smaller projects, we cannot use the RAD model.

o On the high technical risk, it's not suitable.

o Required user involvement.

 Evolutionary model is a combination of Iterative and Incremental model

of software development life cycle. Delivering your system in a big bang
release, delivering it in incremental process over time is the action done in
this model. Some initial requirements and architecture envisioning need to
be done.
 Evolutionary model suggests breaking down of work into smaller chunks,
prioritizing them and then delivering those chunks to the customer one by one.
The number of chunks is huge and is the number of deliveries made to the
customer.

Application of Evolutionary Model:

1. It is used in large projects where you can easily find modules for
incremental implementation. Evolutionary model is commonly used when
the customer wants to start using the core features instead of waiting for
the full software.
2. Evolutionary model is also used in object oriented software development
because the system can be easily portioned into units in terms of objects.

Necessary conditions for implementing this model:-

  Customer needs are clear and been explained in deep to the developer team.
 There might be small changes required in separate parts but not a major
change.
 As it requires time, so there must be some time left for the market
constraints.
 Risk is high and continuous targets to achieve and report to customer
repeatedly.
 It is used when working on a technology is new and requires time to learn.

Advantages:

 In evolutionary model, a user gets a chance to experiment partially

developed system.
 It reduces the error because the core modules get tested thoroughly.

Disadvantages:

 Sometimes it is hard to divide the problem into several versions that

would be acceptable to the customer which can be incrementally
implemented and delivered

Following are the evolutionary process models.

1. The prototyping model

2. The spiral model
3. Concurrent development model

1. The Prototyping model

 Prototype is defined as first or preliminary form using which other

forms are copied or derived.
 Prototype model is a set of general objectives for software.
 It does not identify the requirements like detailed input, output.
 It is software working model of limited functionality.
 In this model, working programs are quickly produced.
The different phases of Prototyping model are:

1. Communication
In this phase, developer and customer meet and discuss the overall objectives
of the software.

2. Quick design

 Quick design is implemented when requirements are known.

 It includes only the important aspects like input and output format of
the software.
 It focuses on those aspects which are visible to the user rather than
the detailed plan.
 It helps to construct a prototype.
3. Modeling quick design

 This phase gives the clear idea about the development of

software because the software is now built.
 It allows the developer to better understand the exact requirements.
4. Construction of prototype
The prototype is evaluated by the customer itself.

5. Deployment, delivery, feedback

 If the user is not satisfied with current prototype then it

refines according to the requirements of the user.
 The process of refining the prototype is repeated until all
the requirements of users are met.
 When the users are satisfied with the developed prototype then
the system is developed on the basis of final prototype.
Advantages of Prototyping Model

 Prototype model need not know the detailed input, output,

processes, adaptability of operating system and full machine
interaction.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies
the confusing or difficult functions.
Disadvantages of Prototyping Model:

 The client involvement is more and it is not always considered by

the developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a thrown away prototype when the users are confused with it.

The Spiral model

 Spiral model is a risk driven process model.

 It is used for generating the software projects.
  In spiral model, an alternate solution is provided if the risk is found
in the risk analysis, then alternate solutions are suggested and
implemented.
 It is a combination of prototype and sequential model or waterfall model.
 In one iteration all activities are done, for large project's the output
is small.
The framework activities of the spiral model are as shown in the
following figure.

NOTE: The description of the phases of the spiral model is same as that of the
process model.

Advantages of Spiral Model

 It reduces high amount of risk.

 It is good for large and critical projects.
 It gives strong approval and documentation control.
 In spiral model, the software is produced early in the life cycle process.
Disadvantages of Spiral Model

 It can be costly to develop a software model.

The concurrent development model
• The concurrent development model is called as concurrent model.

• The communication activity has completed in the first iteration and exits in the awaiting changes state.

• The modeling activity completed its initial communication and then go to the underdevelopment
state.

• If the customer specifies the change in the requirement, then the modeling activity moves from the
under

development state into the awaiting change state.

• The concurrent process model activities moving from one state to another state.

Advantages of the concurrent development model

• This model is applicable to all types of software development processes.

• It is easy for understanding and use.

• It gives immediate feedback from testing.

• It provides an accurate picture of the current state of a project.

Disadvantages of the concurrent development model

• It needs better communication between the team members. This may not be achieved all the time.

• It requires to remember the status of the different activities.