software engineering , its characteristic ,changing nature of software,evolving nature of software,legacy software,generic view of software,process flow ,umbrella activity,CMMI,PROCESS ASSESSMENT ,team and personal software process

1. Text Books:
1.Software Engineering, A practitioner’s approach Roger s.
Pressman 6th edition McGraw-Hill
2.Software Engineering Somerville 7th edition
1
Software Engineering

2. Module I (12 Hrs)
The Evolving role of Software – Software – The changing Nature
of Software – Legacy software ,Introduction to CASE tools, A
generic view of process– A layered Technology – A Process
Framework – The Capability Maturity Model Integration
(CMMI) – Process Assessment – Personaland Team Process
Models. Product and Process. Process Models – The Waterfall
Model –Incremental Process Models – Incremental Model –
The RAD Model – Evolutionary Process Models– Prototyping
– The Spiral Model – The Concurrent Development Model –
Specialized Process Models – the Unified Process.
2

3. Software is defined as
1. Instructions
- Programs that when executed provide desired functionality
and performance
2. Data structures
-Enable the programs to adequately manipulate information
3. Documents
-Describe the operation and use of the programs.
eg: User Manual ,Device Manual
3

4. • Software is developed or engineered, it is not manufactured
in the classical sense.
• Software does not wear out. However it deteriorates due to
change.
• Software is custom built rather than assembling existing
components.
-Although the industry is moving towards component based
construction, most software continues to be custom built
4
Characteristics of software compared with hardware

5. 5

6. 6

7. 7

8. CHARACTERISTICS OF HARDWARE
Failurerate
Time
“Infant
mortality” “Wear out”
Fig: FAILURE CURVE FOR HARDWARE
8

9. CHARACTERISTICS OF SOFTWARE
Fig: FAILURE CURVE FOR SOFTWARE
9

10. THE CHANGING NATURE OF SOFTWARE
 System software
 Application software
 Engineering and scientific software
 Embedded software
 Product-line software
 Web-applications
 Artificial intelligence software
 Real time software
10

11. 1System software
System software is a collection of programs written to service
other programs
System software is computer software designed to operate the
computer hardware, to provide basic functionality, and to
provide a platform for running application software
11

12. 2Application software
An application is a job or task a user wants to accomplish
through a computer.
Application software are programs that help a user perform a
specific job.
12

13. 13

14. 3 Embedded software
14

15. 4 Artificial intelligence software
• Software that is capable of intelligent
behavior.” In creating intelligent software, this
involves simulating a number of capabilities,
including reasoning, learning, problem solving,
perception, knowledge representation.
• makes use of nonnumeric algorithms to solve
complex
Flying drones
This flying drones use video cameras and sensors
to translate the environment into a 3D model
15

16. 5 Product-line software
16
A set of software-intensive system sharing a common,
managed set of features that satisfy the specific needs of
particular market segment or mission and that are developed
from a common set of core assets in a prescribed way

17. 6 Engineering and scientific
software
Category of software used to facilitate the engineering
functions and tasks.
-characterized by "number crunching" Algorithms
Computer Aided Design (CAD) programs and
applications that help an engineer in drawing and (in
some cases) test the properties of a drafted part.
17

18. 7 Web-applications
• Web-based software is software you use over
the internet with a web browser. You don't have
to install any CDs, download any software, or
worry about upgrades.
• Eg online bank or web based
email program like Gmail, Hotmail, or Yahoo
Mail then you've already used web-based
software
18

19. 8 Real time software
• Software that monitors /analyze/controls
real world events
• Hard real time
• Soft real time
19

20. Evolving role of software
1. Product (stand alone)
Information transformer-Modify display or
transmitting
2. Vehicle (interface using which we can
develop our own software)
(environment to develop new s/w)
20

21. 21
• Software is a product
– Delivers computing potential
– Produces, manages, acquires, modifies, displays, or
transmits information
• Software is a vehicle for delivering a
product
– Supports or directly provides system functionality
– Controls other programs (e.g., an operating system)
– Effects communications (e.g., networking software)
– Helps build other software (e.g., software tools)

22. Software Evolution
• Software evolves due to changes
• Changes occur due to correction,adaption and
enhancement
• 8 Laws of unified theory
 The Law of Continuing Change.
 The Law of Increasing Complexity.
 The Law of Self-Regulation
 The Law of Conservation of Organizational Stability.
 The Law of Conservation of Familiarity
 The Law of Continuing Growth
 The Law of Declining Quality
 The Feedback System Law 22

23. 23
Oh
my
God

24. LEGACY SOFTWARE
• Legacy software are older programs that are developed
decades ago
– quality of legacy software is poor
• inextensible design , convoluted code
• poor and nonexistent documentation,
• test cases and results that are not achieved.
24

25. 25

26. Legacy systems evolve due to following reasons:
The software must be adapted to meet the needs of new
computing environment or technology.
The software must be enhanced to implement new
business requirements.
The software must be extended to make it interoperable
with more modern systems or database
The software must be re-architected to make it viable
within a network environment.
26

27. • Definition of Engineering
-Application of science, tools and methods to
find cost effective solution to problems
27

28. 28

29. 29

30. • High rate of change of user requirements and environment on
which software is working
• Large software
• Cost
• Quality managment
• Scalability etc
30

31. 31

33. 33

34. • An activity
– strives to achieve a broad objective and
– applied regardless of the application domain
and size of the project
• An action
– encompasses a set of tasks that produce a
major work product
– (e.g., architectural design)
• A task
– focuses on a small, but well-defined objective
that produces a tangible outcome
– (e.g., conducting a unit test
34

35. SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY
35
Model

36. SOFTWARE ENGINEERING-A LAYERED TECHNOLOGY
• Quality focus
- Bedrock that supports software Engineering
eg :Total quality management, Six Sigma
• Process Model
– Foundation for software Engineering
– The software process forms the basis for management
control of software projects and
– establishes the context in which technical methods are
applied,
– work products are produced,
– milestones are established,
– quality is ensured, and
– change is properly managed. 36

37. • Methods
- Provide technical How-to’s for building software
– Methods encompass a broad array of tasks that include
communication,
– requirements analysis,
– design modeling,
– program construction,
– testing, and
– support.
• Tools
- Provide semi-automatic and automatic support for
process and methods
37

38. A Generic View of Software
Engineering
The work associated with software engineering can be
categorized into three generic phases
• The definition phase focuses on what
• The development phase focuses on how
• The support phase focuses on change associated with
– correction,
– adaptation,
– enhancement, and
– prevention
38

39. 39

40. Definition Phase –
The definition phase focuses on “what” ‐
• The key requirements of the system and the software are identified.
• what information is to be processed
• what function and performance are desired
• what system behavior can be expected
• what interfaces are to be established
• what design constraints exist
• what validation criteria are required to define a successful system.
• Three major tasks will occur :
• system or information engineering,
• software project planning and requirements analysis
40

41. Development Phase
• The development phase focuses on “how”.
• How data are to be structured
• How function is to be implemented within a software architecture,
• How procedural details are to be implemented
• How interfaces are to be characterized
• How the design will be translated into a programming language and
• how testing will be performed.
•Three specific technical tasks will always occur in this phase:
• software design,
• code generation and
• software testing
41

42. Support phase
• Focuses on change
Reapplies the steps of the definition and devel
opment phases but does so in the context of ex
isting software.
• Four types of change are encountered during th
e support phase:
– Adaptation
– Correction
– Prevention
– Adaptation 42

43. • Correction
Even with the best quality assurance activities,
it is likely that the customer will uncover defe
cts in the software.
Corrective maintenance changes the software t
o correct defects.
43

44. • Adaptation
Over time, the original environment (e.g., CPU
, operating system, business rules, external pro
duct characteristics) for which the software w
as developed is likely to change.
Adaptive maintenance results in modification t
o the software to accommodate changes to its
external environment.
44

45. • Enhancement
•As software is used, the customer/user will rec
ognize additional functions that will provide be
nefit.
•Perfective maintenance extends the software b
eyond its original functional requirements
45

46. • Prevention
Computer software deteriorates due to change,
and because of this, preventive maintenance, o
ften called software reengineering, must be co
nducted to enable the software to serve the nee
ds of its end users.
Preventive maintenance makes changes to co
mputer programs so that they can be more easi
ly corrected, adapted, and enhanced
46

47. process flow
• Describes how the framework activities and the actions and
tasks that occur within each framework activity are organized
with respect to sequence and time
– A linear process flow executes each of the five framework
activities in sequence, beginning with communication and
culminating with deployment
47

48. • An iterative process flow repeats one or more of the activities
before proceeding to the next
48

49. • An evolutionary process flow executes the activities in a
“circular”manner.
• Each circuit through the five activities leads to a more
complete version of the software
49

50. • A parallel process flow executes one or more activities in
parallel with other activities (e.g., modeling for one aspect of
the software might be executed in parallel with construction of
another aspect of the software).
50

51. 51

52. Software Process Framework:
A process framework establishes the foundation for a
complete software process by
• identifying a small number of framework activities
that are applicable to all software projects, regardless
of size or complexity.
• It also includes a set of umbrella activities that are
applicable across the entire software process.
52

53. 53

54. 54

55. 1.Communication
2.Planning
3.Modeling
– Analysis of requirements
– Design
4.Construction
– Code generation
– Testing
5.Deployment
– Delivery
– Feedback
55

56. • Communication
– Heavy Communication and collaboration with customer
– Encompasses requirement gathering and other related
activity
56

57. 57
Planning
Establishes plan for software engineering work
It describe the technical task to be conducted
Risk that are likely to occur and the resource requirement
The work product to be produce and work schedule

58. • Modeling
– encompasses the creation of model that allow the
developer and customer to better understand software
requirement
– The deign that will achieve those requirement
58

59. • Construction
– code generation
– Testing required to un cover error in a code
• Deployment
– The software is delivered to customer
– Customers evaluate and give feedback based on evaluation
59

60. Umbrella Activities
1. S/W project tracking and control:
2. Risk Management:
3. Software quality assurance:
4. Formal Technical Review:
5. Measurement:
6. Software configuration management:
7. Reusability management:
8. Work product preparation and production
60

61. • Software project tracking and control—
– allows the software team to assess progress against the project plan
– take any necessary action to maintain the schedule.
61

62. • Risk management—
– assesses risks that may affect the outcome of the
project or the quality of the product.
• Steps
– Risk identification
– Risk prioritization
– Risk treatment
62

63. • Software quality assurance—defines and conducts the
activities required to ensure software quality.
• Technical reviews—assesses software engineering work
products in an effort to uncover and remove errors before they
are propagated to the next activity.
63

64. • Measurement—
– defines and collects process, project, and product
measures that assist the team in delivering
software that meets stakeholders’ needs; can be
used in conjunction with all other framework and
umbrella activities.
• Software configuration management—
– manages the effects of change throughout the
software process.
64

65. • Reusability management—
– defines criteria for work product reuse (including
software components) and establishes mechanisms
to achieve reusable components.
• Work product preparation and production—
– encompasses the activities required to create work
products such as models, documents, logs,
forms,and lists.
65

67. CAPABILITY MATURITY MODEL INTEGRATION
(CMMI)
• Developed by SEI(Software Engineering institute)
• CMMI process meta model that defines the process
characteristics that should exist if an organization wants to
establish a software process that is complete
• CMMI can be represented in different ways
1.A continuous model
2.A staged model
67

68. 68
Focus of CMMI
SW-CMM is applied here
CMMI is applied here

69. 69
Bridging the Divide
CMMI:
•Integrates systems and
software disciplines into
one process
improvement
framework.
•Provides a framework
for introducing new
disciplines as needs
arise.

70. 70
Staged Representation
• Provides a proven sequence of improvements, each serving
as a foundation for the next
• Permits comparisons across and among organizations by the
use of maturity levels
Indicates maturity of an organization’s
standard process -- to answer
“What is a good order for approaching
improvement across the organization?”

71. 71

72. 72
Maturity Levels
• A maturity level is a well-defined evolutionary
plateau of process improvement.
• There are five maturity levels.
• Each level is a layer in the foundation for continuous
process improvement using a proven sequence of
improvements, beginning with basic management
practices and progressing through a predefined and
proven path of successive levels.

73. 73
The Maturity Levels
1
2
3
4
5
Process unpredictable,
poorly controlled, and
reactive
Process characterized for
projects and is often
reactive
Process characterized
for the organization and
is proactive
Process measured
and controlled
Focus on continuous
process improvement
Optimizing
Quantitatively
Managed
Defined
Initial
Managed
Optimizing
Defined

74. Maturity levels
LEVEL FOCUS PROCESS AREA
Optimizing Continuous process
Improvement
-Organizational Innovation and
Deployment
-Causal Analysis and Resolution
Quantitatively
managed
Quantitative
management
-Organizational process performance
-Quantitative project management
Defined Process standardized Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Risk Management 74

75. −Integrated Teaming
−Integrated Supplier
Management
−Decision Analysis and
Resolution
−Organizational
Environment for Integration
Managed Basic project management Requirements Management
Project Planning
Project Monitoring and
Control
Supplier Agreement
Measurement and Analysis
Process and Product
Quality Assurance
Configuration Management
Performed
75

76. Continuous model:
• Lets organization select specific improvement that
best meet its business objectives and minimize risk
• Levels are called capability levels.
• Describes a process in 2 dimensions
• Each process area is assessed against specific goals
and practices and is rated according to the following
capability levels.
76

77. 77
Continuous Representation
• Allows you to select the order of improvement that best meets
your organization’s business objectives and mitigates your
organization’s areas of risk
• Enables comparisons across and among organizations on a
process-area-by-process-area basis
• Provides an easy migration from other models with a
continuous representation to CMMI
Indicates improvement within a single
process area -- to answer,
“What is a good order for approaching
improvement of this process area?”

78. 78

79. 79
Capability Levels
• A capability level is a well-defined evolutionary plateau
describing the organization’s capability relative to a
process area.
• There are six capability levels.
• For capability levels 1-5, there is an associated generic
goal.
• Each level is a layer in the foundation for continuous
process improvement.
• Thus, capability levels are cumulative, i.e., a higher
capability level includes the attributes of the lower
levels.

80. 80
The Capability Levels
5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
1 Performed
0 Incomplete

81. 81
Model Components
• Process Areas (PA)
– Specific Goals (SG) Required
• Specific Practices (SP) Expected
– Typical Work Products Informative
– Sub-practices Informative
– Notes Informative
– Discipline Amplifications Informative
– References Informative
– Generic Goals (GG) Required
• Generic Practices (GP) Expected
– Generic Practice Elaborations Informative

82. CMMI- capability levels
• INCOMPLETE
-Process is adhoc.Objective and goal of process areas are not
known
• Performed
-Goal,objective,work tasks,work products and other activities
of software process are carried out
• Managed
-Activities are monitored, reviewed, evaluated and controlled
• Defined
-Activities are standardized, integrated and documented
82

83. • Quantitatively Managed
-Metrics and indicators are available to measure the process
and quality
- Defect Prevention
• Optimized
- Continuous process improvement based on quantitative feed
back from the user
-Use of innovative ideas and techniques, statistical quality
control and other methods for process improvement.
83

84. SW-CMM V1.1 vs. CMMI V1.1
Defect Prevention Causal Analysis and Resolution
Technology Change Mgmt Organizational Innovation & Deployment
Process Change Management
Quantitative Process Mgmt Organizational Process Performance
Software Quality Mgmt Quantitative Project Management
Organization Process Focus Organization Process Focus
Organization Process Definition Organization Process Definition
Training Program Organizational Training
Integrated Software Mgmt Integrated Project Management
Risk Management
Software Product Engr Requirements Development
Technical Solution
Product Integration
Intergroup Coordination Verification
Peer Reviews Validation
Decision Analysis and Resolution
Requirements Management Requirements Management
Software Project Planning Project Planning
Software Project Tracking & Oversight Project Monitoring and Control
Software Subcontract Mgmt Supplier Agreement Management
Software Quality Assurance Product & Process Quality Assurance
Software Configuration Mgmt Configuration Management
Measurement and Analysis
LEVEL 5
OPTIMIZING
LEVEL 4
MANAGED
LEVEL 3
DEFINED
LEVEL 2
REPEATABLE
84
Key Process Areas (KPAs) Process Areas (PAs)

85. PROCESS ASSESSMENT
• Does not specify the quality of the software or whether the
software will be delivered on time or will it stand up to the
user requirements.
• It attempts to keep a check on the current state of the software
process with the intention of improving it.
85

86. 86

87. 87
Initiation
Preparation
Assessment
Analysis
and
Reporting
Closure

88. APPROACHES TO SOFTWRE ASSESSMENT
• Standard CMMI assessment (SCAMPI)
• CMM based appraisal for internal process improvement
• SPICE(ISO/IEC 15504)
• ISO 9001:2000 for software
• Refer PROCESS ASSESSMENT.ppt
• ProcessAssessmentMethod.ppt
• process_assmnt.docx
88

89. • Standard CMMI Assessment Method for
Process Improvement (SCAMPI)
—provides a five-step process assessment
model that incorporates five phases:
1. initiating,
2. diagnosing,
3. establishing,
4. acting, and
5. learning.
The SCAMPI method uses the SEI CMMI as the
basis for assessment
89

90. • CMM-Based Appraisal for Internal Process
Improvement (CBA IPI)—
provides a diagnostic technique for assessing
the relative maturity of a software
organization; uses the SEI CMM as the basis
for the assessment
90

91. • SPICE (ISO/IEC15504)—
A standard that defines a set of requirements for
software process assessment. The intent of the
standard is to assist organizations in
developing an objective evaluation of the
efficacy of any defined software process
91

92. Personal and Team Software Process
• Personal software process
 PLANNING
 HIGH LEVEL DESIGN
 HIGH LEVEL DESIGN REVIEW
 DEVELOPMENT
 POSTMORTEM
92

93. Team Software Process
93

94. • TSP defines the following framework
activities:
1.project launch,
2.high-level design,
3.implementation,
4.integration and test, and
5.postmortem.
94

95. CLASSICAL WATERFALL
MODEL
95
Communication
Planning
Modeling
Construction
Deployment
analysis
design
code
test
project init iat ion
requirement gat hering estimating
scheduling
tracking
delivery
support
f eedback
By Royce:

96. 96
Sl
no
advantages disadvantages When to use
1 It allows for
departmentalization and
managerial control.
it assumes that no development error is ever
committed by the engineers during any of the life
cycle phases. However, in practical development
environments, the engineers do commit a large
number of errors in almost every phase of the life
cycle
Requirements are
well understood
2 Simple and easy to
understand and use
It is difficult for customer to state all requirements
explicitly(without any change)
Automation of
existing manual
system
3 Phases are processed and
completed one at a time.
Working version of software will not be available
until late in project span
Short duration
project
4 Works well for smaller
projects where requirements
are very well understood.
User feedback not encouraged
Not a good model for complex and object-oriented
projects.
5 A schedule can be set with
deadlines for each stage of
development and a product
can proceed through the
development process like a
car in a car-wash, and
theoretically, be delivered
on time.
. Once a defect is detected, the engineers need to go
back to the phase where the defect had occurred
and redo some of the work done during that phase
and the subsequent phases to correct the defect and
its effect on the later phases

97. • Incremental Process Models
• The Incremental Model
• The RAD Model
97

98. 98

99. 99
5
advantages disadvantages When to use
1 Generates working
software quickly and
early during the software
life cycle.
Needs good planning and
design.
when the requirements of the
complete system are clearly
defined and understood.
2 Lowers initial delivery
cost.
Total cost is higher
than waterfall.
A new technology is being used
3 Easier to manage risk
because risky pieces are
identified and handled
during individual
iteration.
Needs a clear and complete
definition of the whole system
before it can be broken down
and built incrementally.
Staffing is not available for
complete implementation of
project
4 It is easier to test and
debug during a smaller
iteration.
In this model customer
can respond to each built.
There are some high risk features
and goals.
5 This model is more
flexible – less costly to
change scope and
requirements.

100. 100
Communication
Planning
Modeling
business modeling
dat a modeling
process modeling
Construction
component reuse
aut omat ic code
generat ion
t est ing
Deployment
60 - 90 days
Team # 1
Modeling
business modeling
dat a modeling
process modeling
Construction
component reuse
aut omat ic code
generat ion
t est ing
Mo d e lin g
business modeling
data modeling
process modeling
Co n st ru ct io n
component reuse
automatic code
generation
testing
Team # 2
Team # n
int egrat ion
delivery
feedback
RAD

101. 101
Sl advantages disadvantages When to use
1 Progress can be measured.
Iteration time can be short with use of powerful
RAD tools.
Dependency on technically strong team members for
identifying business requirements.
Sufficient human recourse is needed to create right no of
RAD team
Suitable for
project requiring
shorter
development
times.
2 Integration from very beginning solves a lot of
integration issues.
Only system that can be modularized can be built using
RAD.
Sufficient human recourse is needed to create right no of
RAD team
Requirements are
understood and
project scope is
constrained
3 Encourages customer feedback, Changing
requirements can be accommodated.
Requires highly skilled developers/designers.
High dependency on modeling skills.
Performances issue
Fully functional
system is to be
delivered in short
span of time
4 Reduced development time.
Increases reusability of components
Management complexity is more.
Suitable for systems that are component based and scalable
For large, but
scalable projects,
RAD requires
sufficient human
resources to
create the right
number of RAD
teams.
5 Productivity with fewer people in short time. Requires user involvement throughout the life cycle.
Inapplicable to cheaper projects as cost of modeling and
automated code generation is very high

102. • Evolutionary Process Model
• Prototype
• Spiral model
• incremental
102

103. Prototype
103

104. Prototype
104
Communicat ion
Quick plan
Const ruct ion
of
prot ot ype
Mode ling
Quick de sign
Delivery
& Feedback
Deployment

105. 105
Sl advantages disadvantages When to use
1 Provides a working model to the user
early in the process, enabling early
assessment and increasing user's
confidence.
If the user is not satisfied by the developed
prototype, then a new prototype is
developed. This process goes on until a
perfect prototype is developed. Thus, this
model is time consuming and expensive.
User
requirements
are not
complete
2 serves to clarify requirements, which
are not clear, hence reducing
ambiguity and improving
communication between the
developers and users.
The developer loses focus of the real
purpose of prototype and hence, may
compromise with the quality of the software.
For example, developers may use some
inefficient algorithms while developing the
prototype.
Technical
issues are not
clear
3 Helps in reducing risks associated
with the software.
Prototyping can lead to false expectations
“customer sees what appears to be a
working version of the Software”.
4 User feedback not encouraged The primary goal of prototyping is speedy
development, thus, the system design can
suffer as it is developed in series without
considering integration of all other
components
5 The developer gains experience and
insight by developing a prototype
there by resulting in better
implementation of requirements.

106. Spiral model:Invented by Dr. Barry Boehm
106
communication
planning
modeling
construction
deployment
delivery
feedback
start
analysis
design
code
test
estimation
scheduling
risk analysis

107. 107
Sl advantages disadvantages When to use
1 Avoids the problems resulting in
risk-driven approach in the
software
Re-evaluation after each step
allows changes in user
perspectives, technology advances,
or financial perspectives.
Assessment of project risks and its
resolution is not an easy task.
Spiral may go indefinitely
End of project may not be
known early
suitable for
development of
technically
challenging
software products
that are prone to
several kinds of
risks
2 Specifies a mechanism for
software quality assurance
activities
Difficult to estimate budget and
schedule in the beginning as some
of the analysis is not done until the
design of the software is
developed.
Projects build on
untested
assumptions
3 Development can be divided into
smaller parts and more risky parts
can be developed earlier which
helps better risk management
It demands considerable risk
assessment expertise and relies on
this expertise for success
Is utilized by
complex and
dynamic projects
4 Allows for extensive use of
prototypes
If risks is not uncovered and
managed problems will surely
occur
5 Estimation of budget and schedule
gets realistic as the work
progresses.
Large number of intermediate
stages requires excessive
documentation.

108. Concurrent Development Model
108

109. 109
Under review
Baselined
Done
Under
revision
Await ing
changes
Under
development
none
Modeling act ivit y
represents the state
of a software engineering
activity or task

110. Specialized Process Models
1. Aspect-Oriented Software
Development
2. The Formal Methods Model
3. Component Based Development
110

111. Component Based Development
111
Commercial off-the-shelf (COTS) Software components, developed by
vendors who offer them as products, can be used when Software is to be
built

112. The component-based development model incorporates
the following steps:
1. Available component-based products are researched
and evaluated for the application domain in question.
2. Component integration issues are considered.
3. Software architecture is designed to accommodate the
components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper
functionality.
112

113. The Formal Methods Model
• "Formal Methods" refers to mathematically
rigorous techniques and tools for the
specification, design and verification of
software and hardware systems.
• The phrase "mathematically rigorous" means
that the specifications used in formal methods
are well-formed statements in a mathematical
logic and that the formal verifications are
rigorous deductions in that logic (i.e. each step
follows from a rule of inference and hence can
be checked by a mechanical process.)
113

114. • Formal methods comprise formal
specification using mathematics to specify the
desired properties of the system. Formal
specification is expressed in a language whose
syntax and semantics are formally defined.
• This language comprises a syntax that defines
specific notation used for specification
representation; semantic, which uses objects to
describe the system; and a set of
relations, which uses rules to indicate the
objects for satisfying the specification. 114

115. Aspect-Oriented Software
Development
115

116. 116
concern concern
concern
concern

117. Concerns : properties or areas of interests
1.High-level – security, QoS
2. Low-level – caching, buffering
3.Functional – features, business rules
4.Non Functional (systemic) –
synchronization, transaction management.
117

118. Why they are difficult to program?
1.Some concerns are neatly localized within
specific structural piece,
2.Others tend to scatter and cross multiple
elements.
118

119. “Crosscutting Concerns”
119
Program
Object 1
data
Object 2
data
Object 3
data
Object 4
data

120. • Aspect-Oriented Programming is designed
to handle crosscutting concerns by
providing a mechanism known as aspect
120

121. Unified Process
• A “use-case driven, architecture-centric,
iterative and incremental” software
process closely aligned with the Unified
Modeling Language (UML).
121

122. • The UP 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.”
122

123. Phases of the Unified Process
123
soft ware increment
Release
Incept ion
Elabor at ion
const r uct ion
t r ansit ion
pr oduct ion

124. 124
Inception Elaboration Construction Transition Production
UP Phases
Workflows
Requirements
Analysis
Design
Implementation
Test
Iterations #1 #2 #n-1 #n
Support

125. CASE Tools
• CASE tools are set of software application
programs, which are used to automate
SDLC activities.
• CASE tools are used by software project
managers, analysts and engineers to
develop software system.
125

126. Components of CASE Tools
126
• Central Repository
• CASE tools require a central repository, which
can serve as a source of common, integrated
and consistent information.
• Central repository is a central place of storage
where product specifications, requirement
documents, related reports and diagrams, other
useful information regarding management is
stored.
• Central repository also serves as data
dictionary.

127. • Upper Case Tools - Upper CASE tools are
used in planning, analysis and design stages of
SDLC.
• Lower Case Tools - Lower CASE tools are
used in implementation, testing and
maintenance.
• Integrated Case Tools - Integrated CASE
tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and
documentation. 127

128. 128