SOFTWARE
ENGINEERING
Books :-- BOOKS
1 . Software Engineering by Sommerville - Pearson
2. Software Engineering- a Practitioner Approach
by Rodger Pressman – Mc Graw Hill
3. Object Oriented approach of Software
Engineering by Jacobson
4. Software Engineering concepts and application by
Subhajit Datta
SOFTWARE
ENGINEERING
Books :-- BOOKS
1 . Software Engineering by Sommerville - Pearson
2. Software Engineering- a Practitioner Approach
by Rodger Pressman – Mc Graw Hill
3. Object Oriented approach of Software
Engineering by Jacobson
4. Software Engineering concepts and application by
Subhajit Datta
SOFTWARE
ENGINEERING
Books :-- BOOKS
1 . Software Engineering by Sommerville - Pearson
2. Software Engineering- a Practitioner Approach
by Rodger Pressman – Mc Graw Hill
3. Object Oriented approach of Software
Engineering by Jacobson
4. Software Engineering concepts and application by
Subhajit Datta
OBJECTIVES
v
To introduce software engineering
and to explain its importance
v
Key Concepts of Software
engineering
v
To introduce ethical and professional
issues and to explain why they are of
HISTORY OF SOFTWARE
ENGINEERING
NOTION OF SOFTWARE ENGINEERING:
Ø
The notion “Software Engineering” was
proposed in 1969 at a NATO conference
to discuss software development
problems which is also known as the
“Software Crises”-
●
Late delivery
●
Did not incorporate the required
functionality
●
Cost more than expected
●
Were not reliable
PROGRESS OF SOFTWARE
ENGINEERING
Software engineering has made
remarkable progress in last 40 years with
the coming up of :
Ø
New techniques such as structured and
object oriented programming
Ø
Variety of software engineering
methodologies and software tools
Ø
Recent technologies for development and
deployment of large enterprise
applications
•
J2EE are:
•
.NET
•
Saas
•
SAP
SOFTWARE ENGINEERING
ACHIEVEMENTS
Ø
Controlling national utilities and
infrastructure-
Industrial Production
Financial sector
Energy,
Communications,
Entertainments and
Transport
WHAT IS A SOFTWARE
PRODUCT ?PROGRAMS +
SOFTWARE DOCUMENTATION +
OPERATING
PROCEDURES
1.) PROGRAM
-- It is a subset of software &
it becomes software only if
documentation and operating
SOFTWARE PRODUCT
Ø
Software products are divided in two categories:
1.) Generic Products : These products are
developed for anonymous customers. E.g.
infrastructure software like operating systems,
compliers, word processors, CASE tools etc.
2.) Customized Products : These products are
developed for a particular customer as per his
requirements.
WHAT IS SOFTWARE ENGINEERING ?
Ø Engineering discipline that is concerned with all aspects of
software production.
Engineering : Getting good quality product using systematic and
organised approach to their work & use appropriate tools and methods for
the development meeting the financial constraints and the resources
available.
Good quality product: maintainability, dependability and security,
efficiency, acceptability.
All aspect: It also include software project management and
developments of tools methods and theory
WHAT IS A SOFTWARE PROCESS
Ø It is a set of activities and ordering amongst them to reach the desired
software product. An efficient process is required to produce a good quality
product.
Ø Generic activities in all software processes are:
Specification - what the system should do & its
development constraints
Development - production of the software system
Validation - checking that the software is what the
customer wants
Evolution - changing the software in response to
changing demands
SOFTWARE PROCESS
Ø
A process model is an abstract representation of
the development process presented from a
specific perspective.
Ø
Examples of process perspectives are
Workflow perspective - sequence of activities
Data-flow perspective - information flow
Role/action perspective - who does what
Ø
Generic process models
Waterfall;
Ø
Computer science is concerned with theory and
fundamentals whereas
Ø
Software engineering is concerned with the
practicalities of developing and delivering useful
software.
Ø
Computer science theories are still insufficient to
COMPUTER SCIENCE
act as a complete underpinningVS for software
SOFTWARE ENGINEERING
engineering (unlike e.g. physics and electrical
engineering).
SOFTWARE ENGINEERING VS.
SYSTEM ENGINEERING:
Ø
System engineering is concerned with all
aspects of computer-based systems development
including hardware, software and process
engineering. whereas ;
Ø
Software engineering is part of this process
concerned with developing the software
infrastructure, control, applications and
databases in the system.
SOFTWARE COSTS
Ø
Software costs often dominate computer system
costs. The costs of software on a PC are often
greater than the hardware cost.
Ø
Software costs more to maintain than it does to
develop. For systems with a long life,
maintenance costs may be several times
development costs.
Ø
Software engineering is concerned with cost-
effective software development.
COST OF SOFTWARE ENGINEERING
Ø
Roughly 60% of costs are development costs,
40% are testing costs
Costs vary depending on the type of system being developed
& the requirements of system attributes such as performance
& system reliability.
Distribution of costs depends on the development model that
is used.
Ø
Measurements of Software:
Software measurement is done by-- Metrices
Product Metric, Process Metrics , Project Metrics
Product : size( LOC, Function point), reliability, efficiency
DIVERSITY OF APPLICATIONS
Ø
Stand-alone Applications
Eg.: CAD programs
Ø
Interactive Transaction-based Applications
Eg.: Web applications such as e-Commerce
applications
Ø
Embedded Control Systems
Eg.: Software in a mobile phone
Ø
Real Time Systems
Ø
Entertainment systems
Ø
Data Collection Systems
Eg.: Software interacts with sensors installed in
hostile environment like inside an engine.
KEY CHALLENGES
Ø
Development of new methods and technologies
•
Incorporate diversity of applications
•
Reduced delivery time
•
Develop quality software
•
Heterogeneity
Ø
The web has led to
•
Availability of software services
•
Possibility of developing highly
distributed
KEY CHALLENGES
Ø
Incorporate diversity of applications
Determine which software engineering methodology
is suitable for which application
Ø
Reduced delivery time
Due to business and social changes and economic
development, change the existing software with new
technology.
KEY CHALLENGES
Ø
Develop dependable and secure software
Software are now associated with all aspects of our life in
sectors like banking, transport, hospital, industrial
production. Malacious actor cannot attack our system and
information security is maintained.
Ø
Heterogeneity
Ø
Developing techniques for building software that can run
on
Ø
distributed system across network of computer and
VERY RECENT CHALLENGES
•
World is now faced with a new set of
challenges:
•
Climate change and extreme weather
•
Declining natural resources
•
Increasing world population to be fed and
housed
•
International terrorism
•
Need to help elderly people lead satisfying
•
Need
and for :
New software technologies to address these
fulfilled lives
problems
SOFTWARE COMPONENT
Ø
An independent deliverable piece of
functionality providing access to its
functionality through well defined interface .
– Deployable
– Replaceable
QUALITY CHARACTERISTICS
Qualities of Software /attribute of good Software:
1.) Representative (External):
Correctness
Reliability
Robustness
2.) Performance (Internal):
User-friendly, Verifiability Maintainability,
Repairability, Evolvability, Reusability,
Portability, Visibility Understandability,
ROLE OF MANAGEMENT IN
Ø
SOFTWARE
The management of software DEVELOPMENT
development is heavily
dependent on four factors : People, Product, Process, Project
1.) People: Software development requires good managers who can
understand the psychology of people & provide good leadership.
Manager selection is most crucial and critical for success of the
project. It is the responsibility of a manager to manage, motivate,
encourage , guide and control the people of his team.
2) Project: In order to manage a successful project, we must
understand what can go wrong and how to do it right. We should
define concrete requirements.
SOFTWARE ENGINEERING
METHODOLOGY
Ø
Methodology (Method) : Systematic way of
developing product using techniques, tools
and strategies and guideline. It consists of 4
tuple:
i. Model descriptions - Descriptions of graphical
models which should be produced.
ii. Model Constraint - Constraints applied to
system models such as completeness,
conformity, fidelity, consistency
iii. Set of steps - Set of activities that can follow
SOFTWARE ENGINEERING
METHODOLOGY
Methodologies can be defined for:
Ø
Entire life cycle
Ø
Partial life cycle
CASE-Computer Aided
Ø
These areSoftware
the software systems that are
Engineering
intended to provide automated support for
software process activities.
Ø
They are often used for method support.
Ø
They are of two types:
Upper CASE - Tools to support the early process
activities of requirements and design
Lower CASE - Tools to support later activities such
as programming, debugging and testing.
PROFESSIONAL AND ETHICAL
RESPONSIBILITY
Ø
Software engineering involves wider responsibilities than
simply the application of technical skills.
Ø
Software engineers must behave in an honest and ethically
responsible way if they are to be respected as professionals.
Ø
Ethical behaviour is more than simply upholding the law.
ISSUES OF PROFESSIONAL
Ø RESPONSIBILITY
Confidentiality: Maintain the confidentiality of your employers or
clients irrespective of whether or not a formal confidentiality
agreement has been signed.
Ø
Competence: Should not misrepresent competence and accept
work that is beyond your competence.
Ø
Intellectual Property Rights: Aware of local laws governing the
use of patents and copyright, protect IPR of client and employee.
Ø
Computer Misuse: Should not use your technical skills to misuse
other people’s computers. Computer misuse ranges from trivial to
ACM/ IEEE CODE OF ETHICS
Ø
TheEthical standards have been set up by
professional societies like ACM, IEEE, British
Computer Society.
Members of these organisations sign up to the code of
practice when they join.
The Code contains eighteen Principles related to the
behaviour of and decisions made by professional
software engineers, including practitioners, educators,
managers, supervisors and policy makers, as well as
trainees and students of the profession.
CODE OF ETHICS - PRINCIPLES
Ø
Public
Software engineers shall act consistently with
the public interest.
Ø
Client and Employer
Software engineers shall act in a manner that is
in the best interests of their client and employer
consistent with the public interest.
Ø
Product
CODE OF ETHICS - PRINCIPLES
Ø Judgment
Software engineers shall maintain integrity and independence in their professional
judgment.
Ø Management
Software engineering managers and leaders shall subscribe to and promote an
ethical approach to the management of software development and maintenance.
Ø Profession
Software engineers shall advance the integrity and reputation of the profession
consistent with the public interest.
CODE OF ETHICS - PRINCIPLES
Ø
Colleagues
Software engineers shall be fair to and supportive of their
colleagues.
Ø
Self
Software engineers shall participate in lifelong learning regarding
the practice of their profession and shall promote an ethical
approach to the practice of the profession.
ETHICAL DILEMMAS
Ø
Disagreement in principle with the policies of senior
management.
Ø
Your employer acts in an unethical way and releases a safety-
critical system without finishing the testing of the system.
Ø
Participation in the development of military weapons systems
or nuclear systems.
SOFTWARE ENGINEERING
PROCESS MODEL
SOFTWARE ENGINEERING
DEVELOPMENT ACTIVITIES
1. Requirement analysis & specification
2. Software Design
3. Coding
4. Integration /Testing
5. Installation
6. Delivery & maintenance
SED ACTIVITIES
1) Requirement Analysis and specifications
Identify & document exact requirement of the system,
study is performed by customer, developer &
marketing organization.
Much integration is required between user & developer
Software methodology to perform this.
SED ACTIVITIES
2) System Design:
●
Architectural design or high level design
●
Overall module structure and organization
●
Software detailed design
●
Design each module in detail.
SED ACTIVITIES
3) Coding: Producing the actual code that is
deliverable to customer.
4) Integration /Testing: All the model that were
developed individually are tested & then
integrated as a whole system & then system is
tested.
5) Installation: System is installed at customer site.
6) Delivery & maintenance : Any modification
PROCESS MODELS
Ø
A development process is:
set of activities + ordering among them
to reach the desired product
Ø
Desired Product
•
Conceptual schema
•
Logical schema
•
Data flow diagram
•
Modular structure of programs
Ø
Process model
An abstract representation of the development
process
presented from a specific perspective
WHY PROCESS MODELS?
Ø
Management Viewpoint
Control the progress of projects
Identify milestones and stages
Monitor the project
Identify problem points
Reschedule the project when needed
Cost, time, and manpower estimates
WHY PROCESS MODELS?
Ø
Technical Viewpoint
Develop the product and display its structure
Verify the product
Improve the process
Document
Prototype
GENERIC PROCESS MODELS
Ø
Waterfall Model
Ø
Prototype model
Ø
Incremental Process Model
Ø
Evolutionary Process Model
Ø
Rapid application development model
Ø
Spiral model
WATERFALL MODEL
This model is named “waterfall model”
because its diagrammatic representation
resembles a cascade of waterfalls.
WATERFALL MODEL (Contd…)
Ø
Reinforces the notion of “define before
design” and
“design before code”.
Ø
Easy to understand.
Problems of waterfall model:
Ø
Real projects are not sequential
Ø
Customers cannot state requirements
completely at the start
•
Customer inability to articulate
•
Requirements may not be known
Ø
High lead times to deliver a working system
Ø
Incremental development not possible
WATERFALL MODEL (Contd…)
Ø High cost of undetected omission/error
Ø Customer dissatisfaction
No feel for what shall be obtained
Emphasis on “freezing’
Ø Evolution management is difficult
Reverse Engineering difficulties
Requirements modification difficulties
User sign-off necessary to proceed
Ø Heavily document driven
Ø Analyst may write poorly understood interfaces.
Ø Customer must have patience.
PROTOTYPING MODEL
1) Initial Requirements
2) Rapid design
3) Develop the prototype
4) Evaluation of prototype by customer
5) Refine requirements and go to step 2
Ø)
The prototype may be a usable program but is
not suitable as the final software product.
Ø)
The code for the prototype is thrown
away. However experience gathered helps in
developing the actual system.
Ø)
The development of a prototype might involve
extra cost, but overall cost might turnout to
be lower than that of an equivalent system
developed using the waterfall model.
INCREMENTAL MODEL
Ø
Combining linear Sequential Model to Prototyping Model
with actual product deliverables.
Ø
Effective in situations where requirements are defined precisely and
there is no confusion about the functionality of the final product.
Ø
The model releases the product with prioritized
requirements in the beginning.
Ø
Over the time new functionalities are added and existing
functionalities are enhanced.
Advantages:
Ø
It is useful when staff is unavailable or some hardware is
yet arriving.
Ø
User gets operational product early.
Ø
Cost is decreased( less manpower )
Ø
Testing is easy.
Disadvantages:
Ø
Co-ordination of various modules.
Ø
Project Planning & Coordination.
EVOLUTIONARY PROCESS MODEL
Ø
Resembles iterative enhancement model, but differs in the sense that
this does not require a useable product at the end of each cycle.
Ø
The same phases as defined for the waterfall model occur here in a
cyclical fashion.
Ø
Requirements are implemented by category rather than by priority.
Ø
Useful for projects using new technology that is not well understood.
Ø
Used for complex projects where all functionality must be delivered
at one time, but the requirements are not well understood at the
beginning.
EVOLUTIONARY PROCESS MODEL
THE RAPID APPLICATION
DEVELOPMENT (RAD) MODEL
Ø
Developed by IBM in 1980
Ø
User participation is essential
Ø
Build a rapid prototype
Ø
Give it to user for evaluation & obtain feedback
Ø
Prototype is refined
Ø
Reusable components are required to reduce development time.
Ø
Highly specialized & skilled developers are required
THE RAPID APPLICATION
DEVELOPMENT (RAD) MODEL
SPIRAL MODEL
§
Models do not deal with uncertainly which is
inherent to software projects.
Important software projects have failed because
§
project risks were neglected & nobody was
prepared when something unforeseen
happened.
§
Barry Boehm recognized this and tired to
incorporate the “project risk” factor into a life
cycle model.
The result is the spiral model, which was
§
presented in 1986.
SPIRAL MODEL
Process is represented as a spiral rather than as a
sequence of activities with backtracking.
Each loop in the spiral represents a phase in the
process.
No fixed phases such as specification or design -
loops in the spiral are chosen depending on what is
required.
Risks are explicitly assessed and resolved
throughout the process.
Spiral Model
SPIRAL MODEL
Ø
The radial dimension of
the model represents the
cumulative costs. Each
path around the spiral
is indicative of
SPIRAL MODEL (contd…)
•
An important feature
Each phase is completed with a review by
the people
concerned with the project (designers and
programmers)
•
Advantages
i. The wide range of options to accommodate the
good features
of other life cycle models.
Theii. spiral model has
It becomes some difficulties
equivalent to anotherthat
life need
cycle to
be resolved
model in before it can be a universally applied life
cycle model. appropriate situations.
§
Lack of explicit process guidance in determining objectives
§
Constraints
§
Alternatives
§
Depends on risk assessment expertise; and
§
Provides more flexibility than required for many
applications.
SELECTION OF LIFECYCLE
MODEL
The selection of the model is based on the
following characteristics:
Ø
Requirements characteristics
Ø
Experience of the development team
Ø
User involvement
Ø
Project type and associated risk
SELECTION OF MODEL FOR
REQUIREMENTS
REQUIREMENTS WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
ENHANCEMENT DEVELOPMENT
Are YES NO NO NO NO YES
requirements
easily
understandable
and defined?
Do we change NO YES NO NO YES NO
requirements
quite often?
Can we define YES NO YES YES NO YES
requirements
early in the
cycle?
Requirements NO YES YES YES YES NO
are indicating a
complex system
to be built
BASED ON STATUS OF DEVELOPMENT
TEAM
DEVELOPMENT TEAM WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
ENHANCEMENT DEVELOPMENT
Less experience NO YES NO NO YES NO
on similar
projects
Less domain YES NO YES YES YES NO
knowledge
Less experience YES NO NO NO YES NO
on tools to be
used
Availability of NO NO YES YES NO YES
training
required
BASED ON USER’s PARTICIPATION
INVOLVEMENT OF WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
USERS ENHANCEMENT DEVELOPMENT
Involved in all NO YES NO NO NO YES
phases
Limited phases YES NO YES YES YES NO
No previous NO YES YES YES YES NO
experience of
similar projects
Expert of NO YES YES YES NO YES
domain
TYPE OF PROJECT WITH ASSOCIATED
RISK
PROJECT TYPE AND RISK WATERFALL PROTOTYPE ITERATIVE EVOLUTIONARY SPIRAL RAD
ENHANCEMENT DEVELOPMENT
Enhancement of NO NO YES YES NO YES
the existing
system
Funding is YES YES NO NO NO YES
stable
High reliability NO NO YES YES YES NO
requirements
Tight project NO YES YES YES YES YES
schedule
Use of reusable NO YES NO NO YES YES
components
Resources(Time, NO YES NO NO YES NO
Money, people)
scarce
