Software Engineering

Unit – I

Introduction

Dr. S. Manikandan
HOD-IT

1
 What is Software?

• A set of instructions that direct a computer's hardware

to perform a particular task.

2
 Software Licensing

• A software license is a document that contains

directions and is legally binding on the use and
distribution of software. Typically, software
licenses provide consumers a right to one or more
software versions without breaking copyright.
• Terms and conditions for software licenses usually
include equal usage of the software, restrictions of
responsibility, guarantees, as well as disclaimers
and safeguards if the software or the use breaches
the intellectual property rights of anyone.

3
 Software Patents

• Software patents fall within the scope of an

intellectual property suite of protections, which give
the software owner exclusive rights to use the
protected program.

4
 Software Pattern

• In software development, a pattern (or

design pattern) is a written document
that describes a general solution to a
design problem that recurs repeatedly
in many projects.
• Design patterns are programming
language independent strategies for
solving a common problem. That means
a design pattern represents an idea, not
a particular implementation.
5
 Characteristics of a Software

• Functionality.
• Usability (User-friendly) ...
• Efficiency. ...
• Reliability. ...
• Maintainability. ...
• Portability. ...

6
 Categories of Software

• System Software (Compiler, Editor)

• Application Software
• Engineering/Scientific Software (CAM, Genetic Analysis)
• Embedded Software (Key board control for microwave
oven)
• Product line Software (Inventory control products)
• Web/Mobile Applications
• Artificial Intelligence Software (Robotics, Expert Systems)

7
 Changing nature of Software

Four broad categories of software are evolving to

dominate industry
• WebApps
• Mobile applications
• Cloud Computing
• Product line Software
(a set of software intensive systems that share a
common managed set of features satisfying the
specific needs of a particular market segment and
that are developed from a common set of core
assets)

8
 What is Software Engineering?

• Software is a program or set of programs containing

instructions that provide desired functionality.
• Engineering is the process of designing and building
something that serves a particular purpose and finds a
cost-effective solution to problems.

“Software Engineering is the

application of systematic, disciplined,
quantifiable approach to the design,
development, operation, and
maintenance of a software “
9
Software Engineering Layers

10
 Software Engineering Layers

• A quality focus: It is a culture that ultimately leads to

the development of software engineering. The bedrock
that supports software engineering, it says A quality
focus.
• Process: A process defines who is doing what, when
and how to reach a certain goal. The software process
forms the basis for management control of software
projects. It establishes the context in which technical
methods are applied for work products are produced.
Example: Models, Documents, Data, Reports, Forms,
etc.

11
 Software Engineering Layers

• Methods: Software Engineering methods provide the

technical “how to’s for building software“. Methods
encompass a broad array of tasks that include
communication, requirements analysis, design
modelling, program construction, testing and support.
• Tools: Software Engineering tools provide automated
or semi-automated support for the process and the
methods. When tools are integrated so that information
created by one tool can be used by another, a system
for the support of software development is
called Computer Aided Software Engineering.

12
 Software Process

• Software Process is a collection of activities,

actions and tasks that are performed when some
work product is to be created.

• Software Process Framework is the foundation of

complete software engineering process. Software
process framework includes set of all umbrella
activities. It also includes number of framework
activities that are applicable to all software projects.

13
Process framework encompasses five activities

• Communication:
In this activity, heavy communication with customers
and other stakeholders, as well as requirement
gathering is done.
• Planning:
In this activity, we discuss the technical related tasks,
work schedule, risks, required resources, etc.
• Modeling:
Modeling is about building representations of things in
the ‘real world’. In modeling activity, a product’s model
is created in order to better understand the
requirements.

14
• Construction:
In software engineering, construction is the application
of set of procedures that are needed to assemble the
product. In this activity, we generate the code and test
the product in order to make better product.
• 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 supply of better product.

15
 Umbrella activities

• Software project tracking and control

• Risk Management
• Software Quality Assurance (SQA)
• Technical Reviews
• Software Configuration Management (SCM)
• Measurement
• Reusability management
• Work product preparation and production

16
 Software Engineering Practice

The Essence of Practice

1. Understand the Problem
(Communication and Analysis)
2. Plan a solution (Modeling and
Software Design)
3. Carry out the plan (Code Generation)
4. Examine the result for accuracy
(Testing and Quality Assurance)

17
General Principles that focus on Software Engineering

First Principle : The Reason it All Exists

Second Principle : KISS (Keep it Simple, Stupid)
Third Principle : Maintain the Vision
Fourth Principle : What You Produce, Others Will
Consume
Fifth Principle : Be Open to the Future
Sixth Principle : Plan Ahead for Reuse
Seventh Principle: Think

18
 Software Development Myths

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.

19
 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 Engineering tools help the
computer, they are more important than hardware to
produce quality and productivity. 20
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.
21
 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. 22
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.

23
 Practitioners Myth
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.

24
Process Models

Generic Process Model:

• The Generic process model is an abstraction of
the software development process. It specifies the
stages and order of a process. Generic Process Model
will define the following:
i. The tasks to be performed.
ii. The input and output of each task.
iii. The pre and post conditions for each task.
iv. The flow and sequence of each task.

25
26
 Prescriptive Process Model
• The name 'prescriptive' is given because the model
prescribes a set of activities, actions, tasks, quality
assurance and change the mechanism for every project.
Prescriptive process models are sometimes referred to
as “Traditional Process Models”.

Types of prescriptive process models are:

1. The Waterfall Model

2. Incremental Process model
3. Evolutionary Process models
• Prototyping
• Spiral Model
4. Concurrent Models
27
Waterfall Model

28
• The waterfall model is also called as 'Linear
sequential model' or 'Classic life cycle model'.
• In this model, each phase is fully completed before the
beginning of the next phase.
• This model is used for the small projects.
• In this model, feedback is taken after each phase to
ensure that the project is on the right path.
• Testing part starts only after the development is
complete.

29
Advantages of waterfall model
• The waterfall model is simple and easy to understand,
implement, and use.
• All the requirements are known at the beginning of the
project, hence it is easy to manage.
• It avoids overlapping of phases because each phase is
completed at once.
• This model works for small projects because the
requirements are understood very well.
• This model is preferred for those projects where the
quality is more important as compared to the cost of
the project.

30
Disadvantages of the waterfall model
• Limited Flexibility: Difficult to accommodate
changes once development begins.
• Late Feedback: Stakeholder and user feedback
typically occur late in the process during testing,
leading to potential mismatches with expectations.
• High Risk: Higher risk of project failure if initial
requirements are misunderstood or change
significantly.

31
 Incremental Process Model

• The incremental model combines the elements of

waterfall model and they are applied in an iterative
fashion.
• The first increment in this model is generally a core
product.
• Each increment builds the product and submits it to the
customer for any suggested modifications.
• The next increment implements on the customer's
suggestions and add additional requirements in the
previous increment.
• This process is repeated until the product is finished.

32
33
Advantages of incremental model
• This model is flexible because the cost of development is
low and initial product delivery is faster.
• It is easier to test and debug during the smaller iteration.
• The customers can respond to its functionalities after every
increment.
Disadvantages of the incremental model
• The cost of the final product may cross the cost estimated
initially.
• The planning of design is required before the whole system
is broken into small increments.
• The demands of customer for the additional functionalities
after every increment causes problem during the system
architecture.
34
 Evolutionary Models – 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.

35
36
Advantages of Prototyping Model
• Prototype model need not know the detailed input,
output, processes, adaptability of operating system
and full machine interaction.
• In the development process of this model users are
actively involved.
• The development process is the best platform to
understand the system by the user.
• 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.

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

38
 Evolutionary Models – 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.

39
40
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.
• It is not used for small projects.

41
 Concurrent 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.
42
43
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.

44
 Comparison between all Prescriptive Models
Model Description Advantages Disadvantages
Sequential, linear approach to
software development.
Lack of flexibility, difficult to
Divided into distinct phases: Simple and easy to
Waterfall accommodate changes late in
Requirements, Design, understand.
the process.
Implementation, Testing,
Deployment, Maintenance.
Iterative model where a
preliminary version of the Incomplete or inadequate
Early feedback and validation
Prototype system is built, tested, and prototypes can mislead
of requirements.
refined repeatedly until it stakeholders.
meets the requirements.
Divides software development
into smaller, manageable Initial increments may not
chunks (increments) that are Allows partial implementation represent the final system
Incremental
developed and delivered and delivery of the system. architecture, potential
incrementally. Each increment integration issues.
builds upon the previous one.
Iterative model combining
elements of waterfall and
Complex management and
prototype models. Includes Good for projects with high-
Spiral evaluation process, may be
cycles of planning, risk risk factors.
costly and time-consuming.
assessment, engineering, and
evaluation of each iteration.
Also known as concurrent
development or parallel
Requires effective
development, involves
Accelerates development time coordination and
Concurrent overlapping phases where
by parallelizing tasks. communication between
multiple parts of the system
teams.
are developed simultaneously
by separate teams. 45
 Specialized Process Models

1. Component Based Development Model

• The component based development model
incorporates many of the characteristics of the spiral
model. It is evolutionary in nature, Specialized process
model demanding an iterative approach to the creation
of software.
• However, the component based development model
constructs applications from prepackaged software
components.
• Modeling and construction activities begin with the
identification of candidate components. These
components can be designed as either
conventional software modules or object oriented
classes or packages of classes.
46
Steps in Component based development model

• Available component based products are researched

and evaluated for the application
domain in question.
• Component integration issues are considered.
• A software architecture is designed to accommodate
the components.
• Components are integrated into the architecture.
• Comprehensive testing is conducted to ensure proper
functionality.

The component based development model leads to

software reuse, and reusability provides software
engineers with a number of measurable benefits.
47
 2. Formal Methods Model
• The formal methods model encompasses a set of
activities that leads to formal mathematical specification
of computer software.
• Formal methods enable you to specify, develop, and
verify a computer based system by applying a rigorous,
mathematical notation.
• A variation on this approach, called clean room software
engineering.
• Ambiguity, incompleteness, and inconsistency can
be discovered and corrected more easily, but through the
application of mathematical analysis.
• When formal methods are used during design, they serve
as a basis for program verification and therefore enable
you to discover and correct errors that might otherwise
go undetected. 48
Draw Backs:
• The development of formal models is currently quite
time consuming and expensive.
• Because few software developers have the
necessary background to apply formal methods,
extensive training is required.
• It is difficult to use the models as a communication
mechanism for Technically unsophisticated
customers.

49
 3. Aspect Oriented Software Development

• It is also referred as aspect-oriented

programming (AOP).
• It is a programming paradigm that aims to
increase modularity by allowing the separation
of cross-cutting concerns.
• It does so by adding behavior to existing code
(an advice) without modifying the code itself, instead
separately specifying which code is modified via a
"pointcut" specification, such as "log all function calls
when the function's name begins with 'set'".

50
 Unified Process Model

• A unified process is a software development process

that uses the UML language to represent models of the
software system to be developed. It is iterative,
architecture centric, use case driven and risk
confronting.
• The Unified Process recognizes the importance of
customer communication and streamlined methods for
describing the customer's view of a system.
• It emphasizes the important role of software
architecture and “helps the architect focus on the right
goals, such as understandability, reliance to future
changes, and reuse”.

51
Phases of Unified Process Model

52
Phase1: Inception
• Communication and planning are the main ones.
• Identifies the scope of the project using a use-case
model allowing managers to estimate costs and time
required.
• Customers’ requirements are identified and then it
becomes easy to make a plan for the project.
Phase2: Elaboration
• Planning and modeling are the main ones.
• A detailed evaluation and development plan is carried
out and diminishes the risks.

53
Phase3: Construction
• The project is developed and completed.
• System or source code is created and then testing is
done.
Phase4: Transition
• The final project is released to the public.
• Transit the project from development into production.
• Update project documentation.
Phase5: Production
• The final phase of the model.
• The project is maintained and updated
accordingly.
54
Advantages:
• It provides good documentation, it completes the
process in itself.
• It provides risk-management support.
• It reuses the components, and hence total time
duration is less.
• Good online support is available in the form of tutorials
and training.
Disadvantages:
• Team of expert professional is required, as the process
is complex.
• Complex and not properly organized process.

55
 Personal and Team Process Model

The Personal Software Process

• PSP emphasizes personal measurement of both the

work product that is produced and the resultant quality
of the work product.
• In addition PSP makes the practitioner responsible for
project planning and empowers the practitioner to
control the quality of all software work products that are
developed.

56
 Framework Activities of PSP
• Planning. This activity isolates requirements and
develops both size and resource estimates. In addition,
defects estimate (the number of defects projected for the
work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and
a project schedule is created.
• High level design. External specifications for each
component to be constructed are developed and a
component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
• High level design review. Formal verification methods
are applied to uncover errors in the design. Metrics are
maintained for all important tasks and work results.

57
• Development. The component level design is refined
and reviewed. Code is generated, reviewed, compiled,
and tested. Metrics are maintained for all important
tasks and work results.
• Postmortem. Using the measures and metrics
collected, the effectiveness of the process is
determined. Measures and metrics should provide
guidance for modifying the process to improve its
effectiveness.

58
 Team Software Process (TSP)

• The goal of TSP is to build a “self directed” project team

that organizes itself to produce high quality software.
Objectives for TSP:
• Build self directed teams that plan and track their work,
establish goals, and own their processes and plans. These
can be pure software teams or integrated product teams
(IPTs) of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams
and how to help them sustain peak performance
• Accelerate software process improvement by making
CMM23 Level 5 behavior normal and expected.
• Provide improvement guidance to high-maturity
organizations.
• Facilitate university teaching of industrial-grade team skills.59
 Agile Development

• Definition: Agile is an iterative and incremental

approach to software development where requirements
and solutions evolve through collaboration between
self-organizing cross-functional teams.

• Key Characteristics:
– Iterative and incremental
– Emphasizes flexibility and adaptability
– Customer-centric
– Values individuals and interactions over processes
and tools
– Responds to change over following a plan
60
 Agile Development

• Agile is a time-bound, iterative approach to software

delivery that builds software incrementally from the start
of the project, instead of trying to deliver all at once.
• Each iteration is considered as a short time "frame" in
the Agile process model, which typically lasts from 1 to 4
weeks.
• The division of the entire project into smaller parts helps
to minimize the project risk and to reduce the overall
project delivery time requirements. Each iteration
involves a team working through a full software
development life cycle including planning, requirements
analysis, design, coding, and testing before a working
product is demonstrated to the client.

61
Phases of Agile Model:
• Requirements gathering
• Design the requirements
• Construction/ iteration
• Testing/ Quality assurance
• Deployment
• Feedback

62
 Four Agile Values

• Individuals and interactions over

processes and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following
a plan

63
 Agility Principles
1. Satisfy the client through early and continuous delivery of
valuable computer software.
2. Changes in the requirements must be accommodated.
3. Deliver operating computer software often, within the
shorter time span deliver the working unit.
4. Business individuals and developers should work along
daily throughout the project.
5. Motivate the people who are building the projects.
6. Working software is the primary measure of the progress
of the software development
7. The agile approach promote the constant project
development

64
 Agility Principles

8. To enhance the agility there should be continuous

technical excellence.
9. Proper attention to be given to technical excellence and
good design
10. Simplicity must be maintained while developing the
project
11. The teams must be self-organizing team for getting
best architecture requirements and design
12. At regular intervals the team thinks over the issue of
becoming effective.

65
 Agile Methodologies

• Scrum: Iterative and incremental Agile framework for

managing product development.
– Roles: Product Owner, Scrum Master, Development
Team
– Events: Sprint, Sprint Planning, Daily Standup, Sprint
Review, Sprint Retrospective
– Artifacts: Product Backlog, Sprint Backlog, Increment
• Kanban: Visualizes work, limits work-in-progress, and
maximizes flow.
• Extreme Programming (XP): Emphasizes customer
satisfaction and quality through frequent releases.
• Lean Software Development: Minimizes waste while
maximizing value delivery.
66
 Extreme Programming

• Extreme programming (XP) is one of the most

important software development frameworks of Agile
models. It is used to improve software quality and
responsiveness to customer requirements.
• This type of methodology is used when customers are
constantly changing demands or requirements, or
when they are not sure about the system's
performance.

67
Extreme Programming Process

68
 Scrum
• SCRUM is an agile development process focused
primarily on ways to manage tasks in team-based
development conditions.
• There are three roles in it, and their responsibilities
are:
• Scrum Master: The scrum can set up the master
team, arrange the meeting and remove obstacles for
the process
• Product owner: The product owner makes the
product backlog, prioritizes the delay and is
responsible for the distribution of functionality on each
repetition.
• Scrum Team: The team manages its work and
organizes the work to complete the sprint or cycle.
69
• A sprint is a short, time-boxed period when a scrum
team works to complete a set amount of work.

70
 Principles of Framework Activity
Communication Principles
1)Listen carefully
2) Prepare before you communicate
3) Someone should facilitate the activity
4) Face-to-face communication is best
5) Take notes and document decision
6) Strive for collaboration
7) Stay focused, modularize your discussion
8) Draw a picture to clear your idea
9) Keep the discussion to “ move on ” :-
a) once there is an agreement to do something .
b) If you cannot agree to something.
c) If a feature of function is not clear
10) Negotiation is successful when both parties win 71
 Planning Principles

1) Understand the scope of project

2) Involve the customer in the planning activity
3) Recognize that planning is iterative
4) Estimate based on what you know
5) Consider risk as you define the plan
6) Be realistic
7) Define how you intend to ensure quality
8) Describe how you intend to accommodate change
9) Track the plan frequently and make adjustments as
required

72
 Modeling Principles

1: The primary goal of the software team is to build

software, not create models.
2: Travel light – don’t create more models than you need.
3: Strive to produce the simplest model that will describe
the problem of the software.
4: Build models in a way that makes them amenable to
change.
5: Be able to state an explicit purpose for each model that
is created.

73
6: Adapt the models you develop to the system at hand.
7: Try to build useful models, but forget about building
perfect models.
8: Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representation
is secondary.
9: If your instincts tell you a model isn’t right even though
it seems OK on paper, your probably have reason to be
concerned.
10: Get feedback as soon as you can

74
 Construction Principles

Coding Principles: Preparation

Principle 1: Understand the problem you’re trying to solve
Principle 2: Understand the basic design principles and
concepts
Principle 3: Pick a programming language that meets the
needs of the software to be built and the environment
in which it will operate
Principle 4: Select a programming environment that
provides tools that will make your work easier
Principle 5: Create a set of unit tests that will be applied
once the component you code is completed

75
Coding Principles: Programming
1: Constrain you algorithms by following structured
programming practice
2: Consider the use of pair programming
3: Select data structures that will meet the needs of the
design
4: Understand the software architecture and create interfaces
consistent with it
5: Keep conditional logic as simple as possible
6: Create nested loops in a way that makes them easily
testable
7: Follow coding standards
8: Write code that is self-documenting
9: Create a visual layout that aids understanding.
76
Coding Principles: Validation
Principle 1: Conduct a code walkthrough when
appropriate
Principle 2: Perform unit tests and correct errors you’ve
discovered
Principle 3: Refactor the code

77
 Testing Principles

• Principle 1: All tests should be traceable to customer

requirements.
• Principle 2: Tests should be planned long before
testing begins.
• Principle 3: The Pareto principle applies to software
testing.
• Principle 4: Testing should begin “in the small” and
progress toward testing “in the large”
• Principle 5: Exhaustive testing is not possible

78
 Deployment Principles

• Principle 1: Customer expectations for the software

must be managed.
• Principle 2: A complete delivery package should be
assembled and tested.
• Principle 3: A support regime must be established
before the software is delivered.
• Principle 4: Appropriate instructional materials must be
provided to the user.
• Principle 5: Buggy software should be fixed first,
delivered later.

79
 Part – A Questions
• Define software.
• List out the characteristics of software.
• Define a software pattern.
• Distinguish between personal software process and
team software process model.
• What are the advantages of Prototype model?
• Define Software Engineering
• List out the types of software?
• What are the disadvantages of water fall model?
• What is software development myth?
• What is software process? Give its importance

80
 Part – B Questions
• Construct a short note on spiral life cycle model with a
diagram
• Summarize about agile principles with suitable
example.
• Explain in detail about waterfall model with necessary
diagram
• Outline about Prototyping model along with example.
• Summarize about any two prescriptive process models
with advantages and disadvantages
• Explain in detail about Unified process model with
necessary diagram
• Discuss about the various principles of framework
activity.

81