Configuration management involves establishing and maintaining the integrity of software products throughout the software life cycle. It includes identifying configuration items, controlling changes, and recording and reporting change implementation status. The key activities of configuration management are configuration management planning, change management, version management, and system building. Configuration management aims to explain the importance of software configuration management and describe these main configuration management activities.

1. A Presentation on
“Software Engineering and
Project Management”
Course Code : IT-605
Presented by : MANOJ KUMAR SONI

2. SEPM…?
1. SOFTWARE : Collection of code/collection of
methods/collection of Objects in a sequencing
manner.
2. ENGINEERING : A technique or collection of
techniques for implementing something to achieve
desired goals.
3. PROJECT : A project is a temporary endeavor,
having a defined beginning and end undertaken to
meet unique goals and objectives.
 MANAGEMENT : Managing/Maintaining
something.

3. SOFTWARE ENGINEEERING
 Software Engineering Is the establishment and use
of Sound Engineering Principles in order to obtain
economically Software that is reliable & works
efficiently on real machines.
(or)
 Software Engineering is a systematic approach to
development, operation, maintenance and retirement
of software.

4. TOOLS
METHODS
PROCESS
A QUALITY FOCUS
FIG. : SOFTWARE ENGG. LAYERS

5. – A discipline whose aim is the production of
quality software, delivered on time, within
budget, and satisfying users' needs.
– The specification, development, management,
and evolution of software systems.
– Designing and developing high-quality
software

6. Software Applications :
 S system software
 s application software
 a engineering/scientific software
 e embedded software
 e product-line software
 p WebApps (Web applications)
 WAI software

9. Management of software projects is different
from other types of management because:
 Software is not tangible(clear enough).
 Software processes are relatively new and still
“under trial”
 Larger software projects are usually “one-off”
projects
 Computer technology evolves very rapidly.

10. MODELS
1. S/W PROCESS MODEL :
 Waterfall Model / Linear Sequential model /
Classic Life Cycle Model.
 Incremental Model
 RAD Model
2. EVOLUTIONARY PROCESS MODEL :
 Prototyping Model
 Spiral Model
 WIN WIN SPIRAL MODEL
 The Concurrent devlopment model

11. Waterfall Model / Linear Sequential
model / Classic Life Cycle Model.

12. Diagram
FIG: WATERFALL
MODEL

13. COMMUNICATION
PLANNING
MODELING
CONSTRUCTION
DEPLOYMENT
FIG: WATERFALL MODEL

14. Waterfall Model
 Requirements – defines needed
information, function, behavior,
performance and interfaces.
 Design – data structures, software
architecture, interface
representations, algorithmic
details.
 Implementation – source code,
database, user documentation,
testing.

15. Waterfall Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than cost
or schedule

17. When to use the Waterfall Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.

18. Incremental Model

21. Incremental Model
Communication
SOFTWARE FUNCTIONALITY & FEATURES
Increment # n
Planning
Modeling
Construction(Code, Test)
Deplyment(delivery, feeback)
Delivery of n th
increment
Increment # 02
Delivery of 2nd
increment
Increment # 01
Delivery of 1st
increment
PROJECT CALANDAR TIME

22. When the elements of waterfall model are
applied in iterative manner, the result is the
Incremental Model. In this, the product is
designed, implemented, integrated and
tested as incremental builds. This model is
more applicable where software
requirements are well defined and basic
software functionality is required early.

23. ADVANTAGES OF INCREMENTAL MODEL
- It generates working software quickly and
early during the software life cycle.
- Flexibility is more and less costly.
- Testing and debugging becomes easier
during a smaller iteration.
- Risk can be managed more easily because
they can be identified easily during iteration.
- Early increments can be implemented with
fewer people.

24. DISADVANTAGES OF INCREMENTALMODEL
- Each phase of an iteration is rigid (not
changed) and do not overlap each other.
- Problems may arise pertaining to system
architecture because not all requirements
are gathered up front for the entire software
life cycle.

25. RAD MODEL

29. RAD MODEL DEPLOYMENT
TEAM # N Integration,
Delivery, Feedback
MODELLING
Business, data &
process modeling
CONSTRUCTION
COMMUN TEAM # 2 Component reuse,
ICATION MODELLING Automatic code generation,
Business, data & Testing
PLAN process modeling
NING CONSTRUCTION
TEAM # 1 Component reuse,
MODELLING Automatic code generation,
Business, data & Testing
process modeling
CONSTRUCTION
Component reuse,
Automatic code generation,
Testing
60 to 90 Days

30. Advantages of the RAD methodology:
 Flexible and adaptable to changes.
 Prototyping applications gives users a tangible description
from which to judge whether critical system requirements
are being met by the system. Report output can be compared
with existing reports. Data entry forms can be reviewed for
completeness of all fields, navigation, data access (drop
down lists,checkboxes, radio buttons, etc.).
 RAD generally incorporates short development cycles -
users see the RAD product quickly.
 RAD involves user participation thereby increasing chances
of early user community acceptance.
 RAD realizes an overall reduction in project risk.
 Pareto's 80 - 20 Rule usually results in reducing the costs to
create a custom system.

31. Disadvantages of RAD methodology:
 Unknown cost of product. As mentioned above,
this problem can be alleviated by the customer
agreeing to a limited amount of rework in the RAD
process.
 It may be difficult for many important users to
commit the time required for success of the RAD
process.

32. PROTOTYPING MODEL

35. PROTOTYPING MODEL
QUICK PLAN
COMMUNICATION
MODELING
QUICK DESIGN
DEPLOYTMENT
DELIVERY &
FEEDBACK CONSTRUCTION
OF PROTOTYPE

38. Spiral Model

39. Since end-user requirements are hard to
obtain/define, it is natural to develop software
in an experimental way: e.g.
4. Build some software
5. See if it meets customer requirements
6. If no goto 1 else stop.

41. This loop approach gives rise to structured
iterative lifecycle models.
In 1988 Bohem developed the spiral model as
an iterative model which includes risk
analysis and risk management.
Key idea: on each iteration identify and solve
the sub-problems with the highest risk.

42. Spiral Model
PLANING
COMMUNICATION
MODELING
START
DEPLOYMENT
CONSTRUCTION

43. Cumulative cost Evaluate alternatives,
Determine objectives, Identify & resolve risks
alternatives & constraints
Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment Requirements Concept
Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Testing
End Acceptance
Plan next phase Develop & verify
Testing
next-level product

44. Each cycle follows a waterfall model by:
2. Determining objectives
3. Specifying constraints
4. Generating alternatives
5. Identifying risks
6. Resolving risks
7. Developing next-level product
8. Planning next cycle

45. Advantages
n Realism: the model accurately reflects the
iterative nature of software development on
projects with unclear requirements
n Flexible: incoporates the advantages of the
waterfal and rapid prototyping methods
n Comprehensive model decreases risk
n Good project visibility.

46. Disadvantages
 Needs technical expertise in risk analysis to
really work
 Model is poorly understood by non-technical
management, hence not so widely used
 Complicated model, needs competent
professional management. High administrative
overhead.

47. open source software

48. What is Open Source Software (OSS)
• OSS: software licensed to users with these freedoms:
– to run the program for any purpose,
– to study and modify the program, and
– to freely redistribute copies of either the original or
modified program (without royalties, etc.)
• Original term: “Free software” (confused with no-
price)
• Other synonyms: libre sw, free-libre sw, FOSS, FLOSS
• Antonyms(oposite word): proprietary software, closed
software
• Widely used; OSS #1 or #2 in many markets
• Not non-commercial; OSS almost always commercial

49. what is open source software?
 Open Source software is distributed with its source
code. The Open Source Definition has three
essential features:
 It allows free re-distribution of the software without
royalties or licensing fees to the author
 It requires that source code be distributed with the
software or otherwise made available for no more than
the cost of distribution
 It allows anyone to modify the software or derive other
software from it, and to redistribute the modified
software under the same terms.

50. Typical OSS development model
Improvements (as source code) and
Developer evaluation results: User as Developer
Development Trusted Bug Reports
Community
Developer
Trusted
Sou Repository
rc e Co
de → Distributor
“Stone soup development” User
• OSS users typically use software without paying licensing fees
• OSS users typically pay for training & support (competed)
• OSS users are responsible for paying/developing new improvements &
any evaluations that they need; often cooperate with others to do so
• Goal: Active development community (like a consortium)

51. examples of open source software
 Operating Systems
 Linux
 FreeBSD, OpenBSD, and NetBSD: The BSDs are
all based on the Berkeley Systems Distribution of
Unix, developed at the University of California,
Berkeley. Another BSD based open source project
is Darwin, which is the base of Apple's Mac OS X.

52. 
examples of open source software
Internet
 Apache, which runs over 50% of the world's web
servers.
 BIND, the software that provides the DNS (domain
name service) for the entire Internet.
 sendmail, the most important and widely used email
transport software on the Internet.
 Mozilla, the open source redesign of the Netscape
Browser
 OpenSSL is the standard for secure communication
(strong encryption) over the Internet.categories.

53. example of open source software
 Programming Tools
 Zope, and PHP, are popular engines behind the "live
content" on the World Wide Web.
 Languages:
 Perl
 Python
 Ruby
 Tcl/Tk

54. open source software sites
 Free Software Foundation www.fsf.org
 Open Source Initiative www.opensource.org
 Freshmeat.net
 SourceForge.net
 OSDir.com
 developer.BerliOS.de
 Bioinformatics.org
 see also individual project sites; e.g.,
www.apache.org; www.cpan.org; etc.

55. some dates from the history of open
source
 1970s: UNIX operating system developed at
Bell Labs and by a diverse group of
contributors outside of Bell Labs; later AT&T
enforces intellectual property rights and
“closes” the code
 1983: Richard Stallman founds the Free
Software Foundation
 1993: Linus Torvalds releases first version of
Linux built
 1997: Debian Free Software Guidelines
released

56. open source software development
Users Documenters Users
Bug reporters
Patchers
Maintainers
Core
developer(s)
Users Users

57. open source companies
 IBM
 uses and develops Apache and Linux; created Secure Mailer
and created other software on AlphaWorks
 Apple
 released core layers of Mac OS X Server as an open source
BSD operating system called Darwin; open sourcing the
QuickTime Streaming Server and the OpenPlay network
gaming toolkit
 HP
 uses and releases products running Linux
 Sun
 uses Linux; supports some open source development
efforts(Forte IDE for Java and the Mozilla web browser)

58. open source licensing
 see http://www.opensource.org/licenses/
 apache software license
 python license
 ibm public license
 apple public source license etc.

59. Unified Process

60. Unified Process
 Unified Process (UP) is an attempt to draw
on the best features and characteristics of
conventional Software process model.
 The UP recognizes the importance of
customer communication and streamlined
methods for describing the customer's view
of a system.

61. HISTORY
During the early 1990s James Rumbaugh, Grady
Booch and Iver Jacobson began working on a
“Unified Method” that would combines the
best features of each of their individuals
methods and adopt additional features
proposed by other experts. The result was
UML- “Unified Modeling Language” that
contains a robust notation for the modeling
and development of OO (Object Oriented)
systems.

62. UNIFIED PROCESS

65. Inception Elaboration
Transition Construction
UP Lifecycle – single phase workflow
(drawn as a UML Statechart!)

66. Unified Process
Product
Management Software Lifecycle
Environment * * releases
Workflow Cycle
Requirements
Inception
4
Design
Phase Elaboration
Implementation
Construction
*
Assessment Iteration
Transition
Deployment *
Artifact

67. Documentation

68. Documentation as part of the
software life cycle
Programming
Specifications Documentation Testing
Maintenance

69. What is Documentation
 Anything written or printed
 Relied on as a record of proof for authorized
persons
 Vital part of professional practice

70. A few questions to ask before writing
 Who will use the document?
 How will they use it?
 Does the documentation contain the
information to help the achieve their goals?

71. Some quality aspects of good
documentation
 concise
 complete
 up-to-date
 free of jargon
 well organized
 accurate
 consistent

72. Parts of a good user manual
 Table of contents (two levels if necessary)
 Conventions
 What’s new
 Content
 Appendix
 Index

73. Configuration management

74. What is a Configuration?
A configuration is the “functional and physical
characteristics of hardware or software” as set
forth in technical documentation or achieved in
a product.
What is SCM?
Software configuration management (SCM) is
responsible to establish and maintain the integrity of
the products of the software project throughout the
software life cycle.
This includes identifying configuration items,
controlling changes and recording and reporting the
change implementation status.

75. Configuration management
 Managing the products of system change
 Objectives:
 To explain the importance of software configuration
management (CM)
 To describe key CM activities namely CM planning,
change management, version management and system
building
 Topics covered:
 Configuration management planning
 Change management
 Version and release management
 System building

76. Configuration management – Why
 New versions of software systems are created as
they change
 For different machines/OS
 Offering different functionality
 Tailored for particular user requirements
 Configuration management is concerned with
managing evolving software systems
 System change is a team activity
 CM aims to control the costs and effort involved in
making changes to a system

77. Configuration management – Why
 Involves the development and application of
procedures and standards to manage an
evolving software product
 May be seen as part of a more general quality
management process
 When released to CM, software systems are
sometimes called baselines as they are a
starting point for further development

78. System families
PC Mainfram e
version version
VMS
version
Initial D EC Workstation
system version version
U nix
version
Sun
version

79. Configuration management planning
 Starts during the early phases of the project
 All products of the software process may have to
be managed
 Specifications
 Designs
 Programs
 Test data
 User manuals
 Thousands of separate documents may be
generated for a large software system

80. The CM plan
 Defines the types of documents to be managed and
a document naming scheme
 Defines who takes responsibility for the CM
procedures and creation of “baselines”
 Defines policies for change control and version
management
 Defines the CM records which must be maintained
 Describes the tools which should be used to assist
the CM process and any limitations on their use

81. Symptoms of poor CM
S Bugs that have been corrected reappear
B Previous releases of software cannot be rebuilt
P Previous releases of software cannot be found
P Files get lost
F Files are “mysteriously” changed
F The same or similar code exists multiple times
in different projects
i Two developers accidentally change the same
file concurrently

82. Configuration item identification
 Large projects typically produce thousands of
documents which must be uniquely identified
 Some of these documents must be maintained
for the lifetime of the software
 Document naming scheme should be defined
so that related documents have related names.
 A hierarchical scheme with multi-level names
is probably the most flexible approach

83. The configuration database
 All CM information should be maintained in a
configuration database
 This should allow queries about configurations
to be answered
 Who has a particular system version?
 What platform is required for a particular version?
 What versions are affected by a change to
component X?
 How many reported faults in version T?
 The CM database should preferably be linked
to the software being managed

84. Risk Management

85. What is Risk Management?
 The total process to identify, control, and
minimize the impact of uncertain events.
 In IT – we focus on availability, reliability,
maintainability & security
 In SE – we focus on quality & productivity
 One time, on budget & works
 Realistic expectations
 Critical, but not glamorous – Important but not
urgent

86. Risk Management in IT context
 Key business functions
 Procurement, stock control, payroll, etc.
 Key business systems
 ERP, CRM, Data Warehousing etc.
 Key business infrastructure
 Computer systems & communication networks
 Mission Critical Systems – high dependency

87. Risk Analysis Methods
 Identify potential source of risk
 Threats, vulnerabilities & breaches
 Quantification of consequences
 Financial & non financial losses
 Assessment of likelihood of occurring
 Annual loss expectation (ALE)
 Mitigation strategies
 Insurance, procedures, back-ups

88. Threats, Vulnerabilities & Breaches
 Threat
 Potential for an event to occur having
adverse consequences
 Vulnerability
 A weakness in a system which increases the
likelihood of a failure (e.g. security breach)
 Breach/Failure
 Exploitation of a vulnerability yielding
unauthorised access to a system or failure

89. Risk Identification
 Threats
 Natural disasters (fire, flood, lightning…)
 Infrastructure failures (blackouts, head crash,
communications outage…)
 Software defects (buffer overflows…)
 Government policies (ban on SPAM/Porn)
 Intruders & illegitimate use (hacking, sniffing…)
 Human limitation (user errors, staff shortages…)

90. Risk Identification
 Vulnerabilities
 Software defects (no audit trail, poor
documentation, poor version control, insufficient
testing…)
 Hardware failure (MTBFs)
 Design weakness (open protocols, spoofing…)
 Human behaviour (security awareness, social
engineering, recruitment procedures…)

91. Risk Identification
Example of Social Engineering

92. Risk Identification
 Breaches
 Michelangelo virus
 ‘I Love You’ virus
 ‘Good Times’ hoax
 Kevin Mitnick
 Failures
 Head crash
 Staff absence

93. Four Facets of Security
1. Confidentiality
 Access control, unobservability, Anonymity
2. Integrity
 Physical integrity, rollback, separation of duties
3. Availability
 Containment, robustness, recovery
4. Accountability
 Audit, id & authentication, trusted path…

94. Security Control Techniques
 Physical security
 Access control, intrusion detection, monitoring
 Logical security
 Accountability, least privilege, separation of powers,
default security, cryptography, audits
 Disaster Recovery Plans
 Id risks, assess impact, plan recovery, test
 Backup Strategies
 Loss tolerance, target data, media rotation, test

95. Questions?