www.gagnesharora.

com

Software Engineering:

Definition 1:

Software Engineering is the application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance of software; that is, the
application of engineering to software.

Definition 2:

Software engineering is the establishment and use of sound engineering principles in

order to obtain economically software that is reliable and work efficiently on real
machine.

Definition 3:

A discipline whose aim is the production of quality software, software that is delivered
on time, within budget, and that satisfies its requirements.

Software Crisis:
Software crisis is characterized by inability to develop the desired Software Project because
of such problems:

• Projects running over-budget.

• Projects running over-time.
• Software is inefficient.
• Software is of low quality.
• Software does not meet requirements.
• Project is unmanageable/ Code difficult to maintain.

The roots of the software crisis are complexity, expectations, and change. To avoid
software crisis, software engineering principles and process are applied strictly.

Software Development Life Cycle Models (SDLC):

• Build and Fix Model

• Waterfall Model
• Iterative Enhancement Model
• Rapid Application Development Model
• Prototype Model
• Spiral Model
 www.gagnesharora.com

Build and Fix Model:

It is the simplest model; there is no specification and design phase in this model. In this
model code is built and used; and if there is an error or requires an enhancement then
developer fix it. Cycle of use and fix remain continue till all problems are resolved as shown
in the diagram below. This model can be implemented only when project size is very small.
 www.gagnesharora.com

Waterfall Model:

The waterfall model, sometimes called the classic life cycle model suggests a systematic,
sequential approach to software development. This model is named “Waterfall Model”,
because its diagrammatic representation resembles waterfall.

Requirement analysis and specification phase:

The goal of this phase is to understand the exact requirements of the customer and to
document them properly. This activity is usually executed together with the customer, as the
goal is to document all functions, performance and interfacing requirements for the software.
These requirement describe the “what” of a system, not the “how”. This phase produces a
large document, written in a natural language, contains a description of what the system will
do without describing how it will be done. The resultant document is known as software
requirement specification (SRS) document. This SRS document may act as contract between
the developer and the customer.

Design phase:
The goal of this phase is to transform the requirements specifications into a structure that is
suitable for implementation in some programming language. Design phase focuses on four
distinct attributes of a program: software architecture, data structure, procedural detail,
interface representations. This work is documented and known as software design description
(SDD) document. The information contained in the SDD should be sufficient to begin the
Implementation phase.

Coding and unit testing phase:

The design must be translated to into a machine-readable form. Use of appropriate
programming language is important activity in this phase. If SDD is complete, the coding
phase proceeds smoothly, because all information needed by the software developers is
contained in SDD. After coding individual modules are tested and this testing called unit
testing. Testing is an activity in which the error in the program are identified and removed.
During testing it is necessary to test the given set of input whether producing correct output
or not.

Integration and System Testing:

In this phase, all the modules of the software are integrated and System testing takes place.
System testing involves the testing of the entire system, because through this it can be found
that the interfaces between the different modules are also functionally correct or not.

Maintenance Phase:
When software is installed on the customer’s site, maintenance phase starts. The maintenance
is a broad activity which includes: error correction, optimization of the product, software
capabilities enhancement and small modifications in the software with time.
 www.gagnesharora.com

Requirement
Analysis and
specifications

Design Phase

Coding and Unit

Testing Phase

Integration and
System testing

Operation and
Maintenance Phase

Waterfall Model

Advantages:

• This model is linear, so it is easy to implement.

• Documentation is produced at every stage of the waterfall model. This makes the
understanding of the process simpler.
• In this model, every phase has a defined start and end point, and progress can be
conclusively identified by both vendor and client.
• The emphasis on requirements and design before writing a single line of code ensures
minimal wastage of time and effort.
 www.gagnesharora.com

Disadvantages:

• This model expects complete and accurate requirements early in the process, which is
unrealistic.
• In this model, we cannot go back, if the design phase has gone wrong, things can get
very complicated in the implementation phase.
• Risk factor is not included in this model
• The greatest disadvantage of the waterfall model is that until the final stage of the
development cycle is complete, a working model of the software does not lie in the
hands of the client
 www.gagnesharora.com

Prototype model:

In this model, a working prototype is developed before developing the actual software. When
prototype is created, it is reviewed by the customer and gives feedback to the developer that
helps to remove uncertainties in the requirements of the software, and an iteration of
refinement is started in order to further clarify requirements as shown in the diagram. After
the finalization of software requirement and specification (SRS) document, the prototype is
discarded and actual system is then developed using the Waterfall approach. Thus, it is used
as an input to waterfall model and produces maintainable and good quality software.

Requirements

Quick Design

Refinement of
requirements as per
Implement suggestion

Customer Evaluation
Not accepted by customer
Accepted by customer

Design

Coding and Unit

Testing Phase

Integration and System

testing

Prototype Model
Operation and
Maintenance Phase
 www.gagnesharora.com

Iterative Enhancement Model:

The model has the same phases as the waterfall model, but development is done in several
cycles. During the first requirements analysis phase, customers and developers specify as
many requirements as possible and prepare a SRS document. Developers and customer then
prioritize these requirements. And on the basis of these priorities, the complete product is
divided into releases, and developer deliver the product release by release and at every
release, customer has an operational quality product that does a portion of what is required.
With this model, the customer is able to do some useful work even after first release.

Requirments

Implementation Integration and

Design and Unit testing System testing Operation

Release I

Implementation Integration and

Design and Unit testing System testing Operation

Release II

Implementation Integration and

Design and Unit testing System testing Operation

Release III

Iterative Enhancement Model

 www.gagnesharora.com

Spiral Model:

The spiral model, originally proposed by Boehm, is an evolutionary software process model
that couples the iterative nature of prototype with the Risk factor. Project Risks are ignored
in the earlier models which are the main reasons of software project’s failure. By using spiral
model projects are developed through many cycles or phases and each phase is split into four
major sectors or task regions.

Planning: Determination of objectives and alternatives.

Risk analysis: identification of risks and resolve the risk.

Development: Product development and testing product.

Assessment: Customer evaluation.

 www.gagnesharora.com

Introduction to Object Oriented Methodology:

OO Methodology is a process to develop software using some well-defined stages and every
stage includes OO data models. The stages are:

System Conception:

System conception deals with the genesis of an application. Initially some person, who
understands both business needs and technology, thinks of an idea for application. Developer
must then explore the idea to understand the needs and devise possible solutions. The purpose
of system conception is to know what need does the proposed system meet and the result of
system justify the cost of building it.

Analysis:

Analysis focuses on preparing models to get a deep understanding of the requirements. the
goal of analysis is to specify what need to be done, not how it is done. It is important to
consider all available inputs, including requirements statements, user interviews, real-world
experience, and artifacts from related systems. The output from analysis is a set of models
that specify a system in a rigorous and complete manner. There are two sub stages to
analysis: domain analysis and application analysis. The domain analysis is a description of
the real-world objects reflected within the system; and the application analysis is addresses
the computer aspects of the application that are visible to users.

Design:

Analysis addresses the what of an application: design addresses the how. Once we have a
thorough understanding of an application from analysis, we are ready to deal with the details
of building a practical and maintainable solution. Design then becomes a process of adding
details and making fine decisions. There are two sub stages to design: system design and
class design.

In System Design, the development team devises a high-level strategy- the system
architecture- for solving the application problem. The system designer must decide what
performance characteristics to optimize and choose a strategy of attacking the problem.

In class Design, details are added to the analysis model in accordance with the system design
strategy. The class designer elaborates both domain and application models.

Implementation:

Implementation is the stage for writing the actual code. Developers map design elements to
programming language and database code.
 www.gagnesharora.com

All the above stages include graphical notations called UML (Unified Modeling Language)
and these notations represent data models. These data models are used to describe a system.

Class model:
The class model describes the static structure of the objects in a system and their
relationships. The class model contains class diagrams.

State model:
The state model describes the aspects of an object that change over time. The state diagram is
a graph whose nodes are states and whose arcs are transitions between states caused by
events.

Interaction model:
The interaction model describes how the objects in a system cooperate to achieve broader
results. The interaction model starts with use cases then elaborated with sequence and activity
diagram.
 www.gagnesharora.com

Overview of Requirements Elicitation:

In requirements engineering, requirements elicitation is the practice of obtaining the

requirements of a system from users and customers. The real requirement actually resides in
user’s mind; and Requirements elicitation is to find out what users really need. Requirements
elicitation is perhaps the most difficult, most critical, most error-prone, and most
communication intensive aspect of software development. Elicitation can succeed only
through an effective customer-developer partnership. Requirements elicitation is a part of the
requirements engineering process, usually followed by Requirement analysis and
Requirement documentation.

Requirements elicitation techniques/ Requirements elicitation Activities/

Managing Requirements elicitation

• Interviews
• Brainstorming Sessions
• Facilitated Application Specification Technique (FAST)
• Quality Function Deployment (QFD)
• Use Case

Interview:

After receiving the problem statement from the customer, the first step is to arrange a meeting
with the customer. During the meeting or interview, both the parties would like to understand
each other. Normally specialized developers often called ‘requirement engineers’ interact
with the customer. The objective of conducting an interview is to understand the customer’s
expectations from the software. It will be impossible to interview every stakeholder. Thus
representatives from groups must be selected based on technical expertise, domain
knowledge, credibility and accessibility. During interview questions should be simple and
short.

Brainstorming Sessions:

Brainstorming has become very popular and is being used by most of the companies. It is a
group technique that may be used during requirements elicitation to understand the
requirements. The group discussions promote creative thinking, generate new ideas and
provide platforms to share views. Brainstorming Sessions technique may be carried with
requirement engineers, actual uses, middle level managers or total stake holders.
 www.gagnesharora.com

Facilitated Application Specification Technique (FAST):

This approach is similar to brainstorming session. The objective of the approach is to bridge
the expectation gap – a difference between what developers think they are supposed to build
and what customers think they are going to get. In order to reduce expectation gap, a team
oriented approach is developed for requirement elicitation and is called Facilitated
Application Specification Technique (FAST). In this technique, meeting is conducted at some
neutral site which is attended both by developers and customers. The meeting is controlled by
a facilitator. Participants also agree not to debate. Each participant presents his or her list of
objectives and services required, and these lists are displayed in the meeting. Discussions are
held on these objectives and services. And after this, combined lists for these topics are
prepared by eliminating redundant entries and adding new ideas. And the same process is
repeated many times and many sessions are held for this; till a consensus (agreement) is
reached.

Quality Function Deployment (QFD):

It is one of the Requirement elicitation techniques and it used to find out the requirements
that enhance the quality of the Software Product. Here, in QFD Prime concern is the
customer satisfaction and emphasizes on the requirements which are valuable to the customer
and to add these valuable requirements to the SRS. To satisfy the customer needs, in QFD
technique, every requirement can be given some value on a scale of 1 to 5 according to their
importance to the customer. And in QFD, it has been suggested that Quality in the software
product is achieved if we fulfill following requirements:

Normal requirement: The objective and goals of the proposed software comes under the
category of Normal requirements and these normal requirements must be fulfilled. e.g. entry
of the marks, calculation of the marks, reports generation are the Normal requirements for the
result management system.

Expected requirements: Expected requirements are implicit requirements, and customers do

not state them explicitly. e.g. for wrong entry of data, there must be proper message, and
protection from unauthorized access is also an expected requirement.

Exciting requirement: Exciting requirements are the requirements which go beyond the
customer’s expectations and prove to very satisfy when present. In Result Management
System, if reports can be generated in various formats; even customers have not demanded,
and this type of requirement is called exciting requirement and enhance the quality of
product.
 www.gagnesharora.com

Use case Approach:

Use case approach is the one of approach of Requirement Elicitation in which interaction
between the user and proposed software system is studied to find out Requirements for the
proposed system. The terms use case, use case scenario, and use case diagram are used
interchangeably but they have different meanings as given below.

Use case scenario: use scenario is the unstructured description of user requirements. e.g. If
we explain the interaction between the user and system as a story description.

Use case: use case is the structured description of user requirements. e.g. if we represent all
the interaction in a template or in a table for requirement elicitation.

Use case diagram: use case diagram are graphically represent of interaction between the user
and system so that requirements can be elicited. Use case diagram for Result Management is
given by:

Marks Entry

Subject Entry

Student info

Entry Student
Data Entry
Operator

Marks view

Result Management System

 www.gagnesharora.com

Introduction to Unified Modeling Language:

James Rumbaugh, Grady Booch and Ivar Jacobson are the main contributors in developing
Unified Modeling Language. In every stage in Object Oriented Software Development, there
are Object Oriented Models (Class, State and interaction Model) and the language of these
models is UML.

UML is used to visualize, specify, construct and document the artifacts (Requirements,
Architecture, Design, Source code, Project plans, Tests, Prototype, Releases etc.) of a
software-intensive system. UML is a standard language for writing software blueprints.

The UML is appropriate for modeling systems ranging from enterprise information systems
to distributed Web-based application and even to hard real time embedded systems. It is very
expressive language, addressing all the views needed to develop and then deploy such
systems.

Conceptual Model of UML:

To form a conceptual model of UML, there are three major elements:
1. UML’s basic building blocks.
2. Rules on how these building blocks may be put together.
3. Mechanisms that apply throughout UML.

1. Building Blocks of the UML:

The vocabulary of the UML encompasses three kinds of Building Blocks:

a) Things
b) Relationship
c) Diagrams

a) Things in UML:

There are four kinds of things in the UML:

i) Structural things.
ii) Behavioral things
iii) Grouping things
iv) Annotational things

i) Structural things:
Structural things are the nouns of UML models. These are the mostly static parts of a model,
representing elements that are either conceptual or physical. Collectively, the structural things
are called classifiers. Structural things are:

• class
• interface
• collaboration
• use case
• active class
• component
 www.gagnesharora.com

• artifact
• node

ii) Behavioral Things:

Behavioral things are the dynamic parts of UML models. These are the verbs of a model,
representing behavior over time and space. There are three primary kinds of behavioral
things, these are:

• interaction
• state machine
• activity

iii) Grouping Things:

Grouping things are the organizational parts of UML models. These are the boxes into which
a model can be decomposed. There is one primary kind of grouping thing, namely, packages.

iv) Annotational Things:

Annotational things are the explanatory parts of UML models. There is one primary kind of
annotational thing, called a note. A note is simply a symbol for rendering constraints and
comments attached to an element or a collection of elements.

b) Relationships in the UML:

There are four kinds of relationships in the UML:

i) Dependency
ii) Association
iii) Generalization
iv) Realization

c) Diagrams in the UML:

A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and paths (relationships). We draw diagrams to visualize
a system from different perspectives, so a diagram is a projection into a system. The UML
includes thirteen kinds of diagrams:

i. Class diagram
ii. Object diagram
iii. Component diagram
iv. Composite structure diagram
v. Use case diagram
vi. Sequence diagram
vii. Communication diagram
viii. State diagram
ix. Activity diagram
x. Deployment diagram
xi. Package diagram
xii. Timing diagram
xiii. Interaction overview diagram
 www.gagnesharora.com

2. Rules of the UML:

The UML’s building blocks cannot simply be thrown together in a random fashion. Like any
language, the UML has a number of rules that specify what a well-formed model should look
like. A well-formed model is one that is semantically self-consistent and in harmony with all
its related models.

The UML has syntactic and semantic rules for

 Name: What you can call things, relationship, and diagrams

 Scope: The context that give specific meaning to a name
 Visibility: How those names can be seen and used by others
 Integrity: How things properly and consistently relate to one other
 Execution: What it means to run or simulate a dynamic model

Models built during the development of a software-intensive system tend to evolve and may
be viewed by many stakeholders in different ways and at different times. For this reason, it is
common for the development team to not only build models that are well-formed, but also to
build models that are

 Elided: Certain elements are hidden to simplify the view

 Incomplete: Certain elements may be missing
 Inconsistent: The integrity of the model is not guaranteed

These less-than-well-formed models are unavoidable as the details of a system unfold and
churn during the software development life cycle. The rules of the UML encourage you-but
do not force you-to address the most important analysis, design, and implementation
questions that push such models well-formed over time.

3. Common Mechanism in the UML:

The UML is made simpler by the presence of four common mechanisms that apply
consistently throughout the language:

i. Specification
ii. Adornments
iii. Common division
iv. Extensibility mechanism